Oracle RMAN is a fully functional backup utility that provides unparalleled functionality, particularly in a high-availability environment. However, one thing RMAN cannot do by itself is 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 MML is provided by a third-party vendor (unless you are using Oracle Secure Backup—see “Oracle Secure Backup and the OSB Cloud Module” a bit later) and is written specifically to receive data from an RMAN backup session and redirect it to tape. Common media management products include Symantec NetBackup, EMC NetWorker, HP OpenView 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. RMAN can locate the library file provided by the media management vendor in two ways: 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 or 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.
If you are looking for the default libobk.so file, you won’t find it, because it’s no longer included with the installation (hasn’t been since 8i). This file will exist only in the $ORACLE_HOME/lib directory if it is created by your media management provider (therefore, not default). Instead, you now specify the SBT library file as a value in the PARMS specification of your tape channel allocation. This is the approach recommended by Oracle, because it is more specific and requires less work in the Oracle software stack.
RMAN> configure channel device type sbt parms='SBT_LIBRARY=/fullpath/ libraryfilename';
Believe it or not, many media management vendors still use the libobk.so symbolic link. Refer to your vendor documentation to find out.
If you want to test a tape channel usage using the Oracle-provided default SBT interface, you can specify it at the PARMS line, as noted earlier, and then you provide an additional ENV variable for the place on disk to which you would like to write the tape backup:
RMAN> configure channel device type sbt parms 'SBT_LIBRARY=oracle .disksbt, ENV=(BACKUP_DIR=/nas/fake_tape_backups)';
NOTE
It’s not a good idea to take your production-level backups using the disk SBT file (it is not supported). 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.
Once you have configured your SBT device, you can then back up the FRA to tape (remember our preferred MAA backup strategy) as follows:
RMAN> backup device type sbt tag "fra_backup" recovery area;
How do we restore the FRA from tape? When we back up the FRA, we are essentially backing up our backups. That said, it really doesn’t make sense to restore a backup of a backup to restore our database. As you can imagine, that would be far too time-consuming. For this reason, FRA backups can be used directly to restore the respective database just like any other backup to tape would be used.
Backing up directly to tape
We’ve covered the use of the FRA as a staging area for backups: first the backups go to disk, and then, after a predetermined amount of time elapses, we move the backups to alternate media such as tape. However, in your environment, backups might need to 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 simply schedule your backups.
RMAN> configure default device type to sbt; RMAN> configure channel device type sbt parms = 'SBT_LIBRARY=/fileloc/ libobk.so, EN=(NB_ORA_SERV=ratlnx01,NB_ORA_CLASS= oracle)'; RMAN> configure device type sbt parallelism 4; RMAN> 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 (same as we discussed for disk backups). Multiple channels run simultaneously to speed up the backup process. However, seriously bad side effects can occur during restore 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, 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 backup set (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 backup set 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 or single data block.
In the best possible scenario, you can write to dozens of tape devices simultaneously during a backup so that you can set a higher level of parallelization during backup where only one backup set is being written to any one tape at a time. Then you set filesperset=1 at the time of backup so that every backup set contains only 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.
Oracle secure backup and the OSB cloud module
With all this talk about tape backups, you may be thinking, “But I don’t have a media manager in my environment.” No problem, Oracle Secure Backup (OSB) will provide this functionality for you. OSB is a complete tape backup solution designed for Linux, Windows, and Unix file systems as well as database files through its tight integration with RMAN.
No access tape device? Well, no problem there either. With Oracle Database 11g Release 2 you can utilize the OSB Cloud Module allowing for the integration of RMAN with the Internet-based Amazon Simple Storage Service (S3) to facilitate your tape backup and offsite backup storage needs. Since these technologies are beyond the Grid Infrastructure and database scope, they are indeed beyond the scope of this book; however, you should be aware that these services are available. More information on OSB and the OSB Cloud Module can be found on the Oracle Technology Network.
Leave a Reply