TSM losing connection with DB2

27 March,2010 by Tom Collins

OS = RedHat Linux ESE 4.6  32 bits
DB2 versiion = v9.1.0.3
DB2 code release = SQL09013
Tivoli Storage Automation (TSA)  =  SAFMP V310

Assumption - installed OK - and system has been running OK
i.e scheduled backups and archived logging working OK .

The problem can be created with the following step:
1)Upon issuing a db2_kill   TSA restarts the instance - which it does so successfully.

But at that point :
a)issuing a "backup database MYDB online use TSM"
b)archival logging

both return a  (in db2diaglog):

TSM RC=0x0000006A=106 -- see TSM API Reference for meaning.

I can still issue a "db2adutl Query full db MYDB" and get a recordset from TSM

From the TSA perspective :
It looks like the TSA in the process of monitoring the instance , and sees the instance is down goes through a clean up process
via this code :
   $INSTHOME/sqllib/bin/db2gcf -t 60 -k -p ${NN?} -i ${DB2INSTANCE?}
kill -9 $(ps -fu $DB2INSTANCE | awk '{print $2 " " $8}' | grep " db2[a-z]" | awk '{print $1}')
kill -9 $(ps -ef | grep -v grep | grep db2chkau | awk '{print $2}')
su - ${DB2INSTANCE} -c "ipclean -a"

and the start up process


To recover back to the point of Archival Logging and Backups via TSM I can   reauthenticate  via :
1)stop TSA
2)run though the dsmapipw authentication

3)issue a db2stop \ db2start

this allows the backups and archival logging to start
4)start TSA

In a 24\7 environment -  the expectation  is to recover and maintain the TSM authentication

The cause of the problem is to found in the TSA file "db2_start.ksh" - which is installed as part of the rsct/sapolicies , normally to be found on :

As part of the db2 recovery process the script issues the following command  as root:

$INSTHOME/sqllib/bin/db2gcf -t 60 -k -p ${NN?} -i ${DB2INSTANCE?}

Interogating this line indicates that :
1)the dbgcf command - which controls the Db2 Instance Command . This command is used to startstop or monitor the DB2 instance within the cluster setup
2)The -t switch is the timeout
3) the -K switch renoves al processes associated with he specified instance
4)the -p switch is the partition number
5)the -i switch is the instance


As part of the configuation of TSM per DB2 instance the following environment varibales are set up per instance . They are added to the : "<instance_home>/sqllib/userprofile"  as follows:

DSMI_LOG=/myInstance /tsmlog

The problem arises when the line is issued as root  : $INSTHOME/sqllib/bin/db2gcf -t 60 -k -p ${NN?} -i ${DB2INSTANCE?}
The environment variables are not   set up for root  which outline the path of the .opt file and log files .

The workaround is to add the following lines in the "/usr/sbin/rsct/sapolicies/db2/db2_start.ksh" . Ensure you add them just under the line : DB2INSTANCE=${1}


## These lines fix the environment problems with TSA and TSM passwords




Assuming your DB2 instances are all set up in a standard path format , this will cover all DB2 instances on the server .

 Ref:Jack Vamvas(http://www.dba-db2.com)


Author: Rambler(http://www.dba-db2.com)


Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment on TSM losing connection with DB2

Comments are moderated, and will not appear until the author has approved them.

dba-db2.com | DB2 Performance Tuning | DBA DB2:Everything | FAQ | Contact | Copyright