RMAN BACKUP
Using the RMAN BACKUP Command to Create Backups
- Server-Managed Consistent Backups
- server-managed open backups
- incremental backups
- image copy
- protect your backups
- parallelism your backups
Managing and Monitoring RMAN Backups
- The LIST, REPORT, and DELETE Commands
- Archival Backups
- The Dynamic Performance Views
- Crosschecking Backups
backup terminology
There are three questions need to be asked before backup:
- closed or open
- whole or partial
- full or incremental
Colsed is aslo called cold, consistent, offline backup. It must be done when database is in shutdown status. Open is also called hot, inconsistent, online backup。It can be done when the database is open but only in archive mode(why only in archive mode). One more thing you need to notice, rman can backup a database when it is in mount mode but user managed backup cannot. This is because in mount mode the control file can still being updated, so the control file you copyed may be inconsistent and you cannot find this until you try to resotre the backup. Rman can avoid this issue by using a control file snapshot.
A whole backup is a backup of all thedatafiles and the control files. A partial backup is a backup of a subset of these. In most circumstances, partial backups can only be made if the database is in archivelog mode(for example when？).
A full backup includes all used blocks of the files backed up. An incremental backup includes only those blocks that have been changed since the last backup. An incremental backup can be cumulative (including all blocks changed since the last full backup) or differential (including all blocks changed since the last incremental backup).
Any combination of these is possible. Many sites perform closed, whole, full backups during weekly or monthly maintenance slots, and open, whole, incremental backups daily. Partial backups are often carried out more frequently for particularly volatile files, or following direct load operations that do not generate redo.
In this chapter we only discuss rman backup. So there is one thing you need to notice about the above three kinds of backup. The closed backup in rman is not in db shutdown status. Because rman may need to use the controlfile.
The file types that can be backed up by RMAN are
- Datafiles
- Controlfile
- Archive redo log files
- SPFILE
- Backup set pieces
Files that cannot be backed up by RMAN include
- Tempfiles
- Online redo log files
- Password file
- Static PFILE
- Oracle Net configuration files
One thing you need to notice here is that static pfile can not be backup by rman while spfile can.
RMAN can generate three types of backup:
- A backup set is a proprietary format that can contain several files and will not include blocks of a datafile that are not currently part of a segment.
- A compressed backup set has the same content as a backup set, but RMAN will apply a compression algorithm as it writes out the backup set.
- An image copy is a backup file that is identical to the input file. An image copy is immediately interchangeable with its source, whereas to extract a file from a backup set requires an RMAN restore operation.
RMAN backup and restore operations are carried out by server processes known as channels. A channel is either of type disk (meaning that it can read and write backups on disk) or of type SBT_TAPE (meaning that it is capable of reading and writing backups stored on a tape device).
The RMAN repository is metadata about backups: the names and locations of the pieces that make up the backup sets, and the files contained within them, and the names and locations of image copies. The repository is the key to automating restore and recovery operations: RMAN reads it to work out the most efficient way of restoring and recovering damaged datafiles. The repository is stored in the controlfile of the target database, and optionally in a set of tables created in a catalog database. Use of a catalog substantially enhances RMAN’s capabilities
Using the RMAN BACKUP Command to Create Backups
All the types of backup that RMAN can create are launched with the BACKUP command. Previous versions have a COPY command, used to create image copies, which is still supported for backward compatibility, but the functionality of this has now been subsumed into the BACKUP command.
Server-Managed Consistent Backups
We already know that consistent backup is cold backup, means the database need to be shutdown. But in rman, we need the database to be mount as rman need to access control file. Below are a simple consistent database backup example.
run { shutdown immediate; startup mount; allocate channel d1 type disk; backup as backupset database format 'd:\backup\offline_full_whole.bus'; alter database open; }
The script could be entered and executed interactively, from an RMAN prompt. Alternatively, if the script were written with an editor (such as vi on Unix or the Windows Notepad) and saved to a file offline_full_whole.rman, an operating system command that could be scheduled to run this script is rman target sys/oracle@orcl11g @offline_full_whole.rman
Server-Managed Open Backups
As we aready know, open backup means the database is open when we backup. Here is an example for open backup.
run { allocate channel t1 type sbt_tape; allocate channel t2 type sbt_tape; backup as compressed backupset filesperset 4 database; backup as compressed backupset archivelog all delete all input; }
An open or closed backup can be made of the entire database, one tablespace, or an individual file, as in these examples:
backup as backupset format '/backup/orcl/df_%d_%s_%p' tablespace gl_tabs; backup as compressed backupset datafile 4; backup as backupset archivelog like '/u01/archive1/arch_1%';
Incremental Backups
Why should you consider incremental backups? There are three major reasons: time, space, and the impact on end users. Even though the default operation of RMAN is to scan the whole datafile when backing it up incrementally in order to identify which blocks have changed, there will still be time savings because in virtually all cases it is the writing to tape that is the bottleneck, not the reading of the files. By enabling block change tracking (detailed later in this section), which obviates the need to scan the whole file, the time for the backup can be reduced dramatically.
An incremental backup relies on a starting point that contains all blocks: this is known as the incremental level 0 backup. Then an incremental level 1 backup will extract all blocks that have changed since the last level 1 backup, or the last level 0 backup if there have been no intervening level 1 backups. A cumulative backup will extract all blocks that have changed since the last level 0 backup, irrespective of whether there have been any level 1 backups in the meantime. An RMAN command to make a level 0 backup is:
backup as backupset incremental level 0 database;
This command relies on configured defaults for launching channels, for the number of files to place in each backup set, and to where the backup set will be written. The backup set will contain all blocks that have ever been used. Many sites will make an incremental level 0 backup every weekend. Then a level 1 backup can be made with this command:
backup as backupset incremental level 1 database;
This command could be run daily, to extract all blocks changed since the last level 1 (or, the first time it is run, the level 0) backup. A cumulative incremental backup might be run midweek:
backup as backupset incremental level 1 cumulative database;
Block change tracking relies on starting an additional background process: the Change Tracking Writer, or CTWR. This process records the address of each block that has been changed in a file called the change tracking file. If block change tracking has been enabled, then RMAN will read the change tracking file when doing an incremental backup to determine which blocks need to be backed up. This is far faster than scanning the whole file. The change tracking file will be created in a location specified by the DBA, or by default it will go to the DB_CREATE_FILE_DEST directory if this has been defined. It is initially sized at 10MB and will grow in 10MB increments, but unless the database is terabyte sized, 10MB will be adequate. The change tracking file is in the form of a
bitmap, with each bit covering 32 blocks of the database. There may be a minimal performance overhead to enabling block change tracking, but experience shows that this is not significant. To enable block change tracking and nominate the name and location of the tracking file, use a command such as this:
alter database enable block change tracking using file '/u01/app/oracle/oradaa/orcl/change_tracking.dbf';
To monitor the effectiveness of block change tracking, query the view V$BACKUP_ DATAFILE. This view is populated every time a datafile is backed up into a backup set: the column DATAFILE_BLOCKS is the size of the datafile, and BLOCKS_READ is the number of blocks read by the last backup. The ratio of these will show that block change tracking is reducing the number of blocks that must be read to carry out an incremental backup:
select file#, datafile_blocks, (blocks_read / datafile_blocks) * 100 as pct_read_for backup from v$backup_datafile where used_change_tracking-'YES' and incremental_level > 0;
image copy
An image copy of a file is a byte-for-byte identical copy of an individual datafile, controlfile, or archive log file. The result is exactly as though the file had been copied with an operating system utility, though the mechanism is different: RMAN reads and writes in Oracle blocks, not operating system blocks. This means that many of the great features of backup sets (such as incremental backup, compression, writing directly to tape, or controlling the size of the output pieces) cannot be used. But it does mean that a restore can be very fast, because there is no need to extract the file from a backup set.
Tape channels cannot be used for image copies, but if multiple files are to be copied, then parallelism can be considered. However, thought needs to be put into the degree of parallelism to be used. If all the copies are going to a single nonstriped disk, then there is little point in launching more than one disk channel. Also, the speed of backup to disk can have a negative impact on your users. A full-speed image copy will take up a significant amount of CPU and I/O capacity; this can be avoided by deliberately slowing down the backup process.
Image copies can be made of datafiles, the controlfile, and archive logs. Image copies cannot be made of the spfile. Although image copies are made on a file-for-file basis, RMAN does let you copy many files with one command. To back up the entire database,
RMAN> backup as copy database;
The follow-up command would be
RMAN> backup as copy archivelog all delete all input;
Protect Your Backups
RMAN can back up your live database and its archive log files, and it can also back up its own backups. These can in any case be protected with backup duplexing. Consider this command:
backup as backupset device type disk copies 2 database plus archivelog;
This will back up the entire database and any archivelogs to the default disk destination (the flash recovery area) using the default number of channels (one).
However, there will be two backup sets generated, each consisting (by default) of one piece, and each containing the entire database and its archivelogs.
Multiplexing the backups on disk in this manner gives a degree of protection, but it will be essential to transfer the backups to tape eventually. This could be accomplished as follows:
backup device type sbt_tape backupset all delete all input;
This command will locate the pieces of all known backup sets on disk and copy them into another backup set in the tape library, removing them from disk as it does so. An alternative technique is to use one of these commands, which are only valid if a tape library is available:
backup recovery area;
backup recovery files;
The first command backs up the flash recovery area (both current and any previous locations( oracle can know what is the orignal fast recofery area is if it is changed )) to tape, using defaults for the number of channels, sets, and pieces. The second command backs up all these recovery-related files, even if they are not in the flash recovery area.
This structure lets you create a three-tiered backup strategy:
- Primary storage is the live database, on disk.
- Secondary storage is the flash recovery area, on disk.
- Tertiary storage is the tape library.
A simple script to implement a backup strategy using three tiers of storage would be
run {backup recovery files delete all input;
backup database plus archivelog all delete all input;}
The first command will move all existing backups to tape, and the second command will create a new backup of the database and any archive logs, while
removing the logs from the LOG_ARCHIVE_DEST_n locations.
The DELETE ALL INPUT clause will not be applied to the live database; it only applies to archive logs and backups.
Parallelizing Backup Operations
Every time RMAN is used, there will be at least two sessions launched against the target database: these are known as the default session and the polling session. The default session is the session that invokes the kernelized PL/SQL (kernelized PL/SQL is PL/SQL that is available to the instance before a database has been mounted or opened) that implements RMAN; the polling session monitors the progress of RMAN operations. Whenever RMAN reads or writes a disk or tape, it will need a third session: a channel.
A database of many gigabytes will take a long time to back up, even if the backup is a fast incremental. To reduce the time taken, parallelize the backup by launching multiple channels. The degree of parallelism achieved will be constrained by the lowest of these factors:
- The number of channels
- The number of backup sets
- The number of input files
Each channel reads one or more files and writes one or more backups; the number of channels is therefore a hard limit on parallelism. However, parallelism is applied within a backup command, not across several backup commands, so if the command itself limits the number of backup sets generated, this may limit the degree of parallelism. Finally, it is not possible for the degree of parallelism to exceed the number of input files—unless the multisection backup capability is enabled.Consider this script:
run {allocate channel t1 type sbt; allocate channel t2 type sbt; allocate channel t3 type sbt; allocate channel t4 type sbt; backup database files per set 8;}
The first four lines launch four arbitrarily named channels. The backup command then forces RMAN to count the number of files in the database, and distribute them into backup sets containing no more than eight files each. If the database consists of 100 datafiles plus the controlfile, 13 backup sets will be generated: the first 12 will each contain 8 files, the thirteenth will have the remaining 5 files. The degree of parallelism will be 4: constrained by the number of channels. However, if the database had only 20 datafiles, there would be only 3 backup sets produced, and the degree of parallelism would be 3; one channel would be idle. If the database had only 4 datafiles, all would go into one backup set produced serially.
If a file is many gigabytes (or terabytes), then it will be desirable to parallelize the backup of this one file. Normally, only one channel can read a file, but by using the multisection keyword this behavior can be changed
run {allocate channel t1 type sbt; allocate channel t2 type sbt; allocate channel t3 type sbt; allocate channel t4 type sbt; backup as compressed backupset datafile 16 section size 10g;}
This script will launch four channels, each of which will read a series of 10GB sections of datafile 16. Each channel will generate pieces (separate physical files)
containing the backup of a section. If the file is 200GB, there will be 20 such pieces, generated four at a time. Without the SECTION SIZE keywords, the degree of parallelism would have been one (i.e., serial) and one channel would have carried out the entire operation.
Configuring RMAN Defaults
The Recovery Manager is meant to be easy to use out of the box, but the defaults may well not be appropriate for any one site. By configuring the defaults, RMAN’s operations can be customized to your environment. We can use show command to see the default configuration:
myserver[/export/home/oratop ] rman target sys/c21upg10@mydb Recovery Manager: Release 10.2.0.3.0 - Production on Thu Sep 26 11:21:22 2013 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: mydb(DBID=88888888) RMAN> show all; using target database control file instead of recovery catalog RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/opt/oratop/product/10.2.0/top_db/dbs/snapcf_c21upg10.f'; # default
You can use configure command to change the default configuration. You can use clear command to revert the configure to default.
RMAN> show device type; RMAN configuration parameters for database with db_unique_name ORCL are: CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED BACKUPSET; RMAN> configure device type disk clear; old RMAN configuration parameters: CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED BACKUPSET; RMAN configuration parameters are successfully reset to default value RMAN> show device type; RMAN configuration parameters for database with db_unique_name ORCL are: CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
Managing and Monitoring RMAN Backups
The RMAN executable provides commands for reporting on what backups have been made and what backups are required. The same information can also be obtained through the Database Control interface, or it is possible to query the RMAN repository directly by querying various views that are populated from it. If you are using a Recovery Catalog, this is another source of information. RMAN can also physically remove backups from tape and disk.
The LIST, REPORT, and DELETE Commands
As a general rule, LIST tells you about backups that have been made
| command | function |
| RMAN> list backup; | List all your backup sets. |
| RMAN> list copy; | List all your image copies. |
| RMAN> list backup of database; |
List all your whole database backup sets, |
|
RMAN> list backup of datafile 1; |
List the backup sets that include datafile 1 |
|
RMAN> list backup of archivelog all; |
List all archive log backup set backups. Use this |
|
RMAN> list copy of archivelog from time='sysdate - 7'; |
List all image copies of archive logs generated |
|
RMAN> list backup of archivelog from sequence 1000 until |
List all backup sets containing archive logs of |
To change the format of the dates and times in the output of LIST, set the environment variable NLS_DATE_FORMAT before launching the RMAN executable. For example, on Unix,
$ export NLS_DATE_FORMAT=dd-mm-yy hh24:mi:ss
The REPORT command interrogates the target database to determine what needs to be backed up. This requires contrasting the physical structure of the database and the archived logs that have been generated with the backup sets and copies as recorded in the repository, and applying a retention policy. The retention policy can be that configured as a default, or it can be specified as part of the REPORT command. This table shows some examples:
| command | function |
| RMAN> report schema; |
List the datafiles (but not the controlfile or archived |
| RMAN> report need backup; |
Apply the configured retention policy and list all the |
|
RMAN> report need backup |
List all objects that haven’t been backed up for three |
|
RMAN> report need backup |
List all files of which there are not at least three |
RMAN has a retention policy. This is a database-wide setting, which controls how many backups of each file RMAN will attempt to keep.
The REPORT OBSOLETE command takes things a step further: it contrasts the RMAN backups that have been taken with the retention policy and lists all those that can be deleted because they are no longer required. This command works in conjunction with DELETE OBSOLETE, which will remove the records of any such backups from the repository and physically remove the backup files from disk or tape. For example,
RMAN> report obsolete;
will apply the configured retention policy and list all copies and backup sets that are no longer required. Then,
RMAN> delete obsolete;
will remove the backups deemed surplus to requirements.
RMAN> report obsolete redundancy 2;
lists all backups that take the number of backups of an object to three or more. Then to remove the superfluous backups,
RMAN> delete obsolete redundancy 2;
Archival Backups
The Dynamic Performance Views
A number of views populated from the target database controlfile can be used to report on RMAN’s backups. By querying these, you can develop your own reports, rather than relying on RMAN’s LIST command.
| command | function |
| v$backup_files |
One row for each file that has been backed up, which may be a datafile, |
| v$backup_set | One row per backup set |
| v$backup_piece | One row per backup piece |
| v$backup_redolog | One row for each archived log that has been backed up |
| v$backup_spfile | One row for each backup that has been made of the spfile |
| v$backup_datafile | One row for backup of a datafile |
| v$backup_device | Names of SBT devices that have been linked to RMAN |
| v$rman_configuration | One row for every configuration setting, excluding all those on default |
Crosschecking Backups
The information used by the RMAN commands REPORT and LIST, and the information displayed in the dynamic performance views, is drawn from the RMAN repository: data stored in the controlfile of the target database. It says nothing about reality—whether the backup files actually still exist. To confirm that the backups do exist, use the CROSSCHECK command. For example:
RMAN> crosscheck backup of database; using channel ORA_DISK_1 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=/u01/app/oracle/flash_recovery_area/orcl/backupset/2008_10_20/ o1_mf_nnnd0_backup_orcl_000002_1_4hs9zcn8_.bkp RECID=5 STAMP=668623611 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=/u01/app/oracle/flash_recovery_area/orcl/backupset/2008_10_21/ o1_MF_nnnd1_tag20081020t165738_4hsbmv14_.bkp RECID=8 STAMP=668624267 Crosschecked 2 objects
This command queries the repository to find details of what whole backups have been made of the database, and then goes to the storage device(s) to see if the pieces do in fact exist. For pieces on disk, the disk directory is read and the file header validated; for pieces on tape, only the tape directory is read. Any pieces that no longer exist are flagged in the repository as EXPIRED. An expired backup will not be considered by RMAN when it works out how to carry out a restore and recover operation. In some circumstances (such as if a file system or a tape drive is taken offline), a crosscheck may mark many backups as expired; rerunning the crosscheck when the device is brought back into use will reset their status to AVAILABLE. A related command is
RMAN> delete expired;
This command will not delete any files from disk. It will, however, remove from the repository all references to backups previously marked EXPIRED by a crosscheck. At many installations, the tape library will automatically delete files according to their age: if this is happening, then a crosscheck followed by DELETE EXPIRED will update the RMAN repository to make it aware of what has happened
