Table of Contents
TSM Server will not start
Backup DB2 OFFLINE
OffLine DB Backup have been taken. Need OffLine DB Restore!
Solution 1: Archive log directories are full and server will not start
Technote (FAQ)
Question If a FULL database backup is not taken in time to prune the archive logs before the directory becomes full.
Cause Tivoli Storage Manager server shuts down and archive log directory and active log directory are full. The server cannot be started again.
Answer Prune the archive logs by running a DB2 database backup.
1. Create a directory on a drive/volume with enough space to hold a full DB2 database backup.
2. From the DB2 command prompt, issue the following commands:
db2start db2 backup db tsmdb1 to <path to directory that was created in step 1>
Examples: Windows: db2 backup db tsmdb1 to C:\dbbackup
UNIX: db2 backup db tsmdb1 to /dbbackup
The following message will appear once the backup is complete: Backup successful. The timestamp for this backup image is: 20090721130818 At the end of this backup, archive logs will start pruning. Note: depending on the size of the database and archive logs, this could take a while to complete the backup.
To check the progress:
[tsminst1@tsm00]/home/tsminst1$ db2 list utilities show detail ID = 1 Type = BACKUP Database Name = TSMDB1 Member Number = 0 Description = offline db Start Time = 09/05/2018 14:07:50.744655 State = Executing Invocation Type = User Throttling: Priority = Unthrottled Progress Monitoring: Estimated Percentage Complete = 15 Total Work = 1204132742956 bytes Completed Work = 179878185236 bytes Start Time = 09/05/2018 14:07:50.744687
3. Review the archive log directory. Is the drive/volume free space still low? You will have to decide if you need to run a second DB2 database backup to avoid having the archive logs fill up again before the next scheduled Tivoli Storage Manager database backup. This depends on the average growth of archive logs per day. Review the timestamps on the archive log. If need, issue another DB2 database backup.
4. Start Tivoli Storage Manager server in foreground. Open a command terminal and navigate to the server directory and issue the dsmserv command to start the correct instance.
5. Take a full database backup by issuing the following commands:
disable sessions backup db type=full dev=<your device class> enable sessions
Now that the Tivoli Storage Manager server is up and running, attention should be paid to see how often FULL Tivoli Storage Manager database backups are needed in order to prune the archive log directory.
Solution 2: Active and archive log directory are full and server will not start
Problem(Abstract)
If a FULL database backup is not taken in time to prune the archive logs, the server will shut down. The archive log volume becomes full and archive logs fill the active log volume and cause the Tivoli Storage Manager server to shut down. Symptom
Tivoli Storage Manager server shuts down and archive log directory and active log directory are full. Cause
Active log and archive log directories (drives) are full.
Activity log may show the following warning message:
ANR0297I A full database backup is needed. The last log number used is 194 and the first log number used is 194. The log file size is 512 megabytes. The maximum log file size is 12288 megabytes
Actlog may report the following right before server shuts down: ANR0171I dbieval.c(779): Error detected on 6:3, database in evaluation mode.
Resolving the problem
When this happens, Tivoli Storage Manager cannot start and cannot be used to move the active log or archive log to a directory with more space. In order to get the Tivoli Storage Manager server up and running, the archive logs must be pruned. The way to do that is to take database backups using DB2 commands. The procedure is as follows:
1. Create a temporary directory large enough to place the active logs (see dsmserv.opt for value of ACTIVELOGSIZE)
2. Update DB2 parameter to the active log directory to a new location. Open a DB2 command terminal and issue the following commands:
set db2instance=SERVER1 db2start db2 update db cfg for tsmdb1 using newlogpath <path\from\step1> db2stop db2start
3. No log files will be moved until the following 'activate' command is issued:
db2 activate db tsmdb1
Active logs will be COPIED and RENAMED (not moved) to the location specified in step 1. The logs in the active and archive directory will not change.
4. After “db2 activate db tsmdb1” command returns to a command prompt, the first out of two database backups are ready to begin. Note: the database backups are temporary and will be deleted. The purpose is to prune the archive logs.
Create a directory on a drive/volume with enough space to hold a full database backup. Issue the following:
db2stop db2start db2 backup db tsmdb1 to <path\to\database\directory>
Examples:
db2 backup db tsmdb1 to C:\dbbackup db2 backup db tsmdb1 to \usr\dbbackup
The following message will appear once the backup is complete: Backup successful. The timestamp for this backup image is: 20090721130818 At the end of this backup, archive logs will start pruning. Note: depending on the size of the database and archive logs, this could take a while.
5. Start another full DB2 database backup to the same or other directory with enough space to hold another full database backup.
db2 backup db tsmdb1 to <path\to\database\directory>
Examples:
db2 backup db tsmdb1 to C:\dbbackup db2 backup db tsmdb1 to \usr\dbbackup
The following message will appear once the backup is complete: Backup successful. The timestamp for this backup image is: 20090721132017 At the end of the second backup, the archive log directory and original active log directory are empty of log files. (The active log files are in the temporary directory created in step 1)
6. Delete the first DB2 database backup as follows:
db2stop db2start db2 connect to tsmdb1
Delete the DB2 database using the timestamp from the first database backup. See step 4. db2 PRUNE HISTORY 20090721130818 WITH FORCE OPTION AND DELETE
7. Update the DB2 parameter to point the location of the active log back to the original location (see ACTIVELOGDIRECTORY value in dsmserv.opt)
db2 UPDATE DATABASE CONFIG FOR TSMDB1 USING NEWLOGPATH <path\to\activelogdir>
8. Connect to the database to start automatic moving of active logs from temp location to original active log location.
db2 force application all db2stop db2start db2 connect to tsmdb1
The connect command will trigger DB2 to move (not copy) the active logs to the original directory (directory specified in step 7).
Note: depending on the size of the active logs, this process can take a long time.
9. Start Tivoli Storage Manager server in foreground. Open a command terminal and navigate to the server directory and issue the dsmserv command to start the correct instance. Refer to the command here: http://publib.boulder.ibm.com/infocenter/tsminfo/v6r2/topic/com.ibm.itsm.srv.ref.doc/r_cmd_dsmserv_start.html?resultof=%22%64%73%6d%73%65%72%76%22%20
10. Take 2 full database backups in Tivoli Storage Manager.
Disable sessions Backup db type=full dev=<device class> Enable sessions
11. Delete the second DB2 database backup as follows:
List the database backups:
db2 list history backup all for TSMDB1
Delete the DB2 database using the timestamp from the second database backup. See step 5.
db2 PRUNE HISTORY 20090721132017 WITH FORCE OPTION AND DELETE
Halt and restart the server. Now that the Tivoli Storage Manager server is up and running, attention should be paid to see how often FULL Tivoli Storage Manager database backups are needed in order to prune the archive log directory.
Only active logs are full
If the Active log fills up and the server stops, the process to get your TSM server up again is:
DSMSERV DISPLAY LOG - to check the current log status Update the Active log size parameter in dsmserv.opt Start the server up
OffLine DB Restore
OffLine DB Backup have been taken. Need OffLine DB Restore steps
Need steps to restore the Tivoli Storage Manager OffLine DB Backup per backup steps in knowledge item: http://www.ibm.com/support/docview.wss?uid=swg21668753
Overview of OffLine DB Backup steps:
From the instance owner login, do the following DB2 commands:
$ db2start $ db2 backup db TSMDB1 to /tmp/dbbackup
Example messages:
Backup successful. The timestamp for this backup image is: 20100129142928
The DB backup image created for this example in the current directory:
TSMDB1.0.tsminst1.NODE0000.CATN0000.20100129142928.001
RESTORE STEPS:
DB2 restore command:
$ db2 restore db TSMDB1 from /tmp/dbbackup taken at 20100129142928 Question before the restore: SQL2539W Warning! Restoring to an existing database that is the same as the backup image database. The database files will be deleted. Do you want to continue ? (y/n) y
Successful restore message:
DB20000I The RESTORE DATABASE command completed successfully.
$ db2 rollforward db TSMDB1 stop SQL1032N No start database manager command was issued. SQLSTATE=57019 $ db2start 01/29/2010 14:58:48 0 0 SQL1063N DB2START processing was successful. SQL1063N DB2START processing was successful.
Do the following command again and wait for successful message:
$db2 rollforward db TSMDB1 stop Rollforward Status Input database alias = TSMDB1 Number of nodes have returned status = 1 Node number = 0 Rollforward status = not pending Next log file to be read = Log files processed = - Last committed transaction = 2010-01-29-22.29.51.000000 UTC DB20000I The ROLLFORWARD command completed successfully.
At this time, start the Tivoli Storage Manager server.
A Query DB shows the last OnLine DB Backup (Last Complete Backup Date/Time:). The server is not aware of the OffLine DB Backup.
TSM:VENTANA> q db f=d ANR2017I Administrator SERVER_CONSOLE issued command: QUERY DB f=d Database Name: TSMDB1 Total Size of File System (MB): 285,985 Space Used by Database(MB): 7,200 Free Space Available (MB): 278,264 Total Pages: 354,308 Usable Pages: 354,172 Used Pages: 347,516 Free Pages: 6,656 Buffer Pool Hit Ratio: 96.7 Total Buffer Requests: 70,361 Sort Overflows: 0 Lock Escalation: 0 Package Cache Hit Ratio: 86.4 Last Database Reorganization: 01/29/2010 16:16:29 Full Device Class Name: FILE Incrementals Since Last Full: 0 Last Complete Backup Date/Time: 01/29/2010 15:00:32
