Recovery Manager (RMAN) is fully integrated with the Oracle Database to perform a range of RMAN Backup and Recovery activities
Backing Up a Database
The BACKUP command backs up all data files, the current control file, the server parameter file, and archived redo log files to the default storage device:
% rman RMAN> CONNECT TARGET / RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
Backing Up a Sparse Database
This example uses the BACKUP command to backup a sparse database in the backup set format and the archive log.
RMAN> BACKUP AS SPARSE BACKUPSET DATABASE PLUS ARCHIVELOG;
Backing Up Multiple PDBs
This example connects to the root using operating system authentication and then creates backups of the PDBs hr_pdb an sales_pdb.
%rman RMAN> CONNECT TARGET / RMAN> BACKUP PLUGGABLE DATABASE hr_pdb, sales_pdb;
Performing a Cumulative Incremental Backup
This example backs up all blocks changed in the database since the most recent level 0 incremental backup. If no level 0 backup exists when you run a level 1 backup, then RMAN makes a level 0 backup automatically. Any inaccessible files are skipped.
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE SKIP INACCESSIBLE DATABASE;
Distributing a Backup Across Multiple Disks
This example backs up tablespaces to two different disks and lets RMAN perform automatic parallelization of the backup. The %U in the FORMAT string is a substitution variable that generates a unique file name for each output image copy.
RUN
{
ALLOCATE CHANNEL dev1 DEVICE TYPE DISK FORMAT '/disk1/%U';
ALLOCATE CHANNEL dev2 DEVICE TYPE DISK FORMAT '/disk2/%U';
BACKUP AS COPY
TABLESPACE SYSTEM, tools, users, undotbs;
}Identifying Data File Copies by Tag
In this example, you back up data file image copies to tape. The BACKUP command locates all data file copies with the tag LATESTCOPY, backs them up to tape, and names the backups using substitution variables. The variable %f specifies the absolute file number, whereas %d specifies the name of the database. After the data file copies are on tape, the example deletes all image copies with the tag LATESTCOPY.
BACKUP
DEVICE TYPE sbt
DATAFILECOPY
FROM TAG 'LATESTCOPY'
FORMAT 'Datafile%f_Database%d';
DELETE COPY TAG 'LATESTCOPY';Backing Up and Deleting Archived Redo Log Files
This example assumes that you have two archiving destinations set: /disk2/PROD/archivelog/ and /disk1/arch/. The command backs up one archived redo log for each unique sequence number. For example, if archived redo log 1000 is in both directories, then RMAN only backs up one copy this log. The DELETE INPUT clause with the ALL keyword deletes all archived redo log files from both archiving directories after the backup.
BACKUP DEVICE TYPE sbt ARCHIVELOG LIKE '/disk%arc%' DELETE ALL INPUT;
Sample output for the preceding command appears as follows:
Starting backup at 12-MAR-13 allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: SID=150 device type=SBT_TAPE channel ORA_SBT_TAPE_1: Oracle Secure Backup channel ORA_SBT_TAPE_1: starting archived log backup set channel ORA_SBT_TAPE_1: specifying archived log(s) in backup set input archived log thread=1 sequence=4 RECID=4 STAMP=616789551 input archived log thread=1 sequence=5 RECID=5 STAMP=616789551 input archived log thread=1 sequence=6 RECID=6 STAMP=616789554 input archived log thread=1 sequence=7 RECID=7 STAMP=616789731 input archived log thread=1 sequence=8 RECID=8 STAMP=616789825 input archived log thread=1 sequence=9 RECID=10 STAMP=616789901 input archived log thread=1 sequence=10 RECID=12 STAMP=616789985 channel ORA_SBT_TAPE_1: starting piece 1 at 12-MAR-13 channel ORA_SBT_TAPE_1: finished piece 1 at 12-MAR-13 piece handle=0vice0g7_1_1 tag=TAG20130312T105917 comment=API Version 2.0,MMS Version 10.1.0.3 channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:25 channel ORA_SBT_TAPE_1: deleting archived log(s) archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_4_2z45sgrc_.arc RECID=4 STAMP=616789551 archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_5_2z45sgrc_.arc RECID=5 STAMP=616789551 archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_6_2z45sl3g_.arc RECID=6 STAMP=616789554 archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_7_2z45z2kt_.arc RECID=7 STAMP=616789731 archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_8_2z4620sk_.arc RECID=8 STAMP=616789825 archived log file name=/disk1/arch/archiver_1_8_616789153.arc RECID=9 STAMP=616789825 archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_9_2z464dhk_.arc RECID=10 STAMP=616789901 archived log file name=/disk1/arch/archiver_1_9_616789153.arc RECID=11 STAMP=616789901 archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_10_2z4670gr_.arc RECID=12 STAMP=616789985 archived log file name=/disk1/arch/archiver_1_10_616789153.arc RECID=13 STAMP=616789985 Finished backup at 12-MAR-13 Starting Control File and SPFILE Autobackup at 12-MAR-13 piece handle=c-28643857-20130312-02 comment=API Version 2.0,MMS Version 10.1.0.3 Finished Control File and SPFILE Autobackup at 12-MAR-13
Scripting Incrementally Updated Backups
By incrementally updating backups, you can avoid the overhead of making full image copy backups of data files, while also minimizing media recovery time. For example, if you run a daily backup script, then you never have more than one day of redo to apply for media recovery.
Assume you run the following script daily. On first execution, the script creates an image copy backup of the database on disk with the specified tag. On second execution, the script creates a level 1 differential incremental backup of the database. On every subsequent execution, RMAN applies the level 1 incremental backup to the data file copy and then makes a new level 1 backup.
RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incr_update';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;
}Backing Up Disk-Based Backup Sets to Tape
Assume your goal is to keep recent backup sets on disk and older backup sets on tape. Also, you want to avoid keeping copies of the same backup set on disk and tape simultaneously. This example backs up backup sets created more than two weeks ago to tape and then deletes the backup pieces from disk.
BACKUP
DEVICE TYPE sbt
BACKUPSET
COMPLETED BEFORE 'SYSDATE-14'
DELETE INPUT;Duplexing a Database Backup
This example uses the COPIES parameter to create two compressed backups of the database, with each backup on a separate disk. The output locations are specified in the FORMAT parameter.
BACKUP AS COMPRESSED BACKUPSET DEVICE TYPE DISK COPIES 2 DATABASE FORMAT '/disk1/db_%U', '/disk2/db_%U';
Specifying How Channels Divide Workload
This example explicitly parallelizes a backup by using the CHANNEL parameter to specify which channels back up which files and to which locations.
RUN
{
ALLOCATE CHANNEL ch1 DEVICE TYPE sbt
PARMS 'ENV=(OB_DEVICE_1=stape1)';
ALLOCATE CHANNEL ch2 DEVICE TYPE sbt
PARMS 'ENV=(OB_DEVICE_1=stape2)';
BACKUP
(DATABASE # ch1 backs up database to tape drive stape1
CHANNEL ch1)
(ARCHIVELOG ALL
CHANNEL ch2); # ch2 backs up archived redo log files to tape drive stape2
}Creating an Incremental Backup for Refresh of a Standby Database
In this example, your goal is make an incremental backup of the primary database and use it to update an associated standby database. You start the RMAN client, CONNECT to the primary database as TARGET, and then connect to the recovery catalog. The BACKUP command creates an incremental backup of the primary database that can be applied at a standby database to update it with changes since the specified SCN.
RMAN> CONNECT TARGET / connected to target database: PROD (DBID=39525561) RMAN> CONNECT CATALOG [email protected] recovery catalog database Password: password connected to recovery catalog database RMAN> BACKUP DEVICE TYPE DISK 2> INCREMENTAL FROM SCN 404128 DATABASE 3> FORMAT '/disk1/incr_standby_%U';
Specifying Corruption Tolerance for Data File Backups
This example assumes a database that contains five data files. It uses the SET MAXCORRUPT command to indicate than only one corruption is tolerated in each data file. Because the CHECK LOGICAL option is specified on the BACKUP command, RMAN checks for both physical and logical corruption.
RUN
{
SET MAXCORRUPT FOR DATAFILE 1,2,3,4,5 TO 1;
BACKUP CHECK LOGICAL
DATABASE;
}Creating a Consistent Database Backup for Archival Purposes
This example uses a keepOption to create an archival backup set that cannot be considered obsolete for one year. The example backs up the database, archives the redo in the current online logs to ensure that this new backup is consistent, and backs up only those archived redo log files needed to restore the data file backup to a consistent state.
The BACKUP command also creates a restore point to match the SCN at which this backup is consistent. The FORMAT parameter must be capable of creating multiple backup pieces in multiple backup sets.
BACKUP DATABASE FORMAT '/disk1/archival_backups/db_%U.bck' TAG quarterly KEEP UNTIL TIME 'SYSDATE + 365' RESTORE POINT Q1FY06;
Exempting Copies from the Retention Policy
The following example copies two data files and exempts them from the retention policy forever. The control file and server parameter file are also backed up, even with autobackup off.
KEEP FOREVER requires a recovery catalog.
SHUTDOWN IMMEDIATE; STARTUP MOUNT; BACKUP KEEP FOREVER FORMAT '?/dbs/%U_longterm.cpy' TAG LONGTERM_BCK DATAFILE 1 DATAFILE 2; ALTER DATABASE OPEN;
Backing Up Files That Need Backups
Assume that you back up the database and archived redo log files every night to tape by running the following command.
BACKUP MAXSETSIZE 500M DATABASE PLUS ARCHIVELOG;
The preceding command sets an upper limit to the size of each backup set so that RMAN produces multiple backup sets. Assume that the media management device fails halfway through the backup and is then restarted. The next day you discover that only half the backup sets completed. In this case, you can run the following command in the evening:
BACKUP NOT BACKED UP SINCE TIME 'SYSDATE-1' MAXSETSIZE 500M DATABASE PLUS ARCHIVELOG;
With the preceding command, RMAN backs up only files not backed up during in the previous 24 hours. When RMAN determines that a backup from the specified time window is available, it displays output like the following:
skipping datafile 1; already backed up on 18-JAN-13 skipping datafile 2; already backed up on 18-JAN-13 skipping datafile 3; already backed up on 18-JAN-13
If you place the NOT BACKED UP SINCE clause immediately after the BACKUP command, then it affects all objects to be backed up. You can also place it after individual backupSpec clauses to cause only backups for those objects described by the backupSpec to be subject to the limitation.
Using NODUPLICATES To Back Up Data File Copies
This example creates a data file copy of data file 2 named /disk2/df2.cpy. The example then backs up this data file copy to the /disk1 and /disk3 directories. The NODUPLICATES option on the final BACKUP command indicates that only one copy of data file 2 is backed up.
BACKUP AS COPY DATAFILE 2 FORMAT '/disk2/df2.cpy' TAG my_tag; BACKUP AS COPY DATAFILECOPY '/disk2/df2.cpy' FORMAT '/disk1/df2.cpy'; BACKUP AS COPY DATAFILECOPY '/disk1/df2.cpy' FORMAT '/disk3/df2.cpy'; BACKUP DEVICE TYPE sbt DATAFILECOPY ALL NODUPLICATES; # backs up only copy of data file 2
Copying Archived Log From Operating System File to ASM
BACKUP AS COPY REUSE ARCHIVELOG LIKE "/ade/b/369893928/oracle/work/arc_dest/arcr_1_11_686060575.arc" AUXILIARY FORMAT "+RCVAREA";
Multisection Backup of Data Files as Image Copies
This example creates a multisection backup of the data file users_df.dbf. The backup is created as image copies and each backup piece cannot exceed 150MB.
BACKUP AS COPY SECTION SIZE 150M DATAFILE '/oradata/dbs/users_df.dbf';
Multisection Incremental Backup of Database as Backup Sets
This example creates a multisection incremental backup of the database as backup sets. The incremental backup includes all data file blocks that changed at SCN greater than or equal to 8564. The FORMAT clause is mandatory when you use INCREMENTAL FROM SCN to create a multisection incremental backup.
BACKUP FORMAT '/tmp/datafiles/db_incr_ms_%U' INCREMENTAL FROM SCN 8564 SECTION SIZE 400M DATABASE;
Multisection Incremental Backup of Tablespaces
This example creates a multisection incremental backup of the tablespace orders as backup sets. Before creating the backup, three channels are explicitly allocated using the ALLOCATE CHANNEL command. Therefore, RMAN uses these channels to write, in parallel, to the backup pieces.
run {
ALLOCATE CHANNEL MY_CH1 TYPE DISK;
ALLOCATE CHANNEL MY_CH2 TYPE DISK;
ALLOCATE CHANNEL MY_CH3 TYPE DISK;
BACKUP
INCREMENTAL LEVEL 1
AS COMPRESSED BACKUPSET
SECTION SIZE 100M
TABLESPACE sales;
};
Cross-Platform Backup of the Entire Database
This example creates a cross-platform backup of the entire database for transport to the Linux x86 64-bit platform. The source platform is Microsoft Windows IA (32-bit) and the backup is stored in a backup set named full_db.bck. The database must be placed in read-only mode before the backup is created.
BACKUP
TO PLATFORM='Linux x86 64-bit'
FORMAT '/tmp/xplat_backups/full_db.bck'
DATABASE;
Cross-Platform Backup of a Consistent Tablespace
This example backs up the tablespace example for cross-platform transport. The tablespace must be placed in read-only mode before the backup is performed. The backup set containing the tablespace data is called example_readonly.bck. The metadata required to plug this tablespace into the target database is stored in the backup set example_dmp.bck.
BACKUP FOR TRANSPORT FORMAT '/tmp/xplat_backups/example_readonly.bck' TABLESPACE example DATAPUMP FORMAT '/tmp/xplat_backups/example_dmp.bck';
Cross-Platform Backup of a Tablespace Using Multiple Backup Sets
This example creates a cross-platform backup of the tablespace example using multiple backup sets. Ensure that the tablespace is read-only before you create the backup. Because FILESPERSET is set to 1, each backup set contains only one input file. The backup sets use unique names that begin with db_multiple_.
BACKUP FOR TRANSPORT FILESPERSET 1 FORMAT '/tmp/xplat_backups/db_multiple_%U' TABLESPACE example DATAPUMP FORMAT '/tmp/xplat_backups/db_multiple.dmp';
Cross-Platform Backup of a Tablespace Using Multiple Backup Pieces
This example creates a cross-platform backup of the tablespace example. The backup uses multiple backup pieces because MAXPIECESIZE is set in the ALLOCATE CHANNEL command. Ensure that the tablespace is in read-only mode before the backup is created.
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE disk MAXPIECESIZE 301464;
BACKUP
FOR TRANSPORT
FORMAT '/tmp/xplat_backups/example_multi-piece.bck'
TABLESPACE example
DATAPUMP FORMAT '/tmp/xplat_backups/example_multi-piece_dmp.bck';}
Cross-Platform Inconsistent Backup of a Tablespace
This example creates a cross-platform level 0 incremental backup of the tablespace example. The tablespace is in read-write mode at the time of creating the backup and, therefore, you use ALLOW INCONSISTENT to create an inconsistent backup.
Note that inconsistent backups of tablespaces cannot be used to directly plug the tablespace into the destination database. You must use an incremental backup of the tablespace that is created when the tablespace is read-only to make the tablespace consistent.
BACKUP
FOR TRANSPORT
ALLOW INCONSISTENT
INCREMENTAL LEVEL 0
FORMAT '/tmp/xplat_backups/example_inconsist.bck'
TABLESPACE example;
Cross-Platform Incremental Backup of a Tablespace
This example creates a cross-platform level 1 incremental backup of the tablespace example. The tablespace is placed in read-only mode before this backup is created. This backup contains changes made to the tablespace after the most recent incremental backup was created. The backup is stored in a backup set called example_inconsist_incr.bck. The metadata required to plug the tablespace into the destination database is stored in the backup set example_incr_dmp.bck.
You can use this level 1 incremental backup, along with the level 0 incremental backup created, to transport the tablespace example to a different platform. On the destination database, you first restore the level 0 incremental backup created to create a set of foreign data files. These foreign data files are inconsistent because the tablespace was in read/write mode when the level 0 incremental backup was created. You then apply a level 1 incremental backup to the foreign data files. Next, you plug the tablespace in to the destination database by restoring the backup set specified in the DATAPUMP clause.
In most scenarios, after creating the level 0 incremental backup, you create multiple level 1 incremental backups with the tablespace is placed in read/write mode. The final incremental level 1 backup is created with the tablespace placed in read-only mode. These incremental backups that are created and applied over time help minimize the data divergence between the source and destination database.
BACKUP FOR TRANSPORT INCREMENTAL LEVEL 1 TABLESPACE example FORMAT '/tmp/xplat_backups/example_inconsist_incr.bck' DATAPUMP FORMAT '/tmp/xplat_backups/example_incr_dmp.bck';
Also See: