|
>Delivered-To: spanner@s.pop.ihug.co.nz >From: "Graap, Ken" <keg@nwnatural.com> >To: 'Evan Harris' <spanner@ihug.co.nz> >Subject: RE: Remote journals and APYJRNCHG >Date: Tue, 12 Mar 2002 10:18:36 -0800 >X-Mailer: Internet Mail Service (5.5.2653.19) > >Evan wrote: > > >If you had a data constrained remote system, then just keeping the journals > > >without applying them might make sense but it would be easier to just spin > >them off direct to tape or keep them in a separate ASP. > >Yes, you could store journal receivers on tape or in a secondary ASP on the >source system.... > >But, what would you do in this situation: > >Backups ran at 10PM and the tapes were sent offsite immediately afterwards. > >All production data files are being journaled and the receives are being >stored in ASP2 or to a local tape drive every once in awhile. > >At 10AM the next morning, there is a fire in the building resulting in a >total loss of the system... > >I go to my disaster recovery site, with the BU tapes I sent off site the >night before and recover my system. The best I can do though is to recover >to 10PM the previous evening. I just lost 12 hours worth of transactions. > >Now, if I had been using remote journaling to transmit my journal >transactions to a "small" system located at another site... I could have >copied those receivers to tape, taken that tape along with me to my disaster >recovery site, restored the receivers on my recovered system and applied the >changes... > >I just recovered my system right to the point where the last transaction was >able to be transmitted to the remote journal system. I didn't lose 12 hours >worth of transactions. > >Payoff: I can have this level of recoverability without having to pay >thousands and thousands of $$$$ for a system large enough to mirror my >production database and for replication software that will use the remote >journal receivers to keep these two system in sync. Admittedly I will have >some down time while recovering my system at a disaster recovery site, but >my users have indicated that they could be without the system for a few days >in the event of such a catastrophic event. > >Would you mind if this message was also sent to the MIDRANGE discussion >group? There are some people following this thread that might find our >discussion to be interesting. If you agree, please forward it. > >Kenneth > >**************************************** >Kenneth E. Graap >IBM Certified Specialist >AS/400e Professional System Administrator >NW Natural (Gas Services) >keg@nwnatural.com >Phone: 503-226-4211 x5537 >FAX: 603-849-0591 >**************************************** > > >-----Original Message----- >From: Evan Harris [mailto:spanner@ihug.co.nz] >Sent: Monday, March 11, 2002 9:41 PM >To: Graap, Ken >Subject: RE: Remote journals and APYJRNCHG > > >Ken > > > > >contortions for the restoring back to the original system scenarios >border > > >on the ridiculous unless you think that maybe IBM didn't want to kill the > > >businesses based on selling replication solutions. > > > >Come on Evan .... A lot of people use remote journaling for recovery > >purposes, not just replication. > > > >In a recovery scenario, you would recover the source system, restore remote > >journal receivers to the recovered source system and apply journal changes > >to recover your data to the point of failure.... > >And in the mean time, what do you do ? It would have seemed to me that one >of the main points behind journalling to a remote machine would have been >to use that machine in the interim while the production box was being >recovered. Wouldn't I be better off with them in an ASP or on tape if I >can't easily use them remotely ? > > >I wouldn't call that ridiculous. > >OK. I was over the top. But the last missing piece of the remote >journalling function really annoys me. I think that an apply function is so >obviously required in this scenario that the absence of it can only be >deliberate. The why of that can only be guessed at. > > >The point of remote journaling in this case is to make sure your journaled > >transactions are immediately relocated to a remote system which is >separated > >from your source system. > >In this case, but if you just happen to have a remote system capable of the >storage you can set everything up except the actual apply of the data to >the remote database, although you can write a (non-trivial) program to do >this. But why should you ? The journals are there - surely you should be >able to just apply them to the remote database ? > >If you had a data constrained remote system, then just keeping the journals >without applying them might make sense but it would be easier to just spin >them off direct to tape or keep them in a separate ASP. > >Regards >Evan Harris
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.