Many of the directory and file names mentioned below will be site specific. For the sake of illustration, I'm assuming that Oracle was installed with a userid called 'oracle' and the main control files are located in /u01/app/oracle/admin/tsm_rman. We are backing up a database called PBW on an AIX server called U20614P545 to a TSM server called P2XT1, which has an IP address of 19.66.123.123
The Oracle TDP is installed in /usr/tivoli/tsm/client/api/bin64 and TSM itself can be found in /usr/tivoli/tsm/client/ba/bin64.
First install the Oracle TDP software. The TSM TDP for Oracle interfaces with Oracle RMAN, the integrated Oracle backup and recovery tool. RMAN understands how the Oracle databases and recovery logs fit together, so we don't need to. Essentially, TSM is just used as a back-end data store. The one thing you will need to understand is the RMAN options file, which is usually created by your DBA and held in the Oracle data space.
Every database will have an RMAN options file which basically defines some environment variables. The location of these files will be site dependent. At a minimum they should set three DSMI variables as shown below.
DSMI_LOG /u01/app/oracle/admin/tsm_rman
DSMI_DIR /usr/tivoli/tsm/client/api/bin64
DSMI_ORC_CONFIG /usr/tivoli/tsm/client/api/bin64/dsm.opt
It's useful to know where the RMAN logs are kept, as specified by the DSMI_LOG parameter, as you might need to check these out if you get problems.
DSM_DIR tells RMAN where you installed the TDP code, /usr/tivoli/tsm/client/api/bin64 is the default location.
DSMI_ORC_CONFIG points to the Oracle dsm.opt file
Some sites like to keep all their TSM option files together, so they keep the ORC_CONFIG file in the default TSM installation directory, usually /usr/tivoli/tsm/client/ba/bin64/ and call it something like dsm_ora.opt to distinguish it from the normal dsm.opt file. In this case you either need to change the DSMI_ORC_CONFIG parameter to point to the correct file and path, or you need to add a symbolic link from /usr/tivoli/tsm/client/api/bin64/dsm.opt pointing to /usr/tivoli/tsm/client/ba/bin64/dsm_ora.opt.
Other sites are quite happy to have a 'normal' dsm.opt file in ba/bin64 and an 'oracle' dsm.opt in api/bin64.
All the oracle dsm.opt file needs to contain is
Servername P2XT1_ORA
Other parameters that you might see include
TDPO_FS PBW
Ths is the filespace name used at the TSM server for this database. The default is adsmorc. In this case the database is called PBW, so we are calling the filespace PBW
TDPO_NODE U20614P545_ORA
The TSM node name that will be used to backup this database
TDPO_PSWDPATH /u01/app/oracle/admin/tsm_rman/password
See below
TDPO_OWNER oracle
The userid that 'owns' the TDPO process
You also need to add at least one extra stanza to your dsm.sys file for Oracle database backups. This will typically look like
** Oracle backup stanza
servername P2XT1_ORA
commmethod tcpip-tsm
tcpserveraddress your_tsm_server_address
tcpport your_tsm_server_port
webports 1504,0
nodename U20614P545_ORA
errorlogname /usr/local/logs/U20614P545__ORA_dsmerror.log
errorlogretention 30d
passwordaccess prompt
enablelanfree yes
lanfreecommethod tcpip
lanfreetcpport 1510
Older Oracle backups needed a separate stanza from scheduling, like this
** Oracle backup scheduling stanza
servername P2XT1_ORA_SCHED
commmethod tcpip-tsm
tcpserveraddress your_tsm_server_address
tcpport your_tsm_server_port
webports 1505,0
nodename U20614P545_ORA
errorlogname /usr/local/logs/U20614P545__ORA_dsmerror.log
errorlogretention 30d
schedlogname /usr/local/logs/U20614P545__ORA_dsmsched.log
schedlogretention 30d
passwordaccess generate
passworddir /etc/security/tsm/P2XT1_ORA
managedservice schedule
schedmode prompted
After you configure the option files as above, you may need to set the TDP password. To do this, you run the tdpoconf command
tdpoconf password -tdpo-optfile=/u01/app/oracle/admin/tsm_rman/PBW_tdpo.opt
You will then need to input the password for the TSM Oracle node 3 times. If you need to create the oracle password directory you should assign ownership to the 'oracle' userid (or whatever userid you use to manage oracle) as follows. This links to the RMAN option, TDPO_PSWDPATH /u01/app/oracle/admin/tsm_rman/password
Navigate to the tsm_rman directory, then run
mkdir password
chown oracle:oracle
chmod 770 password
Make sure that you have a licence file, /usr/tivoli/tsm/client/oracle/bin64/agent.lic
Then check that 'oracle' can update the TSM logs (666) and can read all the tsm option files (644)
All database backups have unique names, and backup retention is controlled by RMAN, so you must set backupdelete=yes. Your oracle management class should be set to keep just one active backup forever, with retonly and verdelete parameters both set to 0.
Define the client on your TSM server as U20614P545_ORA, the only difference from your standard UNIX clients would be that you set backupdelete=yes and may invoke the oracle management class with a special client optionset that picks up a database management class. Oracle clients also usually have maxnummountpoints set to 2.
Start up the oracle client with dsmc -server=P2XT1_ORA and set the client password when prompted.
Finally, check the RMAN setup is working with the showenv option on the tdpoconf command;
tdpoconf SHOWENV -TDPO_OPT=/u01/app/oracle/admin/tsm_rman/PBW
We often get requests for special oracle database backup retentions, but these are also controlled by RMAN. Special backups can be retain for longer than the default cycle using the RMAN command, 'CHANGE BACKUPSET TAG ... KEEP UNTIL ...', usually controlled and issued by your DBA.
Oracle backups can fail with timeout errors, but one issue is that the error message does not make it clear that this is the problem, A typical error message might look like:
Oracle: RMAN output
- - - - - - - - - -
ORA-27192: skgfcls: sbtclose2 returned error - failed to close file
ORA-19511: Error received from media manager layer, error text:
ANS1235E (RC-71) An unknown system error has occurred ...
When an oracle backup starts, it often sits for quite a while waiting, while RMAN is calculating what it needs to back up. This wait time can be several minutes for a multi-terabyte database. I've seen an IBM recommendation that to calculate the best timeout values to use, you estimate how long your backup will run, then add an extra 50%. So if you expect a database backup to run for about 2 hours, plan timeout values at 3 hours, or 180 minutes, or 10800 seconds.
If you are running TSM 6.3 or above you can set these values dynamically from your TSM server by running the following commands. Note that commtimeout is set in seconds, but idletimeout and resourcetimeout are in minutes.
setopt commtimeout 10800
setopt idletimeout 180
setopt resourcetimeout 180
For earlier versions of TSM you need to set the values in the server .opt file, then recycle the server.
If you use separate library manager, then you need to set the timeout values on both the library manager server and the client manager server. If you are using LanFree, you have to to set the timeout values on the StorageAgent. All the TSM servers that are involved in the backup must be set with the same, or greater values.