Oracle RMAN 11g Backup and Recovery (29 page)

Server-Managed Recovery

In the previous chapter, you learned the principles and practices of backup and recovery in the old world. It involved creating and running scripts to capture the filenames, associate them with tablespaces, get the tablespaces into backup mode, get an OS utility to perform the copy, and then stop backup mode.

But this book is really about using Recovery Manager (RMAN). Recovery Manager implements a type of
server-managed recovery
(SMR). SMR refers to the ability of the database to perform the operations required to keep itself backed up successfully. It does so by relying on built-in code in the Oracle RDBMS kernel. Who knows more about the schematics of the database than the database itself?

The power of SMR comes from what details it can eliminate on your behalf. As the degree of enterprise complexity increases, and the number of databases that a single DBA is responsible for increases, personally troubleshooting dozens or even hundreds of individual scripts becomes too burdensome. In other words, as the move to “grid computing” becomes more mainstreamed, the days of personally eyeballing all the little details of each database backup become a thing of the past. Instead, many of the nitpicky details of backup management get handled by the database itself, allowing us to take a step back from the day-to-day upkeep and to concentrate on more important things. Granted, the utilization of RMAN introduces certain complexities that overshadow the complete level of ease that might be promised by SMR—why else would you be reading this book? But the blood, sweat, and tears you pour into RMAN will give you huge payoffs. You’ll see.

The RMAN Utility

RMAN is the specific implementation of SMR provided by Oracle. RMAN is a stand-alone application that makes a client connection to the Oracle database to access internal backup and recovery packages. It is, at its very core, nothing more than a command interpreter that takes simplified commands you type and turns those commands into remote procedure calls (RPCs) that are executed at the database.

We point this out primarily to make one thing very clear: RMAN does very little work. Sure, the coordination of events is important, but the real work of actually backing up and recovering a database is performed by processes at the target database itself. The
target database
refers to the database that is being backed up. The Oracle database has internal packages that actually take the PL/SQL blocks passed from RMAN and turn them into system calls to read from, and write to, the disk subsystem of your database server.

The RMAN utility is installed as part of the Database Utilities suite of command-line utilities.

This suite includes Data Pump, SQL*Loader, DBNEWID, and dbverify. During a typical Oracle installation, RMAN will be installed. It is included with Enterprise and Standard Editions, although there are restrictions if you have a license only for Standard Edition: without Enterprise Edition,

Chapter 2: Introduction to the RMAN Architecture
35

RMAN can only allocate a single channel for backups. If you are performing a client installation, it will be installed if you choose the Administrator option instead of the Runtime client option.

The RMAN utility is made up of two pieces: the executable file and the recover.bsq file. The recover.bsq file is essentially the library file, from which the executable file extracts code for creating PL/SQL calls to the target. The recover.bsq file is the brains of the whole operation. These two files are invariably linked and logically make up the RMAN client utility. It is worth pointing out that the recover.bsq file and the executable file must be the same version or nothing will work.

The RMAN utility serves a distinct, orderly, and predictable purpose: it interprets commands you provide into PL/SQL calls that are remotely executed at the target database. The command language is unique to RMAN, and using it takes a little practice. It is essentially a stripped-down list of all the things you need to do to back up, restore, or recover databases, or to manipulate those backups in some way. These commands are interpreted by the executable translator, then matched to PL/SQL blocks in the recover.bsq file. RMAN then passes these RPCs to the database to gather information based on what you have requested. If your command requires an I/O operation (in other words, a backup command or a restore command), then when this information is returned, RMAN prepares another block of procedures and passes it back to the target database. These blocks are responsible for engaging the system calls to the OS for specific read or write operations.

RMAN and Database Privileges

RMAN needs to access packages at the target database that exist in the SYS schema. In addition, RMAN requires the privileges necessary to start up, shut down, and—during restore operations—

create the target database. Therefore, RMAN always connects to the target database as a sysdba user. Don’t worry, you do not need to specify this as you would from SQL*Plus; because RMAN

requires it for every target database connection, it is assumed. Therefore, when you connect to the target, RMAN automatically supplies the “as sysdba” to the connection:

RMAN> connect target sys/password

connected to target database: PROD (DBID 4159396170)

If you try to connect as someone who does not have sysdba privileges, RMAN will give you an error:

RMAN> connect target /

RMAN-00571:

RMAN-00569:

ERROR MESSAGE STACK FOLLOWS

RMAN-00571:

ORA-01031: insufficient privileges

This is a common error during the setup and configuration phase of RMAN. It is encountered when you are not logged into your server as a member of the dba group. This OS group controls the authentication of sysdba privileges to all Oracle databases on the server. (The name dba is the default and is not required. Some OS installs use a different name, and you are by no means obligated to use dba.) Typically, most Unix systems have a user named oracle that is a member of the group dba. This is the user that installs the Oracle software to begin with, and in most modern configurations, you will have sudo set up so that you can
‘sudo oracle’
—still logged in as yourself, but assuming oracle privileges. It doesn’t matter who you connect as within RMAN—you will always be connected as a sysdba user, with access to the SYS schema and the ability to start up and shut down the database. On Windows platforms, Oracle creates a local group called ORA_

DBA and adds the installing user to the group.