we currently use TSM for our backups. We totally have two different TSM servers. Our test backups point to TSMserver1 and Production backups point to TSMserver2.
When I do a redirected restore from production to test, I need to change the TSM server of the test databse to point to TSMServer2 in the dsm.opt file and give the db2adutl grants for the production backup so that the test server could see it. After that I can run a restore on test database.
Is there anyway to do the redirected restore without changing the TSM server ?
In the link which you provided its been talked about "password = prompt" and "password = generate" environments. Our environment is "password = genearte" environment but we have two different TSM servers . The tsm server name is provided in dsm.opt file.
Considering the first example "password = generate" in the link which you provided, the node dps could read the backups, logs and load copy images of the first db zample by this command "db2adutl query db zample nodename bar owner roecken" provided db2adutl grants are granted and both the nodes have a setting of the same TSM server in dsm.opt file.
My question is what if node BAR has the TSM setting of TSM server1 and node dps has the setting of TSM server2 in dsm.opt ? All I do is to change the setting of node dps to point to TSM server1 after which dps could read the backups of zample database. But is there any other way this can be accomplished without changing the TSM server in dsm.opt file
I don't see any option to override the TSM server name on the restore command. So, you need to modify TSM server name in dsm.opt (what you're currently doing) or possibly modify TSM server address in dsm.sys. Or create two dsm.opt files (one points to test TSM server and the second one points to prod TSM server). You will also need to have two entries in dsm.sys. But you'll need to modify dsmi_config to point to prod's dsm.opt and restart the instance prior to restoring the db. I don't really see any other way.
I have the entries of TSM server1 and TSM server2 in dsm.sys file. I also have two server names in dsm.opt file with one commented out. Whenever I wanted to do such redirected restores, I swap the commented server name with the other one. That is all !!!The backups and log archivals will then start going to the new TSM server.
Can you please explain what do you mean by "But you'll need to modify dsmi_config to point to prod's dsm.opt and restart the instance prior to restoring the db".
As soon as I change dsm.opt file to point to prod TSM server, I can start seeing the prod backups and restore starts working. But I don't really restart the instance and change any other configuration
The reason you don't need to restart the instance is because you're using one dsm.opt file (with one server commented out). If you were using two opt files (ie. dms.opt.test to point to test TSM server and dms.opt.prod to point to prod TSM server), then you would have to restart the instance for DSMI_CONFIG change (this would have to be changed to point to prod TSM server if you were using two opt files) to take effect.
I just did that experiment. I didn't need to restart the instance for it. All I need is to export the DSMI_CONFIG with the new filename. It starts taking the new dsm.opt file.
Here is what I did
$ env | grep -i dsmi
You were right. Backup got stored in the TSM file defined in the file DSMI_CONFIG=/usr/tivoli/tsm/client/api/bin64/dsm.opt
$ db2 "force applications all" ; db2 "deactivate db sample" ; db2 "backup db sample use tsm"
DB20000I The FORCE APPLICATION command completed successfully.
DB21024I This command is asynchronous and may not be effective immediately.
DB20000I The DEACTIVATE DATABASE command completed successfully.
Backup successful. The timestamp for this backup image is : 20100409172955
$ db2adutl query full db sample
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.
I kind of forgot about not needing to restart the instance for db2adutl