Fwd: RE: Remote journals and APYJRNCHG

>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