Backup DB2 on two different TSM server

pictux

ADSM.ORG Member
Joined
Apr 28, 2005
Messages
83
Reaction score
0
Points
0
Website
www.pictux.org
PREDATAR Control23

Hi all.
Here my situation:
an old TSM server 5.3.0
a new TSM server 5.4.0.2

Customer want to maintain db2 backup on TSM server 5.3.0 since TSM server 5.4.0.2 is not full working and tested.

For all client nodes i'm able to backup data both on old tsm server and new tsm server in this way:
- create a new dsm.opt with the new server name
- create another stanza on dsm.sys for the new server name
- start the dsmcad with "-optfile=/path/to/new/dsm.opt"
etc. etc.

For DB2 i have instead some problem.
I have a /home/adminpo/sqllib/tsm/ folder, with inside some files, (for example:
- db2backup.ksh (copy of db2backup.db2);
- dsm.opt file
)

So i duplicate this folder and create /home/adminpo/sqllib/tsm54/ folder with the modified dsm.opt (and added the right new stanza on dsm.sys).

But running db2backup.ksh from new folder contiunue to backup on old tsm server (it points in some way to the old dsm.opt file).

What can i do to follow my objective?
Thanks!
 
PREDATAR Control23

In your dsm.sys file, you need to point your DB2 node to the correct TSM Server using the "TCPServeraddress" entry - point it to the IP of the 2nd server, and make sure you have already registered the node on the 2nd server, etc.
Make sure also the dsm.opt file stanza will match a single node in the dsm.sys file for this to work.
You cannot have 2 stanzas of the same node name in dsm.sys - so the stanza to go to the new TSM server must be different (in both the dsm.sys and new dsm.opt) to make this work.

-Chef.
 
PREDATAR Control23

Hi and thanks.
Of course, i've done as you say:
- create another dsm.opt with another "ServerName";
- added in dsm.sys another stanza with the new "ServerName" defined and with the correct TCPIP address;
- but i let the same nodename..... it's so important? i point with this stanza to another server with different TCPip address and different tcpipport...
 
PREDATAR Control23

If you have 2 of the same nodename stanzas in the dsm.sys file -
when it goes to authenticate dsm.opt vs. dsm.sys for server #2 -
it will likely take the first available stanza that matches -
so it could still then go to the wrong server...

No need to confuse it :)
nodename within the stanza can be the same -
however, you need it to look similar to this to work:

Stanza #1 (to match OLD DB2 dsm.opt)
--------------------------------------
~ SErvername nodename_orig_SID_DB2
COMMMethod TCPip
TCPPort 1500
~ TCPServeraddress old_server_ip
~ NODename nodename_SID_DB2
TCPClientaddress client_IP
PASSWORDAccess generate
SCHEDmode prompted
inclexcl /path_to_db2/inclexcl.txt


Stanza #2 (to match NEW DB2 dsm.opt)
--------------------------------------
~ SErvername nodename_new_SID_DB2
COMMMethod TCPip
TCPPort 1500
~ TCPServeraddress new_server_ip
~ NODename nodename_SID_DB2
TCPClientaddress client_IP
PASSWORDAccess generate
SCHEDmode prompted
inclexcl /path_to_db2/inclexcl.txt

(impt things to note above have the ~ in front of them)
Note that SEvername's value can be whatever you want -
it's the TCPServeraddress piece that really matters on where the data goes to -
and nodename should ideally be the same nodename as on the TSM side as well.

Hope that helps -
-Chef.
 
Last edited:
PREDATAR Control23

Hi.
Of course, that is my situations, right as you describe it.
And about "nodename" i refer to the nodename reported in different stanza of same dsm.sys
>> nodename within the stanza can be the same -

My problem is that if i try to run the script for the backup in the DB2 machine (the script is the db2backup.ksh), it connects itself to the old tsm server.
I think that somewhere there's a variable that tell to db2 where find the dsm.opt file.
I check the .bashrc and .bash_profile of user adminpo, but nothing there.

I see that in that folder reside also another file (i don't remember which) that user must compile and where was possible to define some variable to dsm.opt.
I read also that :
(http://www.ibm.com/developerworks/db2/library/techarticle/dm-0501zikopoulos/)
""
Setting up DB2 to use TSM is simple.

First, you need to run the dsmapipw utility (as a user with administrative authority) to set the TSM password. This utility is located in the sqllib\adsm directory. This utility encrypts and stores the TSM password for the node on disk. Failure to perform this step alone is responsible for about 60% of the problems that people run into when using TSM and DB2. If the password isn't set correctly, you will receive a 137 error code.

Next, export the DB2 TSM-specific environment variables. There are three environment variables that can be set:

* DSMI_DIR is the directory where the TSM client is installed.
* DSMI_CONFIG is the configuration where you set up TSM.
* DSMI_LOG specifies the files where any errors are written.
""
Any suggest??
Thanks!!
 
PREDATAR Control23

Suggest - try typing "env" as the DB2 user and look for the DSM/DSMI profile stuff.
If you find it, then it is being puilled from the profile somewhere.
If not, well...keep looking I guess...

Here's how I setup my profile for DB2 backups (for the specific instance user):

setenv DSM_DIR /usr/tivoli/tsm/client/ba/bin
setenv DSM_CONFIG <db2 user instance home>/sqllib/tsm/dsm.opt
setenv DSM_LOG <db2 user instance home>/sqllib/tsm
setenv DSMI_DIR /usr/tivoli/tsm/client/api/bin64
setenv DSMI_CONFIG <db2 user instance home>/sqllib/tsm/dsm.opt
setenv DSMI_LOG <db2 user instance home>/sqllib/tsm

I just add the DSM stuff to be sure the env variables are all overwritten properly.
If you think your env is pointing to the wrong place, this could very well be the reason...

Also, are you telling me you already set this up for the new TSM server, and ran the passwd utilty ok - or no?
 
Last edited:
PREDATAR Control23

Thanks.
I'll try to see the environment variables.
If here is the problem, i'll modify the backup script (also for the old tsm server) adding on the top a section where "setenv .. " all needed variables.
(for example:
#!/bin/ksh
##set variables
setenv DSM_DIR /usr/tivoli/tsm/client/ba/bin
setenv DSM_CONFIG /home/adminpo/sqllib/tsm/dsm.opt #in the other script it will be: /home/adminpo/sqllib/tsm54/dsm.opt
setenv DSM_LOG /home/adminpo/sqllib/tsm #in the other script it will be: /home/adminpo/sqllib/tsm54
setenv DSMI_DIR /usr/tivoli/tsm/client/api/bin64
setenv DSMI_CONFIG /home/adminpo/sqllib/tsm/dsm.opt #in the other script it will be: /home/adminpo/sqllib/tsm54/dsm.opt
setenv DSMI_LOG /home/adminpo/sqllib/tsm #in the other script it will be: /home/adminpo/sqllib/tsm54

## do Backup online
db2 backup db DBONE online use tsm
db2 backup db DBTWO online use tsm
)
In this way if i'll run one or another script, i'll have always the right env.
Of course: it's better to not run either the scripts in the same time :)

Do you think it could be an idea?
 
PREDATAR Control23

Another thing:
>> and ran the passwd utilty ok

I think i must use the dsmapipw utility..can you explain me shortly how?
Thanks!!!
 
PREDATAR Control23

Are you going to back this one DB2 instance up to both TSM servers then?
You may want to test that extensively if so...I am not 100% sure but I do think the script itself should overwrite the env variables in this case...

As far as dsmapipw -

As the db2user, su root
then go to the dsmapipw dir and run
./dsmapipw
 
Last edited:
PREDATAR Control23

Hi and thanks.
Yes, i want to backup this db2 istance to both TSM servers...
Rigth to test that backup works well, for about one week.

I test to setenv / export some environment variables; the environment variables values don't change for system (for all user), but only for the user that run the setenv / export.
It seems to be good and usable.

Later i'll test for the dsmapipw...
 
PREDATAR Control23

Ok, i'm here.

So, i do the following test (after the steps above described):
- update the DSMI_DIR, DSMI_CONFIG, DSMI_LOG environment variables for db2 istance user (now point to the new tsm 5.4 dsm.opt file);
- update the DSMI_DIR, DSMI_CONFIG, DSMI_LOG environment variables for root user (need to do this to run dsmapipw);
- run the dsmapipw utility: new file TSM.PWD created (so the command works well);

Now, i try to do a backup, but in spite of new env. variables, backup still use the old tsm istance.
The only way to do the backup work correctly (backup to new TSM server) is restarting DB2 server.
(or move the new dsm.opt in the folder where resides the older dsm.opt, but it's quite dangerous...).

I read infact "DB2 only reads the DSMI environment variables at the time when db2start is issued. (redbook SG246247)".

Is there a way to force the DB2 server to re-read this variable without restart it??
Or is there any other way to do this job?

Thanks...
 
PREDATAR Control23

Do not do this step:

update the DSMI_DIR, DSMI_CONFIG, DSMI_LOG environment variables for root user (need to do this to run dsmapipw);

"su root" from the db2user keeps the db2users' profile -
so no further action is needed there.

Restarting the DB2 server will do you no good here -
Unless you did something funky within DB2, forget about this.

This is purely an env/setup issue -
nothing to do with DB2 specifically.

I can't think of anything else, if you have pointed all the ENV DSMI & DSM files to the right dsm.opt and set the passwd to the new TSM server, then that's about all the help I can offer...
 
PREDATAR Control23

A thought to try -

Lock the node on the new TSM server
Run dsmapipw until you get a "locked node" error...

Then you will know you are at least hitting the right server...
 
PREDATAR Control23

Thanks.
I confirm i have update all env. variables and run the dsmapipw with good results, but without restart DB2 there is no way to use the new dsm.opt (using the new env. variables).
After DB2 restart (with new env. variables) backup is done to the right tsm server.
But i cannot restart DB2 every day ... :-(

I hope i find a way; if so i'll post it here :)
 
PREDATAR Control23

Why do you think you have to restart DB2 to use the new DSM.OPT file???
This is absolutely NOT true -

(Unless you ran a "db2set" for the file -
which is NOT necessary anyway...I would not do it that way...)

dsm.opt file is a TSM setup file.
It is independent of DB2.

If anything, maybe you are confusing this with the scheduler?
The scheduler would have to be bounced to re-read in any changes to the dsm.opt file.
But in this case, new dsm.opt means new scheduler -
so this should not apply.
 
Last edited:
PREDATAR Control23

Hi.
Of course dsm.opt file is a tsm file.
But when you backup a db2 db with (for example):
"db2 backup db sample use tsm"
db2 must know how to contact tsm server.
Of course, using the api, but trought the DSMI_CONFIG env. var. defined file.

But the DSMI_* env. var. are readed by DB2 server when it is started.
So, if you after 1 hour (for example) change the DSMI_* env.var (for example, you set DSMI_CONFIG=mickeymouse), you'll see that DB2 server continue to backup without problem.

"DB2 only reads the DSMI environment variables at the time when db2start is issued. (redbook SG246247)".

If you want i can post all my test, to confirm that.
Thanks!


You can try, as i've done.
 
PREDATAR Control23

Thanks.

I've download yesterday a virtual machine from novell site (link from vmware : http://www.vmware.com/appliances/directory/812), that is a demo machine:
"IBM DB2 Express and WebSphere Community Edition running on Novell SUSE Linux Enterprise Server 10"

So i can try for 2 days (and night) all the way above described.
I've installed TSM API & BA on it and start.

I can assure that is ALL true..
Bye!
 
Top