Hi,
My name is Mark Tiger, creator
of this blog. I am an Oracle Certified
Professional (OCP DBA 11g).
Gathering information for some
DBA tasks can be time-consuming, even although the commands that you need to
issue eventually can be over quite quickly.
I have gone through this process over and over again, and have decided
to help other Oracle DBA’s in the community.
In this blog, I will give you
the details of how to carry out those tasks; that typically need a lot of
research, before you can do them. I will
try to present the information in an easy to understand way. My hope is that this will save you lots of
time in research, and help to make you more productive as an Oracle DBA. The illustrations are primarily meant for
Linux, since this is a Platform; that enjoys preference from Oracle. However they are easily adaptable for
versions of UNIX/AIX and windows etc.
Overview of the Recovery Catalog
A Recovery Catalog is a
Database Schema used by RMAN to store metadata about one or more Oracle
databases. Typically you store the
catalog in a dedicated database. The
following benefits are associated with a Recovery Catalog.
·
A Recovery Catalog creates redundancy for the
RMAN repositorystored in the control file of each target database. The recovery catalog serves as a secondary
metadata repository. If the control file
and all the backups are lost, then the RMAN metadata still exists in the
recovery catalog.
·
A Recovery Catalog centralizes metadata for all
your target databases. Storing the
metadata in one place, makes reporting and administrative tasks easier to
perform.
·
A recovery catalog can store metadata history
much longer than the control file. This
capability is useful, if you need to do a recovery that goes back further in
time than the history in the control file.
The added complexity of managing a recovery catalog database can be
offset by the convenience of having the extended backup history available.
Some RMAN only function when
used with a recovery catalog. For
example stored scripts, need to be stored in a recovery catalog. A RMAN script is available to any RMAN client
that can connect to the target database, and the recovery catalog. Command files are only available if the RMAN
client has access to the file system on which they are stored.
A Recovery Catalog is required
when you use RMAN in a Data Guard environment.
By storing backup metadata for all primary and standby databases, the
catalog enables you to offload backup tasks to one standby database while enabling you to restore backups on another
database in the environment.
The recovery catalog contains
metadata about RMAN for each registered target database. When RMAN is connected to the catalog, then
RMAN obtains its metadata exclusively from the recovery catalog. The recovery catalog includes the following
types of metadata:
·
Data file and archived redo log backup sets and
backup pieces
·
Data file copies
·
Archived redo logs and their copies
·
Database structures, tablespaces and data files
·
Stored scripts, which are names user-created
sequences of RMAN commands
·
Persistent RMAN configuration settings
The process of enrolling of a
database in a recovery catalog for RMAN use is called “registration”. The recommended practice is to register every
target database in your environment in a single recovery catalog.
The owner of a centralized
recovery catalog, which is also called the “base recovery catalog”; can grant
or revoke restricted access to the catalog to other database users. Each restricted user has full read/write
access to his own metadata, which is called a “Virtual Private Catalog”. The RMAN metadata is stored in the schema of
the Virtual Private Catalog owner. The
owner of the base recovery catalog determines which objects each virtual
private catalog user can access.
You can use a recovery catalog
in an environment in which you use or have used different versions of the
Oracle Database. As a result your
environment can have different versions of the RMAN client, recovery catalog
database, recovery catalog schema, and target database.
For RMAN operations such as
backup, restore, and crosscheck, RMAN always first updates the control file and
then propagates the data to the recovery catalog. This flow of metadata from the mounted
control file to the recovery catalog is known as Recovery Catalog “Resynchronization”. This process ensures that the metadata that
RMAN accesses from the Control file is current.
You can use a stored script as
an alternative to using a command file, especially useful for frequently used
sequences of RMAN commands. The script
is stored in the recovery catalog, rather than in the file system.
A local stored script is associated
with the target database to which RMAN is connected when the script is
created. To execute this script you must
be connected to the same target database.
A global stored script can be run against any database registered in the
recovery catalog. A virtual private
catalog user has read-only access to global scripts. To create or update a Global script, you must
be connected to the Base Recovery Catalog.
In a Data Guard environment,
you must use a recovery catalog to manage Metadata for all physical databases, both primary and
standby. RMAN references the recovery
catalog as the single source of truth for entire Data Guard environment.
You can update a primary or
standby control file with a “reverse resynchronization” mechanism, using RMAN. In “reverse resynchronization”, the metadata
flows from the catalog to the control file, rather than the standard way, which
is the other way around. RMAN will
automatically perform resynchronizations in most situations in which it is
needed. This means that you will only
need to use the manual RESYNC command on rare occasions.
Steps for Managing a Recovery Catalog
1. Create
the Recovery Catalog
2. Register
your target database in the recovery catalog.
RMAN can then store the metadata for your target database
3. If
necessary; catalog older backups whose records have aged out of the control
files
4. Create
Virtual Private Catalogs for users, and determine what metadata they will have
access to
5. Protect
the Recovery Catalog, by including it in your backup and recovery strategy
Mark Tiger,
Need a Database Health Check, Remote Monitoring, Support,
Maintenance, or a Security Audit?
P.S. I am busy
preparing Nine books on preparing for the Oracle 11g R2 OCM DBA exam.
Watch this spot for details on the books, as they start becoming available.
No comments:
Post a Comment