Oracle and TSM for Databases: Part 2

Posted by on Jun 30, 2011 in Databases, Infrastructure, Oracle, TSM | 4 Comments

In the first installment of this series, I discussed some of the basic concepts in using Tivoli Storage Manager for Databases to backup and recover Oracle databases.  In this installment, we’ll look at how to keep TSM and Oracle in sync.

When backing up a typical filespace, the TSM backup-archive (BA) client compares what files and directories are on the node to what is in the TSM database.  Any new or changed files and directories are added to the TSM database and copied to the appropriate storage pool managed by the TSM server.  Expiration of these backups is handled by the TSM server, which compares its retention policies to its database.

However, when backing up a running (“hot”) Oracle database, the process changes.  Rather than the TSM client managing the backups, the Oracle backup utility, RMAN, performs this function.  RMAN determines which files need to be backed up, and hands them to TSM.  Keeping track of which files are needed for restores, or are ready to be expired, is handled by RMAN.  It then instructs TSM what to do with the files.  As you may have guessed, RMAN keeps track of objects in its own database, called a catalog in Oracle parlance.  Without a catalog, objects are tracked in the control files, which can only contain so many references.  Once you reach the limit…you loose reference to your database backups.  So, let’s not do that.

Create the catalog on a separate Oracle database.  Please note that these instructions are for a single instance (RAC may be different).  Always read the documentation and/or talk to your DBA before copying and pasting things from the Internet.  Better yet, just create a test instance and see what happens…

Connect to the instance where you will create the recovery catalog as a user with SYS or SYSDBA privileges, and issue the following command to create the user/schema which will be used for the catalog:

CREATE USER rman IDENTIFIED BY cat
  TEMPORARY TABLESPACE temp
  DEFAULT TABLESPACE tools
  QUOTA UNLIMITED ON tools;

Grant the RECOVERY_CATALOG_OWNER role to the schema owner you just created (“rman”):

GRANT RECOVERY_CATALOG_OWNER TO rman;

Create the recovery catalog:

[oradood@bigserver1 ~]$ rman catalog rman/cat@catdb
RMAN> create catalog;

Register the database in the catalog.  Note that “target /” refers to the local database:

[oradood@bigserver1 ~]$ rman target / catalog rman/cat@catdb
RMAN> register database;

Note that multiple instances can use the same catalog.  You do not need to create a separate catalog for every instance you want to backup.

Once the database has been registered, add the catalog reference to your RMAN scripts.  Don’t forget to add the catalog reference to your scripts that backup your archived redo logs, delete obsoletes, etc.:

#!/bin/bash
# Backs up Oracle database through RMAN using TSM as the MML
# Includes archived redo logs but does not delete them from disk,
# so that they will be included in the regular system backups.
export ORACLE_HOME=/path/to/oracle/home
export ORACLE_SID=bigdb
export TNS_ADMIN=$ORACLE_HOME/network/admin/bigdb_hostname
$ORACLE_HOME/bin/rman target=/ catalog rman/cat@catdb << END_OF_RMAN
RUN
{
allocate channel t1 device type sbt_tape parms
'ENV=(TDPO_OPTFILE=/home/oradood/bin/tdpo_bigdb.opt)';
BACKUP DATABASE;
RELEASE CHANNEL t1;
}
END_OF_RMAN

Now when RMAN performs backup, expiration, and restore operations, it will connect to the catalog server, where information on all of the instance’s backups are kept.

So, now we have RMAN keeping track of objects in its catalog and using TSM to store them.  How do we know if things exist in TSM and not in the catalog, or vice versa?  And what can we do about that?  Glad you asked, because that brings us to the next utility, tdposync.

IBM supplies the tdposync utility to keep the catalog and TSM in sync.  If there are objects in one and not the other, it will show you the discrepancies and give you the option to correct them.

[oradood@bigserver1 ~]$ /opt/tivoli/tsm/client/oracle/bin64/tdposync syncdb

You will be prompted for Catalog 1 User Name (“rman” in our example), Catalog 1 Password (“cat”), and the Catalog1 Connect String (the SID of the catalog, “catdb”).  And then from and to dates.  Tdposync will connect to the catalog and to TSM, and compare the two.    If there are no differences, you will get the slightly cryptic success message:

The TSM Server is Synchronized with the Oracle Catalog or there
are no matching files in the requested filespace.

If tdposync finds discrepencies, it will give you a listing of the differences and a text menu to let you decide what to do.

But wait!  Before blowing away any potentially good backups (and therefore, recoveries, and maybe your job), see if you can get RMAN to sync the catalog with the control files.  I have seen situations where the catalog is not updated with the latest backups.

[oradood@bigserver1 ~]$ rman target / catalog rman/cat@catdb
Recovery Manager: Release 10.2.0.3.0 - Production on Thu Jun 30 15:55:20 2011
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
connected to target database: BIGDB (DBID=1234567890)
connected to recovery catalog database
RMAN> resync catalog;
starting full resync of recovery catalog
full resync complete

If not, rerun tdposync and work with a small date range to see if that resolves your issue.

References

Part one:  http://www.lanigera.com/wordpress/2011/02/oracle-and-tdp-part-one/

See the Oracle Database Backup and Recovery User’s Guide for documentation on creating a recovery catalog

See the RMAN Compatibility Matrix to verify that your target and catalog databases are compatible