USING RMAN, CONNECT TO THE CATALOG AS VPCOWNER AND TO THE TARGET AS...

6. Using RMAN, connect to the catalog as vpcowner and to the target as SYS, register

the target (if was not previously registered), and then carry out backup and

restore operations as normal.

The owner of a virtual private catalog will have no access to backups relating to

databases not registered in their domain, and need have no object or tablespace privileges

in the catalog database, nor any system privileges beyond those granted in Step 2.

TIP A GRANT REGISTER DATABASE will insert a row in VPC_USERS, a

table in the catalog owner’s schema. A GRANT CATALOG FOR DATABASE

will insert a row in the VPC_DATABASES table. The virtual catalog owner has

synonyms that allow these tables, which are used to filter access to be seen.

Protecting and Rebuilding the Catalog

If the recovery catalog is not available, RMAN can still function—but it will be crippled.

Because the RMAN repository is always stored in the target databases’ controlfiles, loss

(temporary or permanent) of the catalog is not disastrous. But the controlfile-based

repository will only hold a relatively small amount of information—all data older than

the CONTROLFILE_RECORD_KEEP_TIME parameter will be overwritten. So while

backups can still be performed, any restore and recover operations will be much harder.

Backup sets and image copies going back weeks may be available, but RMAN will not be

able to find them. Furthermore, any stored scripts will also be unavailable. It is therefore

necessary to protect the catalog database. And worst of all, if all copies of the controlfile

itself are lost, then RMAN will be useless—unless the controlfile autobackup facility has

been enabled (which it should always be).

There is a recursive problem with backing up the catalog database. If you back it up

with RMAN, then if it needs to be restored, RMAN will not be able to do the job. So,

unless you have a second catalog database and use this to register the first, you will have

to use a user-managed backup technique. These are fully described in Chapter 18.

The catalog schema is not very big, nor very busy. Even if the catalog is supporting

hundreds of databases, it will usually be only a few gigabytes. It may therefore be feasible

to make full whole offline backups regularly: simply shut it down, and copy it. This,

together with the archive logs (as with any production database, the catalog database

should be run in ARCHIVELOG mode), will be an adequate backup—if you can stand

the downtime. Alternatively, it may be possible to make a logical backup, using the

export/import utilities or the newer Data Pump facility (described in Chapter 23).

If backups are made without connecting to the catalog for any reason (such as the

catalog being unavailable—perhaps because it was down for a cold backup), then

the catalog repository must be resynchronized with the controlfile repository. This

will happen automatically the next time RMAN connects to both the target and the

catalog. The resync operation transfers all information from the controlfile repository

into the catalog, thus bringing it up to date. Data about backups will therefore only be

lost if the period without a resync exceeds the CONTROLFILE_RECORD_KEEP_TIME.

TIP All backup events that occur while not connected to the catalog, as well

as information regarding archive log generation and physical changes such as

datafile creation, are transferred into the catalog by an automatic resync at the

next connection. You can also force a resync from the RMAN prompt with

P AR T III

the RESYNC CATALOG command.

But what if the controlfile and perhaps other parts of the target database are

lost, and the catalog is lost too? The backups (backup sets and image copies) may

be perfect, but RMAN will not be able to find them. Of course, it should be possible

to restore the catalog—but assume that it is not. The first step is to connect to the

target with the RMAN executable, and start it in NOMOUNT mode. Even if there is

no parameter file, this will succeed because RMAN will start the instance with a

dummy parameter file; Figure 17-2 shows this procedure. Of course, the startup

will stop in NOMOUNT mode: there will be no controlfile to mount.

Once the instance is started, if you know where the backups of the controlfile and

spfile are located, instruct RMAN to restore them from this location; or if autobackup

had been enabled, use the technique described in Chapter 16. Then restart the instance

with the restored spfile, and mount the database with the restored controlfile. Then, if

Figure 17-2 Starting a Windows instance, with RMAN and no parameter file

you know where the other backup sets are stored, register them in the controlfile-based

repository with the CATALOG command. For example,

catalog datafilecopy '/u02/dfcopies/example01/dbf';catalog backuppiece '/u02/backupsets/TAG20081028T174426_4JGMW1R9_.BKP';catalog start with '/u01/app/oracle/flash_recovery_area';

The first of these commands registers an image copy of a datafile, which could

have been made either by RMAN or by a user-managed backup. Similar syntax can

register copies of the controlfile and of archive log files. The second command registers

a backup set piece. Note that in neither case is it necessary to tell RMAN what the copy

or backup set contains: RMAN can work this out by inspecting the file contents. The

third command is the most powerful: it instructs RMAN to go to a directory (in the

example, the root of the flash recovery area) and navigate down all subdirectories

cataloging every copy and backup set piece that it finds. By giving a tape device as the

path, RMAN can rebuild an entire repository. Follow up the catalog commands by

connecting to each target database. The automatic RESYNC operation will populate

the catalog with any information from the repositories in each controlfile that has not

already been inserted.

While it is possible to create a new, empty, RMAN catalog and then populate it

(always assuming that you know where the backups are) with the CATALOG and

RESYNC CATALOG commands, it is far more preferable to back up your catalog so

that if it is damaged, you can restore it.

By all means back up your catalog database with RMAN. Connect to it as a target,

and back it up as you would any other target. Be sure to enable the autobackup facility.

But do not back up your recovery catalog database only with RMAN! If it is damaged,

there could be a recursive problem with any attempt to restore: if either the controlfile

or the tablespace containing the catalog were damaged, any attempt to open the

database and then connect to it as a catalog must fail. The autobackup will help you

to survive this situation, but it will be necessary to protect the catalog database by

other means—perhaps user-managed backups (detailed in Chapter 18), or using

operating system– and hardware-based techniques, or using the Data Pump facility

(described in Chapter 23) to make a logical backup.