Release 9.2.0
Part Number A96670-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle Enterprise Manager Administrator's Guide Release 9.2.0 Part Number A96670-01 |
|
Recovery Manager (RMAN) is an Oracle utility that can back up, restore, and recover database files. It is a feature of the Oracle database server and does not require separate installation. The Oracle Enterprise Manager Backup Management wizards and property sheets provide a graphical user interface to Recovery Manager. This chapter describes how to use Oracle Enterprise Manager to administer your database backup and recovery environment.
Recovery Manager uses database server sessions to perform the work of backup and recovery. It stores metadata about its operations in the control file of the target database and, optionally, in a recovery catalog schema in an Oracle database.
You can invoke RMAN as a command-line executable from the operating system prompt or use RMAN features through the Enterprise Manager GUI. The Oracle Enterprise Manager Backup Management wizards and property sheets provide a graphical user interface to Recovery Manager.
The Recovery Manager environment consists of the various applications and databases that play a role in a backup and recovery strategy. The RMAN environment can be as simple as an RMAN executable connecting to a target database, or as complex as an RMAN executable connecting to multiple media managers and multiple target, recovery catalog, and auxiliary databases, all accessed through Oracle Enterprise Manager.
Possible components of the RMAN environment are listed below.
Of these components, only the RMAN executable and target database are required. RMAN automatically stores its metadata in the target database control file, so the recovery catalog database is optional. Nevertheless, maintaining a recovery catalog is strongly encouraged. If you create a catalog on a separate machine, and if the production machine fails completely, then you have all the restore and recovery information you need in the catalog.
Text description of the illustration rman.gif
The figure above depicts an example of a realistic RMAN environment. In this environment, five nodes are networked together, with each machine serving a different purpose.
The five nodes share duties as follows:
In this scenario, you can run the RMAN executable from a client machine, and then connect to the target, catalog, and auxiliary databases. You can then run backup and recovery jobs. You can also connect to the client hosting Oracle Enterprise Manager and use the Oracle Enterprise Manager to access RMAN.
RMAN is the client application that manages backup and recovery operations for a target database. The RMAN executable is automatically included with the Oracle software installation. The RMAN client uses Oracle Net to connect to a target database, so it can be located on any host that is connected to the target host through Oracle Net.
The target database is made up of the control files, datafiles, and optional archived redo logs that RMAN is in charge of backing up, restoring, or recovering. RMAN uses the target database control file to gather information about the database and to store information about its own operations. The actual work of the backup and recovery jobs is performed by server sessions on the target database. You can use a recovery catalog to manage the metadata of the database.
You can use Oracle Enterprise Manager as an interface to RMAN. Access the wizards and property sheets using one of the following methods:
Note: The Backup Management wizards and property sheets are only available when you are connected to a Management Server.
The Backup Management wizards and property sheets consist of:
The Backup Wizard helps you to back up various objects such as the database, datafiles, tablespaces, and archivelog, or to make an image copy of the datafiles and the current controlfile.
The Recovery wizard helps you restore and recover various objects like databases, datafiles, and tablespaces. It guides you through the process of specifying what you want to restore and recover and submits a recovery job through the Enterprise Manager to complete the operation.
The Maintenance Wizard helps you perform maintenance operations on the target databases and on the recovery catalog. Using this wizard, you can set up backup and retention policies in a target database, or register, reset or resynchronize the target database with the recovery catalog.
Enterprise Manager creates a default backup configuration for each target database, but you can use the Create Backup Configuration property sheets to create other backup configurations for backup and recovery. A configuration can be used for one database or many databases depending if the systems are the same.
The Backup Configuration Library page displays backup configurations.
A recovery catalog database is a database containing the recovery catalog schema, which contains the metadata that RMAN uses to perform its backup and recovery operations.
The Recovery Catalog Schema is the user within the recovery catalog database that owns the metadata tables maintained by RMAN. RMAN uses these metadata tables to store information about the target database and its backup and recovery operations. Among other things, RMAN stores information about:
You can either use a recovery catalog in which to store the repository, or let RMAN store the repository exclusively in the target database control file.
Although RMAN can conduct all major backup and recovery operations using just the control file, note these advantages of using the catalog:
The recovery catalog is maintained solely by RMAN; the target database never accesses it directly. RMAN automatically propagates information about the database structure, archived redo logs, backup sets, and datafile copies into the recovery catalog from the target database's control file.
For Oracle9i and later, a recovery catalog is created if you specify for the Enterprise Manager repository to be located in a local database. The recovery catalog will be created in the CATTBS tablespace for you by default with the recovery catalog user and password of rman/rman.
Text description of the illustration recovery.gif
Important: The recovery catalog and the Oracle Enterprise Manager repository should not reside in the target database (database to be backed up). The recovery catalog can reside in the same database as your Oracle Enterprise Manager repository. Oracle recommends placing the recovery catalog in a separate tablespace. As with any important data, you should back up your recovery catalog regularly.
To use Recovery Manager with a recovery catalog, you must register your database with the recovery catalog. Refer to "Registering the Recovery Catalog" for more information. No setup is required if you are using the control file.
A standby database is a copy of the primary database that is updated using archived logs created by the primary database. RMAN can create or back up a standby database.
To store backups on tape, RMAN requires a media manager, which is a vendor-specific application. A media manager is a software program that loads, labels, and unloads sequential media such as tape drives used to back up and recover data. For information on configuring RMAN to make backups to a media manager, refer to the Oracle9i Recovery Manager User's Guide.
When doing backups or restores, the RMAN client connects to the target instance and directs the instance to talk to its media manager. No direct communication occurs between the RMAN client and the media manager: all communication occurs on the target instance.
A media management catalog is a vendor-specific repository of information about a media management application.
A backup is a copy of data. This copy can include important parts of the database such as the control file and datafiles. A backup is a safeguard against unexpected data loss and application errors. If you lose the original data, then you can reconstruct it by using a backup.
This section contains the following topics:
To back up a database
Text description of the illustration backupst.gif
For more information on using a customized backup strategy, see "Backing Up the Database with a Customized Strategy" on page 11-11.
Select Predefined backup strategy on the Strategy choice page of the Backup Wizard if you want to back up your entire database without having to make too many decisions. The Backup Frequency page appears with general descriptions from which you can choose.
Text description of the illustration backupfr.gif
Pick the description that fit your database in the Backup Frequency page, and RMAN will decide how often to perform a backup based on the general description that you pick.
If the selected (target) database is Oracle 9i and later, the Retain at least the specified number of backups for each datafile and delete obsolete backups after every backup checkbox and the Number of backups field are enabled in the Backup Frequency page.
The checkbox is selected by default. The default value is 2 for the number of backups to retain in the Number of backups field.
With this default selection, the retention policy of the target database will be set to redundancy 2. At least the 2 most recent full backups will be retained for each datafile. Older backups will be deleted after each new backup is successfully performed.
Later, in the process, wizard pages will appear in which you will have the option to perform the following tasks:
Select Customize backup strategy on the Strategy choice page of the Backup Wizard if you want to select the information you want to back up and the schedule for the execution of the backup.
In order to back up the whole database you must select Entire database on the Backup Selection page.
Text description of the illustration backupse.gif
If the target database is 9i or above and the retention policy has been set in the target database, you can also choose to delete obsolete backups after the backup.
For more information, see "Deleting Obsolete Backups and Copies" on page 11-12.
Later in the process, wizard pages will appear in which you will have the option to perform the following tasks:
If you are using a customized backup strategy and if the target database is 9i or above and the retention policy has been set in the target database, you can choose to have obsolete backups and copies deleted after the backup.
The retention policy determines which backups and image copies are obsolete. The current retention policy setting may be viewed through the Maintenance Wizard on the "Retention Policy" page. The retention policy may be modified through the Maintenance Wizard by submitting an Enterprise Manager job.
Select Delete obsolete backups after this backup on the Backup Selection page of the Backup Wizard. The retention policy determines which backups and image copies are obsolete. If selected, the obsolete backups and copies will be deleted when the backup is finished.
If you are using a customized strategy for your backup, you can choose to perform a full or an incremental level backup.
Select Full backup or Incremental Backup in the Backup Options page of the Backup Wizard.
Text description of the illustration backupop.gif
A full backup backs up all blocks into the backup set, skipping only datafile blocks that have never been used. The server process does not skip blocks when backing up archived redo logs or control files. A full backup has no effect on subsequent incremental backups, which is why it is not considered part of the incremental strategy. In other words, a full backup does not affect which blocks are included in subsequent incremental backups.
Incremental backups are a convenient way to conserve storage space because they back up only database blocks that have changed.
The primary reasons for making an incremental backup are
Incremental backups are a method by which you only backup modified blocks. An incremental level 0 backup performs the same function as a full backup in that they both backup all blocks that have ever been used except a level 0 will affect what blocks are copied out by subsequent incremental backups. Incremental backups of levels greater than 0 back up only blocks that have changed since previous incremental backups. Blocks which have not changed will not be backed up.
When you choose to make an incremental backup, you can choose a non-cumulative or a cumulative backup.
A non-cumulative backup is a type of incremental backup in which you back up all blocks that have changed since the most recent backup at level n or lower. For example, in a differential level 2 backup you back up all blocks modified since the last level 2, level 1, or level 0 backup. A non-cumulative backup copies less data and therefore takes a shorter time than the cumulative backup, but recovery time may be longer based on the number of incremental backups that must be applied.
A cumulative backup is a type of incremental backup that allows you to back up all the blocks used since the most recent backup at level n-1 or lower. For example, in a cumulative level 2 backup you back up all blocks used since the most recent level 1 or level 0 backup. A cumulative backup copies more data and therefore takes longer than the non-cumulative backup, but recovery time is shorter.
Choose a backup scheme according to an acceptable MTTR (mean time to recover). For example, you can implement a three-level backup scheme so that a full or level 0 backup is taken monthly, a cumulative level 1 backup is taken weekly, and a cumulative level 2 is taken daily. In this scheme, you never have to apply more than a day's worth of redo for complete recovery.
When deciding how often to take full or level 0 backups, a good rule of thumb is to take a new level 0 whenever 50% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 is appropriate.
If you are making a database backup using a customized strategy and the target database is in ARCHIVELOG mode, you can choose to make an online or an offline backup.
Select Online Backup or Offline Backup in the Backup Options page of the Backup Wizard.
An online backup is a backup of one or more datafiles taken while a database is open and the datafiles are online.
An offline backup is a backup when the database is not open.
Text description of the illustration backupop.gif
Online Backup is the default selection. If the database is in the OPEN state, the database backup will be performed while the database is OPEN.
If you choose Offline Backup, the database will be backed up in the MOUNT state. If the database is in the OPEN state, it will be shut down and brought to the MOUNT state before the backup is performed. When the backup is finished, the database will be brought back to OPEN state.
Your database contains a wide variety of types of data. When developing your backup strategy, you must decide what information you want to back up. The basic principle you should use when deciding what to back up is to prioritize data depending on its importance and the degree to which it changes.
You can backup up individual files with various options.
To back up datafiles or tablespaces, the database must be in ARCHIVELOG mode and the Mount State.
See "Starting Up the Database" and "Setting the Database in ARCHIVELOG Mode" for information on starting the database in Mount mode or putting the database in ARCHIVELOG mode.
Text description of the illustration backupsa.gif
If the target database is 9i or above and the retention policy has been set in the target database, you can also choose to delete obsolete backups after the backup.
For more information, see "Deleting Obsolete Backups and Copies" on page 11-12.
Text description of the illustration backupts.gif
During the process, a few wizard pages will appear in which you will have the option to perform the following tasks:
An archived redo log is an online redo log that Oracle has filled with redo entries, rendered inactive, and copied to one or more log archive targets. You should maintain multiple copies if possible.
Archived redo logs are the key to successful media recovery. Back them up regularly. You can back up logs by issuing selecting Archive Logs from a customized backup strategy or by backing up datafiles and control files and specifying to include archive logs in the backup.
Typically, database administrators back up archived logs on disk to a third-party storage medium such as tape. You can also back up archived logs to disk.
To select to back up archive logs and the date and time for the first and last archive logs to be backed up
Text description of the illustration backupar.gif
If you select to include all or selected archived logs in this backup, the Archived Log Deletion page appears.
From the Archived Log Deletion page, you can delete the input logs (from the primary archiving destination only) automatically after the backup completes.
Text description of the illustration backupaa.gif
Select one of the following options based on your available disk space and desired recovery time.
The default value for number of backups is 2. You may modify the value. With this selection, only archived logs with enough number of backups will be deleted after this backup.
Deleting archive logs saves space. Each archived log will be backed up once before it is deleted.
An image copy contains a single datafile, archived redo log file, or control file that you can use as-is to perform recovery. RMAN only writes image copies to disk.
Text description of the illustration backupsb.gif
Check the Use an image copy box if you want to back up a datafile using an image copy. Oracle supports performing a backup using an image copy of datafiles, or controlfiles. You can only perform an image copy of a controlfile with an image copy of a datafile. Using an image copy of only the controlfile is directly supported from the Backup Wizard. You may submit a "Run Rman Script" job separately from the Console to perform the controlfile image copy. For information on the Rman script, see "RMAN Job Script" on page 11-75.
Text description of the illustration backuplo.gif
During the process, a few wizard pages will appear in which you will have the option to perform the following tasks:
Backup and retention policies are a set of parameters set in the database which define how to perform a backup and how backups are retained. Once configured, these parameters apply to all the subsequent backups, but you can choose to override these backup and retention polices.
The Override Backup and Retention Policy page enables you to make a special backup occasionally that is different from what you have defined for your policy. For example, you may want to override the retention policy and keep one backup for a relatively longer period or you may want to perform a complete whole database backup by choosing Do not optimize this backup and Include all the tablespaces in a complete database backup.
The Override Backup and Retention Policy page is available if the target database is a 9i release or above, and the backup and retention policies have been set in the target database.
Text description of the illustration backupov.gif
The Do not optimize this backup option is enabled when the database has been configured to use backup optimization (from the Maintenance Wizard) and you have chosen to perform a database or archivelog backup. If checked, the Backup Wizard generates the "force" option in the RMAN command. The files are backed up even if they have not changed since the last backup. Choose this option if you want to override the backup optimization configuration.
The Include all the tablespaces in the complete database backup option is available if the target database has been configured to exclude some tablespaces from a database backup and you are planning to make a database backup. This allows you to override the "exclude for tablespace" configuration and include all tablespaces in the database backup. This corresponds to the "noexclude" option in RMAN.
The Keep this backup or copy until <specified time> option allows you to override the retention policy and keep the backup or copy until a specified time is available if a retention policy has been set in the target database. If the database is in ARCHIVELOG mode and you are planning to perform an online backup, the necessary archived logs will be kept to allow recovery of the database.
If the database is in ARCHIVELOG mode and you are planning to perform an offline backup, you have the option of whether to keep the subsequent archived logs or their backups.
Refer to the choices below:
If the subsequent logs are kept, a point-in-time recovery to any time between the backup time and today.
If the logs are not kept, the backup can only be used for vaulting purpose and and can be used only for recovery to the point of time when backup was taken.
Click the View Current Policies button to view the current backup and retention policy setting in the target database. The dialog is read-only.
Text description of the illustration backuppo.gif
Typically, you restore and recover a database or subset of a database in the following cases:
This section contains the following topics:
The basic procedure for performing restore and recovery with RMAN is as follows:
The default operation is to perform a restore and recover.
Restore only, recover only, and recover data blocks only are advanced options.
You may choose to perform a restore only in one of the following situations:
You may choose to perform a recovery only if you have restored the files before or you know there is no need to restore files.
You may choose to recover data blocks only in a 9i database if you know the corruption is limited to a few data blocks.
A recovery of an entire database is a recovery of all database files that belong to a database. RMAN uses the backups and copies that you made earlier and restores the files to their correct locations. Then, it uses archived redo logs (if needed) to recover the database.
You can recover the entire database to the latest time or to a point in time if the database is in ARCHIVELOG mode and MOUNT state.
To restore and recover the database using the default disk channel, perform the following steps:
Text description of the illustration recoverb.gif
Text description of the illustration restorea.gif
You can select to recover the database to a point-in-time in the past if you have selected Restore and recover or Recover only on the Operation Selection page, and the database is in the MOUNT state and ARCHIVELOG mode.
Text description of the illustration recoverd.gif
You can specify a point-in-time in the past by giving a time, an SCN or a log sequence number if you had selected Restore only in the Operation Selection page.
Text description of the illustration restoree.gif
Later, in the process, wizard pages will appear in which you will have the option to perform the following tasks:
If the database is in NOARCHIVELOG mode and MOUNT state, you can restore only the entire database.
When you run your database in NOARCHIVELOG mode, the filled online redo log files are not archived. If the database's redo log operates in NOARCHIVELOG mode, the database can be completely recovered from instance failure but not from disk failure. Also, the database can be backed up only while it is completely closed. Because no archived redo log is created, no extra work is required by the database administrator.
It is not uncommon for a media failure to affect some but not all files in a database. You can recover tablespaces or datafiles to the latest time if
Text description of the illustration recovere.gif
If you have chosen Restore and recover or Recovery only on the Operation Selection page and the database is in the Open state and ARCHIVELOG mode, you can recover the files to the latest time.
Text description of the illustration recovera.gif
If you had selected Restore only on the Operation Selection page, and the database is in the OPEN state and ARCHIVELOG mode, you can restore the files from the latest backup or an older backup.
Text description of the illustration restores.gif
Text description of the illustration recoverh.gif
Later, in the process, wizard pages will appear in which you will have the option to perform the following tasks:
When the database is in the NOMOUNT (Started) state and there are no backup configurations which use a recovery catalog, you can restore a controlfile from a controlfile autobackup for Oracle 9.0.1 target databases. For pre-9.0.1 target databases, an error dialog appears when the database is in NOMOUNT and there are no backup configurations that use a recovery catalog.
Text description of the illustration recoverg.gif
If you have performed backups to tape, your controlfile autobackups are located on both disk and tape. To restore the controlfile from autobackup, select the backup configuration you used when backing up to tape. Both tape and disk will be searched and the latest autobackup will be used to restore the controlfile.
If you have never performed a backup to tape, all your controlfile autobackups are located on disk. To restore the controlfile from autobackup, select the backup configuration you used to backup to disk. The latest autobackup will be used to restore the controlfile.
RMAN requires the DBID to be specified when restoring controlfile from autobackup. If you have performed at least one backup from the Enterprise Manager Backup Wizard, the DBID is stored in the Enterprise Manager repository and the value is filled in the DBID field. Otherwise you will have to enter the DBID manually.
If you have specified a location for the autobackup on disk using the Maintenance Wizard, the location is stored in the Enterprise Manager repository and the value is filled in the location field. Otherwise you have to fill in the value manually. If you do not specify a value, the default location will be searched for autobackups on disk.
You can restore archive log files for use with LogMiner Viewer if the archivelogs need to be restored from backups if they are no longer on disk.
Text description of the illustration restoreb.gif
Text description of the illustration restorec.gif
Text description of the illustration restored.gif
You can recover datablocks if
Text description of the illustration recoveri.gif
The Corruption List option is the default and preferred selection for most users. All the data blocks that have been identified corrupted by RMAN during the backup and copy operations can be recovered.
Data block corruption in non-RMAN operations, such as dbverify, is not included in the corruption list. To recover those database blocks, you will have to find the block numbers or data block addresses of the corrupted blocks from Oracle standard output, an alert.log. user trace files, results of the ANALYZE TABLE and ANALYZE INDEX SQL commands, result of the DBVERIFY utility, or third-party media management output. However, the corrupted blocks are always recorded in the alter.log file.
The View Corruption List button is visible for 9.2 databases only. By clicking the button, a Corruption List dialog will appear, showing the current data blocks that are labeled corrupted by RMAN.
Select the Datafiles option on the Block Media Recovery Method page if the block numbers of the corrupted data blocks can be found in one of the places listed above.
When the Data Block Selection by Datafile page appears, enter the block numbers of the corrupted data blocks for each datafile. If you are entering more than one block number for a datafile, separate the entries by a space or comma.
Select the Tablespaces option on the Block Media Recovery Method page if the data block addresses of the corrupted data blocks can be found in one of the places listed above.
When the Data Block Selection by Tablespace page appears, enter the data block addresses for each tablespace. If you are entering more than one block address for a tablespace, separate the entries by a space or comma.
Text description of the illustration bmrtable.gif
You will use the Maintenance wizard to help you perform maintenance operations on the target databases and on the recovery catalog.
This section contains the following topics:
To set up backup and retention policies in a target database
You may modify persistent RMAN configurations in the target database using this option.
The wizard proceeds to the Backup Policy and Retention Policy pages where you can modify backup related RMAN configuration parameters. This option is enabled for 9i and above databases only. A one time job will be submitted to execute the changes.
Choose a backup policy for your database.
Text description of the illustration maintenc.gif
By default this option is not selected, but it is highly recommended that you choose the option for your database and set the location for the autobackup on disk.
The controlfile and server parameter file (SPFILE) will be backed up automatically after each backup. Additionally these files are backed up automatically after each structural change in the database. The backups of these files are called controlfile autobackups.
If you are making a backup to disk, the controlfile and SPFILE will be automatically backed up to disk. The database backup location is determined by the format of the allocated disk channel. The controlfile autobackup is located in what is specified in the Location for the autobackup on disk field.
If you are making a backup to tape, the controlfile and SPFILE will be automatically backed to tape. The database backup format is determined by the format of the allocated tape channel. The controlfile autobackup format is always %F.
After each structural change (such as adding a tablespace or a datafile) in the database, the controlfile and SPFILE will always to backed up to disk.
The autobackup is located in what is specified in the Location for the autobackup on disk field below.
Note: %F is required as part of the format string. %F contains DBID information which is used to uniquely identify a database.
Specify the Location for the autobackup on disk. It is the location of the autobackups if you are making a backup to disk and after a database structural change. If you do not specify a location on disk, the default location will be used. The default location is on the same disk as the database. The default location is unlikely to be available when you need to restore the controlfile from autobackup. Therefore, it is highly recommended that you specify a disk location which is different from the database location.
If the autobackup format for disk has not been configured in the database, the location appears as <Directory>%F. You are recommended to change the Directory path.
If the autobackup format for disk has been configured, the configured format will appear in the location field.
Note: %F is required as part of the format string. %F contains DBID information which is used to uniquely identify a database.
Database backup and archivelog backup may be optimized by skipping files that have not changed since the last backup. Typical examples of unchanged files include offline or read-only datafiles as well as archivelogs. Once backup optimization is set, archivelogs can only be backed up once unless you specify Yes, delete archived logs only after a specified number of backups option in the Backup Wizard's Archived Log Deletion page (available for 9.2 target databases).
You can choose to exclude some tablespaces from a complete database backup. These tablespaces can still be backed up separately using a tablespace backup. This option allows you to exclude some extremely large but rarely modified tablespaces from a database backup, and back them up on a different schedule. This may reduce the amount of time required for a regularly scheduled database backup.
A retention policy allows you to define how long to retain your backups before they are marked obsolete. Based on this policy, RMAN will mark backups you do not need as obsolete. You can delete obsolete backups by regularly running delete obsolete operations.
Text description of the illustration maintenb.gif
Select the Set the retention policy of backups option to use a retention policy. You can set the policy to retain backups so that you are able to recover database until the past "number of days"or to retain a "number of backup copies."
The Number of days option corresponds to "configure retention policy to recovery window of x days", where x is the value from the Number of days field.
The Number of backups option corresponds to "configure retention policy to redundancy y", where y is the value of the Number of backups field.
Select the No retention policy is set option if you want to manually delete backups. This option corresponds to RMAN's "configure retention policy to none" option.
To register, reset, or resynchronize the target database with the recovery catalog
Text description of the illustration maintena.gif
The target database must be registered with the Recovery Catalog before the Backup wizard can use it. You only need to register the database once.
Choose the Register database option in Operation choice page.
The recovery catalog obtains crucial RMAN metadata from the target database control file. Resynchronization of the recovery catalog ensures that the metadata that RMAN obtains from the control file stays current. Resynchronizations can be full or partial. In a partial resynchronization, RMAN reads the current control file to update changed data, but does not resynchronize metadata about the database physical schema: datafiles, tablespaces, redo threads, rollback segments, and online redo logs. In a full resynchronization, RMAN updates all changed records, including schema records.
RMAN automatically detects when it needs to perform a full or partial resynchronization and executes the operation as needed. You can also force a full resynchronization by issuing a RESYNC CATALOG command.
To ensure that the catalog stays current, run the RESYNC CATALOG command periodically if you run backups periodically.
You will not need to run the RESYNC CATALOG command if you perform at least one backup in n days, where n is the setting for the initialization parameter CONTROL_FILE_RECORD_KEEP_TIME. When you start the RMAN backup (or any other operation) it will automatically perform a "RESYNC CATALOG". In other words, if you perform a backup fairly often (for example, every 2-5 days), then there is no need to do "RESYNC CATALOG" manually.
Because the control file employs a circular reuse system, backup and copy records eventually get overwritten. Resynchronizing the catalog ensures that these records are stored in the catalog and so are not lost.
Resetting the database is rarely performed and should only be done if all the information has been lost. You must reset the recovery catalog if the target database had been previously opened with the RESETLOGS option. Refer to the Oracle9i Recovery Manager User's Guide for information on the RESETLOGS option.
RMAN contains some default configuration settings. These settings apply to all RMAN sessions until you explicitly change them.
An RMAN channel represents one stream of data to a device type and corresponds to one server session. Allocation of one or more RMAN channels is necessary to execute most backup and recovery commands. Each channel establishes a connection from the RMAN executable to a target or auxiliary database instance by starting a server session on the instance. The server session performs the backup, restore, and recovery operations. Only one RMAN session communicates with the allocated server sessions.
RMAN comes preconfigured with a DISK channel that you can use for backups and copies to disk.
This section contains the following topics:
A configuration is a set of defaults you set up for backup and recovery. Enterprise Manager creates a default backup configuration for each target database, but you can use the Create Backup Configuration property sheets to create other backup configurations for backup and recovery. A configuration can be used for one database or many databases depending if the systems are the same.
To create a backup configuration
The Channels page allows you to specify a channel or channels. A channel establishes a connection from the database to the storage device for backup or restore operations. A channel can be either disk or tape-based. Multiple channels can be created to allow parallel backup/recovery by a single job.
Note: If you are connected to a Certified Configurations database, refer to the Oracle Certified Configuration Administrator's Reference for information on features unique to Certified Configurations backups.
Note: At least one channel must exist before performing a backup, restore, or recover operation.
Attention: Oracle9i can only allocate one Recovery Manager channel at a time, thus limiting the parallelism to one stream. The Oracle9i Enterprise Edition allows unlimited parallelism. See Oracle9i Database New Features for more information about the features available with Oracle9i and Oracle9i Enterprise Edition.
To create a configuration that backs up to disk using a backup set, specify the following on the Channels page of the Create Backup Configuration property sheet:
<Directory>b_%u_%p_%c
Text description of the illustration configch.gif
The Directory is the drive and path where backup sets are stored. You must specify a proper directory for the channel. The directory field must end with a proper delimiter, which is OS dependent.
The File Name is the unique backup set name. The following parameters can be used:
To create a configuration that backs up to tape using a backup set, specify the following on the Channels page of the Create Backup Configuration property sheet:
parms parameter, see the Oracle9i Recovery Manager User's Guide and the corresponding Media Management documentation.
Text description of the illustration configca.gif
The following parameters can be used for specifying the unique file format name:
To set the limits for any backup or copy operation, press the Channel Limits button on the Channels page of the Create Backup Configuration property sheet.
For any setting, you move the slider bar to change its value or type in the value. The number in the field changes according to the position of the slider bar.
Text description of the illustration limits.gif
Checking Maximum Capacity allows you set the maximum number of units that a backup operation can write to a single backup.
Checking Maximum Read Rate allows you to control the number of blocks per second read by a backup or copy operation from or to any input datafile. Controlling the read rate ensures that a backup or copy operation does not consume excessive disk bandwidth, which can degrade online performance.
Checking Maximum Open Files allows you to control the maximum number of input files that a backup or copy operation can have open simultaneously. Setting maximum number of open files is particularly useful when backing up a large number of archivelogs into a single backup set.
To create a configuration that uses an image copy, specify the following on the Channels page of the Create Backup Configuration property sheet:
Image copies can only be written to disk.
Text description of the illustration configcb.gif
In the Parallelism field, specify the number of channels for the image copy.
In the Base Location field, specify the location to which you want to copy all the selected files. You must specify a proper directory for the channel. The directory field must end with a proper delimiter, which is OS dependent.
Note: Unlike a backup set, the image copy channel does not need a format because the copy is a one-to-one just like the cp command at the OS level.
You can also specify one set of channel limits, which applies to all the channels in an image copy configuration. Assigning different limits for different channels in an image copy is not a necessity.
Note: At least one channel must exist before performing a backup, restore, or recover operation.
Attention: Oracle9i Standard Edition can only allocate one Recovery Manager channel at a time, thus limiting the parallelism to one stream. The Oracle9i Enterprise Edition allows unlimited parallelism. See Oracle9i Database New Features for more information about the features available with Oracle9i and Oracle9i Enterprise Edition.
A proxy copy is a special type of backup in which RMAN turns over control of the data transfer to a media manager that supports this feature.
You can choose to have Media Management Software take over the backup and recovery of your files instead of using RMAN.
To choose to use a Proxy copy, specify Use Proxy copy supported by media management software to perform a backup on the Backup Set page of the Create Backup Configuration property sheet.
RMAN will provide a list of files that need backup or recovery to the media manager. Proxy copy applies only if you are integrated with media manager software that has implemented the proxy feature.
When the Use Proxy copy supported by media management software to perform a backup checkbox is selected, you can further specify what to do when the proxy copy fails.
Text description of the illustration configba.gif
The proxy option is enabled only if you have created a Tape channel because having a Tape channel tells the media management software to take over the backup. Tape means that data goes to the media management software which in most cases will be backed up to a physical tape.
To set storage parameters for the current backup set and override the Recovery Manager default settings that the Recovery Manager has calculated, specify Override Recovery Manager defaults on the Backup Set page of the Create Backup Configuration property sheet.
The Override Recovery Manager defaults checkbox is disabled when Image Copy on the Channels Page is selected. The checkbox is enabled only when Backup Set is selected and the page is not read-only.
Checking Maximum files at a time in a backup set allows you to set the maximum number of files that can be placed in a single backup set. If the number of files selected for the current backup exceed this number, multiple backup sets are created. In addition, multiple channels, if defined and available, will also be used.
Checking Maximum size of a backup set allows you to set the maximum file size of a backup set. You can specify file size in megabytes or kilobytes. Specifying a set size for backup sets permits better load balancing when performing backups.
Checking Maximum files at a time in a backup set allows you to set the maximum number of files that can be placed in a single backup set for archivelogs. If the number of files selected for the current backup exceed this number, multiple backup sets are created. In addition, multiple channels, if defined and available, will also be used.
Checking Maximum size of a backup set for archivelogs allows you to set the maximum file size of a backup set for archivelogs. You can specify file size in megabytes or kilobytes. Specifying a set size for backup for archivelogs permits better load balancing when performing backups.
The enrolling of a database in a recovery catalog is called registration. You can register a database only once in a given catalog schema: for example, you cannot register prod1 in the catowner catalog and then register prod1 again in the catowner catalog.
Text description of the illustration configrc.gif
To register the first database with the recovery catalog, specify the following on the Recovery Catalog page of the Create Backup Configuration property sheet:
rman.rman.The service name is the name of the database where the recovery catalog resides.
If you choose to use an existing service, you can choose from a list of all the service names of databases that have been discovered by the Management Server.
If you choose to enter a new service, you must enter a new recovery catalog service by specifying the host name, port and sid.
A TNS descriptor constructed using the user supplied host name, port and sid will be used to connect to the recovery catalog database during the backup.
You only need to register the database once. The Backup Configuration you have set become your default backup configuration if you use the Backup and Recovery wizards and submit a job.
If the Oracle Enterprise Manager Console's preferred credentials are not set to SYSDBA and you do not want to set the login credentials to SYSDBA in the Console, you can set SYSDBA credentials that will only be used for backup and recovery jobs.
When running backup and recovery jobs, these configurations will take precedence over the preferred credentials set in the Oracle Enterprise Manager Console.
To use the same configuration on subsequent databases, follow the steps below.
Once the job is completed, check the job history in the Jobs property sheet to make sure that the job completed successfully.
RMAN automatically resynchronizes the catalog on each backup. So, manual resynchronizing of the catalog is needed only in rare cases.
The recovery catalog is not updated automatically when a log switch occurs or when an log is archived. Also, any structural changes to the target database would require re-synchronization of the Recovery Catalog.
To resynchronizes the Recovery Catalog with the target database so that the recovery catalog is updated with current information from the control file of the target database:
Once the job is completed, check the job history in the Jobs property sheet to make sure that the job completed successfully.
This section contains the following topics:
For Oracle9i, a recovery catalog is created if you specify for the Enterprise Manager repository to be located in a local database.
If you want to create the recovery catalog user and schema with a script, follow the procedure below:
CREATE TABLESPACE "CATTBS" LOGGING DATAFILE 'CATTBS.dbf' SIZE 10M AUTOEXTEND ON MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL; CREATE USER rman IDENTIFIED BY rman DEFAULT TABLESPACE CATTBS TEMPORARY TABLESPACE TEMP QUOTA UNLIMITED ON CATTBS; GRANT RECOVERY_CATALOG_OWNER TO rman; GRANT CONNECT, RESOURCE TO rman;
rman CATALOG rman/rman@<database alias>
CREATE CATALOG;
The creation of the catalog could take several minutes.
To set up a recovery catalog, you must complete the following procedures:
From the Oracle Enterprise Manager Console, perform the following steps to create a tablespace:
cattbs.
A datafile is added by default to the tablespace with a default name and default size, but if you can edit them. In Datafile section, check that the Name field contains the complete path and name of the datafile. For example: c:/orant/oradata/cattbs.dbf. In the Size section, change the size of the new datafile if you want. For example, 10 M.
From the Oracle Enterprise Manager Console, perform the following steps to create a user:
Follow the instructions below:
Follow the instructions below