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.
From: firstname.lastname@example.org [mailto:email@example.com]
Sent: Wednesday, 8 June 2005 8:12 p.m.
To: Robert Allely; 'firstname.lastname@example.org'
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' -
....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
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
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.