home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / 6654 < prev    next >
Encoding:
Text File  |  1992-09-10  |  1.4 KB  |  39 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!scd.hp.com!cupnews0.cup.hp.com!dhepner
  3. From: dhepner@cup.hp.com (Dan Hepner)
  4. Subject: Re: Hot Standby DBMS's
  5. Sender: news@cupnews0.cup.hp.com
  6. Message-ID: <BuDIEM.J80@cup.hp.com>
  7. Date: Thu, 10 Sep 1992 17:39:58 GMT
  8. References: <9209091721.AA27050@ludwig.sharebase.com>
  9. Organization: Hewlett-Packard
  10. X-Newsreader: Tin 1.1scd1 PL4
  11. Lines: 26
  12.  
  13. From: glenn@ludwig.sharebase.com (Glenn Linderman)
  14.  
  15. >-> Any ideas on how to convince them? 
  16.  
  17. >The point of passing the journal data from the master RM to a Hot Standby RM
  18. >is performance: 
  19.  [but..]
  20. >As a result, then, you would have an extremely complicated translation
  21. >system that would probably be as slow as or slower than the original
  22. >queries.  So passing the original queries to both machines in parallel
  23. >via a TM sounds like a pretty good alternative, and you can have that
  24. >today.
  25. >GLenn
  26.  
  27. What you can't have today is any sensible way to resynchronize
  28. when an out-of-date copy is to be brought back on-line.  We have
  29. discussed before why the input stream cannot be logged for
  30. future replay, but the journal stream could be.
  31.  
  32. I think the first-order performance evaluation is that journal 
  33. data is more consumptive of communication bandwidth, the input 
  34. stream is more consumptive of cycles at the standby machine. 
  35. For most people, a small advantage to the input stream, but
  36. not enough to drive an entire industry to make that decision.
  37.  
  38. Dan Hepner
  39.