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
%> rman catalog rman/rman@<service name for database>
The correct output is shown below:
RMAN-06008: connected to recovery catalog database RMAN-06428: recover catalog is not installed
The following are description of various database modes.
The instance starts, but does not mount the control file or open the database. This mode is used to recreate a control file or recreate the database from scratch. The database is not open, and therefore access by users is not permitted.
An instance that is started and has the control file associated with the database open. You can mount a database without opening it; typically, you put the database in this state for maintenance or for restore and recovery operations. The database is not open, and therefore access by users is not permitted.
Cold backups (closed backups) are taken while the database is closed. Typically, closed backups are also whole database backups. If you closed the database cleanly, then all the files in the backup are consistent. If you shut down the database using a SHUTDOWN ABORT or the instance terminated abnormally, then the backups are inconsistent.
The instance is started, the database mounted and opened. This mode is the default startup mode which allows any valid user to connect to the database and perform typical data access operations. Hot backups (online backups) are performed when the database is opened.
Cold backups (closed backups) are taken while the database is closed. Typically, closed backups are also whole database backups. If you closed the database cleanly, then all the files in the backup are consistent. If you shut down the database using a SHUTDOWN ABORT or the instance terminated abnormally, then the backups are inconsistent.
This section contains the following topics:
Startup is the action of placing an Oracle instance in a state that allow users to access the database. To change the archiving status of the database, the database should be in the Mount state (mounted and closed).
Note: To start up a database, you must be connected to the database as SYSDBA.
Text description of the illustration instanca.gif
Startup is the action of placing an Oracle instance in a state that allow users to access the database.
Note: To start up a database, you must be connected to the database as SYSDBA.
Note: To shut down, then start and mount a database, you must be connected to the database as SYSDBA.
Shutdown is the action of taking an Oracle instance from a state that allows users to access the database to a dormant state; when the database is shut down, we say that it is closed. Shutdown terminates the processes required for users to access the database, and it releases the portion of your computer's memory within which Oracle was operating.
Current client SQL statements are terminated immediately. Uncommitted transactions are rolled back. Active transactions are rolled back and all users are disconnected.
Text description of the illustration shutdown.gif
A progress dialog appears, giving you the status of the operation.
Text description of the illustration bounce.gif
Press Close to dismiss the dialog once the database is mounted.
ARCHIVELOG mode permits complete recovery from disk failure as well as instance failure, because all changes made to the database are permanently saved in an archived redo log. The database can also be backed up while it is open and available for use.
Text description of the illustration recoverk.gif
If the database is in the Open state (mounted and open), Oracle Enterprise Manager displays the Shutdown Options dialog box allowing you to shut down the database. You can restart the database in the Mount state before changing the ARCHIVELOG mode.
If the database is in the No Mount or Started state (not mounted), Instance Management asks if you want to open the database in the Mount state.
Use the Run Rman Script feature to issue any command or script within Oracle Enterprise Manager that can also be called from the RMAN command line. The rman script will be run as a job through the Oracle Enterprise Manager Job System when you submit or schedule it.
Oracle Enterprise Manager's Job System enables the automation of standard and administrative tasks. With the Job System, you can create and manage jobs, schedule their execution, and view and share information about defined jobs with other administrators.
This section contains some examples of RMAN Backup. For more examples, refer to the Oracle9i Recovery Manager User's Guide.
A single recovery catalog is able to store information for multiple target databases. Consequently, loss of the recovery catalog can be disastrous. Back up the recovery catalog with the same frequency that you back up the target database.
For example, if you make a weekly whole database backup of the target database, then back up the recovery catalog immediately after all target database backups. The backed up catalog contains a record of the target backup preceding it, so if you need to restore the catalog you can use it to restore a target backup.
In the event that the catalog database and control file are destroyed, you can restore a control file from an autobackup and then use it to restore the catalog database.
Run the Backup of the database at regular intervals.
With this strategy, the control file autobackup feature ensures that the recovery catalog database can always be recovered.
Text description of the illustration bkrevcat.gif
To restore and recover the database without using a recovery catalog, follow the guidelines below:
If you lose the current control files, then you can restore a control file autobackup even if you do not use a recovery catalog.
Use the Maintenance Wizard to configure a backup policy which has the Excluding tablespaces in a backup option selected. For more information, refer to "Excluding tablespaces in a backup" on page 11-49.
The exclusion condition applies to any datafiles that you add to this tablespace in the future.
This tablespace exclusion feature is useful when you do not want to make a specified tablespace part of the regular backup schedule, as in these cases:
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.
Many DBAs find that regular whole database backups are not in themselves sufficient for a robust backup strategy. If you run in ARCHIVELOG mode, then you can back up the datafiles of an individual tablespace or even a single datafile. This option is useful if a portion of a database is used more extensively than others, for example, the SYSTEM tablespace and automatic undo tablespaces.
By making more frequent backups of the extensively used datafiles of a database, you avoid a long recovery time.
For example, you may make a whole database backup once every two weeks. If the database experiences heavy traffic during the week, then a media failure on Friday can force you to apply a tremendous amount of redo during recovery. If you had backed up your most frequently accessed tablespaces three times a week, then you could apply a smaller number of changes to roll the restored file forward to the time of the failure.
If you are running in automatic undo management mode, then be sure to regularly back up your undo tablespaces.
If you run in manual undo management mode, then be sure to regularly back up all tablespaces containing rollback segments.
If you want to change from using an automatic channel tape backup to backing up the database to disk using the default configured DISK channel, refer to "Specifying Disk Channel Device for Backup Set" on page 11-54.
Assume that you back up the database and archived logs every night to tape and you limit each backup set to two datafiles, so it produces multiple backup sets. Assume that the media management device crashes halfway through the backup and is then restarted. The next day you discover that only half the backup sets completed.
In this case, you can run to back up again, making sure that you have a backup policy configured for optimization. Database backups and archivelog backups may be optimized by skipping files that have not changed since the last backup. For more information, refer to "Choosing to optimize the backup." on page 11-48.
When backing up to disk, you can specify a format if you need to spread the backup across several drives for improved performance. In this case, allocate one DISK channel for each disk drive and specify the format string. Specify both the directory path and the unique file name format so that the filenames are on different disks.
<directory in disk1>%U
<directory in disk2>%U
<directory in disk3>%U
For more information, refer to "Specifying Disk Channel Device for Backup Set" on page 11-54.
When making backups, RMAN divides the total number of files requiring backups by the number of allocated channels to calculate the number of files to place in each backup set.
Set the size of the backup set in the Backup Set page of the Create Backup Configuration Property Sheet.
A non-cumulative incremental backup contains only blocks that have been changed since the most recent backup at the same level or lower.
If you add a new datafile or tablespace to the database, then make a level 0 backup before making another incremental backup. Otherwise, the incremental backup of the tablespace or the database fails because Recovery Manager does not find a parent backup for the new datafiles. Perform a level 0 backup of a single tablespace.
Note that you can perform incremental backups in NOARCHIVELOG mode, but the backups must be consistent. Hence, you cannot take online incremental backups.
For information on incremental backups, refer to "An incremental backup" on page 11-13.
A cumulative incremental backup at level n contains only blocks that have been changed since the most recent backup at level n - 1 or lower. Cumulative backups require more storage space than differential backups, but they are preferable during a restore operation because only one backup for a given level is needed. Note that the first incremental backup must be a level 0 backup that contains all used blocks.
A cumulative backup at level 2 will contain all blocks changed since the most recent level 1 backup, copying all blocks changed since the base level 0 backup only if a previous level 1 is unavailable. In contrast to a cumulative backup, a differential backup at level 2 will determine which level 1 or level 2 backup occurred most recently and copy all blocks changed since that backup.
For information on incremental backups, refer to "An incremental backup" on page 11-13.
When you create multiple backup sets and allocate multiple channels, RMAN automatically parallelizes its operation and writes multiple backup sets in parallel. The allocated server sessions share the work of backing up the specified datafiles, control files, and archived redo logs.
RMAN automatically assigns a backup set to a device.
For information on setting channels, refer to "Creating a Backup Configuration" on page 11-52.
If you configure a retention policy, then you may want to exclude specified backups from this policy. For example, you may want to archive a consistent backup of the database once a year to serve as a historical record. This long-term backups does not function as a backup that you may perform recovery on, but an archived snapshot of data at a particular time.
To exempt a backup from the retention policy, specify the The Keep this backup or copy until <specified time> option. For more information, refer to "Overriding the Retention Policy" on page 11-26.
Query the v$backup_set and v$datafile_copy tables for the KEEP time information.
Enable backup optimization. Refer to "Configuring a Backup Policy" on page 11-47. When specific conditions are met, RMAN skips backups of files that are identical to files that are already backed up.
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|
