db2 restore and recovery behavor with tsm?

[jbleistein1]

I have a db2 database called prod1, which resides in the prod instance on an AIX system. I have the db2 tsm api setup so it backs up directly to tsm. The db2 backup db prod to tsm works fine. I see the sessions in tsm, and a select from the backups, and archives tables from the tsm server db shows the db2 backup files, and archive log respectively. I goto restore my db2 database. I rm -rf my db2 Unix directly structure. I then issue a db2 resotore db prod.... command. It restores all db2 backup files as well as rollforwards the database completely using the archive logs, just as expected. However when I look in the archive log destination, which I also wiped out before the restore with an rm -fr...., I notice that the logs are still gone.. How did db2 rollforward the logs stored on the tsm server if they aren't there? Does db2 just open a stream to the logs on the tsm server and just restores/rollforwards there contents, but doesn't restore the actual physical db2 log files themselves to the client system? Just wondering because in the Oracle tdp, rman physically restores the archive log files for the database then rollforwards, and after the recovery you can still see the files there via an ls -l .... command.

Also a strictly db2 related question. After I rollforward the db2 database, and bring it back online. I only see like 1 primary log out there rather then 13 which is what my primary log parameter is set to?

Can anyone assist?
Please advise.

Thanks,

--Justin Richard Bleistein
TSM/AIX/IBM Enterprise/Oracle database

 

[cheffern]

Does db2 just open a stream to the logs on the tsm server and just restores/rollforwards there contents, but doesn't restore the actual physical db2 log files themselves to the client system?

yes.

DB2 does not behave like Oracle and put the restore files back in place.
there will never be any archive logs left for you to see in DB2 as the TSM API picks them all up and ships them off directly to TSM (this is if you have the LOGARCHMETH setup correctly) -
and in restore it does effectively use them to rollforward -
it just kinda cleans up after itself if you will...
TSM & DB2 combine forces in this case to make sure no logs are left on disk.

you can verify that you are on the right log by issuing 'db2 get db cfg for SID' and looking for the next logfile.

I only see like 1 primary log out there rather then 13 which is what my primary log parameter is set to?

the reason you can only see the 1 primary log after restore is that it only creates 1 to start and then more as it needs it up until the full # of logs it will use.

(I think you can force this a bit by doing stop / start a few times and connecting / force application all - but not 100% sure and I have no test system to check on...)

after a little bit of use though it will cycle thru all the primary logs and look 'normal' if you will with all 13 being in the active log directory and the older ones cycling off in the background directly (and quietly) to TSM.

hope this helps -
-Chef.

 

[jbleistein1]

Thankyou soo much Chef. That does help me. It was just weird that when I first create the db2 database fresh and activate it, I have 13 logs just like the parameter it set for, but after a restore/recovery there was only 1. I guess the pre-allocation of the primary logs acts differently after a restore/recovery then after an activate of a freshly created db.

Thanks again..

--Justin