Re: Quick start to getting DB2 and ADSM working

I checked on what I put out yesterday, and the email client inserted all
sorts of garbage characters.  Here is the same text again.



 I would appreciate any feedback you may have for improvement.

Here is a quick start guide for backing up db2 to
adsm.  This will be based on the AIX OS and the
3.7 TSM Api level.

1.  Install DB2
2.  Install TSM Api
3.  create a plain text file dsm.opt in /usr/tivoli/tsm/client/api/bin
 It only needs one line, the value for SERVERNAME is arbitrary, but
 must match the dsm.sys file
     SERVERNAME DB2
4.  create a plain text file dsm.sys in /usr/tivoli/tsm/client/api/bin
 It must contain at least the following.
     SERVERNAME DB2
     COMMMETHOD TCPIP
     TCPSERVERADDRESS xxx.xxx.xxx.xxx
     NODENAME DB2TSM
     PASSWORDACCESS GENERATE
5.  register the node DB2TSM on the TSM server
     It is recommended to create a new DOMAIN on the TSM server for this
node.
     It needs only one management class with a copygroup that has the
     following retention settings.
     VEREXIST=1
     VERDELETED=0
     RETEXTRA=0
     RETONLY=0
6.  sign-on as root and cd to the db2 directory that contains the files
    db2adutl and dsmapipw.
7.  run the executable 'dsmapipw' follow the prompts.  It will ask for
the current password, then for a new password, and confirmation of the
new password.  It should report if it is successful.
8.  run the command 'db2adutl query' to confirm that the password file
was correctly set.   If the command comes back and says no db2 objects
found then it is working (you haven't done any backups yet).  You should
be able to check the activity log on the TSM server to confirm that the node
DB2TSM athenticated.
9.  You can now perform a backup using the command line or the db2 connect
gui.


There is one point regarding password authentication that is not explained
really well.

Within the options file you can either specify passwordaccess
generate or password access prompt (dsm.opt for NT, dsm.sys
for the Unix flavors).

No matter which TSM password method you are using, these four
values are needed.  ADSM NODE, ADSM PASSWORD, ADSM MGMTCLASS,
ADSM OWNER.  These values can either come from
within the specific db2 database (db2 set db cfg .....),
or come from the options file and current logged on user.

If you are using password access generate, those values
come from the options file and current logged on user.
The values within the specific db2 database are NOT used.
The ADSM NODE comes from the NODENAME option in the options
file.  The ADSM MGMTCLASS comes from the options file or
goes to the default management class for the node.
The ADSM OWNER is only for the Unix variants and comes from
the user that is logged on to the OS and is performing the
backup(the instance owner, i.e. db2inst1).  The ADSM
PASSWORD comes from an encrypted file that had to
be previously created by running the utility that comes
with db2, DSMAPIPW.

The only time the values set within the specific db2 database
are used is when passwordaccess is set to PROMPT.  Note that
each db2 database in a given instance has it's own four adsm
values.  You must set these everytime for each database if
you are going to use passwordaccess prompt.

The only time PASSWORDACCESS PROMPT is required is when you
are performing a restore of a db2 database that was backed
up under a different unix user (ADSM OWNER).  This case is
when you are trying to restore a database backed up from a
different db2 instance (same machine or different) and want
to restore it to another db2 instance.  DB2 calls this a
redirected restore.

What helped me understand why you had to use PASSWORDACCESS prompt
is the following.  When a file or api object is backed up under Unix,
the owner of the object is sent as well.  Only the owner or a ROOT
user can restore that object.  In the case of a redirected restore
you have DB2 requiring you to be logged on as the unix user that
has authority to perform restores for that instance.  But in this
case you are trying to restore a db2 database that was backed up
to ADSM with a different unix owner.  So ADSM is requiring you to be
logged on as the unix user that initially performed the backup.
Since you can only be logged on once, and since DB2 and ADSM
require different users to be logged on, you have a conflict.
This is resolved by setting all the ADSM parameters within the
DB2 database that you are restoring to.  You then specify password
access prompt, and when you perform the restore, DB2 is happy
since your are logged on as the instance owner, and ADSM is
happy because it gets the ADSM NODE, ADSM OWNER, and ADSM PASSWORD,
from the db2 database that is being restored into.



James Thompson
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com