Configuring DB2 and TSM in Unix / Linux
Configuration steps required for DB2 to work with TSM on Unix/Linux.
|
|
A few notes before configuring DB2 for TSM:
- The TSM API bit level needs to match the DB2 bit
level; 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 TSM
API should be installed to match the bit level of the DB2 instance.
- Keep in mind that the db2adutl and dsmapipw
utilities use the TSM 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 TSM API files (such as dsmtca,
libApiDS.a, or libApiTSM64.a) were copied from one TSM API install
directory to another, from the TSM B/A client directory, or from one
system to another, then it is suggested to uninstall the TSM API,
delete the TSM API install directory, and then reinstall the TSM API to
ensure that the appropriate bit level of the files exist in the correct
location.
To ensure that DB2 and the TSM 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 TSM 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 link to it, in this DSMI_DIR directory
- DSMI_CONFIG should specify a full path and file name for TSM 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 read/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 RW access by the db2 user
2. Edit the file $HOME/sqllib/userprofile to include the DSMI variables from above
- As of DB2 8.2 (DB2 8.1 fixpack 7), 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 already 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 this
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. Switch to the root user by running:
su
- Note: do not use the "-". This will maintain the DB2 environment variables.
whoami
set | grep DSMI
- Verify that the DSMI environment variables are still set appropriately
$HOME/sqllib/adsm/dsmapipw
- Set the password for this TSM Node
- If this fails,
1. Ensure the password being specified is correct or update the
password on the TSM Server with the command: UPDATE NODE
the-tsm-nodename-for-db2 NewPassword
2. If passworddir is specified in the dsm.sys, delete the TSM.PWD file in this directory
- then run dsmapipw again.
exit
- You should now be the DB2 user id again
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 |