home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / 6628 < prev    next >
Encoding:
Text File  |  1992-09-09  |  2.1 KB  |  41 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!mcsun!sunic!aun.uninett.no!ugle.unit.no!teleserve.no!oytor
  3. From: oytor@teleserve.no (Oystein Torbjornsen)
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <1992Sep9.141443.19295@ugle.unit.no>
  6. Sender: oytor@rand (Oystein Torbjornsen)
  7. Organization: Teleserve Transaction Technology, Trondheim, Norway
  8. References: <1992Sep7.165029.26587@uk03.bull.co.uk> <BuAHM6.Ds4@cup.hp.com>
  9. Date: Wed, 9 Sep 92 14:14:43 GMT
  10. Lines: 29
  11.  
  12. In article <BuAHM6.Ds4@cup.hp.com>, dhepner@cup.hp.com (Dan Hepner) writes:
  13. |> From: dboyce@hemel.bull.co.uk (David Boyce)
  14. |> >Interfaces for obtaining journal data from an RM and passing it to an
  15. |> >standby RM would be needed, as would RM-independent methods of recovery
  16. |> >and catch-up.  Not beyond the wit of man, I would have thought.
  17. |> >
  18. |> >Obviously the database vendors need to be convinced of the need to make
  19. |> >this interface available. 
  20. |> Any ideas on how to convince them?  In particular, it needs to be
  21. |> shown what can be done using this scheme which the DB vendors 
  22. |> could not do themselves.  Intuitively, one would say "but it's
  23. |> more open".  In what way does this openness benefit anyone?
  24.  
  25. The main goal for hot standbys are high availability to data. Current hot
  26. standby solutions are able to mask environmental failures (eg. earthquake,
  27. flood, power), operator failures (the two systems are run by two different
  28. system operators), and soft/transient software errors (heisenbugs). By
  29. introducing an open standard the customer can use DBMS' from different vendors
  30. for primary and hot standby. If the software at the primary failes hard
  31. (bohrbug) the hot stanby can take over and most likely be able to run the
  32. transaction(s) that failed on the primary.  The two DBMS' is likely to be
  33. implemented by different people using different languages and different
  34. mechnisms and therefore have independent failure modes. The effect is coarse
  35. granularity N-version programming.  
  36.  
  37. -- 
  38. Oystein Torbjornsen                                  Phone: +47 7 596541
  39. Teleserve Transaction Technology AS                  Fax:   +47 7 596538
  40. N-7005 Trondheim, NORWAY                             Email: oytor@teleserve.no
  41.