By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,611 Members | 2,296 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,611 IT Pros & Developers. It's quick & easy.

restoring DB on test server after alt_obj() fails due to COPY YES

P: n/a
aj
DB2 LUW 8.2 FP14 Red Hat AS 2.1

I went to restore a backup of my production DB on my test/developmental
server. The backup on the prod system was taken /before/ alt_obj() was
used there to do some schema evolution.

The restore on the test box barfed on the roll forward because alt_obj()
uses COPY YES on its LOAD, and the test box did not have the magic data
COPY YES files (apparently they are in ~/sqllib/tmp?).

Willing to try anything, I tried to copy these COPY YES/LOAD data files
from prod to test, but the copy command barfed - some of the data files
are named pipes or something odd?

So this means that whenever I use alt_obj(), I must do DB backup /after/
that before I can restore that DB on my test box.

<heavy sigh>....

Does anyone have a way around this? Any ideas? It would even be
acceptable if the tables associated with the COPY YES data just weren't
restored..

Maybe alt_obj() be persuaded to do a non-recoverable LOAD?

TIA

aj
Jan 25 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
If your altobj is run immediately after the backup has been taken and
you know that there are no changes to the database between them, you
could run a point-in-time recovery, stopping just before the altobj is run.

If your backup is offline, you can restore it without the rollforward.
Online backups can also be restored with a rollforward to the end of the
backup.

You could also take a second backup after the altobj. I'm assuming you
don't do regular altobjs, so it may not be a big issue.

Phil Sherman
aj wrote:
DB2 LUW 8.2 FP14 Red Hat AS 2.1

I went to restore a backup of my production DB on my test/developmental
server. The backup on the prod system was taken /before/ alt_obj() was
used there to do some schema evolution.

The restore on the test box barfed on the roll forward because alt_obj()
uses COPY YES on its LOAD, and the test box did not have the magic data
COPY YES files (apparently they are in ~/sqllib/tmp?).

Willing to try anything, I tried to copy these COPY YES/LOAD data files
from prod to test, but the copy command barfed - some of the data files
are named pipes or something odd?

So this means that whenever I use alt_obj(), I must do DB backup /after/
that before I can restore that DB on my test box.

<heavy sigh>....

Does anyone have a way around this? Any ideas? It would even be
acceptable if the tables associated with the COPY YES data just weren't
restored..

Maybe alt_obj() be persuaded to do a non-recoverable LOAD?

TIA

aj
Jan 28 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.