home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / 6647 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  2.6 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!ucbvax!ludwig.sharebase.com!glenn
  2. From: glenn@ludwig.sharebase.com (Glenn Linderman)
  3. Newsgroups: comp.databases
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <9209091721.AA27050@ludwig.sharebase.com>
  6. Date: 9 Sep 92 17:21:01 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Lines: 52
  9.  
  10. -> From: dhepner@cup.hp.com (Dan Hepner)
  11. -> Subject: Re: Hot Standby DBMS's
  12.  
  13. -> From: dboyce@hemel.bull.co.uk (David Boyce)
  14.  
  15. -> >Interfaces for obtaining journal data from an RM and passing it to an
  16. -> >standby RM would be needed, as would RM-independent methods of recovery
  17. -> >and catch-up.  Not beyond the wit of man, I would have thought.
  18. -> >
  19. -> >Obviously the database vendors need to be convinced of the need to make
  20. -> >this interface available.
  21.  
  22.  
  23. -> Any ideas on how to convince them?  In particular, it needs to be
  24. -> shown what can be done using this scheme which the DB vendors
  25. -> could not do themselves.  Intuitively, one would say "but it's
  26. -> more open".  In what way does this openness benefit anyone?
  27.  
  28. -> Dan Hepner
  29.  
  30. The point of passing the journal data from the master RM to a Hot Standby RM
  31. is performance: it generally takes less work (read less time) to process
  32. journal entries than it does to process the original requests.
  33.  
  34. Let's take a look at why: the journal is a log of physical updates to the
  35. database pages (if it isn't, it probably also isn't faster than the
  36. original requests).  Being physical, however, it is related to the particular
  37. (proprietary) data organization used by the DBMS.
  38.  
  39. Translating things like block size and (index and data) record formats
  40. from one proprietary form to another, or even to a canonical form, to pass
  41. to another DBMS via a TM doesn't sound like fun, if it is even possible.
  42. It also sounds very error prone to me, since the combinatorics would make
  43. testing very difficult.
  44.  
  45. As a result, then, you would have an extremely complicated translation
  46. system that would probably be as slow as or slower than the original
  47. queries.  So passing the original queries to both machines in parallel
  48. via a TM sounds like a pretty good alternative, and you can have that
  49. today.
  50.  
  51. The alternative is to rewrite all DBMSs to have the same internal
  52. structures and logging techniques.  Would you suggest the DBase format
  53. as a standard that everyone knows???  :-)  <- that's a joke, please, but
  54. it does make a point, even if DBase doesn't do logging...
  55.  
  56. To play the catchup game would require that the surviving DBMS or the TM
  57. keep a record of the logical transactions processed while the other DBMS(s)
  58. failed, so they can be replayed later to catch up.  If the load is light
  59. enough that they can catch up by applying logical transactions...
  60.  
  61. GLenn
  62.