Sunteți pe pagina 1din 2

Overview of RMAN Functional Components:

The RMAN environment consists of the utilities and databases that play a role in backing up your data.
At a minimum, the environment for RMAN must include the following:

The target database to be backed up:


The RMAN client, which interprets backup and recovery commands,
Directs server sessions to execute those commands,
And records your backup and recovery activity in the target database control file.

Target Database:
The target database is the database that you are backing up, restoring, or recovering with RMAN.

RMAN Repository:
RMAN maintains metadata about the target database and its backup and recovery operations in the RMAN repository.
Among other things, RMAN stores information about its own configuration settings, the target database schema,
Archived redo logs, and all backup files on disk or tape.
RMAN's LIST, REPORT, and SHOW commands display RMAN repository information.

RMAN repository data is always stored in the control file of the target database.:
The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter controls how long backup records are kept
in the control file before those records are re-used to hold information about more recent backups.
The repository can also be kept in a recovery catalog,
a separate database that keeps historical data on backup activities much longer than the control file and preserves
backup information if the control file is lost.

Recovery Catalog:
In addition to RMAN repository records, the recovery catalog can also hold RMAN stored scripts,
Sequences of RMAN commands for common backup tasks.
Centralized storage of scripts in the recovery catalog can be more convenient than working with command files.
For more information on the recovery catalog see Oracle Database Backup and Recovery Advanced User's Guide.

Types of Oracle Database Backup under RMAN

There are several ways of distinguishing among physical backups, according to the state the database was in when the
backup was created, what parts of the database were actually backed up, and how the resulting backup was stored.

1.5.3.1 About Consistent and Inconsistent Backups

Physical backups can also be divided into consistent and inconsistent backups. Consistent backups are those created
when the database is in a consistent state, that is, when all changes in the redo log have been applied to the datafiles. A
database restored from a consistent backup can be opened immediately, without undergoing media recovery. However,
a consistent backup can only be created after a consistent shutdown, that is, not after a crash or a SHUTDOWN
ABORT.
For reasons of availability, the Oracle database is designed to work equally well with an inconsistent backup, a backup
taken while the database is open. However, when a database is restored from an inconsistent backup, it must undergo
media recovery, so that the database can apply any pending changes from the online and archived redo log before the
database is opened again. Because archived logs are required for media recovery, using inconsistent backups requires
that your database be run in ARCHIVELOG mode.

1.5.3.2 About Full and Incremental Backups

Full backups are backups which include datafiles in their entirety. Full backups can be created with Recovery Manager
or with operating system-level file copy commands. Incremental backups are based on the idea of making copies only
of changed data blocks in a data file. In recovery, extracting entire changed blocks from an incremental backup can
substitute for applicationof redo for individual datafile updates during the time covered by the backup, shortening
recovery times considerably. Incremental backups can only be created with RMAN.

_______________________________________________________________________________________________

Tablespace Point-in-Time Recovery:


This section supplements tablespace point-in-time recovery (TSPITR) information in the Oracle9i User-Managed
Backup and Recovery Guide. The most complicated task involved in TSPITR is configuring the parameters for the
auxiliary instance, which is set up as a separate OSDI database service in the same or a different OSDI subsystem.
Assuming that ORA1 is the target database service and that ORA2 is the auxiliary database service, the following are
examples of init.ora parameters for the auxiliary instance:

CONTROL_FILES:
refers to the name of the control file for the auxiliary instance. Because the auxiliary instance does not really contain
any user data, one control file is used for simplicity.

DB_FILE_NAME_CONVERT:
This parameter is used to update the auxiliary instance control file with the location of the auxiliary instance files.

DB_NAME
must be set to the same value as the target database name.

LOCK_NAME_SPACE:
must be set to a unique value such as underscore, followed by the target database name. It allows the auxiliary instance
to start up even though it has the same name as the primary database.

LOG_FILE_NAME_CONVERT:
This parameter is used to update the auxiliary instance control file with the location of the log files.

The other parameters are to be the same as those for the target database.

The control files, database, data files, and online log files for the auxiliary instance can be pre-allocated, or you can rely
on the ORA$FPS parameters of the auxiliary service to govern file creation. The auxiliary instance is to be started, but
unmounted: (START NOMOUNT).