Keith wrote:
sql2537 indicates that you are trying to use an online image to
restore (with w/o RF). Looking at the steps you've done, the only
possibility (that I can think of) for that is the time stamp used in
restore cmd. You may have other images in /tmp and may not have used
the time timestamp of the offline image that you just took.
Hi Keith,
Thanks for that. I've no been playing around with various options and
scenarios to a point where I can barely make out my own notes.
I've now been trying to test with both ON and OFFline backups and am
getting weird results.
In the ONline case, I thought it would be straight-forward:
I'd do this on the source instance:
$ db2 BACKUP DATABASE REX ONLINE TO "/tmp" WITH 2 BUFFERS BUFFER 4096
PARALLELISM 1 INCLUDE LOGS WITHOUT PROMPTING;
Note that there's not much "complexity" in this source DB - pretty much
standard, default tablespaces, all set to auto-maintenance/optimization.
And then this on the target instance:
<any vestige of target instance is removed and uncataloged - I even
tested with a "fresh new instance".>
$ db2 restore db rex from /tmp taken at 'yyyymmddhhmmss' on \
'/db/rextest' into testrex newlogpath '/translogs/rextest' redirect;
$ db2 restore db rex continue;
$ db2 rollforward db testrex to end of logs;
$ db2 rollforward db testrex stop;
Or so, I try. I get an error message at the first rollfoward telling me
that it can't find the the logfiles! As if it had ignored the "include
logs" option.
Then, I try the OFFline case, and now get quite a bit further:
<first quiesce, force all connections off, etc>
$ db2 BACKUP DATABASE REX TO "/tmp" WITH 2 BUFFERS BUFFER 4096
PARALLELISM 1 WITHOUT PROMPTING;
Then again at the target (fresh as above), I've played with these two cases:
$ db2 restore db rex from /tmp taken at 'yyyymmddhhmmss' on \
'/db/rextest' into testrex newlogpath '/translogs/rextest' redirect \
without rolling forward;
Which seems to work, except there's this paranoid streak in me asking
whether this offline backup really is a fully rolled forward version
and/or whether my restore is now missing the most recent transactions of
the active logs, because I told it "without rolling forward".
The reason for this paranoia is because, just for the heck of it, I
tried this:
Backup as above, but the restore with this:
$ db2 restore db rex from /tmp taken at 'yyyymmddhhmmss' on \
'/db/rextest' into testrex newlogpath '/translogs/rextest' redirect;
$ db2 restore db rex continue;
$ db2 rollforward db testrex to end of logs;
$ db2 rollforward db testrex stop;
And the rollforward goes into "deep meditation" for quite a bit, which I
naively assume to mean it *is* doing something roll-forwardish.
What is is rolling forward in an OFFLine backup?! And if there's logs to
roll forward, what does that mean when I do a "without rolling forward"
restore on an offline DB?
So, I now have two scenarios, one which doesn't work the other which
kinda works but I'm not sure I trust the results. (if we look at this in
the light of not just a replication scenario, but as a disaster recovery
restore situation).
My head hurts...
Mike
PS: To clarify just a minor thing, in the above the rexprod instance has
a rex database with alias prodrex, the rextest instance has a rex
database with alias testrex.
