4
Making Backups with Recovery Manager

BACKUP DEVICE TYPE sbt
  DATABASE PLUS ARCHIVELOG;

\

Using Compresse d Backupsets

For any use of the BACKUP command that creates backupsets, you can take advantage of RMAN's support for binary compression of backupsets, by using the AS COMPRESSED BACKUPSET option to the BACKUP command. The resulting backupsets are compressed using an algorithm optimized for efficient compression of Oracle database files. No extra uncompression steps are required during recovery if you use RMAN's integrate d compression.

This example backs up the entire database and archived logs to the configure d default backup destination (disk or tape), producing compressed backupsets:

BACKUP AS COM
PRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;

This example backups up several datafiles to the default device, using binary compression:

BACKUP AS COMPRESSED
BACKUPSET DATAFILE 1,2,4;

Predictably, creating compressed backup sets imposes some extra CPU overhead during backup and restore, which can slow the backup process. The performance penalty can be wor th paying, however, in a number of circumstances:

• If you are u sing disk-based backups and disk space in your flash recovery area or other disk-based backup destination is limited
• If you are performing your backups to some device over a network and reduced network bandwidth is more important than CPU usage
• If you are using some archival backup media such as CD or DVD, where reducing backup sizes saves on media costs and archival storage

Note that performance while creating compressed backupsets is CPU bound. If you have more than one CPU, you can use increased par allelism to run jobs on multiple CPUs and thus improve performance.

RMAN Incremental Backups

You can make incremental backups of databases, individual tablespaces or datafiles.

As with other backups, if you are in ARCHIVELOG mode, you can make incremental ba ckups if the database is open; if the database is in NOARCHIVELOG mode, then you can only make incremental backups when the database is closed.

The goal of an incremental backup is to back up only those data blo cks that have changed since a previous backup.

The primary reasons for making incremental b ackups part of your strategy are:

• For use in a strategy based on incrementally updated backups, where these incremental backups will be used to roll forward an image copy of the database
• To reduce the amount of time needed for daily backups
• To save network bandwidth when backing up over a network
• To get adequate backup performance when the aggregate tape bandwidth available for tape write I/Os is much less than the aggregate disk bandwidth for disk read I/Os
• To be able to recover changes to objects cre ated with the NOLOGGING option. For example, direct load inserts do not create redo log entries and their changes cannot be reproduced with media recovery. They do, however, change data blocks and so are captured by incremental backups.
• To reduce backup sizes for NOARCHIVELOG databases. Instead of making a whole data base backup every time, you can make incremental backups. Note that incremental backups of a NOARCHIVELOG database are o nly legal after a consistent shutdown.

  See Also: Oracle Da tabase Concepts for more information about NOLOGGING mode

One effective strategy is to make incremental backups to disk, and then back up these image copies to a media manager with BACKUP AS BACKUPSET. This avoids the problem of keeping the tape streaming that c an occur when making incremental backups directly to tape. Because incremental backups are not as big as full backups, you can create them on disk more easily.

Incremental Backup Algorithm

Each data block in a datafile contains a system change number (SCN), which is the SCN at which the most recent change was made to the block. During an inc remental backup, RMAN reads the SCN of each data block in the input file and compares it to the checkpoint SCN of the parent incremen tal backup. If the SCN in the input data block is greater than or equal to the checkpoint SCN of the parent, then RMAN copies the blo ck.

Note that if you enable the block change tracking feature, RMAN can refer to the change tracking file to identify changed blocks in datafiles without scanning the full contents of the datafile. Once enabled, block change tracking does not alter how you take or use incremental backups, other than offering increased performance. See "Improving Incremental Backup Performance: Change Tracking" for more details about enabling block change tracking.

Level 0 and Level 1 Incremental Backups

Incremental b ackups can be either level 0 or level 1. A level 0 incremental backup, which is the base for subsequent incremental backups, copies a ll blocks containing data, backing the datafile up into a backup set just as a full backup would. The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy.

A level 1 incremental backup can be either of the following types:

• A differential backup, which backs up all blocks changed after the most r ecent incremental backup at level 1 or 0
• A cumula tive backup, which backs up all blocks changed after the most recent incremental backup at level 0

Incremental backups are differential by default.

The size of the backup file depends solely u pon the number of blocks modified and the incremental backup level.

Differential Incremental Backups

In a differential level 1 backup, RMAN backs up all blocks that have changed since the most recent cumulative or differental incremental backup, whether at level 1 or level 0. RMAN determines which level 1 backup occurred most recently and ba cks up all blocks modified after that backup. If no level 1 is available, RMAN copies all blocks changed since the level 0 backup.

If no level 0 backup is available, then the behavior depends upon the compatibility mode sett ing. If compatibility is >=10.0.0, RMAN copies all blocks changed since the file was created, and stores the results as a level 1 backup. In other words, the SCN at the time the incremental backup is taken is the file creation SCN. If compatibility <10.0.0, RM AN generates a level 0 backup, to be consistent with the behavior in previous releases.

Figure 4-1 Differential Incremental Backups (Default)

Text description of t he illustration brbsc009.gif

In the example shown in Figure& nbsp;4-1, the following occurs:

• Sunday

  An incremental level 0 backup backs up all blocks that have ever been in use in th is database.

• Monday - Saturday

  On each day from Monday through Saturday, a differential incremental level 1 backup backs up all blocks that have changed since th e most recent incremental backup at level 1 or 0. So, the Monday backup copies blocks changed since Sunday level 0 backup, the Tuesda y backup copies blocks changed since the Monday level 1 backup, and so forth.

• The cycle is repeated for the next week.

Cumulative Incremental Backups

In a cumulative level 1 backup, RMAN backs up all the blocks used since the most recent level 0 incremental backup. Cumulative i ncremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular lev el. Cumulative backups require more space and time than differential backups, however, because they duplicate the work done by previo us backups at the same level.

Figure 4-2 Cum ulative Incremental Backups

Text description of the illustration brbsc010.gif

In the example shown in Figure 4-2, the following occurs:

• Sunday

  An incremental level 0 backup backs up all blocks that have ever been in use in this database.

• Monday - Saturday

  A cumulative incremental level 1 backup copies all blocks changed s ince the most recent level 0 backup. Because the most recent level 0 backup was created on Sunday, the level 1 backup on each day Mon day through Saturday backs up all blocks changed since the Sunday backup.

• The cycle is repeated for the next week.

Basic Incremental Backup Strategy

Choose a backup scheme according to an acceptable MTTR (mean time to recover). For example, you can implement a three-level backu p scheme so that a full or level 0 backup is taken monthly, a cumulative level 1 is taken weekly, and a differential level 1 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 mo re 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. The following query displays the number of blocks written to a backup set for each datafile with at least 50% of its blocks backed up:

SELECT FILE#, INCREMENTAL_LEVEL,
COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS 
  FROM V$BACKUP_DATAFILE 
  WHERE INCREMENTAL_L
EVEL > 0 
  AND BLOCKS / DATAFILE_BLOCKS > .5 
  ORDER BY COMPLETION_TIME;

Compare the number of blocks in differential or cumulative backups to a b ase level 0 backup. For example, if you only create level 1 cumulative backups, then when the most recent level 1 backup is about hal f of the size of the base level 0 backup, take a new level 0.

Making Incremental Backups: BACKUP INCREMENTAL

BACKUP INCREMENTAL LEVEL 0 DATABASE;

BACKUP INCREMENTAL LEVEL
 1
  TABLESPACE SYSTEM
  DATAFILE 'ora_home/oradata/trgt/tools01.
dbf';

<
/a>BACKUP INCREMENTAL LEVEL = 1 CUMULATIVE
  TABLESPACE users;

RUN {
   RECOVER COPY OF DATABASE WITH TAG 'incr_update' 
       UNTIL TIME 'SYSDATE - 7';
   BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_upd
ate'
       DATABASE;
   }

SQL> ALTER DATAB
ASE ENABLE BLOCK CHANGE TRACKING;

SQL>
 ALTER DATABASE ENABLE BLOCK CHANGE TRACKING 

  USING FILE '/mydir/rman_change_track.f' REUSE;

SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

1. If necessa ry, determine the current name of the change tracking file:

   SELECT filename 
   FROM V$BLOCK_CHANGE_TRACKING;
   
   

2. Shut down the database. For example:

   SHUTDOWN IMMEDIATE
   
   

3. Using host operating system commands, move the change tracking file to its new lo cation.
4. Mount the database and move the change tracking file to a locat ion that has more space. For example:

   ALTER DATABASE RENAME FILE 'ora_home
   /dbs/change_trk.f' TO '/new_disk/change_
   trk.f'; 
   
   

5. Open the database:

   ALTER DATABASE OPEN;
   
   

If you cannot shut down the database, then you must disable change tracking and re-enable it at the new location, as in the following example:

ALTER DATABASE DISABLE BLOCK CHANGE TRACK
ING;
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location';




If you choose this method, you will lose the contents of the change tracking file. Until th
e next time you complete a level 0 incremental backup, RMAN will have to scan the entire file.
 
Backing Up to the Flash Reco
very Area: Basic Scenarios

 
For all of the following scenarios, a
ssume that the RMAN environment and flash recovery area are configured as shown in "Configure Flash Recov
ery Area for Disk-Based Backups: Example".
 
Scripting Disk-Only Backups

 
Backup scripts depend on the database load and the amount of disk space allocated. You can categorize t
he scripts based on how the database is used and the minimum amount of disk limit required to achieve the recovery window on disk.
 
If few database blocks change, then the incremental backup size will be significantly less th
an the size of the database, and the best practice is to take incremental backups, to make efficient use of disk space and other reso
urces.
 
If most or all database blocks change frequently, then the size of incremental backu
p will be roughly as large as the size of the database, and the best practice is to periodically make a complete image copy of the da
tabase.
 
In the following scenarios, you do not need to back up archived logs because Oracle
 archives the logs to the flash recovery area. They will remain in the flash recovery area for as long as they are required by the re
tention policy. All database backups are also all directed to the flash recovery area.
 
This
 section contains the following topics:

Backup Scripts When Few Data Blocks Change
Backup Scripts When Blocks Change Frequently
B
ackup Scripts When a Moderate Number of Blocks Change Weekly
 
Backup Scripts When Few Data Blocks Change

<
a name="1030090"> 
If most data blocks do not change each day, incremental backups will be small and you can plan y
our strategy around daily incremental backups.
 
Initial Setup

 
The minimum reco
mmended flash recovery area size on disk is dependent on the how frequent the backups are taken and retention policy used.
 
If your configured retention policy is REDUNDANCY X and you plan to take a backup every
Y days, then the formula for the recommended flash recovery area disk quota is:
Disk Quota =
Size of X copies of database +
Size of one copy of incremental b
ackups +
Size of (Y+1) days of archived logs 




If you configure your retention policy to a recovery window of X days and execute your backup script once in
 Y days then you can calculate your required disk quota by one of two formulas. If X>=Y then the formula for
 the recommended flash recovery area disk quota is:
Disk Quota =
Siz
e of one copy of database +
Size of (floor(X/Y) + 1) copies of incremental backups +
Size
 of (X * ceil(X/Y) +1) days of archived logs




where ceil(X/Y
) is the smallest integer greater than or equal to X/Y and floor(X/Y) is the largest integer less than or equal t
o X/Y.
 
If X <Y then the recommended formula is:
<
/a>Disk Quota =
Size of one copy of database +
Size of 2 copies of incremental backups +
Size of (Y +1) days of archived logs




Size y
our flash recovery area according to the applicable formula.
 
For this example, assume that
the retention policy is REDUNDANCY 1:
RMAN> CONFIGURE RETENTION POLICY TO R
EDUNDANCY 1;




Also assume that backups will be performed daily.
 
Daily Scrip
t

 
The daily backup script would look like this:
RMAN> RECOVER COPY OF DATABASE WITH TAG "whole_db_cpy";
# Make an incremental backup o
f the database to the flash recovery area.
RMAN> BACKUP INCREMENTAL LEVEL 1 
      FOR
 RECOVER OF COPY WITH TAG "whole_db_copy" 
      DATABASE;




Assume that there are no backups tagged "whole_db_copy" as of the first day of this backup scheme. The results of run
ning this script daily are as follows:

On the first day, the <
code>RECOVER statement would have no effect, and the BACKUP... FOR RECOVER OF COPY would create the initial level
 0 database copy.
On the second day, the RECOVER statement still
has no effect, as there is no level 1 incremental backup to be applied to the level 0 incremental database copy. The BACKUP command creates the first incremental level 1 backup.

Each day after that,
 the incremental level 1 from the previous day is applied over the level 0 database copy, rolling it forward to the time of the incre
mental level 1 of the previous day, and a new incremental level 1 is created, containing all changes since the level 1 incremental ba
ckup of the previous day.

 
Assuming that this backup strategy is put into effect on Fe
bruary 1, Table 4-1 shows how the flash recovery area contents change over time as a result of th
e strategy. (Note that the flash recovery area may contain other files based on other backup activities; this table only represents f
iles related to this strategy.)
 
 Table 4-1 Backup Timeline for Scenario When Few Blocks Change: Version 1
To alter the example slightly: if you can size the flash recovery area to hold n days worth of archived logs and incremental backups (where n > 1), then you can alter the
RECOVER line to RECOVER COPY UNTIL TIME 'SYSDATE-n'. For example, if the flash recovery area is large enough to hold three days of incremental backups, t
hen you can change the script as follows:
RECOVER COPY OF DATABASE TAG "whole_db_copy" UNTI
L TIME 'SYSDATE-3';
# Make an incremental backup of the database to the flash recovery area.

BACKUP INCREMENTAL LEVEL 1 
      FOR RECOVER OF COPY WITH TAG "whole_db_copy" 

 DATABASE;

Every day that you run the script, RMAN rolls forward
the whole database copy to an SCN three days before the current time. Hence, the disk quota rules will preserve archived logs and inc
remental backups created after SYSDATE-3 (because they are needed to recover the database to an
SCN within the last three days.
The following table lists the set of files expected to be i
n the flash recovery area each day after the daily script for this strategy is run.
In this scenario, typical of a CRM environment, many or most of the data blocks a
re updated over the course of a week.
If you use a retention policy of redundancy X, and a
backup script executed once each Y days, the minimum disk quota required is determined by the following formula:
Disk Quota = Size of X copies of the database + 
        size of Y days of archived redo
logs

If you use a retention policy of a recovery window of X days
, and the backup script is executed once each Y days, then if X>=Y, then disk quota is determined by the following formula:
Disk Quota = Size of 1 copy of the database + 
         size of ((X * ceil(
X/Y)) +1) days of archived redo logs




where ceil(X/Y)
 is the smallest integer greater than or equal to X/Y.
If X<Y, the disk quota is the sam
e as when X=Y, that is,
Disk Quota = Size of 1 copy of the database + 
         size of (Y +1) days of archived redo logs

For this exa
mple, assume that the retention policy is REDUNDANCY 1, and you are executing the backup script once each week. The mini
mum disk quota required for this scenario is as follows:
Disk Quota = Size of 1 copy of the
 database + 
        size of 8 days of archived logs

This scenario requires no initial setup script. The weekly backup script is shown here:
# Execute once a week
# Make a full backup of the database to the flash recovery area.
BACKUP DATABASE TAG "weekly_full_bkup";

As shown in Table 4-2, the disk quota needs only to keep one level 0 copy of the database and one week's worth of arc
hived logs.
 Table 4-2 Backup Timeline for Scenario When Most Blocks Change



 Day
 Script Effects
 Flash Recovery Area Contents After Script



 
Sun
 Feb 1


Attempt incremental upd
ate, which has no effect because there is no level 0 backup.
Create lev
el 0 backup.
 
Level 0incremental image copy backup, with SCN a
s of Sun Feb 1

 
M
on Feb 2


Attempt incremental u
pdate, which has no effect because there is no level 1 incremental.
Bac
k up level 1 incremental.
 
Level 0 incremental image copy back
up with SCN as of Sun Feb 1, level 1 incremental backup containing changes from Feb 1 through Feb. 2, archived logs from Feb 1 throug
h today

 
Feb 3 an
d after


Perform incremental up
date of level 0, rolling it forward to the prcvious day.
Back up level
1 incremental.
 
Level 0 incremental image copy backup rolled f
orward to previous day's level 1 SCN, level 1 incremental backup with changes for previous 24 hours, archived logs from February 1 th
rough today. 
Old incremental backups and archived logs not useful for recovery of the rolled
-forward level 0 backup are automatically deleted when more free space is needed in the flash recovery area.
 





 

 
 

 






 













 




 Day
 Action
 Contents of Flash Recovery Area


 
Sun Feb 1
 
Back up level 0.
 
Full backup


 
Sun Feb 8
 
Back up level 0.
 
Ful
l backup from today, archived logs from Feb 1 through Feb 8

 
Each subsequent Sunday
 

Back up level 0.
 
Full backup from this Sunday, archived logs from t
he previous Sunday through this Sunday
 
Backup Scripts When a Moderate Number of Blocks Change Weekly

 
Use this strategy when roughly half the data blocks change weekly, or when the numb
er of data blocks that change varies widely from week to week. The scripts in this strategy are "all purpose" scripts that use increm
entally updated backups, starting with an image copy of the database, taking incremental level 1 backups at regular intervals, and ro
lling forward the existing level 0 copy.
 
The formula for determining space required for the
 flash recovery area depends upon the retention policy. For a retention policy of REDUNDANCY X and a backup script that
runs once every Y days, the disk space required is:
Disk Quota = Size of X copies of the da
tabase + 
             Size of 1 incremental backup + 
             Size of Y+1 days of a
rchived redo logs




For a recovery window of X days and a backup sc
ript executed once each Y days, if X>=Y then the space required is:
Disk Quota = Size of
 1 copy of the database + 
             Size of floor(X/Y)+1 incremental backups + 

        Size of (X * ceil(X/Y)) + 1 days of archived logs




where <
code>ceil(X/Y) is the smallest integer greater than or equal to X/Y and floor(X/Y) is the largest integer less th
an or equal to X/Y.
 
If X< Y then the space required is the same as when X=Y:
Disk Quota = Size of 1 copy of the database + 
             Size of 2 incrementa
l backups + 
             Size of Y+1 days of archived logs




For the example that follows, assume that the retention policy is REDUNDANCY 1 and the backup script is
 run once each week.
 
Initial Setup

 
The minimum disk quota for such a scenario
 is
Disk Quota = Size of 1 copy of the database + 
             Size
of 1 incremental backup + 
             Size of 8 days of archived logs




The first week, the BACKUP... FOR RECOVER OF COPY command makes a level 0 incremental backu
p of the database to the flash recovery area. This backup will be the basis for the weekly strategy. Each subsequent week, this copy
is rolled forward to the last incremental backup checkpoint time. In this way, you create an on-disk recovery window of one week.

 
Weekly Scrip
t

 
After the initial setup, the weekly backup script (which, for exam
ple, you could run every Sunday night) should look like the following:
# Execute once a wee
k
# Roll forward the whole copy of the database to last incremental backup SCN
RECOVER CO
PY OF DATABASE TAG "whole_db_cpy";
# Make an incremental backup of the database to the flash recovery area.
BACKUP INCREMENTAL LEVEL 1 
      FOR RECOVER OF COPY WITH TAG "whole_db_copy" 
      DATABASE;




Table 4
-3 illustrates how the contents of the flash recovery area change with each run of the backup script, always keeping enough archi
ved logs and backups on hand to maintain the seven day recovery window.
 

 Table 4-3 Backup Timeline for Scenario When Moderate
 Number of Blocks Change



 Day
 Action
 Contents of Flash Rec
overy Area After Run


 
Sun Feb 1


Attempt roll-forward of incremental level 0 copy of database with tag "whole_db_copy". Fail, because there is no level 0
 copy.
Create level 0 incremental backup.
 
Level 0 backup

 
Sun Feb 8



Attempt roll-forward of incremental level 0 copy of database with tag "whole_db_copy" using previous week's inc
remental level 1 backup. Fail, because there is no level 1 backup from the previous week.
Create level 1 incremental backup.
 
Level 0
 backup from Sunday Feb 1 (not rolled forward because no level 1 exists), archived logs from Feb 1 through Feb 8

 
All future Sundays


Roll forward level 0 copy of database to SCN of
 most recent incremental level 1 backup.
Create incremental level 1 bac
kup with changes since last incremental level 1 backup SCN.
 
L
evel 0 backup rolled forward to SCN of previous Sunday's incremental level 1, archived logs from previous Sunday through today. 
Archived logs from prior to previous Sunday and the previous week's incremental level 1 backup ar
e obsolete after the roll-forward of the level 0 backup, because there is no other backup to which they could be applied. 
Obsolete files may remain in the flash recovery area until the need for disk space causes the database
to delete them or until the DELETE OBSOLETE command is used.
 
Backing Up to the Flash
 Recovery Area and to Tape: Basic Scenarios

 
This scenario descri
bes how to use RMAN to make backups to the flash recovery area and then later move them to tape.
 
The scripts in this section use the flash recovery area as the log archiving destination and the destination for all disk backu
ps. Therefore, whenever there is no space to create archived logs or backups in the flash recovery area, Oracle automatically deletes
 archived logs and backups that are obsolete or that have been moved to tape.
 
By moving bac
kup files and archived redo logs to tape, more space becomes available in the flash recovery area for new files. The formulas for the
 flash recovery area disk quota are suggested minimums, and depend upon the availability of space on tape to satisfy the retention po
licy. You can, however, increase your on-disk recovery window and reduce the need to restore archived redo logs and backups from tape
 during a database restore-and-recovery scenario, by allocating a larger flash recovery area disk quota than these formulas specify.<
/p>
 
Configuri
ng the RMAN Environment for Disk and Tape Backups

 
Invoke RMAN to con
figure the retention policy, backup optimization, and the control file autobackup. For example:
CONNECT TARGET SYS/orace@trgt;
# Recovery window of 15 days ensures that the database is recoverable withi
n 7
# days using backups on disk and tape
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW O
F 15 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
# Because you do not use a recovery catalog,
 enable the autobackup feature
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE DEVICE TYPE
 sbt PARMS='...' PARALLELISM 1; # PARMS are vendor-specific



Writing Backup Scripts for Disk and Tape Scenarios

<
a name="1035870"> 
As in the disk-only scenarios, the backup scripts in this section are categorized based on datab
ase workload.
 
Backup Scripts When Few Data Blocks Change

 
In this scenario, re
latively few data blocks change frequently, so daily level 1 incremental backups will typically be small. The goal is to keep one lev
el 0 incremental backup on disk, incrementally updated each day using a level 1 incremental backup, and then move all other files ont
o tape. This keeps flash recovery area usage to a minimum.
 
Initial Setup

 
The
only required setup is to create a flash recovery area with the required disk quota, and set the flash recovery area as a redo log ar
chiving destination.
 
The formula for determining your disk quota depends upon the backup re
tenion policy. It is the same, however, whether your retention policy is based on redundancy or recovery window. Use the following fo
rmula:
Disk Quota = Size of 1 copy of the database 
             + si
ze of 1 day's level 1 incremental backup
             + size of (Y+1) days of archived logs
<
/a>



where Y is the number of days that elapse between executionof BACKUP RECOVERY
AREA in your backup scripts.
 
For this example, there is one backup script, executed
every day, which creates a new incremental level 1 backup with that day's changes, rolls forward the level 0 backup using the level 1
 backup from the previous day, and backs up all flash recovery area files to tape. Since the script backs up the flash recovery area
to tape daily, the flash recovery area must be large enough to hold a copy of the database, the daily level 1 incremental backup, and
 two days' worth of archived redo logs.
 
The on-disk recovery window is one day. To recover
to a point farther back than one day, RMAN must restore backups from tape.
 
Daily Script

 
After the initial setup, a typical daily RMAN backup script would look like the following:
# Execute each day of the week
# Roll forward the copy to most recent incremental backup SCN, which
will
# be yesterday's incremental level 1 backup
RECOVER COPY OF DATABASE WITH TAG "daily
_backup";
# Take incremental backups to flash recovery area (using default disk channel)

BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "daily_backup" DATABASE;
# Back up flash recovery area
to tape
BACKUP RECOVERY AREA;
# delete obsolete backups on tape
DEL
ETE OBSOLETE DEVICE TYPE sbt;




Table&nb
sp;4-4 describes how the contents of the flash recovery area and tape change as this script is run each day. The script rolls for
ward the level 0 database copy tagged as daily_backup to the SCN of the preceding day's incremental level 1 backup, then
 creates a new level 1 incremental backup with the previous day's changes. For example, when you run the script on Thursday, RMAN rol
ls forward the level 0 backup to the SCN of the incremental backup on Wednesday.
 
 Table 4-4 Backup Timeline for Scenario When
 Few Blocks Change
Backup Scr
ipts When Many Blocks Change
In this scenario, many or most of the d
ata blocks are updated over the course of a week, as in a CRM environment. A strategy using daily incremental backups would not be re
commended because the size of the incremental backups could be quite large and is hard to predict.
A better strategy in this case is to back up the database to tape weekly and the archived logs to tape every day, and to use
a recovery window-based retention policy.
The elements of the strategy are as follows:

Redo log files are archived in the flash recovery area.
A full backup of the database is taken to the flash recovery area once each week.
<
li class="LB1" type="disc">Once each day, any backup files (including archived redo logs) in the flash recovery
 area that is not currently stored on tape is backed up to tape using the BACKUP RECOVERY AREA command, and any obsolete
 backups on tape are deleted.
If you use a recovery window-based retention policy, al
l backups required to perform point-in-time recovery within the window are retained as long as they are needed. This provides the nec
essary protection for your data, even with limited use of disk space.
Initial Setup
Create your flash recovery area with the required disk quota and set up the flash recovery area as a redo log archiving destin
ation. The formula for determining your disk quota depends upon the frequency of backups of the flash recovery area to tape, as follo
ws:
Disk Quota = Size of 1 copies of the database 
           + size
of (Y+1) days of archived logs

where Y is the number of days that elapse between executionof BACKUP RECOVERY AREA in your backup scripts.
For this example, assume that you take a full database backup once each week, and back up
the flash recovery area to tape on all seven days of the week.
There are two scripts in thi
s strategy. Use the first script at the beginning of each week (say, on Sunday) to create a full database backup, and the other scrip
t on the remaining days of the week (Monday through Saturday) to back up the flash recovery area contents (the archived redo logs for
 the day) to tape.
Note that both of the scripts in this strategy include the BACKUP RECOVE
RY AREA command, so that command is executed every day. For this example, Y=1, so the disk quota is the size of one copy of the datab
ase plus two days of archived redo logs.
Weekly Scripts
This RMAN backup scri
pt is executed once each week, on Sunday:
# Execute only once a week

# Take copy of database to flash recovery area
BACKUP AS COPY DATABASE;
# Take backup of
flash recovery area to tape
BACKUP RECOVERY AREA;
# Delete obsolete backups on tape
DELETE OBSOLETE DEVICE TYPE sbt;
EXIT;

<
h5 class="H4">Daily Script
The RMAN script to be executed each day (Monday through Saturday) would look like the following:
# Execute 6 days/wk
# Take backup of flash recovery area to tape
B
ACKUP RECOVERY AREA;
# delete obsolete backups on tape
DELETE OBSOLETE DEVICE TPE sbt;

Because the entire flash recovery area is backed up to tape every d
ay, the database may delete backups and archived redo log files from the flash recovery area whenever space is needed for new files.
Between backups it may be difficult to predict exactly which files will still be in the flash recovery area, because files are delete
d whenever space is needed.
Backup Scripts When Blocks Change Moderately
The
following strategy is based on full database backups taken at regular intervals. It is useful when about half of the data blocks chan
ge during the interval between full database backups, or when the number of changed data blocks varies widely between full database b
ackups.
The strategy is based on an incrementally updated backups-based full backup of the
database, rolled forward once each week. This requires a level 0 disk copy incremental backup of the database, and a level 1 incremen
tal created each Sunday with the previous seven days of datafile changes. After the roll-forward, the contents of the flash recovery
area are backed up to tape, so the incremental level 0 copy of the database and the level 1 weekly incremental backup are available b
oth on disk and tape.
Each day, archived redo log files accumulate in the flash recovery ar
ea. Each time the daily script runs, those redo log files are backed up to tape. After that, they may be deleted from disk if space i
s needed in the flash recovery area.
Initial Setup
The minimum flash recovery
 area disk quota for this scenario is calculated with the following formula:
Disk Quota = S
ize of 1 copy of the database 
           + Size of 1 level 1 incremental backup with Y
 days of changes 
           + Size of (Y+1) days of archived redo logs

where Y is the number of days between backing up the fla
sh recovery area to tape.
For this example, Y=7, so the disk quota
must be at least the size of one copy of the database, one seven-day level 1 incremental backup, and eight days' worth of archived re
do logs.

Weekly Script
The script that implement the Sunday backup for this s
trategy weekly parts of the backup is as follows:
# Execute once a week
<
/a># Roll forward the whole copy of the database to last incremental backup SCN
RECOVER COPY OF DATABASE WITH T
AG "whole_db_cpy";
# Make an incremental backup of the database to the flash recovery area.
<
/a>BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 
       FOR RECOVER OF COPY WITH TAG "whole_db_copy" 
       DATABASE;
# Back up flash recovery area to tape
BACKUP RECOVERY AREA;
# delete obsolete backups on tape
DELETE OBSOLETE DEVICE TYPE sbt;
Daily Script
The daily script for this strategy is shown here:
# Execute 6 days/wk
# Back up flash recovery area to tape
BACKUP RECOVERY AREA;
# delete obsolete backups on tape
DELETE OBSOLETE DEVICE TYPE sbt;


Table 4-5 illustrates how the scripts maintain the
recovery window. Assume for the purposes of this example that the week begins on Sunday.
<
a name="1019604"> Table 4-5 Backup Timeline for Scena
rio When Moderate Number of Blocks Change



 Day
 Action
 Contents of Flash Recovery
Area and SBT


 
Sun Feb 1


Attempt roll-forward of level 0 backup; fail because there is no level 0 backup yet.
Create level 0 incremental backup to be rolled forward on future days.
 
Level 0 incremental backup. 
Any other flash recovery area files
 such as archived redo logs are copied to tape and may be deleted from flash recovery area when space is needed.

 
Mon Feb 2


Attempt roll-forward of level 0 backup; fail because the
re is no level 1 backup yet.
Create level 1 incremental backup, contain
ing changes during Feb 2.
Back up flash recovery area to sbt.

 
Level 0 backup from Feb 1, level 1 incremental backup containing chang
es from Feb 2. 
Any other flash recovery area files such as archived redo logs are copied to
tape and may be deleted from flash recovery area when space is needed. 
Any obsolete files st
ored on tape are deleted.

 
All future days


Roll
 forward incremental level 0 backup to SCN of previous level 1 incremental backup.
Create level 1 incremental backup containing changes from previous day.
Back up flash recovery area to sbt.
 
Level 0 back
up rolled forward to previous day, level 1 incremental backup containing changes from this day 
Any other flash recovery area files such as archived redo logs are copied to tape and may be deleted from flash recovery area when
 space is needed. 
Any obsolete files stored on tape are deleted.
 


 

 

 


 

 


 





 

 

 

 


 





 





 


 

 

 

 


 





 

 


 






 





 




 Day
 Script
 Acti
on
 Contents of Flash Recovery Area and Tape After Script


 
Week 1, Sunday

 
Weekly


Attempt RECOVER COPY OF DATABASE command. This command has no effect, because there is no level 0 backup of the databa
se yet.
Create level 0 backup as result of the BACKUP... FOR RECOVER OF
 COPY command.
Back up all files in the flash recovery area to tape.
Delete obsolete backups from tape.
 
Flash recovery area contains the level 0 incremental backup of the database, to be rolled forward e
ach week. 
Tape contains a backup of the level 0 incremental backup of the database.


 
Week 1, Monday- Saturday

 
Daily


Back up flash recovery area to tape.
Delete obsolete backups from tape.
 
Flash recovery ar
ea contains archived redo logs for the previous day, and the incremental level 0 database backup. 
Tape contains a backup of the level 0 incremental backup, and all redo logs for all days since Sunday of week 1. 
No backups are obsolete.

 
Week 2, Sunday
 
Weekly


Attempt RECOVER COPY OF DATABASE level
0 to most recent incremental SCN. This command has no effect, because there is no level 1 incremental backup to use in roll-forward.<
/li>
Perform level 1 incremental backup. A level 1 incremental backup is cre
ated, including changes from week 1.
Back up flash recovery area to tap
e.
Delete obsolete backups from tape.
 
Flash recovery area contains incremental level 0 database backup at SCN of Sunday of week 1, l
evel 1 incremental backup with changes from week 1. 
Tape contains level 0 incremental backup
 from Sunday of week 1, level 1 incremental backup with all changes from week 1, archived redo logs from week 1. 

No backups are obsolete.

 
Week 2, Monday- Saturday
 
Daily


Back up flash recovery area to tape.

Delete obsolete backups from tape.
<
a name="1033846"> 
Flash recovery area contains archived redo logs for the previous day, and the incremental level
0 database backup. May also contain other archived redo logs. 
Tape contains a backup of the
level 0 incremental backup, and all redo logs for all days since Sunday of week 1.

 
Week 3, Sunday


Weekly


Perform
RECOVER COPY OF DATABASE level 0 to most recent incremental SCN. The level 0 incremental backup is rolled forward to the beginning of
 week 2.
Perform level 1 incremental backup. A level 1 incremental back
up is created including changes from week 2.
Back up flash recovery are
a to tape.
Delete obsolete backups from tape.
 
Flash recovery area contains incremental level 0 database backup at SCN of Sunday from
 week 2, level 1 incremental backup with changes from week 2. 
Tape contains level 0 incremen
tal backup rolled forward to SCN of Sunday of week 2, level 1 incremental backup with all changes from week 2, archived redo logs fro
m week 2. 
Obsolete backups deleted from tape include archived redo logs from week 1, tape ba
ckup of level 0 incremental database backup from week 1.
 

Backup Scripts When Not Enough Disk Space for a Database Ba
ckup

 
If the disk quota is not sufficient to keep a copy of database,
 then the flash recovery area should be used only as an archived log destination. The disk quota rules will a
utomatically delete these logs from the flash recovery area when they are no longer needed (because they are obsolete or because they
 have been backed up to tape). Back up the archived logs to tape daily, to ensure that they can be deleted from the flash recovery ar
ea when space is needed there for other files.
 
For this strategy, the flash recovery area s
hould be sized large enough to hold at least two days' worth of archived redo logs, plus one day's worth of incremental backup.
<
a name="1033930"> 
This strategy is based on level 0 and level 1 incremental backups (though it does not use increm
entally updated backups). This strategy uses two scripts: one to be executed once a week (for example, on Sunday), and the other to b
e executed every day except for the day that the first script is executed (Monday through Saturday).
 
The script that runs once each week creates a level 0 incremental backup on tape, containing the full contents of the datab
ase.
 
The script that runs each day except the first day creates level 1 incremental backups
 containing the changes to the database each day.
 
Weekly Script

 
Here is the s
cript to run once at the beginning of each week
# Execute only once a week
# backup database to tape
BACKUP DEVICE TYPE sbt INCREMENTAL LEVEL 0 DATABASE;
# de
lete obsolete backups on tape
DELETE OBSOLETE DEVICE TYPE sbt;
# backup recovery file des
tination to tape
BACKUP RECOVERY AREA;



Daily Script

 

This script executes each day of the week except for the first day, for example, Monday through Saturday:
# backup recovery file destination to tape
BACKUP RECOVERY AREA;
# Take in
cremental backups to flash recovery area
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 DATABASE;




Table 4-6 illustrates how the scripts maintai
n the RMAN retention policy recovery window and how the disk quota is maintained. The recovery files that exist after the execution o
f the script each day also exist on tape, so Oracle can delete files from the flash recovery area as needed.
 
 Table 4-6 Backu
p Timeline for Limited Disk Space Scenario



 Day
 Script
 Act
ion
 Contents of Flash Recovery Area and Tape After Script


 
Sun Feb 1
 
Once-a-week


Back up level 0 to tape.
Delete obsolete from tape.
Back up flash recovery area to tape.
 
Flash recovery area contains... 
Tape contains a level 0 b
ackup of the whole database from February 1, and any archived redo logs.

 
Mon Feb 2 - Sat Feb 7
 
Daily


Back up flas
h recovery area to tape.
Back up level 1 to disk.
 
Flash recovery area contains... 
Tape cont
ains a level 0 backup of the whole database from February 1, incremental level 1 backups for each day from Monday through the present
 day, and any archived redo logs for the whole week.

<
a name="1011096"> 
Sun Feb 8
 
Once-a-week



Back up level 0 to tape.
Delete obsolete from tape.
Back up flash recovery area to tape.
 
Flash recovery area
 contains... 
Tape contains...
 
Validating RMAN Backups


 
You can use the VALIDATE keyword of the BACKUP<
/code> command to check datafiles for physical and logical corruption and confirm that all database files exist and are in the correc
t locations.

 
RMAN does not actually produce backup sets, but scans the files to determine w
hether they can be backed up and are not corrupted. The BACKUP VALIDATE command is similar to the RES
TORE VALIDATE command. If the backup validation discovers corrupt blocks, then RMAN updates the V$DATABASE_
BLOCK_CORRUPTION view with rows describing the corruptions. After a corrupt block is repaired, the row identifying this block
is deleted from the view.
 
For example, you can validate that all database files and archive
d logs can be backed up by running a command as follows:
BACKUP VALIDATE DATABASE ARCHIVELO
G ALL;




RMAN displays the same output that it would if it were rea
lly backing up the files. If RMAN cannot validate the backup of one or more of the files, then it issues an error message. For exampl
e, RMAN may show output similar to the following:
RMAN-00571: =============================
==============================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of ba
ckup command at 08/29/2002 14:33:47
ORA-19625: error identifying file /oracle/oradata/trgt/arch/archive1_6.dbf
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3




You cannot use the 
MAXCORRUPT or PROXY parameters with the VALIDATE option.
 



See Also:  

Oracle Database Recovery Manager Reference for BACKUP syntax
Oracle Database Backup
 and Recovery Advanced User's Guide to learn how to repair corrupt blocks discovered by BACKUP ...
 VALIDATE
 
Overview of Querying the RMAN Repository

Listing RMAN Backups, Archived Logs, and Database Incarnations

 
The LIST command queries the recovery catalog or control file and lists the backup
s, archived logs, and database incarnations. You can specify these files when running the CHANGE, CROSSCHECK, and DELETE commands.
 
This section contains these topics:

About RMAN Lists
Listing Backups
Listing Backups by File
List
ing Backups in Summary Mode
Listing Backups wit
h Restrictions
Listing Database Incarnations
 
A
bout RMAN Lists

 
You can control how the output is displayed by using
 the BY BACKUP and BY FILE options of the LIST command and choosing
between the SUMMARY and VERBOSE options.
 
The primary purpose of t
he LIST command is to determine which backups are available. Note that only backups that completed successfully are stor
ed in the repository. For example, you can list:

Backups and p
roxy copies of a database, tablespace, datafile, archived redo log, or control file
Backups that have expired
Backups restricted by time, path name, device
type, tag, or recoverability
Incarnations of a database
 
Use LIST to determine what you need to back up. In particular, ensure that:

The STATUS columns of the output tables list all backups as A
VAILABLE
All files that you need backed up are included in the output
The backups recorded in the repository are recent
<
/a> 
Note that the V$BACKUP_FILES also contains list information for backups.
 <
!--TOC=h2-"1008734"-->
Listing Backups

 
By default, RMAN lists backups by backup, which means that it serially lists each backup
or proxy copy and then identifies the files included in the backup. You can also list backups by file.
 
By default, RMAN lists in verbose mode. You can also list backups in a summary mode if the verbose mode generates too muc
h output.
 
Listing Backups by Backup

 
To list backups by backup, connect to the
 target database and recovery catalog (if you use one), and then execute the LIST BACKUP command. Specify t
he desired objects with the listObjList clause. For example, you can enter:
LIST BACKUP;       # lists backup sets, image copies, and proxy copies
LIST BACKUPSET;    # lists only
backup sets and proxy copies
LIST COPY;         # lists only disk copies




Optionally, specify EXPIRED to identify backups not found during a crosscheck:
LIST EXPIRED BACKUP;




Examine the
 output (refer to Oracle Datab
ase Recovery Manager Reference for an explanation of the various column headings in the LIST output). Sample ou
tput of LIST BACKUP follows:
List of Backup Sets
=====
==============

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
7       136M       DISK        00:00:20
  04-NOV-03      
        BP Key: 7   Status: AVAILABLE  Compressed: NO  Tag: TAG20031104T200759
        Piece Name: /oracle/work/RDBMS/backupset/2003_11_04/o1_mf_annnn_TAG20031104T200759_ztjxx3k8_.bkp

  List of Archived Logs in backup set 7
  Thrd Seq     Low SCN    Low Time  Next SCN
 Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    1       173832
     21-OCT-03 174750     21-OCT-03
  1    2       174750     21-OCT-03 174755     21-OCT-03

  1    3       174755     21-OCT-03 174758     21-OCT-03

  1    37      533321     0
1-NOV-03 575472     03-NOV-03
  1    38      575472     03-NOV-03 617944     04-NOV-03

1    39      617944     04-NOV-03 631495     04-NOV-03

BS Key  Type LV Size       Device
 Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
8       Full    2M         DISK        00:00:01     04-NOV-03      
        BP Key: 8   Status: A
VAILABLE  Compressed: NO  Tag: TAG20031104T200829
        Piece Name: /ade/lashdown_rdbms/oracle/dbs/c-77462706
8-20031104-01
  Controlfile Included: Ckp SCN: 631510       Ckp time: 04-NOV-03
  SPFILE
Included: Modification time: 21-OCT-03




Sample output of LIST COPY
 follows:
List of Archived Log Copies
Key     Thrd Seq     S Low Ti
me  Name
------- ---- ------- - --------- ----
37      1    37      A 01-NOV-03 /oracle/w
ork/RDBMS/archivelog/2003_11_03/o1_mf_1_37_ztd4hl5d_.arc
38      1    38      A 03-NOV-03 /oracle/work/RDBMS/ar
chivelog/2003_11_04/o1_mf_1_38_zthvg168_.arc
39      1    39      A 04-NOV-03 /oracle/work/RDBMS/archivelog/200
3_11_04/o1_mf_1_39_ztjxwxwy_.arc




Listing Backups by File

 
Specify the desired objects with the listObjList or recordSpec clause (refer to Oracle Database Recovery Manager
Reference). If you do not specify an object, then RMAN displays copies of all database files and archived logs. By default,
RMAN lists in verbose mode, which means that it provides extensive, multiline information.
 

To list backups by file, connect the RMAN client to the target database and recovery catalog (if you use one), and then execute LIST with the BY FILE option, specifying the desired objects to list and options.For example, you c
an enter:
LIST BACKUP BY FILE; # shows backup sets, proxy copies, and image copies
LIST COPY BY FILE;   # shows only disk copies




For
another example, you could specify the EXPIRED option to identify backups not found during a crosscheck:
LIST EXPIRED BACKUP BY FILE;




Examine
the output (refer to Oracle Da
tabase Recovery Manager Reference for an explanation of the various column headings in the LIST output). Sample
 output follows:
List of Datafile Backups
========================
<
a name="1035106">
File Key     TY LV S Ckp SCN    Ckp Time  #Pieces #Copies Compressed Tag
---- ------- -  -- - ---------- --------- ------- ------- ---------- ---
1    5       B  F  A 631092
04-NOV-03 1       1       YES        TAG20031104T195949
     2       B  F  A 175337     21-OCT-03 1       1
   NO         TAG20031021T094513
2    5       B  F  A 631092     04-NOV-03 1       1       YES        TAG200311
04T195949
     2       B  F  A 175337     21-OCT-03 1       1       NO         TAG20031021T094513
... some rows omitted

List of Arc
hived Log Backups
============================

Thrd Seq     Low SC
N    Low Time  BS Key  S #Pieces #Copies Compressed Tag
---- ------- ---------- --------- ------- - ------- ---
---- ---------- ---
1    1       173832     21-OCT-03 7       A 1       1       NO         TAG20031104T200759
<
a name="1035132">                                  1       A 1       1       NO         TAG20031021T094505

1    2       174750     21-OCT-03 7       A 1       1       NO         TAG20031104T200759

             1       A 1       1       NO         TAG20031021T094505
... some rows omitted
<
/em>1    38      575472     03-NOV-03 7       A 1       1       NO         TAG20031104T200759
1    39      617944     04-NOV-03 7       A 1       1       NO         TAG20031104T200759


List of Controlfile Backups
===========================
CF
Ckp SCN Ckp Time  BS Key  S #Pieces #Copies Compressed Tag
---------- --------- ------- - ------- ------- -----
----- ---
631510     04-NOV-03 8       A 1       1       NO         TAG20031104T200829
63
1205     04-NOV-03 6       A 1       1       NO         TAG20031104T200432
175380     21-OCT-03 4       A 1
   1       NO         TAG20031021T094639

List of SPFILE Backups
==
====================
Modification Time BS Key  S #Pieces #Copies Compressed Tag
---------
-------- ------- - ------- ------- ---------- ---
21-OCT-03         8       A 1       1       NO         TAG200
31104T200829
21-OCT-03         6       A 1       1       NO         TAG20031104T200432



Listing Backups in Summary Mod
e

 
By default the LIST output is detailed, but you can a
lso specify that RMAN display the output in summarized form. Specify the desired objects with the listObjectList or recordSpec clause. If you do not specify an object, then LIST BACKUP displays al
l backups.
 
After connecting to the target database and recovery catalog (if you use one), e
xecute LIST BACKUP, specifying the desired objects and options. For example:
LIST BACKUP SUMMARY;  # lists backup sets, proxy copies, and disk copies




You can also specify the EXPIRED keyword to identify those backups that were not found during a cro
sscheck:
LIST EXPIRED BACKUP SUMMARY;




Sample output follows:
List of Backups
=============
==
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- --
-- - ----------- --------------- ------- ------- ---------- ---
1       B  A  A SBT_TAPE    21-OCT-03       1
     1       NO         TAG20031021T094505
2       B  F  A SBT_TAPE    21-OCT-03       1       1       NO
   TAG20031021T094513
3       B  A  A SBT_TAPE    21-OCT-03       1       1       NO         TAG20031021T094624

4       B  F  A SBT_TAPE    21-OCT-03       1       1       NO         TAG20031021T094639
5       B  F  A DISK        04-NOV-03       1       1       YES        TAG20031104T195949
6       B  F  A DIS
K        04-NOV-03       1       1       NO         TAG20031104T200432
7       B  A  A DISK        04-NOV-03
    1       1       NO         TAG20031104T200759
8       B  F  A DISK        04-NOV-03       1       1       N
O         TAG20031104T200829




Refer to Oracle Database Recovery Manager Reference for a
n explanation of the various column headings in the LIST output.
 
Listing Backups with Restrictions

 
You can specify several different conditions to narrow your LIST output.
 
After connecting to the target database and recovery catalog (if you use one), execute LIST COPY or LIST BACKUP with the listObjList or recordSpec condition. For example, enter any of the following commands:
# lists backups of all
files in database
LIST BACKUP OF DATABASE; 
# lists copy of specified datafile    
LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf'; 
# lists sp
ecified backup set
LIST BACKUPSET 213; 
# lists datafile copy
LIST
DATAFILECOPY '/tmp/tools01.dbf';




You can also restrict the search
 by specifying the maintQualifier or RECOVERABLE clause. For example, enter:
<
a name="1008923"># specify a backup set by tag
LIST BACKUPSET TAG 'weekly_full_db_backup';
# specify a backup or copy by device type
LIST COPY OF DATAFILE 'ora_home/oradata
/trgt/system01.dbf' DEVICE TYPE sbt;
# specify a backup by directory or path
LIST BACKUP
LIKE '/tmp/%';
# specify a backup or copy by a range of completion dates
LIST COPY OF DAT
AFILE 2 COMPLETED BETWEEN '10-DEC-2002' AND '17-DEC-2002';
# specify logs backed up at least twice to tape
LIST ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;





The output depends upon the options you pass to the LIST command. For example, the following lists copies of datafile 1:
RMAN> list backup of datafile 1;



List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ---
--------- ---------------
2       Full    230M       SBT_TAPE    00:00:49     21-OCT-03

       BP Key: 2   Status: AVAILABLE  Compressed: NO  Tag: TAG20031021T094513
        Handle: 02f4eatc_1_1   Me
dia: /smrdir
  List of Datafiles in backup set 2
  File LV Type Ckp SCN    Ckp Time  Name

  ---- -- ---- ---------- --------- ----
  1       Full 175337     21-OCT-03 /oracle/dbs
/tbs_01.f

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
5       Full    233M       DISK
        00:04:30     04-NOV-03
        BP Key: 5   Status: AVAILABLE  Compressed: NO  Tag: TAG20031104T195949
<
a name="1035603">        Piece Name: /oracle/work/RDBMS/backupset/2003_11_04/o1_mf_nnndf_
TAG20031104T195949_ztjxfvgz_.bkp
  List of Datafiles in backup set 5
  File LV Type Ckp SCN    Ckp Time  Name

  ---- -- ---- ---------- --------- ----
  1       Full 631092     04-NOV-03 /ade/lashdown_rdbms/oracle/dbs
/tbs_01.f





See Also:





Oracle Database Recovery Manager Reference for listObj
List syntax

 Oracle Database Recovery Manager Reference for an explanation of the various columns in the LIST output











Listing Database Incarnations

 
Each tim
e an OPEN RESETLOGS operation is performed on a database, this operation creates a new incarnation of the d
atabase. Database incarnations and their effect upon database recovery with RMAN are explained in more detail in Oracle Database Backup and Recovery Advanced User'
s Guide.
 
When performing incremental backups, RMAN can use a backup from a previou
s incarnation or the current incarnation as a basis for subsequent incremental backups. When performing restore and recovery, RMAN ca
n use backups from a previous incarnation in restore and recovery operations just as it would use backups from the current incarnatio
n, as long as all archived logs are available.
 
Use the LIST INCARNATION<
/code> command to see the incarnations of your database.

 
To list datab
ase incarnations:
 
After connecting to the target database and the recovery catalog
 if applicable, run LIST INCARNATION:
RMAN> LIST INCARNATION;




If you are using a recovery catalog, and if you register multiple
 target databases in the same catalog, then you can distinguish them by using the OF DATABASE option:
<
pre class="CE">RMAN> LIST INCARNATION OF DATABASE prod3;

Refer to Orac le Database Recovery Manager Reference for an explanation of the various column headings in the LIST output). S ample output follows:

RMAN> LIST INCARNATION OF DATABASE;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset
 Time
------- ------- -------- ---------------- ------  ---------- ----------
1       1
     RDBMS    774627068        PARENT  1          21-OCT-03
2       2       RDBMS    774627068        CURRENT 1
73832     21-OCT-03

The preceding output indicates that a R ESETLOGS was performed on database trgt at SCN 164378, resulting in a new incarnation. The incarnation is disting uished by incarnation key (represented in the Inc Key column).

Reporting on Backups and Database Schema

This section contains the following topics:

• About RMAN Reports
• Reporting on Objects Needing a Backup
• Reporting Obsolete Backups
• Reporting on the Database Schema

About RMAN Reports

To gain more detailed information from the RMAN repository, generate a report. The REPORT command can help answer questi ons such as the following:

• Which files need a backup?
• Which files have had unrecoverable operations performed on them?
• Which backups are obsolete and can be deleted?
• < /a>What was the physical schema of the database at some previous time?
• Which f iles have not been backed up recently?

  Note: For the report to be accurate, the RMAN repository must be synchronized with the control file and you m ust have run the CHANGE, UNCATALOG, and CROSSCHECK commands recently to update the status of a ll backups. .

  See Also: Chapter 6, "Recovery Manager Maintenance Tasks" t o learn how to maintain the RMAN repository.

The information that you obtain from reports can be important for your backup and recovery strategy. In particular, run the REPORT NEED BACKUP and REPORT UNRECOVERABLE commands to ens ure that the backups are available to perform recovery, and recovery can be performed within a reasonable length of time.

Reporting on Objects Needing a Backup

You can report on files that require a backup by s pecifying the NEED BACKUP keyword. The REDUNDANCY parameter specifies the minimum number of ba ckups that must exist for a datafile to be considered not in need of a backup. If you do not specify the parameter, REDUNDANCY< /code> defaults to 1. The DAYS parameter indicates that recovery must begin by using logs more than integer days old. The INCREMENTAL parameter indicates that more than integer increm ental backups are required for complete recovery.

Note: If you disable the retention policy, then REPORT NEED BACKUP with no other options generates an error message.

To report on files that need a backup:

1. After connecting to the target database and recovery catalog (if you use one), run CROSSCHECK commands as needed to verify the status and availability of backups known to RMAN. If files have been deleted, th e RMAN repository will be out of date. This sequence of commands would crosscheck disk image copies, backupsets, and tape and proxy b ackups:

   # allocate maintenance channel for crosscheck if no channels configured
   ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
   CROSSCHECK BACKUP;  # crosschecks backup sets and pr
   oxy copies
   
   

2. This sequence of commands wou ld crosscheck disk image copies only:

   CROSSCHECK COPY;    # crosschecks only disk copies of 
                       # archived redo logs, datafiles and control file
   
   

3. If you have a retention policy configured, then you can just run REPORT NEED BACKUP without any other options to determine which files need backups (sample output follows):

   REPORT NEED BACKUP; RMAN retention policy will be a pplied to the command RMAN retention policy is set to redundancy 1 Report of files with l ess than 1 redundant backups File #bkps Name ---- ----- --------------------------------- -------------------- 2 0 /oracle/oradata/trgt/undotbs01.dbf

4. To override the retention policy (or if you do not have a retention policy enabled), run REPORT NEED BACKUP DAYS. Any files older than the DAYS paramete r value need a new backup because their backups require the specified number of DAYS worth of archived logs for recovery . For example, run:

   REPORT NEED BACKUP DAYS = 7 DATABASE;  # needs min 7 days of logs to reco
   ver
   REPORT NEED BACKUP DAYS = 30 TABLESPACE SYSTEM;
   REPORT NEED BACKUP DAYS = 14 DATAFILE
    'ora_home/oradata/trgt/tools01.dbf';
   
   

5. To determine which files need an incremental backup, specify the INCREMENTAL parameter. If complet e recovery of a datafile requires more than the specified number of incremental backups, then RMAN considers it in need of a new back up. For example, enter:

   REPORT NEED BACKUP INCREMENTAL = 1 DATABASE; 
   R
   EPORT NEED BACKUP INCREMENTAL = 3 TABLESPACE SYSTEM;
   REPORT NEED BACKUP INCREMENTAL = 5 DATAFILE 'ora_
   home/oradata/trgt/users01.dbf';
   

   See Also: Oracle Database Recovery Manager Reference for an explanation of the variou s column headings in the REPORT output

Reporting Obsolete Backups

You can report files that are obsolete, that is, superfluous, by specifying the OBSOLETE keyword. If you do not specify any other options, then REPORT OBSOLETE displays the backups that are m arked obsolete by the current retention policy. By default, the retention policy is configured to REDUNDANCY of 1< /code>.

The REPORT OBSOLETE command supports the RECOVERY WINDOW and REDUNDANCY options at the command level, which have the same meanings as the options with the same names on the CONFIGURE command.

Note: As an alternative to running REPORT OBSOLE TE, you can query the V$BACKUP_FILES view and check the OBSOLETE column.

< /div>

To report obsolete backups:

< li class="LN1" type="1" value="1">After connecting to the target database and recovery catalog (if you use one) , issue CROSSCHECK commands as needed to update the status of backups. Following is a possible crosscheck session:

# allocate maintenance channel for crosscheck if no channels configured
ALLO
CATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; # checks only on tape
CROSSCHECK BACKUP;  # crosschecks backup se
ts and proxy copies on tape
RELEASE CHANNEL;

2. Use the OBSOLETE option to identify which backups are obsolete because they are no longer nee ded for recovery. For example, enter:

   # lists backups that not needed to recover the database
    to within last week
   REPORT OBSOLETE RECOVERY WINDOW OF 7 DAYS; 
   # lists backups that are
    superfluous because more than 2 copies are on tape
   REPORT OBSOLETE REDUNDANCY = 2 DEVICE TYPE sbt;
   
   

3. Use the ORPHAN option to list unusable backups belonging to an incarnation that is not a direct predecessor of the current incarnation. For example, enter:

   REPORT OBSOLETE ORPHAN;
   
   

4. Optionally, delete obsolete backups. You can automatically delete obsolete backups by issuing DELETE OBSO LETE. For example, you can enter:

   # delete obsolete backups displayed when you issue R
   EPORT OBSOLETE
   DELETE OBSOLETE;
   # delete obsolete backups according to a specified recove
   ry window
   DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS;
   # delete obsolete backups according
   to a specified redundancy
   DELETE OBSOLETE REDUNDANCY = 2;
   
   

   RMAN prompts for confirmation before actually deleting the files. To suppress the prompt, specify the NOPROMPT< /code> option. Specify FORCE to delete the files and remove their repository records regardless of whether the files exi st.

   See Also: "Reporting Obsolete Bac kups" for a conceptual overview of reports of obsolete backups "Configuring the Backup Retention Policy" for a c onceptual overview

Reporting on the Database Schema

Issue REPORT SCHEMA to list the database files. If you use a recovery catalog, then you also generate historical reports of the database schema at a past time. You do not need a recovery catalog, however, to report the curren t schema.

To report the database schema at a specified point in time:< /strong>

1. After connecting to the target databa se and recovery catalog (if you use one), issue REPORT SCHEMA:

   REPO
   RT SCHEMA;
   
   

   If you use a recovery catalog, then you can use the < em>atClause to specify a past time, SCN, or log sequence number:

   REPORT
   SCHEMA AT TIME 'SYSDATE-14';     # schema as it was two weeks ago
   REPORT SCHEMA AT SCN 1000;              # sch
   ema as it was at scn 1000
   REPORT SCHEMA AT SEQUENCE 100 THREAD 1; # schema as it was at sequence 100
   
   

2. Examine the report. For example, here is a sample output:

   REPORT SCHEMA AT SCN 1000;
   
   Report of dat
   abase schema
   File K-bytes Tablespace           RB segs Datafile Name
   ---- ------- -------
   ------------- ------- -------------------
   1     307200 SYSTEM               YES     /oracle/oradata/trgt/system
   01.dbf
   2      20480 UNDOTBS              YES     /oracle/oradata/trgt/undotbs01.dbf
   5
     10240 EXAMPLE              NO      /oracle/oradata/trgt/example01.dbf
   6      10240 INDX                 NO
      /oracle/oradata/trgt/indx01.dbf
   7      10240 TOOLS                NO      /oracle/oradata/trgt/tools01.dbf
   <
   a name="1009172">8      10240 USERS                NO      /oracle/oradata/trgt/users01.dbf
   

---

Previous Next

Copyright © 2003 Oracle Corporation All Rights Reserved.

Home Book List Contents Index Master Index Feedback