I am not doing a creeping one. It just allows a copy of the up-to-date
journals and last ckp file etc. to be ready for
A rollforward when required.

-----Original Message-----
From: martin.bowes@ctsu.ox.ac.uk [mailto:martin.bowes@ctsu.ox.ac.uk] 
Sent: Wednesday, 8 June 2005 8:12 p.m.
To: Robert Allely; 'chloe.crowder@bl.uk'
Cc: info-ingres@cariboulake.com
Subject: Re: [Info-ingres] Ingres stand-by database


Hi Robert, Chloe etc.

	I'm not sure if I have a full grasp on whether or not Robert was 
doing a 'creeping' rollforward or not, but just in case, I'd like to get on 
the Ol' Soap Box for a moment.

	Its one thing to set up a DR system using rollforwarddb from a 
checkpoint/journal etc. Thats a perfectly simple and natural thing to do.

But Its quite another to use rollforwarddb from some point and then 
transfer over more journals and do a 'creeping' rollforwarddb -c +j '#f' -
b... [-norollback]

....And then automate the process,
....allowing for errors such as:
*   the rollforwarddb being locked out by another process, 
*   the possibility of a database being flagged as inconsistent on the 
    DR site - which is very probable.
*   A breakdown in the transport of a journal or other essential file 
    between the hosts. scp/rcp/ftp failure.
*   A journal being written to by the primary host archiver as it was 
    transferred to the DR host. Whats that (unsupported) trace point to 
    force a journal flush again?

BTW. There are some situations you can cross where you'll need a 
utility to edit the config file. You feeling lucky today?

Plus what happens when you take a new checkpoint on the primary 
site. How are you going to sync the databases? Do you want to? If so,  
you will need to code an Automatic database sync.

Plus, before activating the 'hot standby database' remember to run the 
last rollforwarddb without the -norollback option. That is assuming you 
are running a rollforwarddb that needs the -norollback. Bug 111470 is a 
real gas! But what if the last possibly rollforwwarddb has already run 
with '-norollback'? What state has that left the database in? What are 
you going to do?

So, Yes it is possible! But there is awful lot to consider, code and test.

So I'm going to go back to my original point - whats preferable - suing 
the Crap out of CA for screwing up Replicator or losing your job 
because you screwed up your code?

Plus Replicator will also deliver a usable database for running reports 
against. This can be done whilst the data is being written into the 
database by the Replicator. A database recovery technique can't do 
that.

Plus as Jon Gibson pointed out, how big is this database anyway? 
What is the recovery time? Is there any serious downside to telling the 
users to wait an hour for a recovery?

The air is getting thin up here on the box. But I can almost see Oz from 
here...

Martin Bowes
--
Random Duckman Quote #52:
Doctor: What have we got?
Nurse: Man vs. Bus.
Doctor: Always bet on the bus.

***
This e-mail is privileged and confidential.  If you are not the intended recipient please delete the message and notify the sender.
***