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 fileyou 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.
Bạn đang xem 6. - OCA OCP ORACLE DATABASE 11G A LL IN ONE EXAM GUIDE P70 POT