RMAN BACKUP

转自 RMAN BACKUP

backup terminology

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

config rman defaults

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, whether full or incremental.
RMAN> list backup of datafile 1; RMAN> list backup of tablespace users;	List the backup sets that include datafile 1 and the backups that include the USERS tablespace.
RMAN> list backup of archivelog all;	List all archive log backup set backups. Use this command or the next to investigate backups of archive logs.
RMAN> list copy of archivelog from time='sysdate - 7';	List all image copies of archive logs generated in the last seven days.
RMAN> list backup of archivelog from sequence 1000 until sequence 1050;	List all backup sets containing archive logs of log switch sequence numbers 1000–1050.

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 logs) that make up the database.
RMAN> report need backup;	Apply the configured retention policy and list all the datafiles and archive log files that need at least one backup to conform to the policy.
RMAN> report need backup days 3;	List all objects that haven’t been backed up for three days. Use this command or the next to ignore the configured retention policy.
RMAN> report need backup redundancy 3;	List all files of which there are not at least three backups.

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, the spfile, the controlfile, or an archive log. Also, one row for each piece that RMAN has created. The column FILE_TYPE distinguishes which type of file the row refers to.
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