| Oracle® Database Backup and Recovery Basics 10g Release 1 (10.1) Part Number B10735-01 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Basics 10g Release 1 (10.1) Part Number B10735-01 |
|
|
View PDF |
This chapter describes how to start RMAN and prepare the RMAN environment for implementation of your backup and recovery strategy.
This chapter includes the following topics:
You have the following basic options for starting RMAN:
% rman
% rman TARGET / % rman TARGET SYS/oracle@trgt NOCATALOG % rman TARGET / CATALOG rman/cat@catdb
If you connect to the target database on the operating system command line, then you can begin executing commands after the RMAN prompt is displayed. If you start RMAN without connecting to the target database, then you must issue CONNECT TARGET command at the RMAN prompt.
To quit RMAN and terminate the program, type EXIT or QUIT at the RMAN prompt. For example:
RMAN> EXIT
You can connect to the following types of databases.
When connecting to a target or auxiliary database, you must have the SYSDBA privilege. You can connect as SYSDBA with a password file or with operating system authentication.
|
Note: You do not need to specify the |
If the target database uses password files, then you can connect using a password. Use a password file for either local or remote access. You must use a password file if you are connecting remotely as SYSDBA with a net service name.
If you connect to the database using operating system authentication, remember to set the environment variable specifying the Oracle SID. For example, to set the SID to trgt at the UNIX command line enter:
% ORACLE_SID=trgt; export ORACLE_SID
A SYSDBA privilege is not required when connecting to the recovery catalog. Note that you must grant the RECOVERY_CATALOG_OWNER role to the schema owner.
| See Also:
Oracle Database Administrator's Guide to learn how to authenticate users on a database |
Before invoking RMAN, set the NLS_DATE_FORMAT and NLS_LANG environment variables. These variables determine the format used for the time parameters in RMAN commands such as RESTORE, RECOVER, and REPORT.
The following example shows typical language and date format settings:
NLS_LANG=american NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS'
If you are going to use RMAN to connect to an unmounted database and mount the database later while RMAN is still connected, then set the NLS_LANG environment variable so that it also specifies the character set used by the database.
A database that is not mounted assumes the default character set, which is US7ASCII. If your character set is different from the default, then RMAN returns errors after the database is mounted. For example, if the character set is WE8DEC, you can set the NLS_LANG parameter as follows:
NLS_LANG=american_america.we8dec
NLS_LANG and NLS_DATE_FORMAT must be set for NLS_DATE_FORMAT to be used.
See Also:
|
In the examples in this section, the generic values used have the following meanings.
| Variable | Meaning |
|---|---|
|
|
User with |
|
|
The password for connecting as |
|
|
The net service name for the target database |
To connect to the target database from the operating system command line, enter the connection as in the following examples:
# example of operating system authentication % rman TARGET / NOCATALOG # example of Oracle Net authentication % rman TARGET SYS/oracle@trgt NOCATALOG
You can also start RMAN without specifying NOCATALOG or CATALOG as follows:
# example of operating system authentication % rman TARGET / # example of Oracle Net authentication % rman TARGET SYS/oracle@trgt
If you do not specify NOCATALOG on the command line, and if you do not specify CONNECT CATALOG after RMAN has started, then RMAN connects in NOCATALOG mode by default the first time that you run a command that requires a repository. For example:
% rman TARGET / RMAN> BACKUP DATABASE; # RMAN defaults to NOCATALOG mode
Alternatively, start RMAN and connect to the target database from the RMAN prompt, as in this example:
% rman NOCATALOG RMAN> CONNECT TARGET /
This example connects to the target database with a password file:
% rman NOCATALOG RMAN> connect target SYS/oracle@trgt
Backing up a database with RMAN is meant to be simple. Therefore, for most of the parameters required for RMAN backup, there are sensible defaults which will let you do basic backup and recovery without extensive setup or configuration.
However, when implementing an RMAN-based backup strategy, you can use RMAN more effectively if you understand the more common options available to you. Many of these can be set in the RMAN environment on a persistent basis, so that you do not have to specify the same options every time you issue a command.
The following discussion presents how RMAN's default behaviors can be changed for your backup and recovery environment and strategies, and introduces the major settings available to you and their most common possible values.
This section includes the following topics:
To simplify ongoing use of RMAN for backup and recovery, the RMAN lets you set a number of persistent configuration settings for each target database. These settings control many aspects of RMAN's behavior when working with that database, such as backup retention policy, default destinations for backups to tape or disk, default backup device type (tape or disk), and so on.
The default values for these configuration settings let you use RMAN effectively without changing any of them. However, as you develop a more advanced backup and recovery strategy, you will have to change these settings to implement that strategy. Use the RMAN SHOW and CONFIGURE commands to view and change the RMAN configuration settings.
| See Also:
Oracle Database Recovery Manager Reference for |
The SHOW ALL command displays the current settings of all parameters that you can set with the CONFIGURE command, including both those that you have altered and those which are still set to RMAN's default setting.
To show all RMAN configuration settings:
After connecting to the target database and recovery catalog (if you use one), run the RMAN SHOW ALL command. For example, enter the following:
RMAN> SHOW ALL; # shows all CONFIGURE settings, both user-entered and default
Sample output for SHOW ALL follows:
using target database controlfile instead of recovery catalog RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE'; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/mydisk/oracle/dbs/%F'; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 1 BACKUP TYPE TO BACKUPSET; CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY PARALLELISM 1; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'SBT_LIBRARY=myvendor.mysbt'; CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/mydisk/oracle/dbs/cf_snap.f';
The configuration is displayed as the series of RMAN commands required to re-create the configuration. You can paste the output of SHOW ALL into a command file so that you can later re-create the entire configuration. You can even run the script on a different target database, to re-create the same RMAN configuration on multiple databases.
You can return any setting you change with the CONFIGURE command to its default value by running the CONFIGURE command with the CLEAR option, as in:
CONFIGURE BACKUP OPTIMIZATION CLEAR; ONFIGURE RETENTION POLICY CLEAR; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;
By default, RMAN sends all backups to an operating system specific directory on disk. You can also configure RMAN to make backups to media such as tape.
After configuring an sbt (that is, tape or media management) device according to the instructions in your media management vendor documentation, you can make the media manager the default device:
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
To configure disk as the default device for backups, you can either use CONFIGURE... CLEAR to restore the default setting, or explicitly configure the default device as shown:
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
You can configure backup sets or image copies as the default, using either of the following commands:
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; # image copies RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; # uncompressed
The default for backups to disk, as with tape, is backup set. Note that there is no analogous option for media manager devices, because RMAN can only write backups to media manager devices as backup sets.
You can configure RMAN to use compressed backupsets by default on a particular device type, by using the CONFIGURE DEVICE TYPE command with the BACKUP TYPE TO COMPRESSED BACKUPSET option, as shown in the following examples.
The following commands let you set the default backup type to compressed backup sets for different device types:
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET; RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COMPRESSED BACKUPSET;
To disable compression, use the CONFIGURE DEVICE TYPE command with arguments specifying your other desired settings, but omitting the COMPRESSED keyword.
RMAN channels (connections to server sessions on the target database) perform all RMAN tasks. By default, RMAN allocates one disk channel for all operations.
The following command configures RMAN to write disk backups to the /backup directory (refer to "Backing Up Database Files and Archived Logs with RMAN").:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/ora_df%t_s%s_s%p';
The format specifier %t is replaced with a four byte time stamp, %s with the backup set number, and %p with the backup piece number.
You can also configure an Automatic Storage Management disk group as your destination, as in the following example:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1';
Note that by configuring an explicit format for disk channels, you direct backups away from the flash recovery area, if you have configured one.
Some media managers require configuration settings that you pass in by including a PARMS string in the CONFIGURE command, as follows:
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=mml_env_settings';
See the media manager documentation for details.
The following command configures two sbt channels for use in RMAN jobs:
CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
RMAN can be configured to automatically back up the control file and server parameter file whenever the database structure metadata in the control file changes and whenever a backup record is added. The autobackup enables RMAN to recover the database even if the current control file, catalog, and server parameter file are lost.
Because the filename for the autobackup uses a well-known format, RMAN can search for it without access to a repository, and then restore the server parameter file. After you have started the instance with the restored server parameter file, RMAN can restore the control file from an autobackup. After you mount the control file, the RMAN repository is available and RMAN can restore the datafiles and find the archived redo log.
You can enable the autobackup feature by running this command:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
You can disable the feature by running this command:
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
See Also:
|
By default, the format of the autobackup file for all configured devices is the substitution variable %F. This variable format translates into c-IIIIIIIIII-YYYYMMDD-QQ, where:
IIIIIIIIII stands for the DBID.YYYYMMDD is a time stamp of the day the backup is generatedQQ is the hex sequence that starts with 00 and has a maximum of FFYou can change the default format by using the following command, where deviceSpecifier is any valid device such as DISK or sbt, and 'string' must contain the substitution variable %F (and no other substitution variables) and is a valid handle for the specified device:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE deviceSpecifier TO 'string';
For example, you can run the following command:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'ora_home/oradata/cf_%F';
The following example configures the autobackup to write to an Automatic Storage Management disk group:
CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK TO '+dgroup1';
To clear control file autobackup formats for a device, use the following commands:
CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK CLEAR; CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE sbt CLEAR;
If you have set up a flash recovery area for your database, you can direct control file autobackups to the flash recovery area by clearing the control file autobackup format for disk.
The SET CONTROLFILE AUTOBACKUP FORMAT command, which you can specify either within a RUN block or at the RMAN prompt, overrides the configured autobackup format in the current session only.
You could use this command in either of the following ways:
RMAN> SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt TO 'controlfile_%F'; RMAN> BACKUP AS COPY DATABASE; RMAN> RUN { SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F.bck'; BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE; }
The first SET CONTROLFILE AUTOBACKUP FORMAT controls the name of the control file autobackup until the RMAN client exits, overriding any configured control file autobackup format. The SET CONTROFILE AUTOBACKUP FORMAT in the RUN block overrides the SET CONTROLFILE AUTOBACKUP FORMAT outside the RUN block for the duration of the RUN block.
The order of precedence is:
SET CONTROLFILE AUTOBACKUP FORMAT (within a RUN block)SET CONTROLFILE AUTOBACKUP FORMAT (at RMAN prompt)CONFIGURE CONTROLFILE AUTOBACKUP FORMATAs explained in "Automatic Disk-Based Backup and Recovery: The Flash Recovery Area", the flash recovery area feature lets you set up a location on disk where the database can create and manage a variety of backup and recovery-related files on your behalf.
Using a flash recovery area simplifies the ongoing administration of your database by automatically naming files, retaining them as long as they are needed for restore and recovery activities, and deleting them when they are no longer needed to restore your database and space is needed for some other backup and recovery-related purpose.
Your long-term backup and recovery administration can be greatly simplified by using a flash recovery area. Use of the flash recovery area is strongly recommended. You may want to set up a flash recovery area as one of the first steps in implemeting your backup strategy.
This section outlines the functions of the flash recovery area, identifies the files stored there, explains the rules for how files are managed there, and introduces the most important configuration options.
When setting up a flash recovery area, you must choose a location (a directory or Automatic Storage Management disk group) to hold the files. The flash recovery area cannot be stored on a raw file system.
You must also determine a disk quota for the flash recovery area, the maximum space to be used for all files stored there. You must choose a location large enough to accomodate the required disk quota. When the disk space limit is approached, Oracle can delete nonessential files to make room for new files, subject to the limitations of the retention policy.
The flash recovery area should be on a separate disk from the database area, where active database files such as datafiles, control files, and online redo logs are stored. Keeping the flash recovery area on the same disk as the database area exposes you to loss of both your live database files and backups in the event of a media failure.
The flash recovery area is closely related to and can be used in conjunction with two other Oracle features: Oracle Managed Files and Automatic Storage Management.
Oracle Managed Files (OMF) is a service that automates naming, location, creation and deletion of database files such as control files, redo log files, datafiles and others, based on a few initialization parameters. It can simplify many aspects of the DBA's work by eliminating the need to devise your own policies for such details.
The flash recovery area is built on top of OMF, so the flash recovery area can be stored anywhere Oracle-managed files can. Oracle Managed Files can be used on top of a traditional file system supported by the host operating system (for example, VxFS or ODM).
The flash recovery area can also be used with Oracle's Automatic Storage Management (ASM). ASM consolidates storage devices into easily managed disk groups and provides benefits such as mirroring and striping without requiring a third-party logical volume manager.
Even if you choose not to use a flash recovery area, you can still use Oracle Managed Files to manage your backup files in an ASM disk group. (On a regular file system, OMF can only be used by using the flash recovery area feature.) You will lose one of the major benefits of the flash recovery area, the automatic deletion of files no longer needed to meet your recoverability goals. However, the other automatic features of OMF will still function.
| See also:
Oracle Database Administrator's Guide for more information on Automatic Storage Management and Oracle Managed Files |
The files in recovery area can be classified as permanent or transient. The only permanent files (assuming these are configured to be stored in the recovery area) are multiplexed copies of the current control file and online redo logs. These cannot be deleted without causing the instance to fail. All other files are transient, because Oracle will generally eventually delete these files, at some point after they become obsolete under the retention policy or have been backed up to tape. Transient files include archived redo logs, datafile copies, control file copies, control file autobackups, and backup pieces.
|
Note: The Oracle Flashback Database feature, which provides an convenient alternative to point-in-time recovery, generates flashback logs, which are also considered transient files and must be stored in the flash recovery area. See Oracle Database Backup and Recovery Advanced User's Guide for more details about Oracle Flashback Database. |
The larger the flash recovery area is, the more useful it becomes. Ideally, the flash recovery area should be large enough to contain all of the following files:
If providing this much space is impractical, it is best to create an area large enough to keep a backup of the most important tablespaces and all the archived logs not yet copied to tape. At an absolute minimum, the flash recovery area must be large enough to contain the archived logs that have not been copied to tape.
|
Note: If you wish to use the Oracle Flashback Database feature, you must allow for storage required for flashback logs. See Oracle Database Backup and Recovery Advanced User's Guide for more details. |
To determine the disk quota and current disk usage in the flash recovery area, query the view V$RECOVERY_FILE_DEST.
Formulas for estimating a useful flash recovery area size depend upon several factors in your backup and recovery strategy: whether few or many datafile blocks change frequently, whether you are backing up only to disk or both to disk and tape, and whether you use a redundancy-based retention policy or a recovery window-based retention policy. Specific formulas are provided for many different backup scenarios in "Backing Up to the Flash Recovery Area: Basic Scenarios" and "Backing Up to the Flash Recovery Area and to Tape: Basic Scenarios".
To enable the flash recovery area, you must set the two initialization parameters DB_RECOVERY_FILE_DEST_SIZE (which specifies the disk quota, or maximum space to use for flash recovery area files for this database) and DB_RECOVERY_FILE_DEST (which specifies the location of the flash recovery area).
|
Note: .
|
Initialization parameters can be specified by any of the following means:
ALTER SYSTEM SETSee Also:
|
To find out the current flash recovery area location, query V$RECOVERY_FILE_DEST.
| See Also:
Oracle Database SQL Reference for |
There are also restrictions on some other initialization parameters when using a flash recovery area.
This parameter specifies the maximum storage in bytes of data to be used by the flash recovery area for this database. Note, however, that this value does not include certain kinds of disk overhead:
DB_RECOVERY_FILE_DEST_SIZE does not indicate the real size occupied on disk when the underlying filesystem is mirrored, compressed, or in some other way affected by overhead not known to Oracle. For example, if you can configure the flash recovery area on a normal redundancy (2-way mirrored) ASM disk group, each file of X bytes occupies 2X bytes on the ASM disk group. In such a case, DB_RECOVERY_FILE_DEST_SIZE must be set to no more than 1/2 the size of the disks for the ASM disk group. Likewise, when using a high redundancy (three-way mirrored) ASM disk group, DB_RECOVERY_FILE_DEST_SIZE must be no more than 1/3 the size of the disks in the disk group, and so on.This parameter specifies a valid disk location for file creation, which can be a directory on a file system, or Automatic Storage Management disk group.
Mutliple database can have the same value for DB_RECOVERY_FILE_DEST, if one of the following conditions is met:
DB_UNIQUE_NAME is specified have the same value for DB_UNIQUE_NAME.DB_UNIQUE_NAME is provided, no two databases have the same value for DB_NAME.For example, you might want to set up primary and standby databases to share the same DB_RECOVERY_FILE_DEST. These two databases will have the same DB_NAME but one of them must have a DB_UNIQUE_NAME different from DB_NAME.
When databases share a single flash recovery area in this fashion, the file system or ASM disk group holding the flash recovery area should be large enough to hold all of the recovery files for all of the databases. Add all the values for DB_RECOVERY_FILE_DEST_SIZE for the different databases, and then allow for any overhead such as mirroring or compression in allocating actual disk space, as described in "The DB_RECOVERY_FILE_DEST_SIZE Initialization Parameter".
Using a flash recovery area has implications for some other initialization parameters:
LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameters to specify redo log archive destinations. You must instead use the newer LOG_ARCHIVE_DEST_n parameters. See Oracle Database Reference for details on the semantics of the LOG_ARCHIVE_DEST_n parameters.LOG_ARCHIVE_DEST_10 is implicitly set to USE_DB_RECOVERY_FILE_DEST (meaning that archived redo log files will be sent to the flash recovery area) if you create a recovery area and do not set any other local archiving destinations.DB_RECOVERY_FILE_DEST not be the same as DB_CREATE_FILE_DEST or any of the DB_CREATE_ONLINE_LOG_DEST_n parameters. A warning will appear in the alert log if DB_RECOVERY_FILE_DEST is the same as any of the other parameters listed here.To create a flash recovery area, you can set the necessary parameters in the initialization parameter file (PFILE) and restart the database. You can also use the following steps to add a flash recovery area to an open database.
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10g SCOPE=BOTH SID='*';
Set SCOPE to BOTH make the change both in memory and the server parameter file. Setting SID to "*" has no effect in a single-instance database; in a RAC database it causes the change to take effect across all instances.
/dir1, then you can do the following:
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/dir1' SCOPE=BOTH SID='*';
If the flash recovery area location is an Automatic Storage Management disk group named disk1, for example, then you can do the following:
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+disk1' SCOPE=BOTH SID='*';
You can query the V$RECOVERY_FILE_DEST view to find out the current location, disk quota, space in use, space reclaimable by deleting files, and total number of files in the flash recovery area.
SQL> SELECT * FROM V$RECOVERY_FILE_DEST; NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES -------------- ----------- ---------- ----------------- --------------- /mydisk/rcva 5368709120 109240320 256000 28
This view can help you determine whether you have allocated enough space for your flash recovery area.
To disable the flash recovery area, set the DB_RECOVERY_FILE_DEST initialzation parameter to a null string. For example, use this SQL*Plus statement to change the parameter on a running database:
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BTOTH SID="*";
The database will no longer provide the space management features of the flash recovery area for the files stored in the old DB_RECOVERY_FILE_DEST location. The files will still be known to the RMAN repository, however, and available for backup and restore activities.
The backup retention policy specifies which backups must be retained to meet your data recovery requirements. This policy can be based on a recovery window (the maximum number of days into the past for which you can recover) or redundancy (how many copies of each backed-up file to keep).
Use the CONFIGURE command to set the retention policy.
See Also:
|
The RECOVERY WINDOW parameter of the CONFIGURE command specifies the number of days between the current time and the earliest point of recoverability. RMAN does not consider any full or level 0 incremental backup as obsolete if it falls within the recovery window. Additionally, RMAN retains all archived logs and level 1 incremental backups that are needed to recover to a random point within the window.
Run the CONFIGURE RETENTION POLICY command at the RMAN prompt. This example ensures that you can recover the database to any point within the last week:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
RMAN does not automatically delete backups rendered obsolete by the recovery window. Instead, RMAN shows them as OBSOLETE in the REPORT OBSOLETE output and in the OBSOLETE column of V$BACKUP_FILES. RMAN deletes obsolete files if you run the DELETE OBSOLETE command.
The REDUNDANCY parameter of the CONFIGURE RETENTION POLICY command specifies how many backups of each datafile and control file that RMAN should keep. In other words, if the number of backups for a specific datafile or control file exceeds the REDUNDANCY setting, then RMAN considers the extra backups as obsolete. The default retention policy is REDUNDANCY=1.
As you produce more backups, RMAN keeps track of which ones to retain and which are obsolete. RMAN retains all archived logs and incremental backups that are needed to recover the nonobsolete backups.
Assume that you make a backup of datafile 7 on Monday, Tuesday, Wednesday, and Thursday. You now have four backups of the datafile. If REDUNDANCY is 2, then the Monday and Tuesday backups are obsolete. If you make another backup on Friday, then the Wednesday backup becomes obsolete.
Run the CONFIGURE RETENTION POLICY command at the RMAN prompt, as in the following example:
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
You can view the currently configured retention policy with the SHOW RETENTION POLICY command. Sample output follows:
RMAN> SHOW RETENTION POLICY; RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
When you disable the retention policy, RMAN does not consider any backup as obsolete.
To disable the retention policy, run this command:
CONFIGURE RETENTION POLICY TO NONE;
Configuring the retention policy to NONE is not the same as clearing it. Clearing it returns it to its default setting of REDUNDANCY=1, whereas NONE disables it completely.
If you disable the retention policy and run REPORT OBSOLETE or DELETE OBSOLETE without passing a retention policy option to the command, RMAN issues an error because no retention policy exists to determine which backups are obsolete.
|
Note: If you are using a flash recovery area, then you should not run your database with the retention policy disabled. If files are never considered obsolete, then a file can only be deleted from the flash recovery area if it has been backed up to some other disk location or to a tertiary storage device such as tape. It is quite likely that all of the space in your recovery area will be used. This interferes with the normal operation of your database as described in "When Space is Not Available in the Flash Recovery Area". |
Oracle does not delete eligible files from the flash recovery area until the space must be reclaimed for some other purpose. The effect is that files recently moved to tape are often still available on disk for use in recovery. The recovery area can thus serve as a kind of cache for tape. Once the flash recovery area is full, Oracle automatically deletes eligible files to reclaim space in the flash recovery area as needed.
There are relatively simple rules governing when files become eligible for deleteion from the flash recovery area:
If, for instance, the RMAN retention policy requires keeping a set of backups larger than the flash recovery area disk quota, or if the retention policy is set to NONE, then the flash recovery area can fill completely with no reclaimable space.
The database issues a warning alert when reclaimable space is less than 15% and a critical alert when reclaimable space is less than 3%. To warn the DBA of this condition, an entry is added to the alert log and to the DBA_OUTSTANDING_ALERTS table (used by Enterprise Manager). However, the database continues to consume space in the flash recovery area until there is no reclaimable space left.
When the recovery area is completely full, the error you will receive is:
ORA-19809: limit exceeded for recovery files ORA-19804: cannot reclaim nnnnn bytes disk space from mmmmm limit
where nnnnn is the number of bytes required and mmmm is the disk quota for the flash recovery area.
The database handles a flash recovery area with insufficient reclaimable space just as it handles a disk full condition. Often, the result is an database hang, but not always. For example, if the flash recovery area is one of your mandatory redo log archiving destinations, and the database cannot archive a new log because the recovery area is full, then the archiver may, depending on your configuration, retry archiving periodically until space is freed in the recovery area. For information on how a particular feature of Oracle responds to a disk full condition, see the documentation for that feature.
See Also:
|
In this example the database is configured to store archived logs and RMAN backups to the flash recovery area. The control file and online redo log copies will still be stored in the conventional file system. The datafiles are assumed to be 3GB in size, and the retained archived redo logs should be no larger than 4GB. The backup strategy will be based on incremental backups. The control file will be automatically backed up to the flash recovery area.
The flash recovery area will be sized to 10gB, room enough for control file autobackups, a whole database level 0 incremental backup (which consists of image copies of the 3GB of datafiles), plus several incremental level 1 backups.
The parameter file should contain the following entries:
DB_NAME=sample # set location for current datafiles: DB_CREATE_FILE_DEST = '/u02/oradata/wrk_area' # set location for control files and online redo logs: DB_CREATE_ONLINE_LOG_DEST_1 = '/u03/oradata/wrk_area' DB_CREATE_ONLINE_LOG_DEST_2 = '/u04/oradata/wrk_area' # set flash recovery area location and size DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area' DB_RECOVERY_FILE_DEST_SIZE = 10g
Because the parameter file does not set LOG_ARCHIVE_DEST_n, Oracle sends archived logs to the flash recovery area only.
Once the target database is started, the following RMAN commands configure the retention policy, backup optimization, and the control file autobackup:
RMAN> CONNECT TARGET SYS/orace@trgt; RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1; RMAN> CONFIGURE BACKUP OPTIMIZATION ON; RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
You could now run a series of backup jobs to take backups to your flash recovery area.
| See also:
"Scripting Disk-Only Backups" for examples of backup jobs you could run in this environment. |
Assume that you want to create a database in which the control files, datafiles, and online redo logs are Oracle managed files in a single file system directory. Additionally, you want to do the following:
| See Also:
Oracle Database Backup and Recovery Advanced User's Guide for more detailed information about file creation in the flash recovery area |
To create a database with a flash recovery area:
# set DB_NAME DB_NAME=sample # set destination for OMF datafiles, control file and online redo logs DB_CREATE_FILE_DEST = /u01/oradata/wrk_area/ # set log archiving destinations to a file system location # and the flash recovery area LOG_ARCHIVE_DEST_1 = 'LOCATION=/arc_dest1' LOG_ARCHIVE_DEST_2 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST' # multiplexed copies of control file and online logs in flash recovery area # rman backups also go here DB_RECOVERY_FILE_DEST = 'LOCATION=/u01/oradata/rcv_area' DB_RECOVERY_FILE_DEST_SIZE = 10g
The DB_CREATE_FILE_DEST parameter sets the default directory for all datafiles, online logs, and control files. Another copy of the control file and online logs is created in the flash recovery area.
SQL> CREATE DATABASE sample;
The preceding statement creates Oracle managed datafiles in DB_CREATE_FILE_DEST. Because you did not specify a LOGFILE clause, this statement creates two online log groups. Each log group has two members, with one member in DB_CREATE_FILE_DEST and another in DB_RECOVERY_FILE_DEST. Because the CONTROL_FILES parameter was not set, Oracle creates a control file in DB_CREATE_FILE_DEST (primary) and DB_RECOVERY_FILE_DEST (multiplexed copy). On a Solaris system, the filenames might look like the following:
/u02/oradata/wrk_area/SAMPLE/datafile/o1_mf__system_cmr7t30p_.dbf # OMF datafile /u02/oradata/wrk_area/SAMPLE/logfile/o1_mf_0orrm31z_.log # log grp 1, mem 1 /u02/oradata/wrk_area/SAMPLE/logfile/o1_mf_2_2xyz16am_.log # log grp 2, mem 1 /u02/oradata/wrk_area/SAMPLE/controlfile/o1_mf_3ajeikm_.ctl # primary ctl file /u01/oradata/rcv_area/SAMPLE/logfile/o1_mf_1_ixfvm8w9_.log # log grp 1 mem 2 /u01/oradata/rcv_area/SAMPLE/logfile/o1_mf_2_q89tmp28_.log # log grp 2, mem 2 /u01/oradata/rcv_area/SAMPLE/controlfile/o1_mf_6adjkid_.ctl # ctl file copy
LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_DEST_2 as destinations for archiving the redo logs. Archived redo log files are created in the flash recovery area because LOG_ARCHIVE_DEST_2 is configured as flash recovery area. Because you enabled a local redo log archiving destination, LOG_ARCHIVE_DEST_10 is not implicitly set to the flash recovery area.
The archived redo log files in the flash recovery area are given Oracle-managed filenames that are not based on the LOG_ARCHIVE_FORMAT parameter. For example, generate an archived log:
ALTER SYSTEM ARCHIVE LOG CURRENT;
On Solaris, the preceding statement creates an archived log in the primary archiving location as well as the following flash recovery area subdirectory: /u01/oradata/rcv_area/SAMPLE/archivelog/YYYY_MM_DD
where YYYY_MM_DD is the creation date format.
ALTER DATABASE ADD LOGFILE statement. When no file name is specified, it creates another log file member in the flash recovery area. For example, enter the following:
ALTER DATABASE ADD LOGFILE;
The preceding statement creates another log group with two members: one in DB_CREATE_FILE_DEST and another in DB_RECOVERY_FILE_DEST.
Assume that you want to create a database in which the control files, datafiles, and online redo logs are Oracle managed files in a single file system directory. Additionally, you want to do the following:
| See Also:
Oracle Database Backup and Recovery Advanced User's Guide for more detailed information about file creation in the flash recovery area |
To create a database with a flash recovery area:
DB_NAME=sample DB_CREATE_FILE_DEST = '/u02/oradata/wrk_area' DB_RECOVERY_FILE_DEST = 'location=/u01/oradata/rcv_area' DB_RECOVERY_FILE_DEST_SIZE = 10g # if you set the following parameters, then the online redo logs *and* # current control file are located here DB_CREATE_ONLINE_LOG_DEST_1 = '/u03/oradata/wrk_area' DB_CREATE_ONLINE_LOG_DEST_2 = '/u04/oradata/wrk_area'
The DB_CREATE_FILE_DEST parameter sets the default file system directory for the datafiles. The DB_CREATE_ONLINE_LOG_DEST_n parameter sets the default file system directories for the online redo logs and control files. DB_RECOVERY_FILE_DEST sets the file system directory for archived logs.
CREATE DATABASE sample;
No multiplexed copies of the online redo logs or control files are created in the flash recovery area.
LOG_ARCHIVE_DEST_10 to the flash recovery area. The filenames in the flash recovery area are given Oracle managed filenames that are not based on the LOG_ARCHIVE_FORMAT parameter. For example, generate an archived log:
ALTER SYSTEM ARCHIVE LOG CURRENT;
On Solaris, the preceding statement creates an archived log in a flash recovery area subdirectory: /u01/oradata/rcv_area/SAMPLE/archivelog/YYYY_MM_DD, where YYYY_MM_DD is the creation date format.
ALTER DATABASE ADD LOGFILE statement. When no file name is specified, it creates another log file member in each DB_CREATE_ONLINE_LOG_DEST_n location (but not the flash recovery area). For example, enter the following:
ALTER DATABASE ADD LOGFILE;
On Solaris, the preceding statement creates one member in /u03/oradata/wrk_area/SAMPLE/logfile and another member in /u04/oradata/wrk_area/SAMPLE/logfile. On other platforms, the specific file and directory names are platform-dependent.
|
 Copyright © 2003 Oracle Corporation All Rights Reserved. |
|