3
Setting Up and Configuring Backup and Recovery

When connecting to a target or auxiliary database, you must have the SYSDBA p rivilege. You can connect as SYSDBA with a password file or with operating system authentication.

% ORACLE_SID=trgt; export ORACLE_SID




A SYSDBA privilege is not required when connecting to the recovery catalog. Not
e that you must grant the RECOVERY_CATALOG_OWNER role to the schema owner.
 

NLS_LANG=american

NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS'

NLS_LANG=american_america.we8
dec

# example of operating system authentication
% rman TARGET /   
# example of Oracle Net authentication
% rman TARGET SYS/oracle@t
rgt   

% rman TARGET /
RMAN> BACKUP DATABASE;    # RMAN defaults to NOCATALOG mode

% rman NOCATALOG
RMAN> CONNECT TARGET /

% rman NOCATALOG
RMAN>
 connect target SYS/oracle@trgt

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 < code>CONFIGURE commands to view and change the RMAN configuration settings.

Displaying Current RMAN Configuration Settings: SHOW ALL

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:

RMAN>
; SHOW ALL;    # shows all CONFIGURE settings, both user-entered and default

using target data
base 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 CONTRO
LFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 
'/mydisk/oracle/dbs/%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORM
AT FOR DEVICE TYPE SBT_TAPE TO '%F'; # 
default
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 1 BACKUP TYPE TO B
ACKUPSET;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY PARALLELISM 1;
CONFIGURE DATAFIL
E 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
<
/a>CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_T
APE' PARMS  'SBT_LIBRARY=myvendor.mysbt';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CO
NFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/mydisk/oracle/db
s/cf_snap.f';

CONFIGURE
 BACKUP OPTIMIZATION CLEAR;
ONFIGURE RETENTION POLICY CLEAR;
CONFIGURE CONTROLFILE AUTOBA
CKUP FORMAT FOR DEVICE TYPE DISK CLEAR;

CONFIGURE DEFAULT DEVICE TYPE TO sbt;

CONFIGURE DEFAULT DEVICE TYPE TO DISK;

RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; # image copies
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; # uncompressed

RMAN> CONFI
GURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET; 
RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO C
OMPRESSED BACKUPSET; 

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/ora_df%
t_s%s_s%p';

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.
 
Configuring Tape Devices and Channels



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 docu
mentation for details.
 
The following command configures two sbt channels for u
se in RMAN jobs:
CONFIGURE DEVICE TYPE sbt PARALLELISM 2;



Configuring Control File and Server Par
ameter File Autobackup

 
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 bac
kup record is added. The autobackup enables RMAN to recover the database even if the current control file, catalog, and server parame
ter file are lost.
 
Because the filename for the autobackup uses a well-known format, RMAN c
an 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 AUTOB
ACKUP ON;




You can disable the feature by running this command:
CONFIGURE CONTROLFILE AUTOBACKUP OFF;






See Also:  

Oracl
e Database Backup and Recovery Advanced User's Guide for a conceptual overview of control file autobackups
Oracle Database Recovery Manager Reference for CONFIGURE syntax
 
Configuring the Contr
ol File Autobackup Format

 
By default, the format of the autoback
up file for all configured devices is the substitution variable %F. This variable format translates into c-III
IIIIIII-YYYYMMDD-QQ, where:

IIIIIIIIII stands for the DBID.

YYYYMMDD is a time stamp
 of the day the backup is generated
QQ is the hex sequen
ce that starts with 00 and has a maximum of FF

 
You can chan
ge the default format by using the following command, where deviceSpecifier is any valid device such as D
ISK or sbt, and 'string' must contain the substitution variable <
code>%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 f
ollowing command:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT 
  FOR DEVI
CE 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 CONTR
OLFILE 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 fi
le autobackup format for disk.
 
Overriding the Configured Control File Autobackup Format

 
The SET CONTROLFILE AUTOBACKUP FORMAT command, which you can specify e
ither within a RUN block or at the RMAN prompt, overrides the configured autobackup format in the current session only.<
/p>
 
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 TYP
E DISK TO '/tmp/%F.bck'; 
       BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE;
      }
<
a name="1020143">



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<
/code> (at RMAN prompt)

CONFIGURE CONTROLFILE AUTOBA
CKUP FORMAT

 
Setting Up a Flash Recovery Area for RMAN

 
<
p class="BP">As 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 man
age a variety of backup and recovery-related files on your behalf.

 
Using a flash recovery a
rea simplifies the ongoing administration of your database by automatically naming files, retaining them as long as they are needed f
or 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 adminis
tration can be greatly simplified by using a flash recovery area. Use of the flash recovery area is strongly recommended. You may wan
t 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 f
iles are managed there, and introduces the most important configuration options.
 
<
h3 class="H2">Choosing a Location for the Flash Recovery Area
<
!--/TOC=h2-->
 
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. W
hen the disk space limit is approached, Oracle can delete nonessential files to make room for new files, subject to the limitations o
f 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 back
ups in the event of a media failure.



Note:  
There are special considerations for choosing a location for the flash recovery area in a RAC environm
ent. The location must be on a cluster file system, ASM or a shared directory configured through NFS. The location and disk quota mus
t be the same on all instances.





  
Flash Recovery Area, Automatic Storage Management, and Oracle Managed
Files

 
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 c
ontrol 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 rec
overy area is built on top of OMF, so the flash recovery area can be stored anywhere Oracle-managed files can. Oracle Managed Files c
an 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 st
orage devices into easily managed disk groups and provides benefits such as mirroring and striping without requiring a third-party lo
gical volume manager.
 
Even if you choose not to use a flash recovery area, you can still us
e 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.





Note:  
When storing backup fil
es, using OMF on top of Automatic Storage Management without using a flash recovery area is supported but discouraged. It is awkward
to directly manipulate files under Automatic Storage Management.




See also:  
Oracle Database
Administrator's Guide for more information on Automatic Storage Management and Oracle Managed Files




  
Fi
les That Can Be Stored in the Flash Recovery Area

 
The files in recov
ery 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 Orac
le will generally eventually delete these files, at some point after they become obsolete under the retention policy or have been bac
ked up to tape. Transient files include archived redo logs, datafile copies, control file copies, control file autobackups, and backu
p pieces.





Note:  
The Oracle Flashback Database feature, which provides an convenient alternative to point-in-time recovery, generates flashback lo
gs, 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 f
or more details about Oracle Flashback Database.





  
Planning the Size of the Flash Recovery Area

 
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:

A copy of all datafiles
Incremental backups, as used b
y your chosen backup strategy
Online redo logs
Archived redo logs not yet backed up to tape
Control f
iles
Control file autobackups (which include copies of the control file and SP
FILE)
 
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 d
etails.





  
To determine the disk quota and current dis
k usage in the flash recovery area, query the view V$RECOVERY_FILE_DEST.
 
Formu
las 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 redu
ndancy-based retention policy or a recovery window-based retention policy. Specific formulas are provided for many different backup s
cenarios in "Backing Up to the Flash Recovery Area: Basic Scenarios" an
d "Backing Up to the Flash Recovery Area and to Tape: Basic Scenarios".

 
Setting
Initialization Parameters for the Flash Recovery Area

 
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 specif
ies the location of the flash recovery area).





Note:  
.

DB_RECOVERY_FILE
_DEST_SIZE must be set before DB_RECOVERY_FILE_DEST.
In a RAC database, all instances must have the same values for these parameters.





  
Initialization parameters can be specified by any of the following means:
<
ul class="LB1">
Include them initialization parameter file of the target database
Specify them with the SQL statement ALTER SYSTEM SET
Use the Database Configuration Assistant to set them 



See Also:  

Oracle Database Administrator's Guide for details on setting and changing database initialization parameters

 
To find out the current flash recovery area location, query
V$RECOVERY_FILE_DEST.



See Also:
  
Oracle Database SQL Reference for ALTER SYSTEM syntax




  
There are also restrictions on some other initialization parameters when using a f
lash recovery area.
 
The DB_RECOVERY_FILE_DEST_SIZE Initialization Parameter

 
T
his 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:

<
/a>Block 0 or the OS block header of each Oracle file is not included in this size. Allow an extra 10% for this data when computing t
he actual disk usage required for the flash recovery area.

DB_RECOVERY_F
ILE_DEST_SIZE does not indicate the real size occupied on disk when the underlying filesystem is mirrored, compressed, or in s
ome other way affected by overhead not known to Oracle. For example, if you can configure the flash recovery area on a normal redunda
ncy (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 redun
dancy (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.
 
The DB_RECOVERY_FILE_DEST Initialization Parameter

 
This parameter specifies a valid disk location for file creation, which can be a directory on a file system, or Automatic Stor
age Management disk group.
 
Sharing a Flash Recovery Area Among Multiple Databases

 
Mutliple database can have the same value for DB_RECOVERY_FILE_DEST, if one of the following conditions is met:


No two databases for which DB_UNIQUE_NAME is specifi
ed have the same value for DB_UNIQUE_NAME.
For those databases wh
ere no 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_FIL
E_DEST. These two databases will have the same DB_NAME but one of them must have a DB_UNIQUE_NAME di
fferent from DB_NAME.
 
When databases share a single flash recovery area in thi
s 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".
 
Restrictions on Initialization Parameters When Using
 Flash Recovery Area

 
Using a flash recovery area has implications fo
r some other initialization parameters:

You cannot use the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameters to specify redo log archive destinations. You must ins
tead use the newer LOG_ARCHIVE_DEST_n parameters. See Oracle Database Reference for details on the semantics of
the LOG_ARCHIVE_DEST_n parameters.
LO
G_ARCHIVE_DEST_10 is implicitly set to USE_DB_RECOVERY_FILE_DEST (meaning that archived redo log files will be se
nt to the flash recovery area) if you create a recovery area and do not set any other local archiving destinations.
Oracle Corporation recommends that 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 ap
pear in the alert log if DB_RECOVERY_FILE_DEST is the same as any of the other parameters listed here.
 
Adding a Flash Recov
ery Area to an Existing Database

 
To create a flash recovery area, yo
u can set the necessary parameters in the initialization parameter file (PFILE) and restart the database. You can also use the follow
ing steps to add a flash recovery area to an open database.
 

After you start SQL*Plus and connect to the database, set the size of the flash recovery area.
For example, set it to 10 GB: 
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.

Set the location of the flash recovery area. For example, if the location is the file system directory /dir1, then y
ou 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 Sto
rage 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='*';



Using the V$RECOVERY_FILE_DEST View

 
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.
 
Disabling the
 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 para
meter on a running database:
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BTOTH SID="*";





The database will no longer provide the space management feature
s of the flash recovery area for the files stored in the old DB_RECOVERY_FILE_DEST location. The files will still be kno
wn to the RMAN repository, however, and available for backup and restore activities.
 
 
The backup retention policy specifies which backups must be re
tained to meet your data recovery requirements. This policy can be based on a recovery window (the maximum number of days into the pa
st 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:  

Oracle Databa
se Recovery Manager Reference for CONFIGURE syntax
 
Configuring a Recovery Window-Based Ret
ention Policy

 
The RECOVERY WINDOW paramete
r of the CONFIGURE command specifies the number of days between the current time and the earliest point of recoverabilit
y. RMAN does not consider any full or level 0 incremental backup as obsolete if it falls within the recovery window. Additionally, RM
AN 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 promp
t. 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 d
oes not automatically delete backups rendered obsolete by the recovery window. Instead, RMAN shows them as OBSOLETE in t
he REPORT OBSOLETE output and in the OBSOLETE column of V$BACKUP_FILES. RMAN dele
tes obsolete files if you run the DELETE OBSOLETE command.
 
 
The REDUNDANCY parameter of the CONFIGURE RET
ENTION POLICY command specifies how many backups of each datafile and control file that RMAN should keep. In othe
r words, if the number of backups for a specific datafile or control file exceeds the REDUNDANCY setting, then RMAN cons
iders 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 ma
ke 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 POLIC
Y command at the RMAN prompt, as in the following example:
CONFIGURE RETENTION POLIC
Y TO REDUNDANCY 3;



Showing the Current Retention Policy

 
You can view the c
urrently 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;



Disabling the Retention Policy

 
When you disable the retention policy, RMAN does not consider any backup as obsolete.
<
/a> 
To disable the retention policy, run this command:
CONFIGURE RETENTION P
OLICY 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 i
ssues 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, the
n 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 stora
ge 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".

 
How Oracle Manages Disk Space in the Flash Recovery Area

When Files are Eligible for Deletion from the Flash Recovery Area<
/h4>

 
There are relatively simple rules governing when files become eligible for
deleteion from the flash recovery area:

Permanent files are ne
ver eligible for deletion.
Files that are obsolete under the configured retent
ion policy are eligible for deletion.
Transient files that have been copied to
 tape are eligible for deletion.
In a Data Guard environment, archived redo lo
g deletion policy governs when archived redo log files can be deleted from the flash recovery area. See Oracle Data Guard Concepts and Administration f
or details on archived redo log deletion policy. 





Note:  
Exactly which of the eligible files will be deleted to satisfy a space request is unpredictab
le. The rules are likely to change between releases and are quite dependent upon your configuration. The safe and reliable way to con
trol deletion of files from the flash recovery area is to change your retention policy. If you wish to increase the likelihood that f
iles moved to tape are also still on disk, increase the flash recovery area quota.

 
When Space is Not Av
ailable in the Flash Recovery Area

 
If, for instance, the RMAN retent
ion policy requires keeping a set of backups larger than the flash recovery area disk quota, or if the retention policy is set to NON
E, 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 Enterpris
e 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 sp
ace just as it handles a disk full condition. Often, the result is an database hang, but not always. For example, if the flash recove
ry 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 a
rea. For information on how a particular feature of Oracle responds to a disk full condition, see the documentation for that feature.




See Also:  

"Resolving a Full Flash Recovery Area" for more on how to address situations where the flash recovery area frequently fills to capacity and there
are no files eligible for deletion




  
Configure Flash Recovery Area for Disk-Based Backups: Example


 
In this example the database is configured to store archived logs and RM
AN backups to the flash recovery area. The control file and online redo log copies will still be stored in the conventional file syst
em. The datafiles are assumed to be 3GB in size, and the retained archived redo logs should be no larger than 4GB. The backup strateg
y 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 dat
abase level 0 incremental backup (which consists of image copies of the 3GB of datafiles), plus several incremental level 1 backups.<
/p>
 
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'
<
/a># set flash recovery area location and size
DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area'
DB_RECOVERY_FILE_DEST_SIZE = 10g




Because the paramet
er file does not set LOG_ARCHIVE_DEST_n, Oracle sends archived logs to the flash recovery area o
nly.
 
Once the target database is started, the following RMAN commands configure the retenti
on policy, backup optimization, and the control file autobackup:

RMA
N> 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 coul
d run in this environment.




  
Creating a Database with Multiplexed Files in the Flash Recovery Area: Scenario<
/font>


 
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 follow
ing:

Maintain a multiplexed copy of the control file in the fl
ash recovery area
Maintain multiplexed copies of the online redo logs in the f
lash recovery area
Archive one copy of each redo log to a file system location
 outside the work area and flash recovery area
Archive one copy of each redo l
og to the flash recovery area
Send RMAN backups to the flash recovery area by
default 




See Also:
  
Oracle Database Backup and Recovery Advanced User's Guide for more detailed information about file creation in the fl
ash recovery area
 
To create a databa
se with a flash recovery area:

Set th
e initialization parameters. Assume that you set the following: 
# 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 c
ontrol files. Another copy of the control file and online logs is created in the flash recovery area.
After you set the initialization parameters, create the database. For example, start SQL*Plus and
enter: 
SQL> CREATE DATABASE sample;




The preceding statement creates Oracle managed datafiles in DB_CREATE_FILE_DEST. Because you did not spec
ify a LOGFILE clause, this statement creates two online log groups. Each log group has two members, with one member in <
code>DB_CREATE_FILE_DEST and another in DB_RECOVERY_FILE_DEST. Because the CONTROL_FILES parameter w
as not set, Oracle creates a control file in DB_CREATE_FILE_DEST (primary) and DB_RECOVERY_FILE_DEST (multi
plexed copy). On a Solaris system, the filenames might look like the following:
/u02/oradat
a/wrk_area/SAMPLE/datafile/o1_mf__system_cmr7t30p_.dbf # OMF datafile
/u02/oradata/wrk_area/SAMPLE/logfile/o1_m
f_0orrm31z_.log   # log grp 1, mem 1
/u02/oradata/wrk_area/SAMPLE/logfile/o1_mf_2_2xyz16am_.log # log grp 2, me
m 1
/u02/oradata/wrk_area/SAMPLE/controlfile/o1_mf_3ajeikm_.ctl # primary ctl file
/u01/o
radata/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




Oracle uses 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 l
og 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:
<
a name="1019493">ALTER SYSTEM ARCHIVE LOG CURRENT;




On Solari
s, the preceding statement creates an archived log in the primary archiving location as well as the following flash recovery area sub
directory: /u01/oradata/rcv_area/SAMPLE/archivelog/YYYY_MM_DD
 
where YYYY_MM_DD is the creation date format.
To create a new group of online redo logs, execute the ALTER DATABASE ADD LOGFIL
E 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.

 
Creating a Database with Only Archived Logs in the Flash Recovery Area: Scenario

 
Assume that you want to create a database in which the control files, dat
afiles, and online redo logs are Oracle managed files in a single file system directory. Additionally, you want to do the following:<
/p>

Archive each redo log to the flash recovery area (and only to the flash recovery area)
Send RMAN backups to the flas
h recovery area by default. 




See A
lso:  
Oracle Database Backup and Recovery Advanced User's Guide for more detailed information about fil
e creation in the flash recovery area
 
To create a database with a flash recovery area:

Set the relevant initialization parameters. Assume that you set the following: 

DB_NAME=sample
DB_CREATE_FILE_DEST = '/u02/oradata/wrk_area'
DB_RECOVERY_FILE_DEST = 'loc
ation=/u01/oradata/rcv_area'
DB_RECOVERY_FILE_DEST_SIZE = 10g
# if you set the fol
lowing 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'
<
a name="1019526">



The DB_CREATE_FILE_DEST parameter sets the default f
ile 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 director
y for archived logs.
After you set the initialization parameters, c
reate the database. For example, start SQL*Plus and enter: 
CREATE DATABASE sample;




No multiplexed copies of the online redo logs or control files are created
 in the flash recovery area.
Because you enabled a flash recovery a
rea, Oracle automatically sets 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 e
xample, generate an archived log: 
ALTER SYSTEM ARCHIVE LOG CURRENT;




On Solaris, the preceding statement creates an archived log in a flash recovery area subd
irectory: /u01/oradata/rcv_area/SAMPLE/archivelog/YYYY_MM_DD, where YYYY_MM_DD is the creation date format.

To create a new group of online red
o logs, execute the ALTER DATABASE ADD LOGFILE statement. When no file name is sp
ecified, 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, t
he specific file and directory names are platform-dependent.










Previous


Next
<
/td>


Copyright © 2003 Oracle Corporation

All Rights Reserved.





Home


Book List


Contents


Index


Master Index


Feedback