Oracle RMAN 11g Backup and Recovery (116 page)

The Backup Scheduling Wizard is divided into four steps:

1.
Choose backup options (what do you want to back up?).

2.
Choose backup settings (how do you want to back up?).

3.
Schedule the backup (when do you want to back up?).

4.
Perform a final review (is everything to your liking?).

On the final review page, you will be presented with the RMAN script that the wizard has created, as shown in the following example. At this stage, you can either submit the job for execution or edit the RMAN script from there. This allows you to make any minor tweaks in the script. Note that if you decide to modify the script manually, OEM warns you that you will not be able to go back and make any changes in the backup wizard pages. After you make any of your own changes, you can either cancel them or submit the job.

RMAN Script Job vs. Scheduled Backup Wizard

There is another way to use OEM to schedule and run RMAN backups of a target database. If you go to the Jobs tab in Grid Control (or the Jobs link under Related Links in Database Control) and look at the drop-down list of possible job types to create, you will see RMAN Script. This is a specific type of job specification that allows you to use OEM to execute an RMAN script that already exists at the target server.

So what is the difference between an RMAN script job and a host command job? Both require a script to exist prior to scheduling the job. But if you choose an RMAN script job, OEM uses its built-in mechanisms to ensure that the environment is properly configured for your target database before running the script. This is a very nice feature, which you know if you have ever run into the dreaded “compatibility matrix” of RMAN executables versus target databases.

Why Does OEM Always Try to Allocate a Tape Channel for Maintenance?

You may notice that when you review your RMAN script after using the OEM wizard to schedule a backup, OEM has the following lines:

allocate channel for maintenance type 'SBT TAPE';

delete noprompt obsolete device type disk;

What gives? OEM has this little quirk. If you have, at any point, gone into the Configure Backup Settings page and set the number of tape drives to some value, then OEM has gone to your target database and configured a tape channel in the permanent configuration parameters. Thus, it assumes that any maintenance operation should always check tape and disk. From within OEM, there is no way to change this. You have to go to the RMAN

command line and enter the following:

configure channel device type 'sbt tape' clear;

332
Part III: Using RMAN Effectively

RMAN Workshop:
Create an RMAN Script Job in OEM

Workshop Notes

This workshop uses OEM to schedule an RMAN backup. However, the backup will be specified by an RMAN script that already exists as a file on the Linux machine where database v112 exists.

In this example, this script, named rmanback.rcv, already exists in /home/oracle/scripts and contains the following code:

backup incremental level 1 cumulative device type disk

filesperset 2 database;

backup device type disk filesperset 2 archivelog all not backed up

delete all input;

delete noprompt obsolete device type disk;

Step 1.
Go to the Jobs page of OEM. In Grid Control, there is a Jobs tab along the upper-right side. In Database Control, go to the bottom under Related Links to find the Jobs link.

Step 2.
Create a new job of type RMAN Script by using the drop-down list (that defaults to OS Command) to specify RMAN Script and then clicking Go. This will take you to a page with multiple tabs.

Step 3.
On the General tab, give the job the name
RMAN_BACK_INC_1_ARCH_DELETE_OBS
, as shown next. On this tab, you also need to add the target you want to back up. Click the Add button and select your desired database.

Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery
333

Step 4.
Click the Parameters tab. In the text box, provide the full path and name to the backup script you created on the target server.

Step 5.
On the Credentials tab, ensure that you have selected SYSDBA Database Credentials, as this is required by RMAN.

Step 6.
On the Schedule tab, set a schedule for the job. Your choice is One Time (Immediately), One Time (Later), or Repeating. New in 11
g,
you can also specify a Grace Period for the backup job: by specifying Indefinite, you are telling EM to let the job run until it signals that it is finished.

334
Part III: Using RMAN Effectively

By choosing End After, you are indicating to EM that you want the job killed if it hasn’t completed in the specified time.

Step 7.
Click the Submit button at the top of the page to send the job to the active jobs page.

This submits the job as a one-time event. You can, alternatively, save the job to the library without submitting it immediately, or both submit the job now and save it to the library.

Performing Recovery in Enterprise Manager

After seeing all the backing up that can be done from OEM, it should come as no surprise that you can also perform recovery from OEM. That being said, there are not many situations where we’ve seen OEM’s recovery options being used—even when OEM is used for backups. The decision to use OEM for recovery boils down to your ability to mitigate the overwhelming sensation typically felt when you realize your database is hosed: panic.

OEM does not help you manage your panic very well. You’d think that a GUI would be the best defense against panic—easy to use, quickly implemented, and all that. But this is actually quite the opposite of all DBAs’ reactions we’ve seen in a recovery situation. During the most solemn and distressing recovery situations we’ve been a part of, the one overwhelming DBA desire that we’ve noticed is not ease of use, built-in intelligence, or anything like that. What every DBA wants at that time is control. They want complete, total control over everything that they can possibly get control over. Database recovery is no time to be hitting the big red button and hoping for the best.

Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery
335

The Recovery Wizard in OEM is primarily useful in all those databases you deployed in development for people who assured you that they would take care of it themselves. In other words, OEM Recovery is for databases that have Oracle-suggested backup strategies.

There is one notable exception: if you have made yourself aware of how OEM Recovery works, you have noticed that it has the capabilities to lead you to the Oracle Flashback Technology, outlined in Chapter 15. Flashback Technology provides a whole new arsenal against downtime, particularly when it comes to user-induced trauma. So, if it is control you seek, understand that you are not in complete control of your recovery situation until you have explored your Flashback Technology options.

While the Recovery Wizard may not help you manage panic after an unknown failure, there is a new feature in 11
g
R2 that will help you know about failures proactively, thereby saving you from the panic altogether. This new utility is built into each 11.2 database, and it is collectively referred to as the Data Recovery Advisor.

Data Recovery Advisor and the OEM Checkers

The Data Recovery Advisor (DRA) is an advisory function built into the core RDBMS of the database.

It utilizes the same Diagnostic Repository that has been established in 11
g
for consolidating all diagnostic and fault information, so that remediation can occur more programmatically (for more on the Automatic Diagnostic Repository, see the discussion in Chapter 3). The DRA mines the data in the diagnostic repository to determine if there is a recovery action that the DBA should take in order to rectify the database and keep it available.

To be able to provide intelligence on recovery situations, the DRA must have access to additional data in the diagnostic repository. Some of that information, such as the known state of datafiles, will end up in the repository no matter what, and if RMAN has discovered any corrupt blocks during its last backup. However, some of it will get there only if you run one of the newly integrated health checkers against the database. These checkers perform diagnostic data gathering operations on different aspects of the database and then store that data in the Diagnostic Repository for action by different actors (such as the DRA).

The health checkers and the DRA are native components of the RDBMS in 11.2, so you don’t need Enterprise Manager to utilize the functionality. There is a fuller discussion on the command-line DRA in Chapter 3. Here, we are going to focus on the EM interface for the tools. This is one of those places where the GUI interface really earns its keep—in scheduling health check operations and in giving you a one-stop location to rectify any outages.

The Checkers in EM

There are seven checkers available in 11.2. Each of these performs actions against different database objects, or with different architectural needs. Each of these is described next. What they all have in common is that you get to them in EM from the main database home page, by scrolling down to Related Links and clicking Advisor Central. Advisor Central offers two pages—