Configuring DB2 and IBM Spectrum Protect in Unix / Linux

Answer

A few notes before configuring DB2 for IBM Spectrum Protect:

• The IBM Spectrum Protect API bit level needs to match the DB2 bit level (check output of command 'db2level', ran as the instance owner); the bit level of the OS does not affect this. For example, if a 32bit DB2 Instances is installed on a 64bit AIX OS, then the 32bit IBM Spectrum Protect API should be installed to match the bit level of the DB2 instance.
• Keep in mind that the db2adutl and dsmapipw utilities use the IBM Spectrum Protect API environment variables (the DSMI variables) that are set in their current working shell. Therefore, any changes to the DSMI environment variables will be seen immediately by these utilities. However, DB2 utilizes the environment variables from memory that are loaded when the instance is started. Therefore, any changes to these DSMI environment variables require the DB2 instance to be recycled (i.e. db2stop/db2start) for the changes to take affect.
• If any of the IBM Spectrum Protect API files (such as dsmtca, libApiDS.a, or libApiTSM64.a) were copied from either one IBM Spectrum Protect API install directory to another, from the Backup-Archive client directory, or from one system to another, then it is recommended to uninstall the IBM Spectrum Protect API, delete the API install directory, and then reinstall the IBM Spectrum Protect API to ensure that the appropriate bit level of the files exist in the correct location.

To ensure that DB2 and the API are properly configured, perform the following steps:
1. Log in with DB2 Instance owner (or use "su - db2inst1") and run:
db2level

• From this output, verify if this is a 32 or 64bit DB2 instance
• If DB2 is 32bit, install the 32bit TSM API
• If DB2 is 64bit, install the 64bit TSM API

set | grep DSMI
Determine the current setting for the API environment variables

• DSMI_DIR should specify the:
• /<opt or usr>/tivoli/tsm/client/api/bin directory if DB2 is 32bit
• /<opt or usr>/tivoli/tsm/client/api/bin64 directory if DB2 is 64bit
• the dsm.sys file must exist, or have a link to it, in this DSMI_DIR directory
• DSMI_CONFIG should specify a full path and file name for the user options file (i.e., dsm.opt)
• verify that "servername xyz" in this dsm.opt corresponds to an existing "servername xyz" stanza in the $DSMI_DIR/dsm.sys
• DSMI_LOG, if defined, should specify a directory that is writable by DB2

Note that the errorlogname parameter takes precedence over the DSMI_LOG variable.
• if errorlogname exists in the stanza in the dsm.sys ensure the file specified has wrie access by the db2 user

2. Edit the file $HOME/sqllib/userprofile to include the DSMI variables from above

• Currently supported versions of DB2 will only use the DSMI variables defined in this $HOME/sqllib/userprofile.
• Defining these DSMI variables solely in the $HOME/.profile is no longer sufficient as they will be ignored by DB2.

3. At the bottom of the $HOME/.profile (for Korn shell) or $HOME/.bash_profile (for Bash shell) or the equivalent for any other shell, source (i.e. execute/run) the DB2 file $HOME/sqllib/db2profile. For example:

• Add the following to the bottom of the $HOME/.profile

. /<db2home>/sqllib/db2profile
Note: <dot><space>/full/path/sqllib/db2profile
• Add the following to the bottom of the $HOME/.bash_profile

source /<db2home>/sqllib/db2profile
• By default, the .../sqllib/db2profile sources the .../sqllib/userprofile. Therefore, the DSMI variables will still be exported into the DB2 user's shell.
• To avoid confusion, it is recommended to remove the DSMI variables from the $HOME/.profile or $HOME/.bash_profile (if they exist) and only define the DSMI variables in the .../sqllib/userprofile

4. If using passwordaccess generate (in the dsm.sys), the DB2 database configuration parameters TSM_OWNER, TSM_NODE, and TSM_PASSWORD must be set to NULL. To verify, run:

db2 get db cfg for dbname | grep TSM
TSM management class (TSM_MGMTCLASS) = MYDB2CLASS
TSM node name (TSM_NODENAME) =
TSM owner (TSM_OWNER) =
TSM password (TSM_PASSWORD) =

• The query will show blank values for the parameters that are NULL.
• If you need to update any of these DB2 database configuration parameters, run:

db2 update db cfg for dbname using TSM_NODENAME NULL
• The value for TSM_MGMTCLASS will not affect the sign-in or authentication, so it can be either NULL or populated with a valid management class. The mgmtclass specified will only be used for the DB2 database backups, not the DB2 logs.
• The TSM_OWNER, TSM_NODE, and TSM_PASSWORD parameters should only be populated when passwordaccess is set to prompt within the dsm.sys file.

5. Log out and log back in again as the DB2 user to set the environment

6. Verify the DSMI environment variables by running:

set | grep DSMI

7. Run the dsmapipw to set the password.

• If using a IBM Spectrum Protect Client version LOWER than 7.1.8 or 8.1.2, switch to the root user by running:

su
• Note: do not use the "-". This will maintain the DB2 environment variables.
whoami
• Verify that you are root
set | grep DSMI
• Verify that the DSMI environment variables are still set appropriately
$HOME/sqllib/adsm/dsmapipw
• This command sets the password for this IBM Spectrum Protect Node
• If this fails,
• Ensure the password being specified is correct or update the password on the IBM Spectrum Protect Server with the command:
• UPDATE NODE the-tsm-nodename-for-db2 NewPassword
• If passworddir is specified in the dsm.sys, delete the TSM.PWD file in this directory and then run dsmapipw again.
exit
• You should now be the DB2 user id again
• If using IBM Spectrum Protect 7.1.8 and 8.1.2 and higher, there are security enhancements that require additional configuration updates as follows:
• Change the GSKit symbolic link to have DB2 use the newer GSKit supplied with the IBM Spectrum Protect Client. Instructions are in the guide:
• https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.8/client/t_cfg_ssl_symb_lnk_gskit.html
• https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.2/client/t_cfg_ssl_symb_lnk_gskit.html
• set the PASSWORDDIR in the $DSMI_DIR/dsm.sys file to a location that has write permissions for the DB2 Instance Owner
• Ensure the dsmcert* files in either the /<opt or usr>/tivoli/tsm/client/ba/bin directory or the /<db2home>/IBM/SpectrumProtect/certs/ directory have read permissions for the DB2 Instance Owner.
• then run the 'dsmapipw' as the DB2 Instance Owner, so that the password files will be created and owned by the instance owner (instead of root).

• db2adutl query
• This should complete successfully, which verifies that the environment in the current shell is properly configured

8. Recycle the DB2 instance so that the proper DSMI variables will be picked up by the DB2 instance

9. Run the backup from DB2. For example:

db2 backup db dbname use TSM