Oracle RMAN 11g Backup and Recovery (50 page)

Oracle has its own media management software solution, Oracle Secure Backup (OSB). OSB

is a fully integrated, RMAN-to-tape solution that does not require any third-party vendor software plug-in, and OSB has come a long way since its introduction in 10
g
R2. However, many customers will continue to purchase a license from any of the number of certified backup providers that have an Oracle RMAN plug-in (more on this in a minute).

This chapter covers the conceptual architecture of employing a media manager to back up your database directly to disk. It does so from a generic standpoint, by staying focused on the RMAN side of the equation and speaking in sweeping generalizations about the media management products themselves. We will talk about the setup from the RMAN side, how it all works, and what changes when you use tape for your output device. Chapters 6, 7, and 8 go into detail about four of the most popular media management products on the market, and talk about configuring and using them specifically. Chapter 5 provides an overview of the new Oracle-produced media management product, Oracle Secure Backup (OSB).

In Oracle 10
g
R2 and Oracle 11
g,
you can utilize OSB to provide free backup to tape functionality, provided that you have a single tape head and it is attached directly to the server that contains the Oracle database that you want to back up. In other words, you will pay for centralized tape farms. To get additional backup-to-tape functionality, you will have to purchase the full version of OSB, or to buy a product from a media management vendor.

Tape Backups in a Disk Backup World

In the world of Oracle databases, size does matter. In fact, less than a decade ago, a database of a few gigabytes was considered very large. Now, databases range upward into the terabytes, the first pedabyte database has been reported, and the average database is 100GB and growing. So when it comes to backups, trying to find enough contiguous space on disk to get the thing backed up can be difficult, even with the massive number of SANs being deployed in the enterprise.

Thus, the first reason for considering tape backups is the size of the database. The size of a database determines whether you need to back up to tape: buying more hard drives can get Chapter 4: Media Management Considerations
103

pricey. But even with disk prices dropping radically, tapes are still cheaper and reliable, considering their purpose is to hold copies of data—copies that likely will rarely get used. Of course, sometimes disk backups become a critical piece of a strategy that stresses quick recovery, and using tape backups is much slower than using disks on both the backup and the restore. The price point of a tape, compared with disks, remains a compelling reason for tape backups.

The second reason to use tape backups is manageability. Typically, enterprise-wide backup strategies are implemented and executed by one person on a centralized system. And this allows your company to invest in large tape storage jukeboxes that can stream data from multiple sources.

Then, the data backups can be catalogued and removed without having someone trek all over the enterprise distributing tapes, troubleshooting individual tape devices, or training users on new software rollouts.

A third and frequently disregarded reason for tape backups is their portability. A pile of tapes can easily be moved offsite for archiving and disaster-proofing. Hard drives just don’t transport that well.

The drawback to pooling backup resources is that it leads to complications, especially in regard to Oracle databases. The complexity of Oracle datafiles, log files, and control files means that we cannot simply let an OS job step in and copy the files at its leisure. Instead, we have to prepare the database for the backup job, signal the copy to begin, and afterward reconfigure the database. Or, so it was in the old-school world (refer to Chapter 1).

Using RMAN means that this kind of database configuration is eliminated and that backups can occur anytime, under any circumstances. However, to get the backups to stream to your centralized tape backup location, you have to do some RMAN-specific configuration.

RMAN and the Media Manager: An Overview

RMAN streams backups to tape by engaging a media manager. A
media manager
is software provided by a third-party vendor that takes the data stream of blocks passed from the RMAN

channel process and redirects it to the appropriate tape. Most often, a media management server exists in an enterprise network. A
media management server
is a centralized system that handles all enterprise-wide backup operations to tape devices that it manages.

To engage a media manager, a computer system must have the corresponding media management client software installed on it. This is the software that makes the connection to the media management server and passes the data to it over the network. For RMAN to engage the media management server, an additional software component is needed. After you install the client software, you must also install the Oracle module for the media manager. The
Oracle module
is a software plug-in for the Oracle RDBMS that connects RMAN to the client media management software, which can then make the pass to the media management server. This plug-in for Oracle is referred to as the
Media Management Library
(MML). Figure 4-1 shows a generalized overview of the backup topology when a media manager is used to back up to tape.

The Media Manager Catalog

The media manager is a separate subsystem in the overall backup system you will use. It has three essential components, as previously described: the Media Management Library that integrates with Oracle, the media management client, and the media management server. The media management server has multiple components, the specifics of which depend upon the vendor.

But all media management servers must have a few similar components, the most important of which (from the perspective of this chapter) is the media manager catalog.

104
Part II: Setup Principles and Practices

FIGURE 4-1
Network topology when backing up to tape

The media manager catalog is the database at the media management server that holds information about the physical tapes, who has access to those tapes, and what is being stored on those tapes. This catalog records the RMAN file handle when a backup is complete. The
handle
refers to the name of the backup piece that gets created when you perform a backup with RMAN.

When you back up to disk, the handle is the physical filename. When you back up to tape, the handle is used in the media manager catalog to refer to the location on tape where the backups can be located.

RMAN completes a backup to tape by providing the handle name to the media manager, which records that handle in the catalog. When a restore is required, RMAN requests a specific handle (based on its own catalog) from the media manager. The media manager looks for that handle, associates it with a specific tape, and determines if that tape is available. If the tape is available, the media manager engages the tape and begins to stream the data back to RMAN

so that you can rebuild the datafiles.

The Media Manager: Other Software Components

In addition to the catalog, the media management server comprises two essential pieces:

■
Device agent
The component responsible for engaging the actual tape device and passing data to and from it.

■
Robotic interface
The software that controls any robotics that are responsible for changing tapes when they are full or for retrieving a tape that was been filled.

From the Oracle perspective, RMAN is blind to these components. RMAN simply sends a command request to its MML, and the media management software handles the coordination of all events after that. However, it is important to be familiar with these software components because your backup and recovery success depends on them. Many problems that come from using RMAN are related to the device agent or the robotic interface, but from the RMAN interface these problems are nearly impossible to discern.

Chapter 4: Media Management Considerations
105

Media Management Library

The MML is simply a library file that interprets generic requests from RMAN for a particular backup or restore operation, and translates that request into the specific system call necessary at the media management server to turn that request into reality. The MML is provided by the same vendor that supplies the media management client and server software, but you purchase and license the MML separately from the client and server software.

The MML is loaded into the Oracle memory space as an integrated library file when a tape channel is first allocated; it is logically part of the Oracle RDBMS software, so that RMAN can make the correct calls to the media management client software. The integration is simple: When a channel to tape is allocated, Oracle loads a file called libobk.so. This file, located in the ORACLE_HOME/lib directory, is just a symbolic link to whichever MML file you will be using.

On the Windows platform, Oracle looks for a file called orasbt.dll in the searchable path.

Regardless of which media management provider you use, its media management DLL will be named orasbt.dll, and media management providers usually write it to the WINDOWS\system32

directory. If your media management provider does not do this, it will append to the system path environment variable a searchable path that leads to orasbt.dll.

In the next four chapters, we discuss the linking process by which you can establish your vendor’s MML file as the one RMAN initiates when a channel is allocated. For testing purposes, Oracle provides a test MML file. This library file allows you to allocate a channel to tape but then to write the backup to disk. In the following RMAN Workshop, we show you how to use this test MML.

RMAN Workshop:
Test Tape Channels with the Oracle

Default SBT Interface

Workshop Notes

You need access to a sufficient amount of disk space, and you need to create a directory in which to place the backup piece. In our example, we use the mount point u04, on which we created a directory called
backup.
Make sure you have sufficient memory available for the backup, as outlined in Chapter 2, and be aware of the disk I/O that goes to the backup location. Try to allocate space on a controller other than those that house your actual database.

Step 1.
Build your backup directory:

$>cd /u04

mkdir backup

Step 2.
Make sure permissions are established so that the Oracle Database, which operates as the user that installed the software, can write to this location:

ls –l backup

Step 3.
Initiate RMAN and connect to the target. In the following example, we are connecting locally to the target PROD. This means that an env command shows us that ORACLE_SID=PROD.

$>Rman

Rman> connect target

106
Part II: Setup Principles and Practices

Step 4.
Run your backup by using the PARMS parameter during channel allocation to specify the oracle test library file. You also need to specify a BACKUP_DIR directory, which is the location that RMAN will write the backup to. Here, we specify this as /u04/backup:

run {

2> allocate channel x1 type 'sbt tape'

3> PARMS "SBT LIBRARY oracle.disksbt,

4> ENV (BACKUP DIR /u04/backup)";

5> backup datafile 1 format '%U';}

Alternatively, you can use a permanent configuration command to set the oracle library (but remember that you’ve done it, and don’t leave it lying around for too long): CONFIGURE CHANNEL DEVICE TYPE 'SBT TAPE' PARMS

'SBT LIBRARY oracle.disksbt,ENV (BACKUP DIR /u04/backup)';

Here’s the output from the preceding command:

allocated channel: x1

channel x1: SID=27 device type=SBT TAPE

channel x1: WARNING: Oracle Test Disk API

Starting backup at 25 SEP 09

channel x1: starting full datafile backup set

channel x1: specifying datafile(s) in backup set

input datafile file number=00001 name=/home/oracle/app/oracle/oradata/v112/system01.dbf channel x1: starting piece 1 at 25 SEP 09

channel x1: finished piece 1 at 25 SEP 09

piece handle=04kq4cbe 1 1 tag=TAG20090925T102902 comment=API Version 2.0,MMS Version 8.1.3.0

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

channel x1: starting full datafile backup set

channel x1: specifying datafile(s) in backup set

including current control file in backup set

including current SPFILE in backup set

channel x1: starting piece 1 at 25 SEP 09

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

released channel: x1