Backing Up the Database (Source Oracle)

Use the BACKUP command to back up all or part of your database.

Backing Up the Database: Advanced Topics to learn about more advanced topics such as backup optimization, duplexing, backup encryption, and restartable backups

Oracle Data Guard Concepts and Administration to learn how to perform RMAN backup and recovery in a Data Guard environment

Overview of RMAN Backups

RMAN backups are created using the BACKUP command.

This section provides an overview of RMAN backups.

Purpose of RMAN Backups

The primary purpose of RMAN backups is to protect your data. If a media failure or disaster occurs, then you can restore your backups and recover lost changes.

You can also make backups to preserve data for long-time archival, as explained in "Making Database Backups for Long-Term Storage", and to transfer data, as explained in the chapters included in Transferring Data with RMAN.

Basic Concepts of RMAN Backups

You can back up all or part of your database with the BACKUP command from within the RMAN client.

In many cases, after your database has been configured in accordance with your backup strategy, you can back up the database by entering the following command at the RMAN prompt:

RMAN> BACKUP DATABASE;

RMAN uses the configured settings, the records of previous backups, and the control file record of the database structure to determine an efficient set of steps for the backup. RMAN then performs these steps.

You might want to perform nightly backups of the whole multitenant container database (CDB) by using an incremental backup strategy, or you might want to make frequent separate backups of individual pluggable databases (PDBs) and do less frequent backups of either the whole CDB or of the root. In terms of the ability to recover from data loss, separately backing up the root and all PDBs, including the CDB seed, is equivalent to backing up the whole CDB. The main difference is in the number of RMAN commands that you must enter and the time to recover. Recovering a whole CDB requires less time than recovering the root plus all PDBs.

As explained in "About RMAN File Management in a Data Guard Environment", you can run RMAN backups at any database in a Data Guard environment. Any backup of any database in the environment is usable for recovery of any other database if the backup is accessible. You can offload all backups of database files, including control file backups, to a physical standby database and thereby avoid consuming resources on the primary database.

Specifying Backup Output Options

You can provide arguments to the BACKUP command to override the default backup options.

If you specify only the minimum required options for an RMAN command such as BACKUP DATABASE, then RMAN automatically determines the destination device, locations for backup output, and a backup tag based on your configured environment and built-in RMAN defaults.

The most typical backup options are described in the following sections:

Specifying the Device Type for an RMAN Backup

The BACKUP command takes a DEVICE TYPE clause that specifies whether to back up to disk or tape device.

When you run BACKUP without a DEVICE TYPE clause, RMAN stores the backup on the configured default device (disk or SBT). You set the default device with the CONFIGURE DEFAULT DEVICE TYPE command.

This example illustrates a backup to disk.

BACKUP DEVICE TYPE DISK DATABASE;

Specifying Backup Set or Copy for an RMAN Backup to Disk

RMAN can create backups on disk as image copies or as backup sets.

"Configuring the Default Type for Backups: Backup Sets or Copies" explains how to configure the default disk device. You can override this default with the AS COPY or AS BACKUPSET clauses.

This example uses BACKUP AS COPY to back up to disk as image copies.

BACKUP AS COPY DEVICE TYPE DISK DATABASE;

To back up your data into backup sets, use the AS BACKUPSET clause. This example illustrates how you can allow backup sets to be created on the configured default device, or direct them specifically to disk or tape.

BACKUP AS BACKUPSET DATABASE;

BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE;
BACKUP AS BACKUPSET DEVICE TYPE SBT DATABASE;

Specifying a Format for RMAN Backups

RMAN provides a range of options to name the files generated by the BACKUP command.
RMAN uses the following set of rules to determine the format of the output files, which are listed in order of precedence:

If a FORMAT parameter is specified on the BACKUP command, then this setting controls the generated file name.

For example, you can direct the output to a specific location, as shown in the following command:

BACKUP DATABASE FORMAT "/disk1/backup_%U";  # specifies a location on the file system

In this case, backups are stored with generated unique file names with the prefix /disk1/backup_. The %U substitution variable, used to generate a unique string at this point in the file name, is required.

You can also use the FORMAT parameter to name an ASM disk group as the backup destination, as shown in the following example:

BACKUP DATABASE FORMAT '+dgroup1';  # specifies an ASM disk group

No %U is required in this case because Automatic Storage Management (ASM) generates unique file names as needed. However, you can specify %U if desired.

If you specify FORMAT when a fast recovery area is enabled, then RMAN obeys the FORMAT setting. If no location is specified in the FORMAT clause, then RMAN creates the backup in a platform-specific location.

If a FORMAT setting is configured for the specific channel used for the backup, then this setting controls the generated file name.

If a FORMAT setting is configured for the device type used for the backup, then this setting controls the generated file name.

If a fast recovery area is enabled during a disk backup, and if FORMAT is not specified, then RMAN creates the backup with an automatically generated name in the fast recovery area.

If no other conditions in this list apply, then the default location and file name format of the backup are platform-specific.

Specifying Multiple Formats for Disk Backups

When backing up to disk, you can specify a format to spread the backup across several drives for improved performance.

To back up a database to multiple disk drives, allocate one DISK channel for each disk drive and specify the format string on the ALLOCATE CHANNEL command so that the file names are on different disks.

RUN
{ 
  ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
  ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
  ALLOCATE CHANNEL disk3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
  BACKUP AS COPY DATABASE; 
} 

To create a default configuration that distributes backups to multiple disk drives by default, configure multiple disk channels.

CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
BACKUP AS COPY DATABASE;

Typically, you do not need to specify a format when backing up to tape because the default %U variable generates a unique file name for tape backups.

Specifying Tags for an RMAN Backup

RMAN attaches a character string called a tag to every backup it creates, as a way of identifying the backup. You can either accept the default tag or specify your own with the TAG parameter of the BACKUP command.

Backup Tags

User-specified tags are a useful way to indicate the purpose or usage of different classes of backups or copies.

You can tag backup sets, proxy copies, data file copies, or control file copies. For example, you can tag data file copies that you intend to use in a SWITCH command as for_switch_only and file copies to use only for a RESTORE command as for_restore_only.

Tags do not need to be unique, so multiple backup sets or image copies can have the same tag (for example, weekly_backup). Assume that you specify that a data file be restored from backups that have a specific tag. If multiple backups of the requested file have the desired tag, then RMAN restores the most recent backup that has the desired tag, within any constraints on the RESTORE command.

In practice, tags are often used to distinguish a series of backups created as part of a single strategy, such as an incremental backup strategy. For example, you might create a weekly incremental backup with a tag like BACKUP TAG weekly_incremental. Many forms of the BACKUP command let you associate a tag with a backup, and many RESTORE and RECOVER commands let you specify a tag to restrict which backups to use in the RESTORE or RECOVER operation.

If you do not explicitly specify a tag with the TAG parameter of the BACKUP command, then RMAN implicitly creates a default tag for backups (except for control file autobackups). The format of the tag is TAGYYYYMMDDTHHMMSS, where YYYY is the year, MM is the month, DD is the day, HH is the hour (in 24-hour format), MM is the minutes, and SS is the seconds. For example, a backup of data file 1 may get the tag TAG20070208T133437. 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 BACKUP command, then each backup piece has the same default tag.

Tags are stored in uppercase, regardless of the case used when entering them. The maximum length of a backup tag is 30 bytes. Tags cannot use operating system environment variables or use special formats such as %T or %D.

Specifying Tags for Backup Sets and Image Copies

Use the TAG parameter with the BACKUP command to specify tags for backup sets and image copies.

The characters in a tag must be limited to the characters that are legal in file names on the target database file system. For example, Automatic Storage Management (ASM) does not support the use of the hyphen (-) in the file names it uses internally, so a tag including a hyphen (such as weekly-incr) is not a legal tag name for backups in ASM disk groups.
When you tag a backup set, the tag is an attribute of each backup piece in a given copy of a backup set. If you create a multiplexed backup set, then each copy of the backup set is assigned the same tag.

Example of Applying a Tag to a Backup Set

This example creates one backup set with the tag MONDAYBKP.

BACKUP AS BACKUPSET COPIES 1 DATAFILE 7 TAG mondaybkp; 

Applying Tags to Image Copies

This example shows that copies of data files in tablespaces users and tools are assigned the tag MONDAYCPY. When you specify a tag for image copies, the tag applies to each individual copy.

BACKUP AS COPY TABLESPACE users, toolsTAG mondaycpy;

This example creates new copies of all image copies of the database that have the tag full_cold_copy and gives the new copies the tag new_full_cold_copy. You can use FROM TAG to copy an image copy with a specific tag, and then use TAG to assign the output copy a different tag.

BACKUP AS COPY COPY OF DATABASE FROM TAG full_cold_copy TAG new_full_cold_copy;

Making Compressed Backups

When creating backup sets, you can use RMAN support for binary compression of backup sets by including the AS COMPRESSED BACKUPSET option to the BACKUP command.

RMAN compresses the backup set contents before writing them to disk. The details of which binary compression level is used are automatically recorded in the backup set. There is no need to explicitly mention the type of compression used or how to decompress the backup set in the recovery operation.

Binary compression creates some performance overhead during backup and restore operations. Binary compression consumes CPU resources, so do not routinely schedule compressed backups when CPU usage is high. However, the following circumstances may warrant paying the performance penalty:

You are using disk-based backups when disk space in your fast recovery area or other disk-based backup destination is limited.

You are performing your backups to some device over a network when reduced network bandwidth is more important than CPU usage.

You are using some archival backup media such as CD or DVD, where reducing backup sizes saves on media costs and archival storage.

AS COMPRESSED BACKUPSET option of the BACKUP command in Oracle Database Backup and Recovery Reference for performance details regarding backup sets

Making Compressed Backups

This example backs up the entire database and archived logs to the configured default backup destination (disk or tape), producing compressed backup sets.

BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;

Specifying Multisection Incremental Backups

A multisection backup enables large data files to be divided into sections that can be backed up in parallel across multiple channels. This provides faster backup performance and better recovery times.

A multisection backup contains multiple backup pieces. During a multisection backup operation, RMAN writes to each backup piece, in parallel, by using a separate channel for each backup piece.

Multisection full backups of databases and data files are supported starting with Oracle Database 11g Release 1. Starting with Oracle Database 12c Release 1 (12.1), RMAN supports multisection incremental backups. Wherever applicable, RMAN also uses unused block compression and block change tracking while creating multisection incremental backups. When backup sets are used, you can create multisection full or incremental backups.

To create level 0 multisection incremental backups, the COMPATIBLE parameter must be set to 11.0 or higher. However, to create multisection incremental backups of level 1 or higher, you must set the COMPATIBLE parameter to 12.0.0 or higher. RMAN always creates multisection incremental backups with FILESPERSET set to 1.

Use the SECTION SIZE clause of the BACKUP command to create multisection backups. The SECTION SIZE clause specifies the size of each backup section. If you specify a section size that is larger than the size of the file, then RMAN does not use multisection backups for that file. If you specify a small section size that would produce more than 256 sections, then RMAN increases the section size to a value that results in exactly 256 sections.

Views to Identify Multisection Backups

Use the MULTI_SECTION column of the V$BACKUP_SET view or the recovery catalog view RC_BACKUP_SET to determine if a backup is a multisection backup. For multisection backups, the MULTI_SECTION column contains YES.

Views That Contain Metadata for Multisection Backups

The V$BACKUP_DATAFILE and RC_BACKUP_DATAFILE views provide information about the number of blocks in each section of a multisection backup. The BLOCKS column specifies the number of blocks in each multisection backup.

Example 9-8 Multisection Incremental Backup of Database as Backup Sets

The following example creates a multisection level 1 incremental backup of the data file as backup sets.

Ensure that the initialization parameter COMPATIBLE of the target database is set to 12.0.0 or higher.

Start RMAN and connect to a target database as a user with the SYSBACKUP or SYSDBA privilege.

Making Database Connections with RMAN for information about connecting to a target database

If required, configure RMAN to write in parallel to the backup device.

The following example configures RMAN to use two disk channels in parallel.

CONFIGURE DEVICE TYPE disk PARALLELISM 2;

Execute BACKUP with SECTION SIZE to indicate that a multisection backup must be created.

The following example creates a multisection section level 1 backup of the data file users_df.dbf using backup sets. Each backup piece is 100MB.

BACKUP INCREMENTAL LEVEL 1 SECTION SIZE 100M DATAFILE '/oradata/datafiles/users_df.dbf';

Unused Block Compression

Using Block Change Tracking to Improve Incremental Backup Performance

Making Multisection Backups Using Image Copies

While an image copy is being created, RMAN uses multiple channels to write files sections. However, the output of this operation is one copy for each data file.

Multisection backups provide better performance by using multiple channels to back up large files in parallel. Starting with Oracle Database 12c Release 1 (12.1), you can create multisection full backups that are stored as image copies.

Use the SECTION SIZE clause to create multisection backups. If the section size that you specify is larger than the size of the file, then RMAN does not use multisection backups for that file. If you specify a small section size that would produce more than 256 sections, then RMAN increases the section size to a value that results in exactly 256 sections

Multisection Backup of Data File as Image Copies

Use the following steps to create a multisection backup of a database as image copies:

Ensure that the COMPATIBLE parameter for the target database is set to 12.0.0 or higher.

Start RMAN and connect to a target database as a user with the SYSBACKUP or SYSDBA privilege.

If required, configure channel parallelism so that RMAN can perform the backup operation using multiple drives in parallel.

Execute BACKUP with SECTION SIZE and AS COPY to indicate that a multisection backup must be created using image copies.

The following command creates a multisection incremental backup of the entire database using image copies. Each backup piece is 500MB.

BACKUP AS COPY SECTION SIZE 500M DATABASE;

Specifying Multisection Incremental Backups for information about the views that contain information about multisection backups.

Backing Up Database Files with RMAN '

You can back up a whole CDB, the root only, one or more pluggable databases (PDBs), or one ore more tablespaces.

Note:Backups of a non-CDB are not usable after the non-CDB is plugged in as a PDB into another CDB.

Backing Up a Whole CDB

Backing up a whole multitenant container database (CDB) backs up the root, all the pluggable databases (PDBs), and the archived redo logs.

You can perform a whole database backup with the database mounted or open. Use the BACKUP DATABASEcommand to perform a whole database backup. You may want to exclude specified tablespaces from a whole database backup. You can persistently skip tablespaces across RMAN sessions by executing the CONFIGURE EXCLUDE command for each tablespace that you always want to skip. You can override the configured setting with BACKUP ... NOEXCLUDE.

To backup up a whole CDB:

Start RMAN and connect to the root as a common user with the SYSBACKUP or SYSDBA privilege and to a recovery catalog (if used) as described in Making Database Connections with RMAN.Ensure that the database is mounted or open.Issue the BACKUP DATABASE command at the RMAN prompt. The simplest form of the command requires no options or parameters:

BACKUP DATABASE;

The list of files backed up depends on the keyword used with the BACKUP command.

The following example backs up the CDB, switches the online redo logs, and includes archived logs in the backup:

BACKUP DATABASE PLUS ARCHIVELOG;

By archiving the logs immediately after the backup, you ensure that you have a full set of archived logs through the time of the backup. In this way, you guarantee that you can perform media recovery after restoring this backup.

Proxy PDBs are not backed up while backing up a CDB.

Backing Up the Root with RMAN

You can use RMAN to make a backup of only the root. Because the root contains critical metadata for the whole CDB, Oracle recommends that you back up the root or back up the whole CDB at regular intervals.

To back up the root with RMAN:

Start RMAN and connect to the root as a common user with the SYSBACKUP or SYSDBA privilege as described in Connecting as Target to the Root.

Enter the following command:

BACKUP DATABASE ROOT;

Backing Up the Root with Oracle Enterprise Manager Cloud Control. Oracle Enterprise Manager Cloud Control (Cloud Control) can be used to back up the root.

Backing Up PDBs with RMAN

RMAN enables you to back up one or more PDBs in a CDB using the BACKUP command.

There are two approaches to backing up a PDB with RMAN:

Connect to the root and then use the BACKUP PLUGGABLE DATABASE command. This approach enables you to back up multiple PDBs with a single command.

When you connect to the root and back up a PDB, this backup is visible to the root and to that particular PDB but not to the other PDBs.

Connect to the PDB and use the BACKUP DATABASE command. This approach backs up only a single PDB and enables you to use the same commands used for backing up databases.

Backups created when connected to any PDB are visible when connected to the root.

When you back up individual PDBs, the archived redo logs are not backed up.

To back up one or more PDBs while connected to the root:

Start RMAN. Connect to the root as a common user with the SYSBACKUP or SYSDBA privilege and to a recovery catalog (if used), as described in Connecting as Target to the Root.

Issue a BACKUP PLUGGABLE DATABASE command at the RMAN prompt.

The following example backs up the PDBs sales and hr:

BACKUP PLUGGABLE DATABASE sales, hr;

To back up one PDB while connected to the PDB:

Start RMAN and connect to the PDB as a local user with the SYSBACKUP or SYSDBA privilege and to a recovery catalog (if used), as described in Connecting as Target to a PDB.

Issue a BACKUP DATABASE command at the RMAN prompt.

BACKUP DATABASE;

Note:Backing up a proxy PDB using RMAN is not supported.

Note:PDB backups can be used to perform media recovery only if the backups include all the archived redo log files that contain changes for this PDB. When creating a backup while connected to the PDB, there may be some situations in which all the required logs are not backed up.

Backing Up PDBs with Oracle Enterprise Manager Cloud Control

Oracle Enterprise Manager Cloud Control (Cloud Control) can be used to perform backups of pluggable databases (PDBs).

To back up one or more PDBs with Cloud Control, complete the following steps:

From the Database Home page, select Backup & Recovery from the Availability menu, and then select Schedule Backup.

If you have not logged in to the database previously, then the Database Login page is displayed. Log in to the database using Named or New credentials and then click Login.

Cloud Control displays the Schedule Backup page.

From the Customized Backup section, select Pluggable Databases, and then click Schedule Customized Backup.

The Schedule Backup Wizard appears and displays the Pluggable Databases page.

Select the PDBs that you want to back up by following these steps:

Click Add to display the Available Pluggable Databases page.

From the list of PDBs shown, click in the Select column to designate the PDBs you want to back up. Optionally, you can click Select All to turn on the Select option for all available PDBs. Click Select None to deselect all PDBs.

Click the Select button to return to the Pluggable Databases page.

Optionally, you can remove PDBs from the table by clicking in the Select column for each PDB that you want to remove and then clicking Remove.

Click Next to move to the Options page of the wizard.

Complete the wizard by navigating the remainder of the pages to back up the PDBs. For more information about each page of the wizard, click Help.

Backing Up Tablespaces and Data Files with RMAN

You can back up one or more tablespaces with the BACKUP TABLESPACE command or one or more data files with the BACKUP DATAFILE command.

When you specify tablespaces, RMAN translates the tablespace name internally into a list of data files. The database can be mounted or open. Tablespaces can be read/write or read-only.

Note:Transportable tablespaces do not have to be in read/write mode for backup as in previous releases.
RMAN automatically backs up the control file and the server parameter file (if the instance was started with a server parameter file) when data file 1 is included in the backup. If control file autobackup is enabled, then RMAN writes the current control file and server parameter file to a separate autobackup piece. Otherwise, RMAN includes these files in the backup set that contains data file 1.

To back up tablespaces or data files:

Start RMAN and connect to a target database and a recovery catalog (if used).

If the database instance is not started, then either mount or open the database.Run the BACKUP TABLESPACE command or BACKUP DATAFILE command at the RMAN prompt.

The following example backs up the users and tools tablespaces to tape:

BACKUPDEVICE TYPE sbt TABLESPACE users, tools;

The following example uses an SBT channel to back up data files 1 through 4 and a data file copy stored at /tmp/system01.dbf to tape:

BACKUP DEVICE TYPE sbt DATAFILE 1,2,3,4 DATAFILECOPY '/tmp/system01.dbf';

Backing Up Tablespaces and Data Files in a PDB

Because tablespaces in different PDBs can have the same name, to eliminate ambiguity you must connect directly to a PDB to back up one or more of its tablespaces.

Ensure that the CDB is open or mounted. Tablespaces can be read-only or read-write.

In contrast, because data file numbers and paths are unique across the CDB, you can connect to either the root or a PDB to back up PDB data files. If you connect to the root, you can back up data files from multiple PDBs with a single command. If you connect to a PDB, you can back up only data files in that PDB.

To back up tablespaces in a PDB:

Start RMAN. Connect to the PDB as a local user with the SYSBACKUP or SYSDBA privilege and to a recovery catalog (if used), as described in Connecting as Target to a PDB.

Issue a BACKUP TABLESPACE command.

The following example backs up the tablespaces users and examples to the configured default device.

BACKUP TABLESPACE users, examples;

To back up data files in a PDB:

Do one of the following:

Start RMAN and connect to the root as a common user with the SYSBACKUP or SYSDBA privilege.

Start RMAN and connect to the PDB as a local user with the SYSBACKUP or SYSDBA privilege.

Issue a BACKUP DATAFILE command.

BACKUP DATAFILE 10, 13;

Backing Up Control Files with RMAN

You can back up the control file when the database is mounted or open. RMAN uses a snapshot control file to ensure a read-consistent version.

If the CONFIGURE CONTROLFILE AUTOBACKUP command is set to ON (by default it is OFF), then RMAN automatically backs up the control file and server parameter file after every backup and after database structural changes. The control file autobackup contains metadata about the previous backup, which is crucial for disaster recovery.

Note:

You can restore a backup of a control file made on one Data Guard database to any other database in the environment. Primary and standby control file backups are interchangeable. See Oracle Data Guard Concepts and Administration to learn how to use RMAN to restore files on a standby database.

If the autobackup feature is not set, then you must manually back up the control file in one of the following ways:

Run BACKUP CURRENT CONTROLFILE.

Include a backup of the control file within any backup by using the INCLUDE CURRENT CONTROLFILE option of the BACKUP command.

Back up data file 1, because RMAN automatically includes the control file and server parameter file in backups of data file 1.

Note:

If the control file block size is different from the block size for data file 1, then the control file cannot be written into the same backup set as the data file. RMAN writes the control file into a backup set by itself if the block size is different. The V$CONTROLFILE.BLOCK_SIZE column indicates the control file block size, whereas the DB_BLOCK_SIZE initialization parameter indicates the block size of data file 1.

Manual Backups of the Control File

A manual backup of the control file is different from a control file autobackup. RMAN makes a control file autobackup after the files specified in the BACKUP command are backed up.

Thus, the autobackup—unlike a manual control file backup—contains metadata about the backup that just completed. Also, RMAN can automatically restore autobackups without the use of a recovery catalog.

You can make a manual backup of the current control file either as a backup set or as an image copy. For a backup set, RMAN first creates a snapshot control file for read consistency. You can configure the file name and location of the snapshot control file. A snapshot control file is not needed for an image copy.

In an Oracle Real Application Clusters (Oracle RAC) environment, the following restrictions apply:

The snapshot control file location must be on shared storage—that is, storage that is accessible by all Oracle RAC instances.

The destination of an image copy of the current control file must be shared storage.

Making a Manual Backup of the Control File

To make a manual backup, you can either specify INCLUDE CURRENT CONTROLFILE when backing up other files or specify BACKUP CURRENT CONTROLFILE.

To manually back up the control file:

You can also back up control file copies on disk by specifying the CONTROLFILECOPY parameter.

Start RMAN and connect to a target database and a recovery catalog (if used) as described in Making Database Connections with RMAN.

Ensure that the target database is mounted or open.

Execute the BACKUP command with the desired control file clause.

Backing Up a Tablespace and Current Control File to Tape

This example backs up tablespace users to tape and includes the current control file in the backup:

BACKUP DEVICE TYPE sbt TABLESPACE users INCLUDE CURRENT CONTROLFILE;

Backing Up Current Control File to Fast Recovery Area

This example backs up the current control file to the fast recovery area as a backup set:

BACKUP CURRENT CONTROLFILE;

RMAN first creates a snapshot control file.

Backing Up the Current Control File as Image Copy

This example backs up the current control file to the default disk device as an image copy:

BACKUP AS COPY CURRENT CONTROLFILE FORMAT '/tmp/control01.ctl';

Backing Up a Control File Copy

This example backs up the control file copy created in the previous example to tape:

BACKUP AS COPY CURRENT CONTROLFILE FORMAT '/tmp/control01.ctl';
BACKUP DEVICE TYPE sbt CONTROLFILECOPY '/tmp/control01.ctl';

A snapshot control file is not needed when backing up a control file copy.

If the control file autobackup feature is enabled, then RMAN makes two control file backups in these examples: the explicit backup of the files specified in the BACKUP command and the control file and server parameter file autobackup.

Backing Up Server Parameter Files with RMAN

RMAN automatically backs up the current server parameter file in certain cases. The BACKUP SPFILE command backs up the parameter file explicitly. The server parameter file that is backed up is the one currently in use by the instance.

To back up the server parameter file:

Start RMAN and connect to a target database and a recovery catalog (if used) as described in Making Database Connections with RMAN.

Ensure that the target database is mounted or open.
The database must have been started with a server parameter file. If the instance is started with a client-side initialization parameter file, then RMAN issues an error if you execute BACKUP ... SPFILE.

Execute the BACKUP ... SPFILE command.
The following example backs up the server parameter file to tape:

BACKUP DEVICE TYPE sbt SPFILE;

Backing Up a Database in NOARCHIVELOG Mode

You can only back up a database in NOARCHIVELOG mode when the database is closed and in a consistent state.

The script puts the database into the correct mode for a consistent, whole database backup and then backs up the database. The script assumes that control file autobackup is enabled for the database.

You can skip tablespaces, such as read-only tablespaces, but any skipped tablespace that has not been offline or read-only since its last backup is lost if the database has to be restored from a backup.

Backing Up a Database in NOARCHIVELOG Mode

SHUTDOWN IMMEDIATE; 
# Start the database in case it suffered instance failure or was 
# closed with SHUTDOWN ABORT before starting this script. 
STARTUP FORCE DBA; 
SHUTDOWN IMMEDIATE; 
STARTUP MOUNT;
# this example uses automatic channels to make the backup
BACKUP INCREMENTAL LEVEL 0 MAXSETSIZE 10M DATABASE TAG 'BACKUP_1';
# Now that the backup is complete, open the database. 
ALTER DATABASE OPEN; 

Creating a Preplugin Backup of the Whole Database

Preplugin backups ensure that an RMAN backup is usable after a non-CDB is plugged in as a PDB into a CDB. Preplugin backups can be either tape and disk backups.

Preplugin backups of non-CDBs are supported with Oracle Database Release 18c and Oracle Database Release 19c. Use the procedure in this topic to create pre-plugin backups of Oracle Database Release 18c or Oracle Database Release 19c non-CDBs.. These preplugin backups are used for restore and recover operations after the non-CDB is plugged in as a PDB in a destination CDB.

To create a preplugin backup of a non-CDB:

Start RMAN and connect to the target database (non-CDB) as a user with the SYSDBA or SYSBACKUP privilege as described in 
"Making Database Connections with RMAN".

Connect to a recovery catalog if one is used.

Ensure that the required prerequisites are met as described in Oracle Database Backup and Recovery Reference.
(Optional) Configure autobackups for the database control file and server parameter file as described in "Configuring Control File and Server Parameter File Autobackups".
Perform a full backup of the non-CDB, including archived redo log files.
If backups of the non-CDB already exist, then you can just create backups of the archived redo log files. All existing RMAN backups are usable after their metadata is exported into the data dictionary by using the dbms_pdb.exportrmanbackup() procedure.

Although it is not mandatory to backup archived redo log files, it is recommended that you do so. By archiving the logs immediately after the backup, you ensure that you have a full set of archived logs through the time of the backup. This enables you to perform media recovery after restoring this backup.

The following command backs up a non-CDB including all archived redo log files. The TAG clause specifies the backup tag that is used to identify this RMAN backup.

RMAN> BACKUP DATABASE PLUS ARCHIVELOG ALL TAG for_migration; 

Exit RMAN.

In the target database, connect to SQL*Plus as a user with the SYSDBA or SYSBACKUP privilege.

Export the RMAN backup metadata for the non-CDB into its data dictionary by using the DBMS_PDB.EXPORTRMANBACKUP procedure.

SQL> EXECUTE DBMS_PDB.EXPORTRMANBACKUP();

While plugging the non-CDB as a PDB in a destination CDB, this backup metadata of the source non-CDB is copied into the data dictionary of the destination CDB.

Creating Preplugin Backups of PDBs Using RMAN

Preplugin backups of a PDB can be used to perform restore and recover operations after the PDB is migrated and plugged in to a different destination CDB.

Starting with Oracle Database Release 18c, you can create preplugin backups of PDBs to disk and tape.

Note:The destination CDB does not manage backups created on the source CDB after it has been plugged in to the destination CDB.
To create preplugin backups of a PDB:

Ensure that the required prerequisites are met as described in Oracle Database Backup and Recovery Reference.Start RMAN and connect using one of the following techniques as described in "Making Database Connections with RMAN":

Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.

Connect to the PDB as a local user or common user with the SYSDBA or SYSBACKUP privilege.

(Optional) Configure control file and server parameter file autobackups for the target database as described in "Configuring Control File and Server Parameter File Autobackups".
Create a full backup of the PDB including the archived redo log files.
If RMAN backups of the PDB already exist, then these backups are usable after the PDB is migrated to another destination CDB. However, it is recommended that you back up the archived redo log files.

The following command backs up the PDB when you are connected to the PDB as a local user with the SYSDBA or SYSBACKUP privilege:

CopyRMAN> BACKUP DATABASE PLUS ARCHIVELOG ALL TAG for_migration; 
The following command backs up the PDB my_pdb when connected to the ROOT as a common user with the SYSDBA or SYSBACKUP privilege:

RMAN> BACKUP PLUGGABLE DATABASE my_pdb PLUS ARCHIVELOG ALL TAG for_migration;

Note:When you use BACKUP PLUGGABLE DATABASE, all the required archived redo logs are backed up only when the CDB uses local undo. The metadata that is required for these preplugin backups to be usable in a destination CDB is included in the XML file created when the PDB is unplugged from the source CDB.

Example: 

Creating a Preplugin Backup of a PDB with RMAN

This example creates a preplugin backup of the PDB my_pdb that is contained in CDB cdb_prod. The CDB uses shared undo and is open in read-write mode.

Ensure that the prerequisites required for creating preplugin backups are met as described in Oracle Database Backup and Recovery Reference.

Start RMAN and connect to the root as a common user with the SYSBACKUP privilege.

The following command uses password file authentication to connect to the root. cdb_prod is the net service name of the CDB.

CONNECT TARGET "sbu@cdb_prod AS SYSBACKUP";

Enter the password for the sbu user when prompted.

Enable control file autobackup for the CDB.

CONFIGURE CONTROLFILE AUTOBACKUP ON;

Back up the PDB using the 

BACKUP PLUGGABLE DATABASE 

command. Include archived redo logs in the backup so that you can use this backup to perform media recovery, if required.
The following command creates a preplugin backup of my_pdb, including the archived redo log files. The tag used when naming the backups is mypdb_bkup.

BACKUP PLUGGABLE DATABASE my_pdb PLUS ARCHIVELOG TAG mypdb_bkup;

Backing Up Application Containers

RMAN enables you to use the BACKUP command to perform backup operations on the application root, one or more application PDBs, and the application container.

Backing Up Application Containers

RMAN can back up application containers, application PDBs, and the application root.

An application container is an optional component of a CDB that stores data for one or more applications and shares application metadata and common data. A CDB can contain zero or more application containers. An application container consists of exactly one application root (different from the root in its CDB) and one or more application PDBs. The application root serves as the parent container to all the application PDBs plugged into it.

An application container typically contains one or more application common users. An application common user can only connect to the application root in which it was created or a PDB that is plugged in to this application root. An application root has its own service name, and you can connect to the application root in the same way that you connect to a PDB.

To perform backup and recovery tasks for the application root or application PDBs, you connect either to the application root or CDB root.

Backing Up the Application Root

Use the RMAN BACKUP command to back up the application root.

The COMPATIBLE parameter for the CDB must be set to 19.0 or higher.

To back up the application root:

Start RMAN and connect to the CDB root as a common user with the SYSDBA or SYSBACKUP privilege, or to the application root as an application common user with the SYSDBA or SYSBACKUP privilege.

Use the BACKUP APPLICATION ROOT command to back up the application root.

BACKUP APPLICATION ROOT DATABASE;

Backing Up the Application Root and its Application PDBs

Use the BACKUP command to back up an application container, which consists of the application root and all the application PDBs that belong to the application root.

The COMPATIBLE parameter for the CDB must be set to 12.2 or higher.

To connect to the CDB and back up the application root and all its application PDBs:

Start RMAN and connect to the CDB root as a common user with the SYSDBA or SYSBACKUP privilege.
Use the following command, where hr_appcont is the name of the application root:

BACKUP PLUGGABLE DATABASE hr_appcont

To connect to the application root and back up the application root and all its application PDBs:

Start RMAN and connect to the application root as an application common user with the SYSDBA or SYSBACKUP privilege.

The application root has its own service name and you can connect to the application root in the same way that you connect to a PDB.Use the following command to back up the application container:

BACKUP DATABASE;

Backing Up Application PDBs

The BACKUP command is used to back up one or more application PDBs.

The COMPATIBLE parameter for the CDB must be set to 12.2 or higher.

To back up one or more application PDBs:
Start RMAN and establish one of the following types of connections:
Connect to the application root as an application common user with the SYSDBA or SYSBACKUP privilege.

The application root has its own service name and you can connect to the application root in the same way that you connect to a PDB.

Connect to the CDB root as a common user with the SYSDBA or SYSBACKUP privilege.

Use the BACKUP PLUGGABLE DATABASE command to back up the application PDB. To back up multiple application PDBs, use a comma-separated list of application PDB names.
The following command backs up an application PDB named hr_app_pdb:

BACKUP PLUGGABLE DATABASE hr_app_pdb;

Backing Up Sparse Databases with RMAN

Use the BACKUP command to back up sparse databases.

Note:

The base (read-only) data files in a sparse database are not encrypted. Ensure that the base data files are stored in a protected storage and accessed using secured communications.

Backing Up a Sparse Database with RMAN

You can use the BACKUP command to back up an entire sparse database or a database containing some sparse PDBs. The backups can be in the form of backup sets or image copies.

While backing up a sparse database, RMAN backs up data only from the delta storage space of the database. This contains the latest changes made to the data blocks within the sparse database.

Ensure you meet the following requirements before backing up a sparse database:
The base database for your sparse database must be read-only.

The COMPATIBLE initialization parameter of the database being backed up must be set to 12.2 or higher.

To back up a sparse database:

Start RMAN and connect to the root as a common user with the SYSDBA or SYSBACKUP privilege, as described in Making Database Connections with RMAN.

Ensure that the database is mounted or open and in ARCHIVELOG mode.

Run the BACKUP command with the AS SPARSE option. To specify your backup format, use one of the following options:

To create backup sets, use the AS SPARSE BACKUPSET option. The following example creates a sparse backup in the backup set format:

BACKUP AS SPARSE BACKUPSET DATABASE PLUS ARCHIVELOG;

To create image copies, use the AS SPARSE COPY option. The following example creates a sparse backup in the image copy format:

BACKUP AS SPARSE COPY DATABASE PLUS ARCHIVELOG;

To create compressed backup sets, use the COMPRESSED BACKUPSET option. The following example creates a backup in the compressed backups set format:

BACKUP AS SPARSE COMPRESSED BACKUPSET DATABASE;

Backing Up Sparse Tablespaces and Data Files with RMAN

You can back up one or more tablespaces containing sparse data files or individual sparse data files using the BACKUP command.

While backing up tablespaces, RMAN translates the BACKUP command to individual data files that are sparse compatible. 
Similarly, only data files containing sparse data blocks are eligible for a sparse backup. RMAN creates sparse backups of sparse data files and non-sparse backups of non-sparse data files.

Ensure that the database containing the sparse tablespace or data file has the COMPATIBLE initialization parameter set to 12.2 or higher.

To back up sparse tablespaces or data files:

Start RMAN and connect to a target database. For tablespaces and data files in CDB, you must connect to the root as a user with the SYSDBA or SYSBACKUP privilege.

Ensure that the database instance is mounted or open.

Run the BACKUP command for the tablespace or data file with the AS SPARSE option. Specify whether you want the backup in the backup set format, image copy format, or compressed backup set format. To do this, state one of the following options:
To create your backup in the backup set format, use the AS SPARSE BACKUPSET option. The following example performs a sparse backup in the backup set format:

BACKUP AS SPARSE BACKUPSET TABLESPACE MYTBS1;

To create your backup in the image copy format use the AS SPARSE COPY option. The following example performs a backup in the image copy format:

BACKUP AS SPARSE COPY DATAFILE 8,9,10;

To create your backup in the compressed backup set format use the COMPRESSED BACKUPSET option. The following example performs a backup in the compressed backups set format:

BACKUP AS SPARSE COMPRESSED BACKUPSET TABLESPACE MYTBS3;

Backing Up a Sparse PDB with RMAN

RMAN enables you to back up one or more sparse PDBs in a CDB.

Ensure that the COMPATIBLE initialization parameter is set to 12.2 or higher.

To back up a sparse PDB while connected to root:

Start RMAN and connect to the root as a common user with the SYSBACKUP or SYSDBA privilege as described in Connecting as Target to the Root.

Run the BACKUP command for the pluggable database. Specify the format for your backup:

To create your backup in the backup set format, use the AS SPARSE BACKUPSET option. The following example performs a sparse backup in the backup set format:

BACKUP AS SPARSE BACKUPSET PLUGGABLE DATABASE PDB1;

To create your backup in the image copy format use the AS SPARSE COPY option. The following example performs a backup in the image copy format:

BACKUP AS SPARSE COPY PLUGGABLE DATABASE PDB1;

To create your backup in the compressed backup set format use the COMPRESSED BACKUPSET option. The following example performs a backup in the compressed backups set format:

BACKUP AS SPARSE COMPRESSED BACKUPSET PLUGGABLE DATABASE PDB1;

To back up a sparse PDB while connected to the PDB:

Start RMAN. Connect to the sparse PDB as a local user with the SYSBACKUP or SYSDBA privilege as described in Connecting as Target to a PDB.

Run the BACKUP command at the RMAN prompt, with the AS SPARSE option and the format required. To specify the format for your backup, use one of the following commands:

To create your backup in the backup set format, use the AS SPARSE BACKUPSET option. The following example performs a sparse backup in the backup set format:

BACKUP AS SPARSE BACKUPSET DATABASE;

To create your backup in the image copy format use the AS SPARSE COPY option. The following example performs a backup in the image copy format:

BACKUP AS SPARSE COPY DATABASE;

To create your backup in the compressed backup set format use the COMPRESSED BACKUPSET option. The following example performs a backup in the compressed backups set format:

BACKUP AS SPARSE COMPRESSED BACKUPSET DATABASE;

To back up a tablespace from a sparse PDB, connect to the selected PDB directly and then run the BACKUP command with the AS SPARSE option, the appropriate backup format, and the tablespace name.

To back up a data file from a sparse PDB, you can either connect to root or directly to the PDB. Run the BACKUP command with the AS SPARSE option, the backup format, and the data file name, to back up an individual data file.

Backing Up Archived Redo Logs with RMAN

Archived redo logs are the key to successful media recovery. You should back them up regularly.

Backups of Archived Redo Logs

Several features of RMAN backups are specific to archived redo logs. For example, you can use BACKUP ... DELETE to delete one or all copies of archived redo logs from disk after backing them up to backup sets.

To perform operations with archived redo logs, such as backing up or switching, you must connect to the root as a common user with the SYSDBA or SYSBACKUP privilege. You cannot perform these operations when connected to a PDB as a local user with SYSDBA or SYSBACKUP.

Archived Redo Log Failover

Even if your redo logs are being archived to multiple destinations and you use RMAN to back up archived redo logs, RMAN selects only one copy of the archived redo log file to include in the backup set. Because logs with the same log sequence number are identical, RMAN does not need to include more than one log copy.

The archived redo log failover feature enables RMAN to complete a backup even when some archiving destinations are missing logs or contain logs with corrupt blocks. If at least one log corresponding to a given log sequence and thread is available in the fast recovery area or any of the archiving destinations, then RMAN tries to back it up. If RMAN finds a corrupt block in a log file during backup, it searches other destinations for a copy of that log without corrupt blocks.

For example, assume that you archive logs 121 through 124 to two destinations: /arch1 and /arch2. Table 9-1 shows the archived redo log records in the control file.

Sample Archived Redo Log Records

Sequence    File Name in /arch1    File Name in /arch2
121        /arch1/archive1_121.arc    /arch2/archive1_121.arc
122        /arch1/archive1_122.arc    /arch2/archive1_122.arc
123        /arch1/archive1_123.arc    /arch2/archive1_123.arc
124        /arch1/archive1_124.arc    /arch2/archive1_124.arc

However, unknown to RMAN, a user deletes logs 122 and 124 from the /arch1 directory. Afterward, you run the following backup:

BACKUP ARCHIVELOG FROM  SEQUENCE 121 UNTIL SEQUENCE 125;

With failover, RMAN completes the backup, using logs 122 and 124 in /arch2.

Online Redo Log Switching

Automatic online redo log switching is an important RMAN feature.

To make an open database backup of archived redo logs that includes the most recent online redo log, you can execute the BACKUP command with any of the following clauses:

PLUS ARCHIVELOG

ARCHIVELOG ALL

ARCHIVELOG FROM ...

Before beginning the backup, RMAN switches out of the current redo log group, and archives all online redo logs that have not yet been archived, up to and including the redo log group that was current when the command was issued. This feature ensures that the backup contains all redo generated before the start of the command.

An effective way of backing up archived redo logs is the BACKUP ... PLUS ARCHIVELOG command, which causes RMAN to do the following:

Run the ALTER SYSTEM ARCHIVE LOG CURRENT statement.

Run BACKUP ARCHIVELOG ALL . If backup optimization is enabled, then RMAN skips logs that it has already backed up to the specified device.

Back up the rest of the files specified in the BACKUP command.

Run the ALTER SYSTEM ARCHIVE LOG CURRENT statement.

Back up any remaining archived logs generated during the backup. If backup optimization is not enabled, then RMAN backs up the logs generated in Step 1 plus all the logs generated during the backup.

The preceding steps guarantee that data file backups taken during the command are recoverable to a consistent state. Also, unless the online redo log is archived at the end of the backup, DUPLICATE is not possible with the backup.

Backing Up Archived Redo Log Files
To back up archived logs, use the BACKUP ARCHIVELOG command.

If backup optimization is enabled, then RMAN skips backups of archived logs that have already been backed up to the specified device.

To back up archived redo log files:

Start RMAN and connect to the root as a common user with the SYSDBA or SYSBACKUP privilege, as described in Making Database Connections with RMAN. Connect to a recovery catalog (if used).
Ensure that the target database is mounted or open.
Execute the BACKUP ARCHIVELOG or BACKUP ... PLUS ARCHIVELOG command.
The following example backs up the database and all archived redo logs:

BACKUP DATABASE PLUS ARCHIVELOG;

The following example uses a configured disk or SBT channel to back up one copy of each log sequence number for all archived redo logs:

BACKUP ARCHIVELOG ALL;

You can also specify a range of archived redo logs by time, SCN, or log sequence number, as in the following example:

BACKUP ARCHIVELOG FROM TIME  'SYSDATE-30' UNTIL TIME 'SYSDATE-7';

Backing Up Only Archived Redo Logs That Need Backups

You can indicate that RMAN should automatically skip backups of archived redo logs.

Use one of the following techniques:

Configure backup optimization.

If you enable backup optimization, then the BACKUP ARCHIVELOG command skips backing up files when an identical archived log has been backed up to the specified device type. An archived log is considered identical to another when it has the same DBID, thread, sequence number, and RESETLOGS SCN and time.

Configure an archived redo log deletion policy.

If the deletion policy is configured with the BACKED UP integer TIMES clause, then a BACKUP ARCHIVELOG command copies the logs unless integer backups exist on the specified device type. If integer backups of the logs exist, then the BACKUP ARCHIVELOG command skips the logs.

The BACKUP ... NOT BACKED UP integer TIMES command specifies that RMAN backs up only those archived log files that have not been backed up at least integer times to the specified device. To determine the number of backups for a file, RMAN only considers backups created on the same device type as the current backup.

The BACKED UP clause is a convenient way to back up archived logs to a specified device type. For example, you can specify that RMAN should keep two copies of each archived redo log on tape and skip additional backups.

To back up archived redo logs that need backups:

Start RMAN and connect to the root as a common user with the SYSDBA or SYSBACKUP privilege, as described in Making Database Connections with RMAN. Connect to a recovery catalog (if used).
Ensure that the target database is mounted or open.
Ensure that appropriate channels are configured for the backup.
Execute the BACKUP ARCHIVELOG command with the NOT BACKED UP clause.

BACKUP ARCHIVELOG ALL NOT BACKED UP 2 TIMES;

Configuring an Archived Redo Log Deletion Policy

Using Backup Optimization to Skip Files for scenarios using NOT BACKED UP

Deleting Archived Redo Logs After Backups

The BACKUP ARCHIVELOG... DELETE INPUT command deletes archived log files after they are backed up. This command eliminates the separate step of manually deleting archived redo logs.

With DELETE INPUT, RMAN deletes only the specific copy of the archived log chosen for the backup set. With DELETE ALL INPUT, RMAN deletes each backed-up archived redo log file from all log archiving destinations.

The BACKUP ... DELETE INPUT and DELETE ARCHIVELOG commands obey the archived redo log deletion policy for logs in all archiving locations. For example, if you specify that logs be deleted only when backed up at least twice to tape, then BACKUP ... DELETE honors this policy.

For the following procedure, assume that you archive to /arc_dest1, /arc_dest2, and the fast recovery area.

To delete archived redo logs after a backup:

Start RMAN and connect to the root as a user with the SYSDBA or SYSBACKUP privilege, as described in Making Database Connections with RMAN. Connect to a recovery catalog (if used).
Ensure that the target database is mounted or open.
Run the BACKUP command with the DELETE INPUT clause.
Assume that you run the following BACKUP command:

BACKUP DEVICE TYPE sbt ARCHIVELOG ALL DELETE ALL INPUT;

In this case, RMAN backs up only one copy of each log sequence number in these archiving locations. RMAN deletes all copies of any log that it backed up from both the fast recovery area and the other archiving destinations.

If you specify DELETE INPUT rather than DELETE ALL INPUT, then RMAN only deletes the specific archived redo log files that it backed up. For example, RMAN deletes the logs in /arc_dest1 if these files were used as the source of the backup, but leave the contents of the /arc_dest2 intact.

Oracle Database Backup and Recovery Reference to learn about the CONFIGURE ARCHIVELOG DELETION POLICY and DELETE ARCHIVELOG commands

Deleting RMAN Backups and Archived Redo Logs

Making and Updating RMAN Incremental Backups

An incremental backup copies only data file blocks that have changed since a specified previous backup. Use the BACKUP command to create incremental backups.

An incremental backup is either a cumulative incremental backup or a differential incremental backup.

Although the content of the backups is the same, BACKUP DATABASE and BACKUP INCREMENTAL LEVEL 0 DATABASE are different. A full backup is not usable as part of an incremental strategy, whereas a level 0 incremental backup is the basis of an incremental strategy. No RMAN command can change a full backup into a level 0 incremental backup.

As with full backups, RMAN can make incremental backups of an ARCHIVELOG mode database that is open. If the database is in NOARCHIVELOG mode, then RMAN can make incremental backups only after a consistent shutdown.

This section contains the following topics:

Purpose of RMAN Incremental Backups

RMAN incremental backups provide multiple benefits.

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

Faster daily backups if block change tracking is enabled (see "Using Block Change Tracking to Improve Incremental Backup Performance")

Ability to roll forward data file image copies, thereby reducing recovery time and avoiding repeated full backups

Less bandwidth consumption when backing up over a network

Improved performance when the aggregate tape bandwidth for tape write I/Os is much less than the aggregate disk bandwidth for disk read I/Os

Possibility of recovering changes to objects created with the NOLOGGING option

For example, direct load inserts do not create redo log entries, so their changes cannot be reproduced with media recovery. Direct load inserts do change data blocks, however, and these blocks are captured by incremental backups.

Ability to synchronize a physical standby database with the primary database

You can use the RMAN BACKUP INCREMENTAL FROM SCN command to create a backup on the primary database that starts at the current SCN of the standby database, which you can then use to roll forward the standby database. See Oracle Data Guard Concepts and Administration to learn how to apply incremental backups to a standby database.

Planning an Incremental Backup Strategy

Choose a backup strategy according to an acceptable MTTR (mean time to recover).

For example, you can implement a three-level backup scheme so that a level 0 backup is taken monthly, a cumulative level 1 is taken weekly, and a differential level 1 is taken daily. In this strategy, you never have to apply more than a day of redo for complete recovery.
When deciding how often to take level 0 backups, a general rule is to take a new level 0 backup whenever 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 your incremental backups to determine when a new level 0 backup is appropriate. The following SQL query determines the number of blocks written to an incremental level 1 backup of each data file with at least 20% of its blocks backed up:

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

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

An effective way to conserve disk space is to make incremental backups to disk, and then offload the backups to tape with the BACKUP AS BACKUPSET command. Incremental backups are generally smaller than full backups, which limits the space required to store them until they are moved to tape. When the incremental backups on disk are backed up to tape, the tape is more likely to stream because all blocks of the incremental backup are copied to tape. There is no possibility of delay due to time required for RMAN to locate changed blocks in the data files.

Another strategy is to use incrementally updated backups, as explained in "Incrementally Updating Backups". In this strategy, you create an image copy of each data file, and&