Backing Up Oracle - Computing at Cornell

4.6 TSM server considerations for Oracle backups
Whenever you use the TSM server to backup and restore data objects, it is of
the utmost importance to consider which management class the data objects
will be bound to. This is true of both API and backup-archive clients. Failure
to do so will result in storing the data objects in one of three situations:
too long, too short, or just right.
It is highly unlikely that you will manage the objects “just right” if you do not
take the time to define your storage requirements, configure the TSM server
appropriately, and configure the TSM client to use the correct management
classes. If you store the data objects for too long, then you waste space and
storage resources on the TSM server. If you store the data objects for too
short a time, then you do not have the required files when you need them.
Each of the TDP products and any product that uses the TSM API should
have a section in the documentation that describes exactly what retention
settings the product uses and how to bind the data objects to the appropriate
management class. The TSM server cannot and does not know how long a
client program needs to keep the data objects. This must be done by the
client.
4.6.1 How TDP for Oracle stores data objects
Database objects stored on the TSM server by TDP for Oracle are stored as
backup objects. Each Oracle backup is stored as a unique object by
generating a random character string as the low level qualifier (LL_NAME).
The RMAN script can control what the LL_NAME or backup piece name is by
using the RMAN format command.
If using the format command, you should generate unique backup piece
names by either random character string (%U option) or timestamp (%s and
%t). This is documented in the Oracle RMAN manual. Failure to do so will
cause inconsistency between the RMAN catalog and the TSM server.
Using unique names means that the Oracle backups must be manually
inactivated. This is done by allocating a channel for deletion using the same
nodename and filespace name that was used to perform the initial backup
(see 9.6.6, “Deleting the backup piece from RMAN” on page 139). This also
means that the management class to which the backup objects are bound
should have retention settings that change the inactivated backup objects to
be expired immediately. The retention settings for a backup copy group that
would facilitate this is RETONLY=0 and VERDELETED=0.
Chapter 4. TSM server considerations 47