2
RMAN Backups Concepts

Figure 2-2 Datafile Multiplexing

Text description of the illustration bradv02 2.gif

Algorithm for Multiplexed Backups

RMAN multiplexing is determined b y the following algorithm:

1. The number of files in each backup set is determined by computing the lesser of the following values:
   • The default number of files in a backup set (16 for archived logs, and 4 fo r datafiles)
   • The number of files read by each channel.
2. The level of multiplexing is determined by t he lesser of the following values:
   • The number of files in the b ackup set (as calculated by the preceding step)
   • The default number of files that RMAN reads simultaneously on a single channel (8 files for each channel)

Assume that you are backing up twelve datafiles with one RMAN channel. The number of files in each backup set is 4. To determine t he level of multiplexing, compare this value to 8 and take the lesser, which is 4. Because the level of multiplexing is 4, the channe l includes blocks from four separate datafiles into each backup set.

Multiplexing by the Media Manager

Manual Parallelization of Backups

When you configure PARALLELISM to greater than 1 or manually allocate multipl e channels, RMAN writes multiple backups sets or image copies in parallel. The channels divide the work of backing up the specified f iles.

By default, RMAN determines which channels should back up which database files. You can use the CHANN EL option of the BACKUP command to manually assign a channel to back up specified files. This example shows a par allelized backup to the default disk location that uses the default automatic DISK channels:

BACKUP
  (DATAFILE 1,2,3 
   CHANNEL ORA_DISK_1)
  (
DATAFILECOPY '/tmp/system01.dbf', '/tmp/tools01.dbf'
   CHANNEL ORA_DISK_2)
  (ARCHIVELOG
 FROM SEQUENCE 100 UNTIL SEQUENCE 102 THREAD 1 
   CHANNEL ORA_DISK_3);

You can also manually allocate channels as in the following example:

RUN 
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server
1)";
  ALLOCATE CHANNEL c2 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server2)";
  AL
LOCATE CHANNEL c3 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server3)";
  BACKUP
   (
DATAFILE 1,2,3
    CHANNEL c1)
   (DATAFILECOPY '/tmp/system01.dbf', '/tmp/tools01.dbf'
<
a name="1007021">     CHANNEL c2)
   (ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 102 THREAD 1
     CHANNEL c3);
}

Figure 2-3 shows an example of parallelization in which channel ch1 backs up datafiles, chann el ch2 backs up datafile copies, and channel ch3 backs up logs.

Figure 2-3 Parallelization of Backups

Text description of the illustratio n bradv024.gif

Multiple Copies of RMAN Backups

In RMAN, there are two ways to make multiple, identical copies of backups:

• Duplex your backups within the BACKUP AS BACKUPSET command, in which case RMAN creates more than one copy of each backup set
• Back up your files as backup sets or image copies, and then back up the backup sets or image copies using the R MAN BACKUP BACKUPSET or BACKUP COPY commands.

Duplexed Backup Sets

When backing up datafiles, archived redo log files, server parameter files and control files into backup pieces , RMAN can duplex the backup set, producing up to four identical copies of each backup piece in the bac kup set on different backup destinations with one BACKUP command. (Note that duplexing is not supported for backup opera tions that produce image copies.)

There are three ways to specify duplexing of backup sets when using the BACKUP command:

• Specify a default level of duplexing with CONFIGURE... BACKUP COPIES

  All backup commands that back up data into backup sets will be affected if you use this option, unless you specify differe nt duplexing options for a command using SET BACKUP COPIES or provide a COPIES option for the BACKUP< /code> command.

• Use SET BACKUP COPIES in a RUN block

  All commands in the RUN block will be affected, overriding any CONFIGURE ... BACKUP COPIES setting, except those where you provide a COPIES option as part of th e BACKUP command.

• Provide a COPIES option to the BACKUP command

  For this specific BACKUP command, files will be duplex ed to produce the number of copies you specify.

The FORMAT option of the BACKUP command specifies the destinations to be used when performing duplexed backups. You c an specify up to 4 values for the FORMAT option. RMAN uses the second, third, and fourth values only when BACKUP COPIES, SET BACKUP COPIES, or CONFIGURE ... BACKUP COPIES is specified. The following example creates 3 copies of the backup of datafile 7:

BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7 FORMAT 
'/tmp/%U','?/oradata/%U','?/%U';

RMAN places the first copy of each backup piece in /tmp, the second in ?/oradata, and the third in the Oracle home. Note that RMAN does not produce 3 backup sets, each with a different unique ba ckup set key. Rather, RMAN produces one backup set with a unique key, and generates 3 identical copies of each backup piece in the se t, as shown in this sample LIST output:

List of Backup Sets

===================

BS Key  Type LV Size
------- ---- -- -----
-----
1       Full    64K
  List of Datafiles in backup set 1
  Fil
e LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  7       Fu
ll 98410      08-FEB-03 /oracle/oradata/trgt/tools01.dbf

  Backup Set Copy #1 of backup
set 1
  Device Type Elapsed Time Completion Time Tag
  ----------- ------------ ---------
------ ---
  DISK        00:00:01     08-FEB-03       TAG20030208T152314

    List of Backup Pieces for backup set 1 Copy #1
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    1       1   AVAILABLE   /tmp/01dg9tb2_1_1


  Backup Set Copy #2 of backup set 1
  Device Type Elapsed Time Completion Time Tag
  ----------- ------------ --------------- ---
  DISK        00:00:01     08-FEB-03
 TAG20030208T152314

    List of Backup Pieces for backup set 1 Copy #2
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    2
      1   AVAILABLE   /oracle/oradata/01dg9tb2_1_2

  Backup Set Copy #3 of backup set 1
  Device Type Elapsed Time Completion Time Tag
  ----------- ------------ ---------------
 ---
  DISK        00:00:01     08-FEB-03       TAG20030208T152314

    List of Backup Pieces for backup set 1 Copy #3
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    3       1   AVAILABLE   /oracle/01dg9tb2_1_3

When choosing which FORMAT value to use for each backup piece, RMAN uses the first format value for copy number 1, the second format value for copy number 2, and so forth. If the number of format values exc eeds the number of copies, then the extra formats are not used. If the number of format values is less than the number of copies, the n RMAN reuses the format values, starting with the first one.

See Also: "Duplexing Backup Sets" to learn how to duplex backups< /li> Oracle Database Recovery Manager Reference for CONFIGURE syntax Oracle Database Recovery Manager Reference for SET syntax

Backups of Backup Sets

The RMAN BACKUP BACKUPSET command backs up previously created b ackup sets. Only backup sets that were created on device type DISK can be backed up, and they can be backed up to any available devic e type.

Note: RMAN issues an error if you attempt to run BACKUP AS COPY BACKUPSET.

The BACKUP BACKUPSET command uses the default di sk channel to copy backup sets from disk to disk. To back up from disk to tape, you must either configure or manually allocate a non- disk channel.

Uses for Backups of Backup Sets

The BACKUP BACKUPSET command is a useful way to spread backups among multiple media. For example, you can execute the following BACKUP com mand weekly as part of the production backup schedule:

# makes backup sets on disk
BACKUP DEVICE TYPE DISK AS BACKUPSET DATABASE PLUS ARCHIVELOG; 
BACKUP DEVICE TYPE sbt BACKUPSET
ALL; # copies backup sets on disk to tape

Note: Backups to sbt that use automatic channels require that y ou first run the CONFIGURE DEVICE TYPE sbt command.

In this way, you ensure that all your backups exist on both disk and tape. You can also dup lex backups of backup sets, as in this example:

BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET A
LL;

(Again, control file autobackups are never duplexed.)

You can also use BACKUP BACKUPSET to manage backup space allocation. For example, to keep more recent backups on disk and older backups only on tape, you can regularly run the following command:

BACKUP DEVICE TYPE sbt BACKUPSET COMPLETED BEFORE 'SYSDATE-7' DELETE INPUT;

This command backs up backup sets that were created more than a week ago from disk to tape, and then de letes them from disk. Note that DELETE INPUT here is equivalent to DELETE ALL INPUT;RMAN deletes all existing copies of the backup set. If you duplexed a backup to four locations, then RMAN deletes all four copies of the pieces in the backup set.

Backup Optimization When Backing Up Backup Sets

If backup optimization is enabled when you issue the command to back up a back up set, and if the identical backup set has already been backed up to the same device type, then RMAN skips the backup of this backup set. For example, when backup optimization is turned on, the following command backs up to tape only those backup sets not already b acked up on device type sbt:

BACKUP DEVICE TYPE sbt BACKUPSET ALL;

Backup Failover W hen Backing Up Backup Sets

When backing up backup sets, if RMAN disc overs that one copy of a backup set is corrupted or missing, then it searches for other copies of the same backup set, based on the R MAN repository records about the backup set. This behavior is similar to the behavior of RMAN when backing up archived redo logs that exist in multiple archiving destinations.

For example, assume that backup set with key 872 contains three backup pieces, and that BACKUP COPIES 3 was issued so that three copies of eac h backup piece were created, each on a different file system. Also assume that some copies have been deleted or corrupted, so that th e following table describes the current status of the backup copies:

< /tr>

3

Backup Piece Number	Copy Number of the Piece	Status of Copy
1	< a name="1013429"> 1	Corrupted
1	2	Intact
1	3	Corrupted
2	1	Missing
2	2	Corrupted
2	Intact
3	1	Inta ct
3	2	Co rrupted
3	3	Missing

The following command will cause RMAN to perform autom atic failover:

BACKUP BACKUPSET 872;

RMAN copies only the backup pieces listed as "Intact" in the preceding table in its backup set.

< /a>

Backups of Image Copies

You can use the following commands to back up image copies of database files either as backup sets or as image copies:

• BACKUP AS COPY
COPY OF DATABASE;
• B ACKUP AS BACKUPSET
COPY OF TABLESPACE;
• < code>BACKUP AS BACKUPSET
COPY OF DATAFILE;

When using these commands, there must already exist an image copy of every datafile specified in the command. If there are mu ltiple copies of a datafile, the latest one is used. RMAN issues an error if image copies of every datafile in the database or tables pace do not exist.

RMAN Backup Options: Naming, Sizing, and Speed

Recovery Manager provides a number of options to control filenames, sizes of backups and speed during backup.

Filenames for Backup Pieces

You can either let RMAN determine a unique name for backup p ieces or use the FORMAT parameter to specify a name. For example, enter:

BACKU
P TABLESPACE users;

RMAN automatically generates unique names for the backup pieces in the default backup location.

The FORMAT parameter provid es substitution variables that you can use to generate unique filenames. For example, you can run a command as follows:

BACKUP TABLESPACE users FORMAT = '/tmp/users_%u%p%c';

< /a>

As described in "Manual Parallelization of Backups", you can specify up to four FORMAT values. RMAN uses the second, third, and fourth values only when you run BACKUP COPIES, SET BACKUP COPIES, or CONFIGURE ... BACKUP COPIES.

Note: If you use a media manager, then check your vendor documentation for r estrictions on FORMAT such as the size of the name, the naming conventions, and so forth.

See Also: Ora cle Database Recovery Manager Reference for descriptions of the FORMAT parameter and the substitution variables

Filenames for Image Copies

FORMAT varia bles are also used to specify the names of image copies. The default format %U is defined differently for image copies t han for backup pieces. RMAN produces image copies of three types of files: datafiles, control files, and archived logs. The following table describes the meaning of %U for each type of file.

Type of File	Meaning of %U
Datafile	data -D-%d_id-%I_TS-%N_FNO-%f_%u
Archived log	arch-D_%d-id-%I_S-%e_T- %h_A-%a_%u
Control file	cf-D_%d-id-%I_%u

When creating image copies (and only image copies), you can also name the output copies with the DB_FILE_NAME_CONVERT option of the BACKUP command. This parameter works identically to the initialization parameter DB_FILE_NAME_CONVERT. Pairs of filename prefixes are provided to change the names of the output files. If a file is not converted by any of the pairs, then RMAN uses the FORMAT specification; if no FORMAT is specified, then RMAN uses the default format %U.

For example, you can ru n the following command to copy the datafiles whose filename is prefixed with /maindisk/oradata/users so that they are p refixed with /backups/users_ts:

BACKUP AS COPY TABLESPACE users
  DB_FILE_NAME_CONVERT=('/maindisk/oradata/users','/backups/users_ts');

Tags for RMAN Backups

You can assign a user-specified character string called a tag to ba ckup sets and image copies (either copies created by RMAN or copies created by an operating system utility). A tag is a symbolic name for a backup set or file copy, such as weekly_backup. You can specify the tag rather than the filename when executing t he RESTORE or CHANGE command. The maximum length of a tag is 30 bytes.

Default RMAN Backup Tag Format

If you do not specify a tag, then RMAN creates a default tag for backups (except f or control file autobackups) in the format TAGYYYYMMDDTHHMMSS, where YYYY is the year, MM is the month, DD is the day, H H is the hour (in 24-hour format), MM is the minutes, and SS is the seconds. For example, a backup of datafile 1 may receive the tag TAG20030208T133437. The date and time refer to when RMAN started the backup, in the time zone of the instance performing the backup. If multiple backup sets are created by one BA CKUP command, then each backup piece is assigned the same default tag.

How Tags Are Applied

When applied to a backup set, a tag applies to a specific copy of the backup set. If you do not duplex a backup set, that is, make multiple identical copies of it, then the backup set has just one tag. For example,

BACKUP COPIES 1 DATAFILE 7 TAG foo 

creates one back up set with tag FOO. Tags are stored in uppercase, regardless of the case used when entering them. However, you can back up this backup set and give this new copy of the backup set the tag BAR. So, the backup set has two identical copies: o ne tagged FOO and the other tagged BAR.

When applied to image cop ies, a tag applies to each individual image copy. For example, you run the following command:

<
/a># Back up as image copies the datafiles of tablespaces users and tools
# all copies get the TAG 'users-tools
'
BACKUP AS COPY TAG users-tools TABLESPACE users, tools;

You can also copy an image copy with a specific tag, and give the output copy a different tag, as in the following exa mple:

# Create new copies of all image copies of the database that have the tag 
# 'full_cold_copy', and give the new copies the tag 'new_full_cold_copy'
BACKUP AS COPY 
  COPY OF DATABASE 
    FROM TAG=full_cold_copy 
    TAG=new_full_cold_copy;

# Create backup sets of the image copy of tablespace users that has the tag
# 'monday_users', and of tablespace SYSTEM which has the tag 'monday_system'.
# All these new backup
# sets receive the tag 'for_audit'.
BACKUP AS BACKUPSET TAG for_audit 
  COPY OF TABLESPA
CE users FROM TAG monday_users 
    TABLESPACE SYSTEM FROM TAG monday_system;

Uniqueness of Backup Tags

< !--/TOC=h3-->

Tags do not need to be unique, so multiple backup sets or image copies can have t he same tag, for example, weekly_backup. When you specify that a datafile should be restored from backups that have a sp ecific tag, and more than one backup of the requested file has the desired tag, RMAN restores the most recent backup that has the des ired tag (within any other constraints of the restore command, of course, such as a point in time).

Tags can indicate the intended purpose or usage of different classes of backups or copies. For example, datafile copies that are suitable for use in a SWITCH can be tagged differently (for_switch_only) from file copies that should be used only for RESTORE (for_restore_only).

Note: If you specify the F ROM tag option to the RESTORE or SWITCH command, then RMAN considers only ba ckup sets and image copies with a matching tag when choosing which backup to use

< /a>

S ize of Backup Pieces

RMAN will, by default, put the entire contents of a backup set into one backup piece, regardless of the size of the backup set. If you are backing up to a file system or media mana ger that has a limit on the maximum file size that can be created, then you may need to restrict the size of backup pieces that RMAN will create.To restrict the size of each backup piece, specify the MAXPIECESIZE option of the CONFIGURE CHANNEL or ALLOCATE CHANNEL commands. This option limits backup piece size to the specified umber of bytes. If the total si ze of the backup set is greater than the specified backup piece size, then multiple physical pieces will be created to hold the backu p set contents.

For example, if datafile 1 is 6GB, you can still restrict the backup piece size for disk backups to 2 GB by configuring an automatic disk channel, and then run a backup as follows:

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 2G;
BACKUP AS BACKUPSET DATAFILE 1;

A LIST BACKUP command reveals that RMAN created five backup pi eces rather than one backup piece to conform to the MAXPIECESIZE size restriction:

BS Key  Type LV Size       Device Type Elapsed Time Completion Time     
------- ---- -- ---------- ------
----- ------------ --------------------
29      Full    9728M      DISK        00:00:35     NOV 02 2002 18:29:2
6
  List of Datafiles in backup set 29
  File LV Type Ckp SCN    Ckp Time             Nam
e
  ---- -- ---- ---------- -------------------- ----
  1       Full 177590     NOV 02 20
02 18:28:51 /oracle/oradata/trgt/system01.dbf

  Backup Set Copy #1 of backup set 29
  Device Type Elapsed Time Completion Time      Tag
  ----------- ------------ --------------
------ ---
  DISK        00:00:35     NOV 02 2002 18:29:26 TAG20021102T152701

    List of Backup Pieces for backup set 29 Copy #1
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    53      1   AVAILABLE   /oracle/dbs/10d85733_1_1
    54      2   AVAILABLE   /oracle/dbs/10d85733_2_1
    55      3   AVAILABLE   /oracle/dbs/1
0d85733_3_1
    56      4   AVAILABLE   /oracle/dbs/10d85733_4_1
    57      5   AVAILABL
E   /oracle/dbs/10d85733_5_1

This option can be used for media ma nagers that cannot manage a backup piece that spans more than one tape. For example, if a tape can hold 10GB, but the backup set bein g created must hold 80GB of data, then RMAN must be instructed to create backup pieces of 10GB, small enough to fit on the tapes used with the media manager. The backup set media will in this case consist of eight tapes. Media managers supporting SBT2.0 can return a value to RMAN indicating the largest supported backup piece size, which RMAN will use in planning backup activities.

See Also: Oracle Database Recovery Manager Reference for SWITCH syntax, and Oracle Database Recovery Manager Reference for RESTORE syntax

< a name="1007514">See Also: < ul class="NL"> Oracle Database Recovery Manager Reference for ALLOCATE CHANNEL s yntax Oracle Database Recovery Manager Reference for CONFIGURE syntax

Number and Size of Backup Sets

Use the backupSpec clause of the BACKUP command to specify the objects that you want to back up as well as specify other options. E ach backupSpec clause produces at least one backup set. The total number and size of backup sets depends for th e most part on an internal RMAN algorithm, although you can tune RMAN behavior to a certain extent with the MAXSETSIZE p arameter.

Factors Affecting the Number and Size of Backup Sets

In determining the characteristics of the RMAN backup sets, the internal algorithm is influenced by the following factors:

• The number of input files specified in each backupSpec clause
• The number of channels that you allocate
• The default number of files in each backup set (4 for datafiles and 16 for archived logs)
• The default number of files read simultaneously by a single channel (8)
• The MAXSETSIZE parameter (specified on the CONFIGURE and BACKUP commands ), which specifies a maximum backup set size

The most important rules in the algorith m for backup set creation are:

• Each allocated channel that per forms work in the backup job--that is, each channel that is not idle--generates at least one backup set.

  Note: RMAN wr ites backup pieces sequentially; striping a backup piece across multiple output devices is not supported. For example, RMAN does not simultaneously write half of a backup piece to one device and the other half to another device, nor can it write the first piece of a backup set to one device andthe second piece to another device.

• RMAN always tries to divide the backup load so that all allocated channels have roughly the same amount of work t o do.
• The default number of datafiles in each backup set is determined by an i nternal RMAN limit (16 for archived logs, 4 for datafiles).
• The number of data files multiplexed in a backup set is limited by the lesser of the number of files in each backup set and the default number of files read by a single channel simultaneously (8).
• The maximum size of a backup set is determined by the MAXSETSIZE parameter of the CONFIGURE or BACKUP command.

  See Also: Oracle Database Recovery Manager Reference to learn the syntax for the backupSpec clause, and Chapter 14, "Tuning Backup and Recovery" to learn about RMAN buffer management

Overview of the MAXSETSIZE Parameter

To specify the maximum size of each backup set, use the MAXSETSIZE parameter in the CONFIGURE or BACKUP command. By limiting the overall size of the backup set, the parameter indirectly limits the number of files in the set and can possibly force RMAN to create addition al backup sets.

Specifying MAXSETSIZE: Example

Assume that you want to back u p 50 datafiles, each containing 1000 blocks. To set the maximum size of each backup set to 10 MB, use the following command:

BACKUP DATABASE MAXSETSIZE = 10M;

Caution: If a datafile being backed up is bigger than MAXSETSIZE then your backup will fail. Always ensure that MAXSETSIZE is as large as your largest datafile.

See Also: Orac le Database Recovery Manager Reference for information on the MAXSETSIZE parameter

I/O Read Rate of Backups

By default, RMAN uses all available I/O bandwidth to rea d/write to disk. You can limit the I/O resources consumed by a backup job with the RATE option of the ALLOCATE CHANNEL or CONFIGURE CHANNEL commands. The RATE option specifies the maximum number of bytes for each second that RMAN reads on the channel.

For example, you can config ure automatic channels to limit each channel to read 1 MB a second:

CONFIGURE DEVICE TYPE s
bt PARALLELISM 2;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL DEVICE TYPE sbt
 RATE 1M;

In effect, the RATE option throttles RMAN so that a backup job does not consume excessive I/O bandwidth on the computer.

See Also:

"Tuning RMAN Backup Performance: Examples" for tips about how to optimize RMAN performanc e

RMAN Backup Types

As explain ed in Table 2-1, RMAN backups can be classified in these ways:

• Full or incremental
• Open or closed
• Consistent or inconsistent

Note that these backup classifications apply only to datafile backups. Backups of other files, such as archivelogs and control files, alwa ys include the complete file and are never inconsistent.

Table 2-1 Backup Types

Backup Typ e	Definition
Full	A backup that in cludes every block in the file being backed up, except never-used blocks omitted due to unused block compression. A full backup canno t be part of an incremental backup strategy; it cannot be the parent for a subsequent incremental backup < p class="TB">Note: A full backup is different from a whole database backup , which is a backup of all datafiles and the current control file.
Incremental	An incremental backup is either a level 0 backup, which includes every block in the file except blocks compressed out because th ey have never been used, or a level 1 backup, which includes only those blocks that have been changed since the parent backup was tak en. A level 0 incremental backup is physically identical to a full backup. The only difference is that the level 0 backup can be used as the parent for a level 1 backup, but a full backup will never be used as the parent for a level 1 backup.
Open	A backup of online, read/write datafiles when the database is open.
Closed	A backup of any part of the target database when it is mounted but not open. Closed backups can be consistent or inconsistent.
Consistent	A backup taken when the database is mounted (but not o pen) after a normal shutdown. The checkpoint SCNs in the datafile headers match the header information in the control file. None of t he datafiles has changes beyond its checkpoint. Consistent backups can be restored without recovery. Note: If you restore a consistent backup and open the database in read/write mode without reco very, transactions after the backup are lost. You still need to perform an OPEN RESETLOGS.
Inconsistent	A backup of any part of the target database when it is open or when a crash occurred or SHUTD OWN ABORT was run prior to mounting. An inconsistent backup requires rec overy to become consistent.

Incremental Backups

The goal of an incremental backup is to back up only those data blocks that have changed since a previous backup. You can use RMAN to cr eate incremental backups of datafiles, tablespaces, or the whole database.

During media rec overy, RMAN examines the restored files to determine whether it can recover them with an incremental backup. If it has a choice, then RMAN always chooses incremental backups over archived logs, as applying changes at a block level is faster than reapplying individua l changes.

RMAN does not need to restore a base incremental backup of a datafile in order t o apply incremental backups to the datafile during recovery. For example, you can restore non-incremental image copies of the datafil es in the database, and RMAN can recover them with incremental backups.

Incremental backups allow faster daily backups, use less network bandwidth when backing up over a network, and provide better performance when tape I/O bandwidth limits backup performance. They also allow recovery of database changes not reflected in the redo logs, such as direct load inserts. Finally, incremental backups can be used to back up NOARCHIVELOG databases, and are smaller than complete copi es of the database (though they still require a clean database shutdown).

One effective str ategy is to make incremental backups to disk (as image copies), and then back up these image copies to a media manager with BAC KUP AS BACKUPSET. Then, you do not have the problem of keeping the tape streaming that sometimes occ urs 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 dataf ile contains a system change number (SCN), which is the SCN at which the most recent change was made to the block. During an incremen tal backup, RMAN reads the SCN of each data block in the input file and compares it to the checkpoint SCN of the parent incremental b ackup. (If block change tracking is enabled, RMAN does not read the portions of the file known to have not changed since the parent i ncremental 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 block.

One consequence of this mechanism is that RMAN applies all blocks containing ch anged data during recovery--even if the change is to an object created with the NOLOGGING option. Hence, making incremen tal backups is a safeguard against the loss of changes made by NOLOGGING operations.

See Also: Oracle Database Concepts for more information a bout NOLOGGING mode

Multilevel Incremental Backups

RMAN can create multilevel incremental backups. Each incremental level is denoted by a value of 0 or 1. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an increm ental strategy.

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

• A differential backup, which bac ks up all blocks changed after the most recent incremental backup at level 1 or 0
• A cumulative backup, which backs up all blocks changed after the most recent incremental ba ckup at level 0

Incremental backups are differential by default.

Note: Cu mulative backups are preferable to differential backups when recovery time is more important than disk space, because fewer increment al backups need to be applied during recovery.

The size of the backup file depends solely upon 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 sin ce the most recent incremental backup at level 1 (cumulative or differential) or level 0. For example, in a differential level 1 back up, RMAN determines which level 1 backup occurred most recently and backs up all blocks modified after that backup. If no level 1 is available, RMAN copies all blocks changed since the base level 0 backup.

If no level 0 back up is available, then the behavior varies with the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all block s that have been changed since the file was created. Otherwise, RMAN behaves as it did in previous releases, by generating a level 0 backup.

Figure 2-4 Differential Incremental Backups

Text description of the illustration bradv017.gif

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

• Sunday

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

• Mon day - Saturday

  On each day from Monday through Saturday, a differential incremental lev el 1 backup backs up all blocks that have changed since the most recent incremental backup at level 1 or 0. The Monday backup copies blocks changed since Sunday level 0 backup, the Tuesday backup copies blocks changed since the Monday level 1 backup, and so forth.

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 incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular level. Cumulative backups require more space and time than differential backups, however, because they duplicate the work done by previous backups at the same level.

Figure 2-5 Cumulative Incremental Backups

Text description of the illustration bradv018.gif

In the example shown in Figure 2-5, the following occurs each week:

• Sunday

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

• Monday - Saturday

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

Planning an Incremental Backup Strategy

Choose a backup scheme according to an acceptable MTTR (mean time to recover). For example, you can implement a t hree-level backup 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 wh enever 20% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of y our 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#, INC
REMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS 
  FROM V$BACKUP_DATAFILE 
  WHE
RE INCREMENTAL_LEVEL > 0 
  AND BLOCKS / DATAFILE_BLOCKS > .5 
  ORDER BY COMPLETIO
N_TIME;

Compare the number of blocks in differential or cumulativ e backups to a base level 0 backup. For example, if you only create level 1 cumulative backups, then take a new level 0 backup when t he most recent level 1 backup is about half of the size of the base level 0 backup.

See Also: Oracle Database Backup and Recovery Basics to learn how make incremental backups

Control File and Server Parameter File Autobackups

How RMAN Performs C ontrol File Autobackups

The first channel allocated during the backu p job creates the autobackup and places it into its own backup set; for autobackups after database structural changes, the default di sk channel makes the backup. If a server parameter file is used, it is backed up in the same backup set as the control file during a control file autobackup.

After the control file autobackup completes, the database writes a message containing the complete path of the backup piece and the device type to the alert log.

The RMAN behavior when the BACKUP command includes datafile 1 depends on the CONFIGURE CONTROLFILE AUTOBACKUP setting. If control file autobackups are ON and the backup includes datafile 1, RMAN w rites the control file and SPFILE to a separate autobackup backup set. If control file autobackups are OFF and the backup includes da tafile 1, then RMAN includes the current control file and SPFILE in the same backup set as the datafiles.

The control file autobackup filename has a default format of %F for all device typ es, so that RMAN can guess the file location and restore it without a repository. The substitution variable %F is define d in the description of the CONFIGURE command in Oracle Database Backup and Recovery Basics. You can specify a different format with the CON FIGURE CONTROLFILE AUTOBACKUP FORMAT command. All autobackup formats must include the < code>%F variable.

The SET CONTROLFILE AUTOBACKUP FORMAT command, which you can specify either within a RUN block or at the RMAN prompt, overrides the co nfigured autobackup format in the session only. The order of precedence is:

1. SET within a RUN block
2. SET at RMAN prompt
3. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT

You can con figure the autobackup format even when CONFIGURE CONTROLFILE AUTOBACKUP is set to OFF, but RMAN does not generate autobackups in this case. For RMAN to make autobackups, you must set CONFIGURE CO NTROLFILE AUTOBACKUP to ON.

See Also: Oracle Database Recover y Manager Reference for BACKUP syntax Oracle Database Recovery Manager Referencefor RESTORE syntax

When RMAN Performs Control File Autobackups

By default, control file autobackups are turned off, and no control file autobackups are performed. If CONFIGURE CONTROLFILE AUTOBACKUP is ON, then RMAN automatically backs up the con trol file and the current server parameter file (if used to start up the database) in one of two circumstances: when a successful bac kup must be recorded in the RMAN repository, and when a structural change to the database affects the contents of the control file wh ich therefore must be backed up.

Control File Autobackups After Backup Acivities

This means that the control file is backed up in the following situations:

• After every BACKUP command issued at the RMAN prompt.
• At the end of a RUN block, if the last command in the block was BACKUP.
• Whenever a BACKUP command within a RUN block is followed by a command that is not BACKUP.

The first channel allocated during the backup job creates the a utobackup and places it into its own backup set. The control file autobackup may be written to disk or tape.

Control File Autobackups After Da tabase Structural Changes

The control file is also automatically bac ked up after database structural changes such as adding a new tablespace, altering the state of a tablespace or datafile (for example , bringing it online), adding a new online redo log, renaming a file, adding a new redo thread, and so on. Losing this information wo uld compromise your ability to recover the database.

This backup is performed by the server process itself, rather than one of the RMAN channels. This type of autobackup, unlike autobackups that occur after a successful back up, is always created on disk. You can use CONFIGURE CONTROLFILE AUTOBACKUP FOR < code>DEVICE TYPE DISK to set the location for this disk based control file autobackup. Note that a f ailure of the automatic control file autobackup after a structural change never causes the associated structural change to fail. For example, if you add a datafile, and if the resulting control file autobackup fails, then the datafile addition is still successful.

Backup Retention Policies

You can use the CONFIGU RE RETENTION POLICY command to create a persistent and automatic backup retention policy. When a backup retention policy is in effect, RMAN con siders backups of datafiles and control files as obsolete, that is, no longer needed for recove ry, according to criteria that you specify in the CONFIGURE command. You can then use the REPORT OBSO LETE command to view obsolete files and DELETE OBSOLETE to delete them.

As you produce backups over time, older backups become obsolete as they are no longer needed to satisfy the retention p olicy. RMAN can identify the obsolete files for you, but it does not automatically delete them. You must use the DELETE OBSOLETE command to delete files that are no longer needed to satisfy the retention policy.

If you have a flash recovery area configured, however, then the database automatically deletes unnecessary files from t he flash recovery area based on its internal disk quota rules. The disk quota rules are distinct from the backup retention policy rul es, but the database will never delete files in violation of the retention policy to satisfy the disk quota.

The term obsolete does not mean the same as expi red. A backup is obsolete when REPORT OBSOLETE or DELETE OBSOLETE determ ines, based on the user-defined retention policy, that it is not needed for recovery. A backup is considered expired only when RMAN p erforms a crosscheck and cannot find the file. In short, obsolete means "not needed," whereas expired means "not found."

From the perspective of a retention policy, a datafile backup is a full or level 0 backup of an individual datafile or control file. It does not matter whether the backup is a datafile ima ge copy, a proxy copy, or part of a backup set. For datafile copies and proxy copies, if RMAN determines that the copy or proxy copy is not needed, then the copy or proxy copy can be deleted. For datafile backups in backup sets, RMAN cannot delete the backup set unt il all of the individual datafile backups within the backup set are obsolete.

Besides affec ting full or level 0 datafile and control file backups, the retention policy affects archived redo logs and level 1 incremental backu ps. First, RMAN decides which datafile and control file backups are obsolete. Then, RMAN considers as obsolete all archived logs and incremental level 1 backups that are not needed to recover the oldest datafile or control file backup that must be retained.

Note: RMAN cannot implement an automatic retention policy if backups are deleted by non-RMAN methods, for example, through the me dia manager's tape retention policy. The media manager should never expire a tape until all RMAN backups on that tape have been remov ed from the media manager's catalog.

There are two mutually ex clusive options for implementing a retention policy: redundancy and recovery windo w. If no retention policy is configured by the user, then the REPORT OBSOLETE and DELETE OBSOLETE commands use a default retention policy of REDUNDANCY 1.

To configure a retent ion policy based on a recovery window, use the following command:

• CONFIGURE RETENTION POLICY TO RECOVERY WINDOW
< /ul>

To configure a retention policy based on redundancy, use the following command:

• CONFIGURE RETENTION POLICY TO REDUNDANCY

You can also disable the retention policy completel y, meaning that RMAN does not consider any backup to be obsolete. To do so, use the following command:

CONFIGURE RETENTION POLICY TO NONE;

Recovery Window

A recovery window is a period of time that begins with the current time and extends backward in time to the point of recoverability. The point of recoverability is the earliest time for a hypothetical point-in-time recovery, that is, the earliest point to which you can recover following a media failure. For example, if you implement a recovery window of one week, then this window of time must extend back exactly seven days from the present so that you can restore a backup and recover it to this poin t. You implement this retention policy as follows:

CONFIGURE RETENTION POLICY TO RECOVERY W
INDOW OF 7 DAYS;

This command ensures that for each datafile one backup that is older than the point of recoverability must be retained. For example, if the recovery window is 7, then t here must always exist one backup of each datafile that satisfies the following condition:

SYSDATE - BACKUP CHECKPOINT TIME >=  7

All backups older than the most recent backup that satisfied this condition are obsolete.

Assume the following ret ention policy illustrated in Figure 2-6. The retention policy has the following aspects:

• The recovery window is 7 days.
• Database backups are scheduled every two weeks on these days:
  • January 1
  • January 15
  • < a name="1008160">January 29
  • February 12
• The database runs in ARCHIVELOG mode, and archived logs are saved on disk only as long as needed for the retention policy.

Fi gure 2-6 Recovery Window, Part 1



Text description of the illustration bradv004.gif

As illustrated in Figure 2-6, the current time is January 23 and the point of recov erability is January 16. Hence, the January 14 backup is needed for recovery, and so are the archived logs from log sequence 500 thro ugh 850. The logs before 500 and the January 1 backup are obsolete because they are not needed for recovery to a point within the win dow.

Assume the same scenario a week later, as depicted in F igure 2-7.

Figure 2-7 Recovery Wind ow, Part 2



Text description of the illustration bradv002.gif

In this scen ario, the current time is January 30 and the point of recoverability is January 23. Note how the January 14 backup is not obsolete even though a more recent backup (January 28) exists in the recovery window. This situation occurs because rest oring the January 28 backup does not enable you to recover to the earliest time in the window, January 23. To ensure recoverability t o any point within the window, you must save the January 14 backup as well as all archived redo logs from log sequence 500 to 1150.

Backup Red undancy

A redundancy-based retention policy specifies how many backu ps of each datafile must be retained. For example, you can specify:

CONFIGURE RETENTION POL
ICY TO REDUNDANCY 2;

Although the recovery window is the best pra ctice for specifying a retention policy, it can complicate disk space usage planning because the number of backups that must be kept by the recovery window is not constant and depends on the backup schedule. Use the CONFIGURE RETENTION POLICY TO REDUNDANCY n command to implement a retention policy that maintain s a constant number of backups of each datafile. RECOVERY WINDOW and REDUNDANCY-based retention policies ar e mutually exclusive.

The default retention policy is REDUNDANCY = 1, to maintain compatibility with the behavior of REPORT OBSOLETE in earlier RMAN releases. You can also run the following command to disable the retention policy altogether:

CONFIGUR
E RETENTION POLICY TO NONE;

If the retention policy is configured to NONE, then REPORT OBSOLETE and DELETE OBSOLETE do not consider a ny backups to be obsolete.

Batch Deletes of Obsolete Backups

Run the RE PORT OBSOLETE command to determine which backups are currently obsolete according to the retention policy.

If you configure the retention policy to NONE, then RMAN does not consider any backups as obsolet e. Consequently, RMAN issues an error when you run REPORT OBSOLETE without any other options and the retent ion policy is set to NONE.

A companion command, DELETE OBSOLETE, deletes all files which are obsolete according to the retention policy. You should run DELETE OBSOLETE peri odically to minimize space wasted by storing obsolete backups. For example, you can run DELETE OBSOLETE in a weekly script.

You can also specify the REDUNDANCY or RECOVERY WINDOW options on the REPORT or DELETE commands, to overrride the configured retention policy.

The REPORT OBSOLETE and DELETE OBSOLETE commands work in two steps:

1. For each datafile for which there are full backup, datafile copy, or level 0 incremental backups, RMAN identifies the oldest full or level 0 backup or copy that is not obsolete under the retention policy being tested. Any full backup, level 0 incremen tal backup, or datafile copy of a datafile older than the one identified in this step is considered obsolete.
2. Any archived logs and level 1 incremental backups that are older than the oldest non-obsolete full backup are then obsolete because there is no full or level 0 backup to which they can be applied.

   See Also: Oracle Database Backup and Recovery Basics to generate reports and delete backups Oracle Database Recovery Manager Reference for DELETE syntax Oracle Database Recovery Manager Referenc e for REPORT syntax

Exempting Backups from the Retention Policy

You may want to store a long-term backup , potentially offsite, for much longer than the time dictated by the retention policy. For example, you may make a database backup on the first day of every year to satisfy some regulatory requirement, independent of backups taken for your ongoing backup and recover y strategy.

Such long-term backups should be recorded in the RMAN repository, but they must be exempted from the retention policy because RMAN would quickly consider them obsolete, and they would be removed the next time the DELETE OBSOLETE command is used.

You can exempt a backup from th e retention policy by using the KEEP option with the BACKUP command when you create the backup, or the KEEP option of the CHANGE command to exempt an existing backup. Note that backups exempted from the retention p olicy are still fully valid backups, which can be used in restore and recovery operations like any other if RMAN judges them to be th e best choice available.

You can change the exempt status of a backup using the CHANG E... KEEP and CHANGE... NOKEEP commands. The NOKEEP option (default) indicates that the backup is no t immune from the configured retention policy.

You can specify the LOGS option to save archived logs for a possible incomplete recovery of the long-term backup. When LOGS is specified, all logs more recent than the backup are kept as long as the backup is kept. In other words, KEEP UNTIL TIME... LOGS mea ns that RMAN will keep all logs required to recover the backup as long as the backup is kept. If you specify NOLOGS, the n RMAN does not keep the logs required to recover the backup. Note that if you use KEEP UNTIL TIME... with an inconsiste nt backup, you must use the LOGS option, or that backup will become unusable when the logs required to recover it are de leted as obsolete.

You can specify an end date using the UNTIL clause, or eith er specify that the backup should be kept FOREVER. If you specify UNTIL, then RMAN will not mark the backup as obsolete until after the UNTIL date has passed. Note that it is an error to specify KEEP FOREVER with t he LOGS option, as this would require keeping all redo logs forever.

The follo wing commands are examples of long-term backups:

# Creates a backup and exempts it from ret
ention policy until last day of 2003
BACKUP DATABASE KEEP UNTIL TIME "TO_DATE('31-DEC-2003', 'dd-mon-yyyy')" NO
LOGS;

# Specifies that backupset 231 is no longer exempt from the retention policy
CHANGE BACKUPSET 231 NOKEEP;

# Creates a backup that is indefinitely ex
empt from the retention policy
BACKUP TABLESPACE users KEEP FOREVER NOLOGS;

See Also: Oracle Database Recovery Manager Reference for CHANGE syntax

Relationship Between Retention Policy and Flash Recovery Area Rules< /font>

The RMAN status OBSOLETE is always determined in refere nce to a retention policy. For example, if a database backup is OBSOLETE in the RMAN repository, it is because it is eit her not needed for recovery to a point within the recovery window, or it is redundant.

If y ou configure a flash recovery area, then the database uses an internal algorithm to delete files from the flash recovery area that ar e no longer needed because they are redundant, orphaned, and so forth. The backups with status OBSOLETE form a subset of the files deemed eligible for deletion by the disk quota rules.

There is one important dif ference between the flash recovery area criteria for OBSOLETE status and the disk quota rules for deletion eligibility. Assume that archived logs 1000 through 2000, which are on disk, are needed for the currently enabled recovery window and so are not o bsolete. If you back up these logs to tape, then the retention policy still considers the disk logs as required, that is, not obsolet e. Nevertheless, the flash recovery area disk quota algorithm considers the logs on disk as eligible for deletion because they have a lready been backed up to tape. The logs on disk do not have OBSOLETE status in the repository, yet are eligible for dele tion by the flash recovery area. Note, though, that the retention policy is never violated when determining which files to delete fro m the flash recovery area.

Backup Optimization

Backup optimization is a feature that avoids creating identical backup copies of files that have not changed since the last time they were b acked up. If you enable backup optimization, then the BACKUP command skips the backup of a file when the identical file has already been backed up to the allocated device type.

Backup Optimization Algorithm

Table 2-3 describes criteria that RMAN uses to determine whether a file is identica l to a file that it already backed up.

Table 2-2 Criteria to Determine an Identical File

< th class="Formal" align="left" valign="bottom" scope="col">T ype of File

Criteria to Determine an Identical File
Datafile	Same DBID, checkpoint SCN, creation SCN, and RESETLOGS SCN and time. The datafile must be off line-normal, read-only, or closed normally.
Archived redo log	Same thread, sequence number, and RESETLOGS SCN and time.
Backup set	Same backup set recid and stamp.

If RMAN determines that a file is identical and it has already been backed up, then it is a candidate to be skipped. However, RMAN must do further checking to determine whether to skip th e file, because both the retention policy and the backup duplexing feature are factors in the algorithm that determines whether RMAN has sufficient backups on the specified device type.

Table&n bsp;2-3 describes the algorithm that backup optimization uses when determining whether to skip the backup of an identical file.

Table 2-3 Backup Optimization Algorithm

For an Identical ...	Back up Optimization Algorithm
Datafile	If you configured a recovery window, then RMAN skips a datafile backup only if the latest backup of a file is earlier than the ea rliest point in the window. In other words, RMAN takes another backup of a file, ignoring any possible optimization, if the latest fi le was backed up longer ago than the recovery window. This is done to allow media to be recycled after the media expires. This is not done for device type DISK. If you did not configure a recovery window, then RMAN sets r=1 by default and searches for values of n in this order of precedence (that is, values higher on the list override values lower on the list): If CONFIGURE RETENTION POLICY TO REDUNDANCY r< /code> is enabled, then RMAN only skips datafiles when n=r+1 backups exist. BACKUP ... COPIES n SET BACKUP COPIES n< /code> CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE ... TO n< /em> RMAN skips backup only if at least n backups of an ident ical file exist on the specified device. If RMAN does not skip the backup, then it makes the backup exactly as specified.
Archived log	By default, n=1. RMAN searches for values of n in this order of precedence (that is, values higher on the list override values lower on the list): BACKUP ... COPIES n SET BACKUP COPIES n CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE ... TO n RMAN skips backup only if at least n backups of an identical file exist on the specified device. If RMAN does not skip the backup, then it makes the backup exactly as sp ecified.
Backup set	By default, n=1. RMAN sear ches for other values of n in this order of precedence (that is, values higher on the list override values lo wer on the list): BACKUP ... COPIES n SET BACK UP COPIES n RMAN skips backup only if at le ast n backups of an identical file exist on the specified device. If RMAN does not skip the backup, then it m akes the backup exactly as specified.

For example, assume that at 9 a.m. you back up three copies of all existing archived logs to tape:

BACKUP DEVICE TYPE
sbt COPIES 3 ARCHIVELOG ALL;

Later, you enable the following conf iguration setting in preparation for another backup:

CONFIGURE ARCHIVELOG BACKUP COPIES FOR
 DEVICE TYPE sbt TO 4;
CONFIGURE BACKUP OPTIMIZATION ON;

Then, you run the following archived log backup at noon:

BACKUP DEVICE TYPE s
bt COPIES 2 ARCHIVELOG ALL;

In this case, the BACKUP ... COPIES setting overrides the CONFIGURE ... COPIES setting, so R MAN sets n=2. RMAN skips the backup of a log only if at least two copies of the log exist on the < code>sbt device. Because three copies of each log exist on sbt of all the logs generated before 9 a.m., RMAN skip s the backups of these logs. However, RMAN backs up two copies of all logs generated after 9 a.m. because these logs have not yet bee n backed up to tape.

At this point, three copies of the logs created before 9 a.m. exist on tape, and two copies of the logs created after 9 a.m. exist on tape. Assume that you run the following backup at 3 p.m.:

RUN
{ 
  SET BACKUP COPIES 3;
  BACK
UP DEVICE TYPE sbt ARCHIVELOG ALL;
}

In thi s case, RMAN sets n=3 and so will not back up the logs created before 9 a.m. because three copies already exist on tape. However, only two copies of the logs created after 9 a.m. exist on tape, so RMAN does not optimize backups of these logs. Hence, RMAN backs up three copies of the logs created after 9 a.m.

Requirements for Enabling and Disabling Backup Optimization

Backup optimization is used when the following conditions are true:

• The CONFIGURE BACKUP OPTIMIZATION ON command has been run.
• You run BACKUP DATABASE, BACKUP ARCHIVELOG with ALL or LIKE options, or BACKUP BACKUPSET ALL.
• Only one type of channel is allo cated, that is, you do not mix channels of type DISK and sbt.

For example, assume that you run these commands:

BACKUP DEVICE TYPE sbt DATABASE PLUS AR
CHIVELOG;
BACKUP DEVICE TYPE sbt BACKUPSET ALL;

If none of these files has changed since the last backup, then RMAN does not back up the files again, nor signal an error if it skips all files specified in the command.

To override backup optimiz ation and back up all files whether or not they have changed, specify the FORCE option on the BACKUP comman d. To disable backup optimization on a persistent basis, use the following command:

RMAN>
; CONFIGURE BACKUP OPTIMIZATION OFF;

Effect of Retention Policies on Backup Optimization

The retention policy influences backup optimization. Because the retention policy defaults to REDUNDANCY=1, a retention policy is always in place unless it is explicitly disabled with CONFIGURE RETENTION P OLICY TO NONE.

Note: Use caution when enabling backup optimization if you use a media ma nager with its own internal expiration policy. Run CROSSCHECK periodically to synchronize the RMAN repository with the m edia manager. Otherwise, RMAN may skip backups due to optimization without recognizing that the media manager has discarded backups s tored on tape.

Backup Optimization and a Recovery Window

If optimization is enabled, and if a recovery window retention policy is in effect, then RMAN always backs up datafiles whos e most recent backup is older than the recovery window. For example, assume that:

• Today is February 21.
• The recovery window is 7 days.
• The most recent backup of tablespace tools to tape is January 3.
• Tablespace tools is read-only.

On February 21, when you issue a command to back up tablespace tools to tape, RMAN backs it up even though it d id not change after the January 3 backup (because it is read-only). RMAN makes the backup because no backup of the tablespace exists within the 7-day recovery window.

This behavior allows the media manager to expire old tape s. Otherwise, the media manager would be forced to keep the January 3 backup of tablespace tools indefinitely. By making a more recent backup of tablespace tools on February 21, RMAN allows the media manager to expire the tape containing th e obsolete January 3 backup.

Backup Optimization and Redundancy

Assume that y ou configure a retention policy for redundancy. In this case, RMAN only skips backups of offline or read-only datafiles when there ar e r + 1 backups of the files, where r is set in CONFIGURE RETENTION POLICY TO REDUNDANCY r.

A ssume that you enable backup optimization and set the following retention policy:

CONFIGURE
 DEFAULT DEVICE TYPE TO sbt;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE RETENTION POLICY
 TO REDUNDANCY 2;

So, RMAN only skips backups when three identica l files are already backed up. Also assume that you have never backed up the users tablespace, which is read/write, and that you perform the actions described in Table 2-4 over the course of the week.

Tab le 2-4 Effect of Redundancy Setting on Backup Optimization

< /tr>

Day	Action	Result	Redundant Backup
Monday	Take tablespace users offline normal.
Tuesday	BACKUP DATABASE	The users tablespace is backed up.
< /a> Wednesday	BACKUP DATABASE	The users tablespace is backed up.
Thursday	BACKUP DATABASE	The users tablespace is backed up.	Tuesday backup
Friday	BA CKUP DATABASE	The users tablespace is not backed up.	Tuesday backup
Saturday	BACKUP DATABASE	The users tablespace is not backed up.	Tuesday backup
Sunday	DELETE O BSOLETE	The Tuesday backup is deleted.
Monday	BACKUP DATABASE	The users tablespace is backed up.	Wednesday backup

The backups on Tuesday, Wednesday, and Thursday back up the offline users tablespace to satisfy the condition that three ba ckups must exist (one more than redundancy setting). The Friday and Saturday backups do not back up the users tablespace because of backup optimization. Note that the Tuesday backup of users is obsolete beginning on Thursday.

On Sunday, you delete all obsolete backups, which removes the Tuesday backup of users. The T uesday backup is obsolete because of the retention policy setting. The whole database backup on Monday then backs up the users< /code> tablespace to satisfy the condition that three backups must exist (one more than redundancy setting). In this way, you can rec ycle your tapes over time.

See Also: "Backing Up Files Using Backup Optimization", and "Configuring Backup Optimization"

Restartable Backups

Using the restartable backups feature, RMAN can back up only those files that have not been backed up since a specified date. Use this feature after a backup fails to back up the parts of the database missed by the failed bac kup.

The unit of restartability is a backup set. If the backup generates multiple backup se ts, then the backups that completed successfully do not have to be rerun. If the entire database is written into one backup set, and if the backup fails halfway through, then the entire backup has to be restarted.

To take be tter advantage of restartable backups, you can use set the MAXSETSIZE parameter of the BACKUP command. If, for instance, you set MAXSETSIZE to 10MB for a given backup command, a new backup set is produced for each 10MB of backu p output. If the backup fails after some backup sets have been produced and must be restarted, the data backed up in those backup set s will not have to be backed up again. (Note that MAXSETSIZE must be large enough that any file can be accomodated in a single backup piece, because large files cannot span backup pieces.)

For example, if the la rgest datafile is less than 10 MB, then you can back up the database daily as follows:

BACK
UP DATABASE MAXSETSIZE = 10M;

Then, after a failure you can back up all files in the database that were not backed up in the last 24 hours by issuing:

BACKU
P DATABASE NOT BACKED UP SINCE TIME 'SYSDATE-1';

If the SIN CE TIME is later than the completion time, then RMAN backs up the file. If you use "BACKUP DATABASE NOT BAC KED UP" without the SINCE TIME parameter, then RMAN only backs up files that have never been backed up.

When determining whether a file has been backed up, RMAN compares the SINCE TIME date with the completion time of the most recent backup of the file. The completion time for a backup piece is th e completion time of the entire backup set, not an individual backup piece; in other words, all files in the same backup set have the same completion time.

See Also: "Restarting a Backup After It Partially Completes"< /a> and Oracle Database Recovery Manager Reference for BACKUP syntax

Man aging Backup Windows and Performance: BACKUP... DURATION

A backup window is a period of time during which a backup activity must complete. For example, you may want to restrict your database backup activities to a window of time when user activity on your system is low, such as between 2:00 AM and 6:00 AM.

The BACKUP command supports a DURATION argument w hich lets you specify how long a given backup job is allowed to run. You could, for example, run the following command at 2:00AM:

BACKUP DURATION 4:00 TABLESPACE users; 

RMAN backs up the specified data at the maximum possible speed. If the backup is not complete in four hours, the backup is interrupted. Any completed backupsets are retained and can be used in restore operations, even if the entire backup is not comple te. Any incomplete backupsets are discarded.

Controlling RMAN Behavior when Backup Window Ends with PARTIAL

By default, when a BACKUP... DURATION command runs out of time before the ba ckup completes, RMAN reports an error. (The effect of this is that if the command is running in a RUN block, the RUN block terminates .) You can control this behavior by adding the PARTIAL option to the BACKUP... DURATION comman d, as in this example:

BACKUP DURATION 4:00 PARTIAL TABLESPACE users FILESPERSET 1;

When PARTIAL is used, no error is reported when a backup co mmand is interrupted due to the end of the backup window. Instead, a message showing which files could not be backed will be displaye d. If the BACKUP command is part of a RUN block, then the remaining commands in the RUN block will continue to execute.< /p>

When using DURATION the least recently backed up files are backed up first. Th us, if you retry a job that was interrupted when the available duration expired, each successive attempt covers more of the files nee ding backup.

Note also the use of FILESPERSET 1 in this example. With this opt ion, RMAN puts each file into its own backupset. This way, when a backup is interrupted at the end of the backup window, only the bac kup of the file currently being backed up is lost. All backup sets completed during the window are saved, minimizing the lost work du e to the end of the backup window.

Managing Backup Performance with MINIMIZE TIME and MINIMIZE LOAD

When using DURATION you can run the backup with the maximum possible performance, or run as slowl y as possible while still finishing within the allotted time, to minimize the performance impact of backup tasks. To maximize perform ance, use the MINIMIZE TIME option with DURATION, as shown in this example:

BACKUP DURATION 4:00 PARTIAL MINIMIZE TIME DATABASE FILESPERSET 1;

< p class="BP">To extend the backup to use the full time available, use the MINIMIZE LOAD option, as in this example:

BACKUP DURATION 4:00 PARTIAL MINIMIZE LOAD DATABASE FILESPERSET 1;

RMAN monitors the progress of the running backup, and periodically estimates how long the bac kup will take to complete at its present rate. If RMAN estimates that the backup will finish before the end of the backup window, it slows down the rate of backup so that the full available duration will be used. This reduces the overhead on the database associated with the backup.

Note: Note these issues when using DURATION and MINIMIZE LOAD with a tape backup: Efficient backup to tape requires tape streaming. If you use MINIMIZE LOAD, RMAN may reduce the rate of backup to the point where tape streaming is not optimal. RMAN will hold the tape resource for the entire duration of the backup window. This prevents the use of the tape resource for any other purpose during the backup window. Because of these concerns, it is not recommended that MINIMIZE LOAD be used with tape. See "Factors Affecting Backup Speed to Tape" for more details on efficient tape handling.





RMAN Backup Errors

RMAN detects and responds to two primary types of backup erro rs: I/O errors and corrupt blocks. Any I/O errors that RMAN encounters when reading files or writing to the backup pieces or image co pies cause RMAN to terminate the backup jobs. For example, if RMAN tries to back up a datafile but the datafile is not on disk, then RMAN terminates the backup. If multiple channels are being used, or redundant copies of backups are being created, RMAN may be able t o continue the backup without user intervention.

If BACKUP AS BACKUPSET creates more than one complete backup set and an error occurs, then RMAN needs to rewrite the backup sets that it was writing at the time of the error. However, it retains any backup sets that it successfully wrote before terminating. The N OT BACKED UP SINCE option of the BACKUP command restarts a backup that par tially completed, backing up only files that did not get backed up.

RMAN copies datafile bl ocks that are already identified as corrupt into the backup. If RMAN encounters datafile blocks that have not already been identified as corrupt, then RMAN stops the backup unless SET MAXCORRUPT has been used. Setting MAXCORRUPT allows a sp ecified number of previously undetected block corruptions in datafiles during the execution of an RMAN BACKUP command. I f RMAN detects more than this number of corruptions while taking the backup, then the command terminates. The default limit is zero, meaning that RMAN does not tolerate corrupt blocks by default.

When RMAN finds corrupt bloc ks, until it finds enough to exceed the MAXCORRUPT limit, it writes the corrupt blocks to the backup with a reformatted header indicating that the block has media corruption. If the backup completes without exceeding MAXCORRUPT,then the dat abase records the address of the corrupt blocks and the type of corruption in the control file. Access these records through the V$DATABASE_BLOCK_CORRUPTION view. Note that if more than MAXCORRUPT corrupt blocks are found, the V$DATAB ASE_BLOCK_CORRUPTION view is not populated. In such a case, you should set MAXCORRUPT higher and re-run the comma nd to identify the corrupt blocks.

S ee Also: "Tests and Integrity Checks for Backups" for more information about fractured and corrupt blocks "Restartable Backups" for more information about the NOT BACKED UP SINCE cl ause Oracle Database Reference for a description of V$DATABASE_BLOCK_CORRUPTION Or acle Database Recovery Manager Reference for SET MAXCORRUPT syntax

Test s and Integrity Checks for Backups

The database prevents operati ons that result in unusable backup files or corrupt restored datafiles. The database server automatically does the following:

• Blocks access to datafiles while they are being restored or recovered
• Allows only one restore operation for each datafile at a time
• Ensures that incremental backups are applied in the correct order
• Stores information in backup files to allow detection of corruption

You can use the BACKUP VALIDATE and RESTORE VALIDATE commands to test backup and restore operations without creating output files. In this way, you can check your datafiles for possible problems. If you run RMAN with the following configuration, then it detects all types of corruption that are possible to detect:

• In the initialization parameter file, set DB_BLOCK_CHECKSUM=TRUE
• In the RMAN BACKUP and RESTORE commands, do not specify the MAXCORRUPT option, do not specify the NOCHECKSUM option, but do specify the CHECK LOGICAL option

See Oracle Database Backup and Recovery Bas ics for more details on BACKUP VALIDATE and RESTORE VALIDATE.

Detecting Physical and Logical Block Corrupti on

Because an database server session is performing the backups and has a great understanding of files being backed up or copied, the server session is able to detect many types of physically corrupt b locks during the backup process. Each new corrupt block not previously encountered in a backup is recorded in the control file and in the alert.log. By default, error checking for physical corruption is enabled.

At the end of a backup, RMAN stores the corruption information in the recovery catalog and control file. Access this data using the V$DATABASE_BLOCK_CORRUPTION view.

If the server session encounters a datafile block during a backup that has already been identified as corrupt by the database, then the server session copies the corrupt block i nto the backup and the corrupt block is recorded the control file as either a logical or media corruption. RMAN copies the block in c ase the user wants to try to salvage the contents of the block.

If RMAN encounters a datafi le block that has media corruption but that has not already been identified as corrupt by the database, then it writes the block to t he backup with a reformatted header indicating that the block has media corruption.

Besides testing for media corruption, the database can also test data and index blocks f or logical corruption, such as corruption of a row piece or index entry. If RMAN finds logical corruption, then it logs the block in the alert.log. If CHECK LOGICAL was used, the block is also logged in the server session trace file. By default, error c hecking for logical corruption is disabled.

For BACKUP commands the MAXC ORRUPT parameter sets the total number of physical and logical corruptions permitted in a file. If the sum of physical and log ical corruptions for a file is less than its MAXCORRUPT setting, the RMAN command completes successfully. If MAXCO RRUPT is exceeded, the command terminates and RMAN does not read the rest of the file. V$DATABASE_BLOCK_CORRUPTION is populated with corrupt block ranges if the command succeeds. Otherwise, you must set MAXCORRUPT higher and re-run t he backup to find out the corrupt block ranges.

See Also: Oracle Database Recovery Manager Reference for BACKUP ... MAXCORRUPT syntax

Detection of Fractured Blocks During Open Backups

One danger in making online backups is the possibility of inconsistent data within a block. For exa mple, assume that you are backing up block 100 in datafile users.dbf. Also, assume that the copy utility reads the entir e block while database writer is in the middle of updating the block. In this case, the copy utility may read the old data in the top half of the block and the new data in the bottom top half of the block. In this case, the block is a fr actured block, meaning that the data contained in this block is not consistent.

Wh en performing open backups without using RMAN, you must put tablespaces in backu p mode in case the copy utility reads a block for a backup that is currently being written by the database writer. When not in backup mode, the database records only changed bytes in the redo stream. When a tablespace is in backup mode, each time a block is changed the datbase writes the before-image ofthe entire block to the redo log before modifying it. Then, the database also records the changes to the block in the redo log. When you recover using SQL*Plus, the database applies both the block images and the changes from the redo logs during recovery. Applying the block images repairs any possible fractured blocks in the backup being restored and recovered.

RMAN does not require that you use backup mode (and it is an error to use backu p mode with RMAN). During an RMAN backup, a database server session reads each block of the datafile and checks whether each block is fractured by comparing the block header and footer. If a block is fractured, the session re-reads the block. If the same fracture is found, then the block is considered permanently corrupt. If MAXCORRUPT is exceeded, the backup stops.

Backup Validation with RMA N

You can run the BACKUP ... VALIDAT E command to check datafiles for physical and logical corruption, or to confirm that all database files exist in the correct l ocations. No backup is taken, but all specified files are scanned to verify that they can be backed up. Here is an example:

BACKUP VALIDATE DATABASE ARCHIVELOG ALL;

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

See Also: < /a> Oracle Data base Recovery Manager Reference for BACKUP syntax and "Validating Backups with R MAN" for more details on using BACKUP VALIDATE.

---

Previous Next

Copyright © 2003 Oracle Corporation< br> All Rights Reserved.

Home Book List Contents Index Master Index< /font> Feedback