Oracle RMAN 11g Backup and Recovery- P8

318

Part III:

Using RMAN Effectively

Jun 11, 2009 3:37:09 PM oracle.sysman.emcp.EMDBPostConfig performConfiguration
INFO: >\>\>\>\>\>\>\> The Database Control URL is
:1158/em <<<<<<<<<<<
Jun 11, 2009 3:45:27 PM oracle.sysman.emcp.EMDBPostConfig invoke
WARNING:
************************ WARNING ************************
Management Repository has been placed in secure mode wherein Enterprise Manager
data will be encrypted. The encryption key has been placed in the file:
/home/oracle/app/oracle/product/11.2.0/dbhome 1/localhost.localdomain dev1/sysman/
config/emkey.ora.
Please ensure this file is backed up as the encrypted data
will become unusable if this file is lost.
***********************************************************
Enterprise Manager configuration completed successfully
FINISHED EMCA at Jun 11, 2009 3:45:27 PM

Configuring Backup Settings in Enterprise Manager
It has taken us a bit of extra time to come to terms with Enterprise Manager, but now we can use
our recently configured OEM Grid or Database Control to take database backups. Hopefully, you
have navigated yourself to the point where you are excited about OEM’s possibilities, and you are
ready to begin scheduling your backups so you can get back to the rest of your day. As we get
started on this section, bear in mind that we are utilizing EM Database Control, not Grid Control,
for this conversation. Thus, we will not be orienting ourselves to a database first—we assume
there is only one database available in the console.
First, we need to get our backup settings dialed in. That means a few page clicks in the

OEM console. All backup- and recovery-related operations will come from the Availability
tab, shown next.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


Chapter 13:

Using Oracle Enterprise Manager for Backup and Recovery

319

From the Availability tab, the first thing that you need to do is configure backup settings, so
click the link called Backup Settings. The Backup Settings page has three tabs, Device, Backup
Set, and Policy, which are described in the following sections.

Device Configuration
From the Device tab, shown next, you can set up both disk and tape settings. These settings are
not for setting which is the default device, but rather are individual settings for all channels on
these devices. For disk backups, you set parallelism, the backup location, and the type of backup
(backup set or image copy). This is also where you would turn compression on, if you want to
use it. For tape backups, you tell OEM how many tape devices will be employed, and the tape
backup type (compressed or noncompressed). In addition, for tapes, you can provide any
environment settings that are required for the tape backup software to operate (for more on
tape backup settings, see Chapters 4 through 8).

Note that at the bottom of the Device tab is a place (not shown in the screen shot) for host
credentials. These are required in order for OEM to submit a job to make the desired changes
on the target database. This same requirement appears at the bottom of each tab of the Configure
Backup Settings page.

Backup Set Configuration
After making device configuration decisions, click the Backup Set tab, which allows you to make
permanent configuration settings for how the backup sets will be generated. Remember, this only
applies to those backups that use backup sets instead of image copies (disk backups can be either;
tape backups are always backup sets).
If you are using disk backups, you have two things to configure here: the maximum size of
your backup pieces, and the compression algorithm. The compression choice is between BZIP2
and ZLIB—with the former optimizing for maximum compression (at the cost of CPU cycles),
and the latter optimizing for low CPU utilization (at the cost of less compression). If you will be

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


320

Part III:

Using RMAN Effectively

backing up to tape, you can set up how many copies of each datafile backup set you will create
on the tape devices and the number of copies of each archive log backup to create.

Policy Settings
The Policy tab allows for configuration of those settings that relate to your business backup policy.
This includes turning on autobackups of the control file and SPFILE, and specifying where the
autobackups will be (if disk backups are used). On the Policy tab, you can turn on backup
optimization (see Chapter 3 for details on backup optimization). This is also where you turn on
block change tracking (see Chapter 16) and configure tablespace exclusions (see Chapter 3).

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


Chapter 13:

Using Oracle Enterprise Manager for Backup and Recovery

321

You also use the Policy tab to configure your retention policy. OEM provides three options:
retain all backups (ack!), set a policy based on a recovery window, or set a policy based on
redundancy. If you choose a recovery window or redundancy, you are required to specify how
many days or how many copies, respectively. After this, you again provide host credentials and
click OK to submit the changes. OEM connects to the target database host and issues the RMAN
configure commands to make these changes.

What Is Missing from OEM’s Backup Configuration?
Not all things that RMAN can configure are configured in OEM. Some changes can be made only
from the RMAN command line:
■

Backup encryption Encryption is enabled when you schedule a specific backup,
not in the overall backup settings. When you go to schedule an Oracle-Suggested or
Customized Backup, you can specify the Encryption level.

■

Default device type It could be argued that because you schedule backups within OEM
to repeat, the default device type is not required. Regardless, you will not find it in the
OEM interface.

■

Archive deletion policy From RMAN, you can set a specific archive log retention policy
that is different from the backup set retention policy. No such option exists in OEM.

■

Snapshot control file location RMAN allows you to modify the snapshot control file
location, which is handy for RAC configurations. OEM has no way of accomplishing this.

■

Backup throttling There is no rate command available in any OEM backups, so there
is no way to throttle back the RMAN backup speed. This also holds true for the duration
command that allows you to specify a backup window with the minimize time or
minimize load options.

RMAN Workshop: Configure Backup Settings in OEM
Workshop Notes
This workshop assumes that you have the v102 database and want to configure it to back up to
a disk location other than the FRA with two channels, that you want filesperset to be 2, and that
you want a recovery window of seven days.

Step 1. Set up the disk backup settings. Click the Availability tab and then click the Backup
Settings link. The default page that appears is the Device tab. Change Parallelism to 2 and Disk
Backup Location to /u01/backup. Click the Test Disk Backup button to the right to confirm that
the location you have specified exists.
Step 2. Click the Backup Set tab. Change Maximum Backup Piece (File) Size to 500MB. Change
the Compression Algorithm to ZLIB.

Step 3. Click the Policy tab. Click the Automatically Backup the Control File and Server
Parameter File check box. Set the Autobackup Disk Location to u01/backup (the same location
as the backups in Step 1).

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


322

Part III:

Using RMAN Effectively

Step 4. Under the Retention Policy heading, change the policy to the second option, Retain
backups that are necessary for a recovery to any time, and set the value to 7 days.
Step 5. Under Host Credentials, set the host server username and password to the user that
installed your database software. Then click OK.
Step 6. Confirm that the changes have taken effect for this database. Connect to the host server
where this database resides:
Export ORACLE SID v112
rman target /
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
…
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'/u01/backup/%F';
…

CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
'/u01/backup/%U'
MAXPIECESIZE 500 M;
…
CONFIGURE CHANNEL DEVICE TYPE 'SBT TAPE' MAXPIECESIZE 500 M;
…

Configuring Recovery Settings
After configuring the backup settings, you will need to configure the database recovery settings.
You can access this page from the main Availability tab of the database target by clicking the
Recovery Settings link. Configuring the recovery settings actually covers a wide scope of options.
On the Recovery Settings page, OEM further divides the recovery settings into three types of
recovery: Instance Recovery, Media Recovery, and Flash Recovery, as described in the following
sections.

Instance Recovery
Only one setting refers to instance recovery, FAST_START_MTTR_TARGET, as shown next. This is
an initialization parameter that determines a target value, in seconds, which you are interested in
hitting when instance recovery is initiated on the database. MTTR is an acronym for mean time
to recover and is a common name for exactly how long it takes for a database to be operational
again after it has crashed for some reason.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


Chapter 13:

Using Oracle Enterprise Manager for Backup and Recovery

323

Instance recovery is initiated automatically by Oracle when a database is started after a hard
crash (or a shutdown abort). Instance recovery uses online redo logs and undo segments to remove
any transactions that were uncommitted at the time of the crash and to set the database to a clean,
synchronized state for further activity. Instance recovery must complete before the database can
be started, so minimizing how long this takes affects how fast your database comes back to life
after a crash.
FAST_START_MTTR_TARGET is a combination of a number of changes that are made internally
to facilitate the speedy recovery of your instance (also referred to as automatic checkpoint tuning).
This parameter makes the LOG_CHECKPOINT_TIMEOUT and LOG_CHECKPOINT_INTERVAL
parameters obsolete. From OEM, you can specify this value in seconds. The valid range is 0 to 3600
seconds (or 0 to 60 minutes).

Media Recovery
The ARCHIVELOG mode/NOARCHIVELOG mode switch appears in the Media Recovery section
of the Recovery Settings page. It’s hard to find if no one has told you to look there—you might
mistakenly start looking in, say, the Archive Logs link from the Server page of the database target.
But here it is, halfway down the Recovery Settings page. It shows up here as a simple check box,
but do not think that OEM has fired some magic bullet at the Oracle RDBMS: you still must
reboot before this will take effect. In fact, OEM will submit a job to the OS to restart the database
and perform the change.
In addition to enabling ARCHIVELOG mode, you can specify your LOG_ARCHIVE_FORMAT
and LOG_ARCHIVE_DEST parameters here. By default in 11g, the parameter USE_DB_RECOVERY_
FILE_DEST, also referred to as the flash recovery area (FRA), is set.
In 11g, a new check box (shown next) has been added to Enable Minimal Supplemental
Logging. This configures the database for additional logging required for using the LogMiner
utility.

Flash Recovery

Under the heading Flash Recovery, you can configure your FRA, providing both an FRA destination
and size. More useful, and unfortunately buried here in a configuration page, is an excellent pie
graph displaying current used space in the FRA, broken down by file type. This is an excellent

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


324

Part III:

Using RMAN Effectively

quick view of the FRA that is hard to find anywhere else. Remember it is here under the Flash
Recovery configuration settings; it can save you valuable time down the road.

In addition to being where you configure the FRA, the flash recovery area is where you can
turn on Flashback Database, functionality introduced in 10g that can radically reduce point-intime recovery by rewinding the database (literally). Flashback Database, and all of the different
configuration requirements and resource needs thereof, are discussed in Chapter 15.
As with ARCHIVELOG mode, turning on Flashback Database requires a database reboot; we
suggest that you do them both at the same time to save yourself a bit of hassle. Along with turning
on Flashback Database, you can set your flashback retention time target, in hours.
Note, finally, the Apply Changes to SPFILE Only check box. Checking this option is the same
as changing parameters like this:
alter database set db recovery file dest '/u01/fra' scope spfile;

Note, of course, that checking this box will not “save” the ARCHIVELOG mode and
Flashback Database changes. Either you restart the database and change them, or you wait
and restart the database and change them later.

Why Are My Archive Log and Flash Recovery Options Grayed Out?
If you arrived at the Recovery Settings page only to find the options to turn on ARCHIVELOG
mode and to modify the LOG_ARCHIVE_DEST locations grayed out in OEM (disallowing you
from making changes to the mode or the flash recovery options), you have logged in as a user
that does not have SYSDBA privileges. You must log out of Grid or Database Control, and log
back in as user SYS with the role SYSDBA, to make changes on the Recovery Settings page.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


Chapter 13:

Using Oracle Enterprise Manager for Backup and Recovery

325

RMAN Workshop: Configure Recovery Settings in OEM
Workshop Notes
This workshop makes changes that set a second archive destination in addition to the FRA, add
more space to the FRA, and enable Flashback Database. This workshop assumes you are already
in ARCHIVELOG mode (see Chapter 3 if you are not, or just choose the ARCHIVE Log check box
on the Recovery Settings page).

Step 1. Log into OEM as user SYS with role SYSDBA. If you are not logged in as SYS, the
options on the Recovery Settings page will be grayed out.
Step 2. Navigate to the Database | Availability | Recovery Settings page.
Step 3. Set a new archive log destination to /u01/backup. Click Add Another Row and then
specify the location (here, we use /home/oracle/backup).
Step 4. Change the Flash Recovery Area Size to 4GB.
Step 5. Check the Enable Flashback Database check box. Set the Flashback Retention Time

to 24 Hours.
Step 6. Click the Apply button. This prompts you to restart the database. Click Yes. You then
need to provide host and database credentials for the shutdown.
Step 7. After the database is restarted, navigate back to the Recovery Settings page to confirm
the changes.

Configuring Recovery Catalogs in OEM
Enterprise Manager cannot actually create a recovery catalog. You still need to manually create
the catalog user, grant the user the RECOVERY_CATALOG_OWNER role, and then connect
RMAN to this user and issue the command create catalog. There is no wizard or anything for
these steps in OEM. This can be a bit confusing, as there is an Add Recovery Catalog button on
the Recovery Catalog Settings page. However, this button only adds an existing recovery catalog
to the Enterprise Manager repository; that is, we make EM aware of the existence of a recovery
catalog, so that it can then add this particular database to the specified catalog.
Once the catalog is created, you can inform OEM that you wish to use the recovery catalog.
After you have registered the recovery catalog with OEM, you can register targets in the catalog. If
you have registered more than one recovery catalog, you can specify that a particular one be put
in use during different backup and recovery operations.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


326

Part III:

Using RMAN Effectively

RMAN Workshop: Register the Recovery Catalog with OEM
Workshop Notes

This workshop creates a catalog in the database emrep manually and then registers it for use in OEM.

Step 1. Connect to the repository database as user SYS and create the user for the catalog:
SQL> create tablespace reco cat datafile
'/u01/app/oracle/oradata/emrep/reco cat1.dbf' size 100m;
Tablespace created.
SQL> create user rman identified by rman
2 default tablespace reco cat
3 quota unlimited on reco cat;
User created.
SQL> grant connect, resource, recovery catalog owner to rman;
Grant succeeded.
SQL> connect rman/rman
Connected.

Step 2. Make sure that you have the 11.2 $ORACLE_HOME/bin in your path before this step so
that the RMAN executable is 11.2. Otherwise, OEM will not be able to register your catalog!
$ echo $PATH
/u01/app/oracle/product/10.2.0/bin
[oracle@dex oracle]$ rman catalog rman/rman@v112
Recovery Manager: Release 11.2.0.0.2 on Wed Dec 21
Copyright (c) 1982, 2009, Oracle. All rights reserved.
connected to recovery catalog database
RMAN> create catalog;
recovery catalog created

Step 3. Now that the catalog is created, go to OEM | Database | Availability | Recovery Catalog
Settings. Select Use Recovery Catalog, and then click the Add Recovery Catalog button. From
Grid Control, you can choose an already discovered database or provide the host, the port, the
SID, and the RMAN username and password. From Database Control, you cannot choose from a

list and must provide the host:port:sid combination. In addition, you need to provide the recovery
catalog credentials (the RMAN user created in Step 2).

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


Chapter 13:

Using Oracle Enterprise Manager for Backup and Recovery

327

Step 4. After the Add Recovery Catalog action returns you to Recovery Catalog Settings, you
need to provide the Recovery Catalog user and password again, along with host credentials to run
the job. When this is complete, you can click OK, and the register database action will complete.

Related Links for Recovery Catalog Settings
Three “related links” that provide additional functionality are at the bottom of the Recovery
Catalog Settings page:
■

Resynchronize Catalog Manually do a sync operation to bring the database control file
and the recovery catalog into a synchronized state.

■

Recovery Catalogs
aware of.

■

Unregister Database
permanently.

View and manage all recovery catalogs that EM has been made
Remove this database from the selected recovery catalog

Database Backups from Enterprise Manager
Now that you have configured your database for backups from the OEM interface, you can get to
the nitty-gritty of actually taking a backup. From the OEM Console, after you have selected your
database and clicked the Availability tab, click the Schedule Backup link. On the Schedule Backup
page, you are given two options: the Oracle-Suggested Backup or Schedule a Customized Backup.

Oracle-Suggested Backup Strategy
Starting with Oracle Database 10g, Oracle has put together a full backup strategy that is “ready to
wear” straight from the rack. This is available only via OEM (in both Grid Control and Database
Control) and requires the existence of the FRA. The Oracle-suggested strategy checks the backup

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


328

Part III:

Using RMAN Effectively

and recovery settings you’ve configured for your database and draws conclusions about whether
you want a disk-only backup, a tape-only backup, or a combined disk and tape backup.

Disk-Only Oracle-Suggested Backup Strategy
The disk-only backup strategy is the most straightforward. It uses the “incremental apply to
database copy” functionality to create a backup strategy that is self-cleaning. Here’s an example
of how it works. In this example, we start the Oracle-suggested strategy on a Monday evening at
10 P.M. The database is running in ARCHIVELOG mode, has automatic control file and SPFILE
backups enabled, and uses the FRA.
■

Monday night A full image copy of every datafile is taken for the database. This backup
is stored in the FRA.

■

Tuesday night A level 1 incremental backup set is created. All blocks that have changed
since Monday night at 10 P.M. are backed up.

■

Wednesday night First, RMAN applies the Tuesday night incremental backup to the
Monday night image copy, which makes the full image copy backup a current copy of
the database as it looked Tuesday night at 10 P.M. After that is complete, RMAN takes a
new level 1 backup.

■

Thursday night RMAN applies the Wednesday night incremental backup to the image
copy, which makes our database backup current as of Wednesday night at 10 P.M. Then,
a new incremental level 1 backup is taken, with all changes since Wednesday night.

■

Friday night RMAN does the exact same thing it did on Thursday night. On Saturday,
it does the same thing. Same with Sunday. This action repeats every day until you tell it
to stop.

Notice a few things about this backup strategy. First, a full database backup is taken only
once. After that, RMAN takes only level 1 incremental backups. Then, nightly, the previous night’s
incremental backup is applied. This strategy ensures that the database backup is at least 24 hours
behind the current point in time. This allows for a point-in-time recovery to any point in the
previous 24 hours, but nothing earlier than that. At most, the database backup is 48 hours behind
the current time, so recovery is never that far behind.
There are limitations to this strategy, but that’s one of the drawbacks to a “one-size-fits-all”
approach to backups.

Tape-Only Oracle-Suggested Backup Strategy
The tape-only suggested strategy differs in many ways from the disk-only suggested strategy. First, no
backup will ever be created in the FRA. Sure, archive logs will accumulate there, but all backups
will go directly to the tape device. In addition, the tape-only strategy cannot take advantage of
the incremental apply feature. Remember, an image copy backup cannot be taken to tape. All
backups to tape will be of the backup set type.
When you schedule an Oracle-suggested tape-only backup, two RMAN scripts are generated:
a daily backup and a weekly backup. First, the weekly script is run. This creates a full database
backup, including all archive logs. Then, the daily script is run. The daily backup does an
incremental backup of only changed blocks, along with all archive logs not already backed
up. Then, once a week, the full database backup runs again.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


Chapter 13:

Using Oracle Enterprise Manager for Backup and Recovery

329

During the tape-only backup wizard, if you have not specified a retention policy, OEM asks
you to specify one. Then, as part of the daily backup, your retention policy is enforced on the
tape channel.
After generating a tape-only suggested strategy, you will find that the scripts might look
something like this:
Daily Script:
run {
allocate channel oem sbt backup1 type 'SBT TAPE' format '%U' parms
'nb ora server (horatio.hadba.com)';
allocate channel oem sbt backup2 type 'SBT TAPE' format '%U' parms
'nb ora server (horatio.hadba.com)';
backup incremental level 1 cumulative database;
backup archivelog all not backed up;
}
allocate channel for maintenance device type 'SBT TAPE' parms
'nb ora server (horatio.hadba.com)';
delete noprompt obsolete recovery window of 7 days device type 'SBT TAPE';
Weekly Script:
run {allocate channel oem sbt backup1 type 'SBT TAPE' format '%U' parms
'nb ora server (horatio.hadba.com)';
allocate channel oem sbt backup2 type 'SBT TAPE' format '%U' parms
'nb ora server (horatio.hadba.com)';
backup incremental level 0 database;
backup archivelog all not backed up;

Combined Disk and Tape Oracle-Suggested Backup Strategy
When you combine disk backups with tape backups, the hybrid solution demands more input
from you than either of the previous Oracle-suggested strategies. And, for the first time, you must
make a configuration decision.
First, consider the disk part of the strategy. Backups to disk are identical in the combined disk
and tape strategy and in the disk-only strategy: a full image copy in the FRA, and then incremental
backups each night that are then applied to the image copy.
As far as the tape part of the strategy, you must decide how much you want backed up to
tape on a daily basis. On a weekly basis, the suggested strategy backs up all recovery-related files
(with the backup recovery files command in RMAN). But, you must choose how much to back
up daily: nothing, archive logs only, archive logs and incrementals, or archive logs and the full
database copy.
If you decide to back up archive logs and incrementals to tape daily, this would be the
resulting daily and weekly script that OEM builds:
Daily Script:
run {
allocate channel oem disk backup device type disk;
recover copy of database with tag 'ORA$OEM LEVEL 0';
backup incremental level 1 cumulative
copies 1 for recover of copy with tag
'ORA$OEM LEVEL 0' database;
release channel oem disk backup;
allocate channel oem sbt backup1 type 'SBT TAPE' format '%U' parms

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


330

Part III:

Using RMAN Effectively

'nb ora server (horatio.hadba.com)';
backup archivelog all not backed up;
backup backupset all not backed up since time 'SYSDATE-1';
}
allocate channel for maintenance device type 'SBT TAPE' parms
'nb ora server (horatio.hadba.com)';
delete noprompt obsolete recovery window of 7 days device type
'SBT TAPE';
Weekly Script:
run {
allocate channel oem disk backup device type disk;
recover copy of database with tag 'ORA$OEM LEVEL 0';
backup incremental level 1 cumulative copies 1 for recover of copy with tag
'ORA$OEM LEVEL 0' database;
release channel oem disk backup;
allocate channel oem sbt backup1 type 'SBT TAPE' format '%U' parms
'nb ora server (horatio.hadba.com)';
backup recovery area;
}
allocate channel for maintenance device type 'SBT TAPE' parms
'nb ora server (horatio.hadba.com)';
delete noprompt obsolete recovery window of 7 days device type 'SBT TAPE';

Final Note on Oracle-Suggested Strategies
Taking a default backup strategy “off the shelf” has its benefits and its drawbacks. The benefits
come from being able to “set and forget” the backups—they will run forever and clean themselves
up. There is some assurance in having this option, particularly for low-priority development

databases that typically are operated by someone other than you. If they come to you in a panic,
you can always use these backups to fix the problem and save everyone a lot of headaches.
But there is (almost) no customization, and sometimes the default strategy will not match your
SLA. The most glaring example of this is in the ability to do point-in-time recoveries to some point
in the past (a limitation of the disk-based strategy only). Remember, these strategies are merely
Oracle suggestions. You don’t have to use them, and if they are giving you any heartburn, there
is a simple answer: drop the suggested strategy and build your own.

Scheduling a Customized Backup
From the same Availability page where you can choose to schedule an Oracle-suggested backup
strategy, you can also choose to build your own customized backup job. This is a wizard-driven
process that steps you through the different choices to be made about the backup. When the
wizard is finished, you can run the backup as a one-time backup immediately, schedule it for
later, or set it up to repeat continually on a schedule.
It is important that you take the time to develop a full backup strategy ahead of time, but OEM
will provide some guidance about how to develop that strategy. These tips appear as small-font
hints under some of the choices you will be asked to make in the Backup Scheduling Wizard.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


Chapter 13:

Using Oracle Enterprise Manager for Backup and Recovery

331

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;

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


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.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


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 11g, 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.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


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.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

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 11gR2 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 11g 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 commandline 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—

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


336

Part III:

Using RMAN Effectively

Advisors and Checkers. Advisors is the default view; you will need to click the Checkers tab to
see the health check utilities.

From the Checkers page, you can see the most recent runs of the checkers and the results.
By clicking on the Run Name, you can move to the Findings page to see if any alerts have been
raised that require action. Each of the checkers may require unique inputs to run, but they all

require at least two items in common: you must name the run you are asking to start (and it must
be unique), and you must provide a time-out after which EM aborts the checker if it has not
completed.
■

Data Block Integrity Check Checks a single block for corruption. You need to know
the suspected file and block number (such as reported by an ORA-1578 error) to run this
checker.

■

CF Block Integrity Check This is the Control File checker. Again, the expectation in the
tool is that you know the suspected back block number that requires an integrity check.

■

Redo Integrity Check This checks for online or archive redo corruption and accessibility.
You specify the SCN that you want to start moving forward from, and EM performs the
check from there.

■

Transaction Integrity Check This is the same as the Undo Segment Integrity Check, in
that it checks for logical undo corruptions, except that it does so for a single transaction.
The required input is the transaction ID.

■

Undo Segment Integrity Check This checks for logical undo corruptions for an entire
Undo segment. The Undo segment number is the required input.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.


Chapter 13:

Using Oracle Enterprise Manager for Backup and Recovery

337

■

DB Structure Integrity Check This checker provides a proactive mechanism for
checking all database files for accessibility, header corruption, and SCN synchronicity
across the files and the control file. There is no input required.

■

Dictionary Integrity Check This examines core data dictionary items to ensure consistency
and integrity. You must provide the name of the data dictionary table you are checking,
and the check mask.

Data Recovery Advisor
As with the health check utilities, you get to the Data Recovery Advisor through the Advisor
Central link from Related Links on the database home page. If there are no current recoveryrelated findings in the database, the DRA will simply have a search field to search previous
cataloged failures. If a new failure exists that hasn’t been rectified yet, you will see the option
to Select failures and… take an action.

If you click the Advise button, EM will take a few moments to examine the information and
then will provide advice on what to do about the particular failure at hand. If there is an action

it can take automatically, it will ask permission and then do so. Otherwise, it will recommend a
manual action to take, as shown next.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.