DB2 Logging and Archiving

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

saramathi@gmail.com - 15 Feb 2007 05:33 GMT

I am trying to understand the logging and archiving features of DB2
V8.2 And I have a couple of questions:

1. When I issue update db cfg using newlogpath /path, the logpath in
db cfg is /path/NODE0000 and the db2 logs go there. But when I use
restore db...logpath /path, the logpath in db cfg of the target
database is /path. The NODE0000 is no more appended. What is the
resoning behind this peculiar behaviour?

2. When I restore db A to db B, the db cfg of A is copied to that of
B. Why is this? An undesirable effect of this is the archive log
destination (logarchmeth1) of A is in the db cfg of B. I would have
thoght that it is better to leave the db cfg of B alone.

3. When you restore db A to db B using an online backup that also
contains the logs, where do you restore the logs to? B's normal
logpath or some other directory?

TIA

Naru Mangalath

Reply to this Message

Knut Stolze - 15 Feb 2007 06:38 GMT

> 2. When I restore db A to db B, the db cfg of A is copied to that of
> B. Why is this? An undesirable effect of this is the archive log
> destination (logarchmeth1) of A is in the db cfg of B. I would have
> thoght that it is better to leave the db cfg of B alone.

You are replacing DB B completely. Why would you want to keep the old,
possibly non-matching DB CFG instead of using the one for DB A?

> 3. When you restore db A to db B using an online backup that also
> contains the logs, where do you restore the logs to? B's normal
> logpath or some other directory?

I haven't tried this myself yet, but I would expect that the log path is set
to the one in DB A's DB CFG upon restore into DB B.

Online vs. offline is irrelevant to restore. It just tells you the mode of
access allowed to the DB while taking the backup itself.

Signature

Knut Stolze
DB2 z/OS Utilities Development
IBM Germany

Reply to this Message

Pierre Saint-Jacques - 16 Feb 2007 03:14 GMT

When a db is created it gets a unique number known as the seed. It will be
unique for any db created.
When you restore a db, DB2 will check the name (alias) you use and then find
out if this alias already exists in the instance. If it does then it checks
if the alias points to a db with a real name that is defferent or equal.
If equal, then you have to use the REPLACE EXISTING parm. Files and logs
will be kept in place in their logpath as defined in the inplace db cfg.
If not equal then DB2 sees that you are creating a new db on that instance.
Then it will replace the db cfg, the db2rhist and will wipe out the logs in
the logpath mentionned in the db cfg.
If restoring to create new (as in restore db A) on a new system. Then
everything will be copied from the backup image.
If restoring db A on to db B, db2 will check the alias names to see if they
point to the same or different real names and behave as stated above.

See below ######
HTH, Pierre.

Signature

Pierre Saint-Jacques
SES Consultants Inc.
514-737-4515

>
>> 2. When I restore db A to db B, the db cfg of A is copied to that of
[quoted text clipped - 4 lines]
> You are replacing DB B completely. Why would you want to keep the old,
> possibly non-matching DB CFG instead of using the one for DB A?

##### As stated by Knut, to DB2 this is a brand new db that overwrites the
existing one so it uses what is in the image. If it kept the logs, it would
not know what to applu to what or where.

>> 3. When you restore db A to db B using an online backup that also
>> contains the logs, where do you restore the logs to? B's normal
>> logpath or some other directory?

###### The logs will go to the path specified in the db cfg of A in the
image and will ignore the path of esixting B. You are replacing B by A. You
have the option in the restore command to specify where the log path will
be:
RESTORE DATABASE source-database-alias { restore-options | CONTINUE |
ABORT }
restore-options:
[......[LOGTARGET directory] .......

> I haven't tried this myself yet, but I would expect that the log path is
> set
[quoted text clipped - 3 lines]
> of
> access allowed to the DB while taking the backup itself.

Reply to this Message