Media Management Considerations

---

RMAN is a fully functional backup utility that provides unparalleled functionality, particularly in a high-availability environment. However, there is one thing RMAN cannot do by itself: back up directly to tape. To back up directly to tape, RMAN must pass the stream of data blocks to a media management layer (MML), which can redirect the data flow to a media management server that controls your tape devices.

The SBT Interface

The media management layer is provided by a third-party vendor, and is written specifically to receive data from an RMAN backup session and redirect it to tape. Common media management products include Veritas NetBackup, Legato Networker, HP Omniback, and Tivoli Data Protection. These vendors provide an Oracle integration file called the SBT library, which gets loaded by RMAN into the Oracle memory stack when a tape channel is allocated for backup. There are two ways that RMAN can locate the library file provided by the media management vendor: the file can be symbolically linked in the $ORACLE_HOME/lib directory, or you can call the sbt_library as a parameter in the channel allocation command.

Prior to version 9i, Oracle looked to load the SBT library by initializing the file $ORACLE_HOME/libobk.so (or libobk.a, libobk.sl, depending on the operating system). This file is merely a symbolic link file that is re-created to point to the actual SBT library file provided by the vendor. By default, this pointed to a dummy sbt library file provided by Oracle, libdsbtsh8.so. This file allowed you to allocate a tape channel and then back up to disk, so that tape channels could be tested and debugged. To use the default SBT interface, you had to set the environment variable BACKUP_DIR to a disk location. In Oracle9i and Oracle Database 10g, you no longer have a libobk.so file by default. This file will only exist in the $ORACLE_HOME/lib directory if it is created by your media management provider.

Instead, you now specify the sbt library file as a value in the PARMS specification of your tape channel allocation. This is the recommended approach by Oracle, as it is more specific and requires less work in the Oracle software stack.

configure channel device type sbt parms= "SBT_LIBRARY=/fullpath/libraryfilename";

Many media management vendors still employ the usage of the libobk.so symbolic link. Refer to your vendor documentation to find out.

If you want to test out tape channel usage using the Oracle-provided default SBT interface, you can specify it at the PARMS line, as noted above, and then you provide an additional ENV variable for the place on disk you would like to write the tape backup to:

configure channel device type sbt parms= "SBT_LIBRARY=oracle.disksbt, env = (BACKUP_DIR=/u02/backup); 

You should know that it is not a good idea to take your production-level backups using the disk sbt file. This gives you all the drawbacks of backing up to tape and none of the benefits of backing up to disk. It is merely a troubleshooting or proofing exercise.

Backing Up Directly to Tape

We have talked already about using the flashback recovery area as a staging area for backups: the backups go to disk first, and then after a predetermined amount of time elapses, we move the backups to tape. However, it may be that in your environment, you require that backups go directly to tape.

Configuration for backing up directly to tape is pretty straightforward. Change your default device to SBT. Configure your SBT channels to contain the proper PARMS values to match your media management setup. Determine your level of parallelization and multiplexing. Then you schedule your backups.

configure default device type to sbt; configure channel device type sbt parms =    "SBT_LIBRARY=/fileloc/libobk.so,    ENV=(NB_ORA_SERV=linx01, NB_ORA_CLASS = oracle)"; configure device type sbt parallelism 4; configure channel device type sbt filesperset=4;

Determining Parallelization and Multiplexing

Parallelization refers to the number of tape channels you allocate simultaneously for an RMAN backup. Multiple channels run simultaneously to speed up the backup process. However, there are seriously bad side effects during restore that occur if your allocated channels during backup outnumber the tape devices that will house the backup pieces. If you allocate two channels, and you have only one tape device, then the two backup sets will be interspersed together on the same tape. On restore, unless you are restoring the entire database, you will have to read through a lot more tape to get access to all the writes that are required for the restore.

The same problem applies to multiplexing. If you do not limit the number of files that go into each backupset (filesperset greater than 1), you will have to wait longer for a single file restore. During the restore, RMAN will have to read the entire backupset into a memory buffer at the target database to determine which blocks are needed for the one file being restored. So, the more files you multiplex, the longer you will have to wait and the more network bandwidth is used during the restore of a single datafile.

So the best possible scenario is one in which you have dozens of tape devices that you can write to simultaneously during a backup, so that you can set a higher level of parallelization during backup where only one backupset is being written to any one tape at a time. Then you set filesperset=1 at the time of backup, so that every backupset only contains one file. If this is not possible in your environment, try coming to terms with some middle ground for your multiplexing solution. One channel per tape device is pretty much set in stone, so what you are determining is a cost-to-return ratio between how long you can run your backup, and how long it will take to restore a file during recovery.

---