How to get DB2 back up to different nodes

Status
Not open for further replies.

Spree

ADSM.ORG Member
Joined
Jan 17, 2012
Messages
27
Reaction score
0
Points
0
Hi,

My client has 3 types of retention requirements: daily, monthly and yearly, with separate client nodes / policy domains / storage pools required.
For DB2, they have 1 instance and a few databases.

I need to get the DB2 databases backed up to different TSM nodes. I have no problem getting DB2 backing up to a single TSM node, but I have no idea on how to get them backed up to multiple TSM nodes.

What makes it seemed impossible is, the system variables (DSMI_CONFIG, DSMI_DIR, DSMI_LOG) needs to be configured and then the instance needs to be restarted (db2stop + db2start) to retrieve the updated configuration, but this is impossible to be done as the databases should be always up.

DB2 is 9.7 and TSM is 6.2.4.0. Any help will be much appreciated, thanks!
 
You can't point a DB2 node to backup to multiple TSM servers without configuratikon changes and doing the STOP/START routine.

Here's a thought (a 'thought' since I have not tested this): Why don't you use just one TSM server but setting up a multiple stanza dsm.sys file (I am hoping that your DB2 is running on Unix/Linux) and point to whatever stanza that has different policies?
 
You can't point a DB2 node to backup to multiple TSM servers without configuratikon changes and doing the STOP/START routine.

Here's a thought (a 'thought' since I have not tested this): Why don't you use just one TSM server but setting up a multiple stanza dsm.sys file (I am hoping that your DB2 is running on Unix/Linux) and point to whatever stanza that has different policies?

Forgot to mention. Yes, DB2 on AIX. Dsm.sys of course can have multiple "servername" stanzas, currently my setting is a few different dsm.opt (e.g. dsm_daily.opt, dsm_monthly.opt, dsm_yearly.opt) pointing to the same dsm.sys. But the "DSMI_CONFIG" parameter needs to point to the dsm.opt file, not the dsm.sys file... And this is where the problem arises.
 
Then run scripts to change the environmental variables on the 'fly' - I believe this may work if you have the dsm.sys setup correctly. No need to stop and start.

Again, saying this based on experience - I haven't tried this approach :) - give it a try if you have not yet.
 
I think you could use multiple dsmcad daemons where each one specified a different option file using the -optfile command line option. I used to do this with multiple Domino clients on the same server.

dsmcad -optfile=monthly.opt
dsmcad -optfile=daily.opt
dsmcad -optfile=yearly.opt
 
Backups under 1 node:
- Correct approach would be to define database aliases for db.
ie
PRD_MONTH, PRD_YEAR pointing to same database PRD
- Then you can backup them as different databases and keep different setting for each alias, setting specified backups as 'never expire', etc

Backups under different nodes:
(taken from production system)
db2 -v "BACKUP DATABASE ${DBNAME} ONLINE USE TSM OPEN ${SESTSM} SESSIONS options '"${VserverTSM}"' WITH 4 BUFFERS BUFFER 4096 PARALLELISM 2 WITHOUT PROMPTING"

Variable VserverTSM contains "-SE=DB2_DAY" or "-SE=DB2_MONTH" or "-SE=DB2_YEAR"

Then expiring of backups
DSMI_CONFIG=$VconfigTSM
export DSMI_CONFIG
#
db2adutl delete full keep ${KEEP_DAYS} db ${DBNAME} nodename ${NodeTSM} without prompting


Variable VconfigTSM contains full path to .opt file

opt file contains only link to stanza in dsm.sys!
DMV01:db2prd 12> cat /db2/db2prd/tsm/dsm_PRD_day.opt
SErvername PRDDAY
 
Status
Not open for further replies.
Back
Top