Deciding Whether to Use RMAN with a Recovery Catalog
By default, RMAN connects to the target database in NOCATALOG mode, meaning that it uses the control file in the target database as the sole repository of RMAN metadata. Perhaps the most important decision you make when using RMAN is whether to create a recovery catalog as the RMAN repository for normal production operations. A recovery catalog is a schema created in a separate database that contains metadata obtained from the target control file.
Benefits of Using the Recovery Catalog as the RMAN Repository
When you use a recovery catalog, RMAN can perform a wider variety of automated backup and recovery functions than when you use the control file in the target database as the sole repository of metadata.
The following features are available only with a catalog:
• You can store metadata about multiple target databases in a single catalog.
• You can store metadata about multiple incarnations of a single target database in the catalog. Hence, you can restore backups from any incarnation.
• Resynchronizing the recovery catalog at intervals less than the CONTROL_FILE_RECORD_KEEP_TIME setting, you can keep historical metadata.
• You can report the target database schema at a noncurrent time.
• You can store RMAN scripts in the recovery catalog.
• When restoring and recovering to a time when the database files that exist in the database are different from the files recorded in the mounted control file, the recovery catalog specifies which files that are needed. Without a catalog, you must first restore a control file backup that lists the correct set of database files.
• If the control file is lost and must be restored from backup, and if persistent configurations have been made to automate the tape channel allocation, these configurations are still available when the database is not mounted.
Costs of Using the Recovery Catalog as the RMAN Repository
The main cost of using a catalog is the maintenance overhead required for this additional database.
For example, you have to:Find a database other than the target database to store the recovery catalog (otherwise, the benefits of maintaining the catalog are lost), or create a new database Create enough space on the database for the RMAN metadata.
• Back up the recovery catalog metadata
• Upgrade the recovery catalog when necessary
The BACKUP command can back up the following types of files:
Database, which includes all datafiles as well as the current control file and current server parameter file:
• Tablespaces (except for locally-managed temporary tablespaces)
• Current datafiles
• Current control file
• Archived redo logs
• Current server parameter file
• Backup sets
RMAN does not back up the following:
• Online redo logs
• Transported tablespaces before they have been made read/write
• Client-side initialization parameter files or noncurrent server parameter files
By default, RMAN connects to the target database in NOCATALOG mode, meaning that it uses the control file in the target database as the sole repository of RMAN metadata. Perhaps the most important decision you make when using RMAN is whether to create a recovery catalog as the RMAN repository for normal production operations. A recovery catalog is a schema created in a separate database that contains metadata obtained from the target control file.
Benefits of Using the Recovery Catalog as the RMAN Repository
When you use a recovery catalog, RMAN can perform a wider variety of automated backup and recovery functions than when you use the control file in the target database as the sole repository of metadata.
The following features are available only with a catalog:
• You can store metadata about multiple target databases in a single catalog.
• You can store metadata about multiple incarnations of a single target database in the catalog. Hence, you can restore backups from any incarnation.
• Resynchronizing the recovery catalog at intervals less than the CONTROL_FILE_RECORD_KEEP_TIME setting, you can keep historical metadata.
• You can report the target database schema at a noncurrent time.
• You can store RMAN scripts in the recovery catalog.
• When restoring and recovering to a time when the database files that exist in the database are different from the files recorded in the mounted control file, the recovery catalog specifies which files that are needed. Without a catalog, you must first restore a control file backup that lists the correct set of database files.
• If the control file is lost and must be restored from backup, and if persistent configurations have been made to automate the tape channel allocation, these configurations are still available when the database is not mounted.
Costs of Using the Recovery Catalog as the RMAN Repository
The main cost of using a catalog is the maintenance overhead required for this additional database.
For example, you have to:Find a database other than the target database to store the recovery catalog (otherwise, the benefits of maintaining the catalog are lost), or create a new database Create enough space on the database for the RMAN metadata.
• Back up the recovery catalog metadata
• Upgrade the recovery catalog when necessary
The BACKUP command can back up the following types of files:
Database, which includes all datafiles as well as the current control file and current server parameter file:
• Tablespaces (except for locally-managed temporary tablespaces)
• Current datafiles
• Current control file
• Archived redo logs
• Current server parameter file
• Backup sets
RMAN does not back up the following:
• Online redo logs
• Transported tablespaces before they have been made read/write
• Client-side initialization parameter files or noncurrent server parameter files
