Oracle RMAN 11g Backup and Recovery (51 page)

This is a great test if you are trying to troubleshoot possible problems with your media manager backup solution and cannot get the backups to work. By allocating a “fake” tape channel, you can see that RMAN is configured correctly.

CAUTION

Do not use the test MML file for production backups. If you will

be backing up to disk in a production environment, allocate a disk

channel. The performance of the fake MML is terrible, because RMAN

is allocating memory buffers for tape, not disk, and therefore is not
taking advantage of the speed of disk writes versus tape writes.

Chapter 4: Media Management Considerations
107

If you have not successfully loaded your vendor’s MML file and you do not specify in the PARMS section of the channel allocation that you want to use Oracle’s disk SBT interface, you will receive an error when you try to allocate a channel to tape:

RMAN-00571:

RMAN-00569:

ERROR MESSAGE STACK FOLLOWS

RMAN-00571:

RMAN-03009: failure of allocate command on x channel

at 12/05/2005 21:26:43

ORA-19554: error allocating device, device type: SBT TAPE, device name

ORA-27211: Failed to load Media Management Library

Interfacing with the MML

When you are linking Oracle and the MML, you are establishing the means by which RMAN can pass a command that engages the MML and, by extension, the media management client software installed on the database server. But how do you know which media management server to engage?

To specify the media management server, you must pass an environment variable within the RMAN session to specify the server name. We specify the server name as an environment variable when we allocate our tape channel. As you saw in the previous RMAN Workshop, you pass the environment variable by using the PARMS option of the
allocate channel
command. Different media management products have different environment variables that they accept. VERITAS

NetBackup, for example, requires the parameter NB_ORA_SERV:

Allocate channel t1 type 'sbt tape'

PARMS "ENV (NB ORA SERV storage1)";

In the preceding example, the name of the media management server is storage1, and our database server has already been registered in this server and has permission to write to its tape devices.

In addition to passing the name of the server, we can pass numerous other parameters at the time of the channel allocation to take advantage of management functions at the server. For instance, NetBackup offers the ability to specify the class or the schedule to use for this backup, whereas EMC Networker allows you to specify the resource pool. More details on these parameters are given in Chapters 6 and 7.

The SBT API

RMAN can engage different media managers with impunity because it sends the same marching orders no matter what MML has been loaded. Oracle developed RMAN with a generic API called the SBT API, which is provided to third-party vendors that wish to write integration products for Oracle database backups. This API is the means by which RMAN sends commands to the media manager.

The SBT API is responsible for sending the commands to the media management server to initiate the creation of backup files on tape. It also sends commands to search for previous backups based on the file handle in the media manager catalog. It can send commands to remove these backups, as well as write new backups and, of course, read from the backup location. There

108
Part II: Setup Principles and Practices

are two versions of the Oracle RMAN SBT API: 1.1 and 2.0. Version 1.1 was published and used with Oracle 8.0.
x,
and that’s it. Since then, RMAN has made calls to the media manager by using the specifications of version 2.0. You can see this version in RMAN’s output when you run a backup: channel x1: finished piece 1 at 25 SEP 09

piece handle=05kq4cfd 1 1 tag=TAG20090925T102902 comment=API Version 2.0,MMS Version 8.1.3.0

channel x1: backup set complete, elapsed time: 00:00:02

Finished backup at 25 SEP 09

RMAN also returns the version of the MML that it initializes at channel allocation time. This is seen during channel allocation in the RMAN output:

allocated channel: x

channel x: sid 12 devtype SBT TAPE

channel x:
VERITAS NetBackup for Oracle8 - Release 3.4GA (030800)

Not only is this a good way to determine your MML version, but it also means that you have successfully linked in your MML with RMAN—otherwise, it would not be able to extract the version information.

Back Up to Tape: From Start to Finish

In this section, we do a walk-through of a backup to tape and show the different calls made to the SBT API and how they are handled by the media manager. Again, please note that we are giving you a very generic overview, and the specifics are handled by the vendor that writes the integration MML.

When you allocate a tape channel, RMAN spawns a server process at your target database.

This server process then makes a call to the SBT API of sbtinit(). This call initializes the MML file and loads it into memory. It also returns to RMAN the version of SBT API supported by that MML.

After calling sbtinit(), RMAN calls sbtinit2(), which supplies further configuration details to the media manager software.

After RMAN has parsed your backup command, it executes the RPC that makes the call to sys.dbms_backup_restore.backuppiececreate. At this time, the channel process calls sbtbackup(), which handles the creation of the backup piece at the specified tape location. This call informs the media manager that Oracle will begin pushing the flow of data blocks to it, so it should prepare the tape device for the onslaught.

The RMAN input buffers fill up and make the memory-to-memory write to the output buffer.

When the output buffer fills, the channel process calls sbtwrite2(), which performs the write of filled output buffers to the tape location (for more on input buffers, see Chapter 2). Typically, this means engaging the device agent at the media management server in order to access the tape itself.

When all the output buffers for a particular backup set have been cleared out and there is no more work for sbtwrite2(), the channel session calls sbtclose2(). This flushes out any media manager buffers and commits the backup piece to tape.

After we complete the backup piece, the channel process invokes sbtinfo2(), to make sure the media manager catalog has documented the backup piece. It requests the tape, the tape location, and the expiration time of the backup from the catalog. Then, it writes the backup piece handle to the catalog.

Chapter 4: Media Management Considerations
109

After confirming the backup piece location, the channel process calls sbtend(), which cleans up any remaining resources and releases them for other database use. The final action performed is the deallocation of the channel process, which is terminated at the target database.

Restore from Tape: From Start to Finish

Of course, sooner or later all that backing up you’ve been doing will get put to the test, and you will need to perform a restore. As with a backup, the SBT API has a specific series of steps that it goes through during a restore operation in order to get the backups on tape back into place for your database. In this section, we briefly run through the SBT API during a restore operation.

When you allocate the tape channel for restore, RMAN creates a server process at the target database. This channel then calls sbtinit() to initialize the media manager software. This is identical to the initialization that would take place for a backup: the MML file is loaded into memory.

Based on the parameters of our
restore
command in RMAN, RMAN will have checked its catalog to determine the handle name of the backup required for the restore. It then takes this requested backup piece handle and passes it to the media manager by using sbtrestore(). The sbtrestore() function instructs the media manager to prepare the appropriate tape for a restore operation. This means engaging the media manager catalog and finding the appropriate tape, and then (if necessary) passing the command to the robotic instruction set to get the tape. After the tape is loaded, it will need to be rewound to the backup piece starting point.

After preparing the tape for the restore, the channel process calls the sbtread2() function to read the data from the tape device and stream it to the Oracle process. This data is loaded into the input buffers, written to the output buffers, and finally written to the datafile locations as specified by the control file.

When the end of a backup piece is detected on tape, the tape channel process calls the sbtclose() function to disengage the particular tape that had that piece on it. This signals that Oracle is done with the tape. If there are more backup pieces that need to be read for the restore operation, then the channel process returns to the second step and calls sbtrestore() for a different backup piece.

After the restore is complete and RMAN requests no more backup pieces, the channel process calls the sbtend() function, which cleans up the channel resources and releases them for other use. Then the channel process is terminated, after which the media manager is free to unload any tapes that had been requested.

Using sbttest and loadsbt.exe

As we mentioned previously, there are always indications as to whether you have successfully linked your MML with Oracle. The information from the channel allocation shows the MML

version, for instance. However, these sorts of indicators do not guarantee success, because a failure may occur farther down the topology: at the media management client level or at the media management server. Oracle provides a utility called sbttest that can test to make sure that RMAN will be able to perform backups to tape by using your media management configuration.

This utility is called from a command line and performs a complete test: it writes a block to tape and then requests a read of that block. In this way, it runs through the entire gamut of SBT API functions that would occur during backup and makes sure they will all be successful.