home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / 6583 < prev    next >
Encoding:
Text File  |  1992-09-08  |  5.2 KB  |  113 lines

  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!think.com!cass.ma02.bull.com!pluto.uk03.bull.co.uk!dboyce
  3. From: dboyce@hemel.bull.co.uk (David Boyce)
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <1992Sep7.165029.26587@uk03.bull.co.uk>
  6. Sender: @uk03.bull.co.uk
  7. Nntp-Posting-Host: pluto
  8. Organization: Bull HN UK
  9. References: <BtI4Bv.D8r@cup.hp.com> <BtI9KD.MAv@world.std.com> <1992Aug25.063147.2764@anasaz> <BtpKqr.Kz1@world.std.com>
  10. Date: Mon, 7 Sep 92 16:50:29 GMT
  11. Lines: 100
  12.  
  13. edwards@world.std.com (Jonathan Edwards) writes:
  14.  
  15. >In article <1992Aug25.063147.2764@anasaz> briand@anasaz (Brian Douglass) writes:
  16. >>>As journal data is received and written at the remote system, it is
  17. >>>asynchronously being recovered there, just like a normal journal (roll-forward)
  18. >>>recovery. Thus the remote system can recover and take over in a few minutes
  19. >>>from the production system.
  20. >>
  21. >>I think a difference lies in that while I suggest transactions
  22. >>are processed as they are received on the remote system, Mr. Edwards system
  23. >>seems to roll forward only upon primary failure, or I suppose nightly.  If
  24. >>I am wrong in this, please clarify.
  25. >No, the remote system is recovering (rolling forward) on the fly.
  26. >That's what the HOT in Remote Hot Standby means.
  27.  
  28. >>What type/size systems is this operation implemented on?  If you can say.
  29. >>Large Unix OLTP operations are still a rarity compared traditional mainframe
  30. >>solutions, and I love to hear what others are doing.
  31.  
  32. >VAX/VMS - the whole size range. The database itself is written in VAX
  33. >assembler and mostly runs in kernel mode to pull off some nice stuff.
  34. >The basic code is 10 years old, though it has evolved considerably.
  35. >By modern standards it is a white elephant, but will still blow the doors
  36. >off anything else. But it seems the market is willing to buy 10 times as
  37. >much hardware (literally!) in order to get a relational solution...
  38.  
  39. For another example of a system of this type, in 1984 Honeywell
  40. Information Systems (now part of Bull) released a two-machine version
  41. of its TPS6 proprietary TP system which was a hot remote standby
  42. configuration (we called it 'Resiliency').  This was (and I believe
  43. still is) being used in a significant number of customer sites.  It ran
  44. on Honeywell's DPS6 range of minicomputers.
  45.  
  46. The two machines were separate systems linked by fibre-optic or
  47. broadband cable (usually two physical links were configured), with
  48. 'intelligent' switches to automatically re-configure terminals and
  49. other devices to the hot standby ('tracker') on master failure.  
  50.  
  51. During normal running, the master database's roll-forward journal was
  52. passed, via one of the links, from 'master' to 'tracker' as it was
  53. generated, and the tracker would apply this to its copy of the
  54. database.
  55.  
  56. If the master failed, the tracker would abort current transactions and
  57. restart their associated programs, and become the new master.  The
  58. on-line users would be interrupted for a short time, and then could
  59. restart their work following the last completed transaction.  When the
  60. reason for the old master failing was dealt with, it could be
  61. re-introduced as a hot standby.
  62.  
  63. One interesting addition to this was to link batch program requests
  64. made within transactions to transaction completion;  these program
  65. requests were also tracked so that requests made by completed
  66. transactions on the master were not lost if the master failed prior to
  67. the requests being scheduled.
  68.  
  69. Another addition was the management of print spool requests;  using the
  70. same mechanism, print requests could be maintained on a hot standby
  71. basis.
  72.  
  73. Care was taken to ensure compatible configurations on each side,
  74. although interestingly there was enough 'give' in the checking to
  75. permit some re-configuration without interrupting service, although
  76. this wasn't possible for every type of configuration change.
  77.  
  78. As noted in other posts, the implementation is tightly coupled to the
  79. particular database (although at the time its loosely-coupled system
  80. architecture gave it significant advantages).
  81.  
  82. A thought arising:
  83.  
  84. Other posts have pointed out that transmission of journalling data
  85. appears to be the only certain method of ensuring database consistency
  86. in a hot-standby architecture.  This presently continues to be
  87. supported only by proprietary databases.
  88.  
  89. With a number of database vendors now offering support for the XA-
  90. interface, allowing co-ordination within distributed transactions,
  91. shouldn't we also be seeking to encourage the definition of an
  92. equivalent 'hot-standby' interface, which permits communication of
  93. journal information to be managed by a component of a Transaction
  94. Manager?
  95.  
  96. Interfaces for obtaining journal data from an RM and passing it to an
  97. standby RM would be needed, as would RM-independent methods of recovery
  98. and catch-up.  Not beyond the wit of man, I would have thought.
  99.  
  100. Obviously the database vendors need to be convinced of the need to make
  101. this interface available. 
  102.  
  103. Note that they do not need to publish the content of the journalised
  104. data - it could be encrypted - just provide it in a form in which it
  105. can be transmitted.
  106.  
  107. Any interest?
  108. --
  109. David Boyce    (David.Boyce@hemel.bull.co.uk) 
  110.                 Tel: +44-442-884468    BULL HN Information Systems Ltd.
  111.                 Fax: +44-442-884570    1, Three Cherry Trees Lane,
  112.                           Hemel Hempstead, Herts HP2 7DZ
  113.