Database Reference
In-Depth Information
ORACLE DBMS releases up to Oracle8
i
release 3 (8.1.7) had a considerable vulnerability
due to the fact that the database—the control file to be precise—is used to keep track of backups.
Of course, RMAN supported a recovery catalog for duplicating recovery-related information in
the control file right from the first release with Oracle8. The recovery catalog enables restore
operations when no control file is available. Contrary to the control file, backup metadata in a
recovery catalog are exempt from overwrites (parameter
CONTROLFILE_RECORD_KEEPTIME
). This
left the architecture with the following two vulnerabilities:
Metadata on backups that were taken without connecting to a catalog (
NOCATALOG
command
line switch) and were never propagated by a subsequent run of RMAN are not registered
in the recovery catalog. Let's say a backup script is smart enough to check the availability
of the catalog and to run RMAN with the
NOCATALOG
option, should the availability test
fail. Should you lose the most recent control file before the catalog and control file are
resynchronized, you would not be able to restore the most recent archived redo log files,
even if the recovery catalog outage was already over.
After the loss of the most recent control file, recovery will not be possible while there is
an outage of the recovery catalog.
No special action is required to resynchronize backup metadata from the control file with
the recovery catalog. If needed, RMAN automatically propagates metadata records from the
control file to the recovery catalog whenever an RMAN command is run while connected to
a catalog. This feature may be leveraged to synchronize the control file metadata with two or
more recovery catalogs on different database servers, thus achieving higher availability of the
catalog without resorting to clustering or replication technologies. Merely run RMAN one more
time after the backup has finished, connect to an additional recovery catalog (e.g., with
CONNECT
CATALOG
), and execute the RMAN command
RESYNC
CATALOG
.
The aforementioned vulnerabilities could be worked around by creating a control file copy
(
ALTER
DATABASE
BACKUP
CONTROLFILE
TO
'
path
'
) and backing up that copy with a file system
backup utility. The downside of this approach is that the administrator performing the restore
will need to be familiar with and privileged for use of both RMAN and file system restore utili-
ties. Often, privileges for file system restores are available only to privileged operating system
users such as root on UNIX systems or the group Administrators on Windows systems. Thus,
a DBA would need assistance from a system administrator to perform restore operations.
Oracle9
i
RMAN shipped with the new automatic control file backup functionality,
1
which
addresses the issues discussed above. Automatic backup of the control file after each backup
makes sure that the most recent copy of the control file, i.e., the only copy that contains all the
bookkeeping information required to restore the last backup, is either backed up to disk or to a
media manager. However, this feature is disabled by default, such that databases remain vulner-
able, unless the DBA enables this new feature.
For the first time, thanks to automatic control file backup, the most recent control file can
be restored without accessing a recovery catalog. An example of how to restore a control file
from an automatic control file backup is shown in the next code segment. The database identifier
(
V$DATABASE.DBID
), which is stored inside the control file, is required by restore operations.
See documentation on the commands
CONFIGURE CONTROLFILE AUTOBACKUP ON
and
CONFIGURE
CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE
in [OL92 2002].
1.
