RMAN(Recovery Manager)

（一）About RMAN

1. RMAN Architecture

1. target database

The work of backup and recovery is performed by server sessions running on the target database.

1. recovery catalog database

A database containing a recovery catalog, which contains metadata that RMAN uses to perform backup and recovery. catalog database只需定时逻辑备份下即可

1. physical standby database

RMAN can create, back up, or recover a standby database. Backups that you make at a physical standby database are usable at the primary database or another physical standby database for the same production database. The recovery catalog is required when you use RMAN to back up a physical standby database.

Note: A logical standby database is treated as a separate database by RMAN because it has a different DBID from its primary database.

1. auxiliary database

A physical standby database, or a database instance created for performing a specific task such as creating a duplicate database, transporting tablespaces, or performing tablespace point-in-time recovery (TSPITR).

For many tasks that use an auxiliary database, RMAN creates an automatic auxiliary instance for use during the task, connects to it, performs the task, and then destroys it when the task is completed. You do not give any explicit command to connect to automatic auxiliary instances.

1. RMAN只可备份文件

Data files and control files

Server parameter file

Archived redo logs

RMAN backups

无法备份redo log、parameter file、tempfile、pfile; 保护Redo log最好的办法就是多路复用，重做日志无法恢复意味数据直接丢失; Data file中不包含tempfile

Although the database depends on other types of files, such as network configuration files, password files, and the contents of the Oracle home, you cannot back up these files with RMAN. Likewise, some features of Oracle Database, such as external tables, may depend upon files other than the data files, control files, and redo log.

RMAN cannot back up these files. Use general-purpose backup software such as Oracle Secure Backup to protect files that RMAN does not support.

（二）Consistent and Inconsistent RMAN Backups

RMAN只在归档模式下可非一致备份，非一致备份提高了可用性，因为它不用关库；在非归档下RMAN只能在MOUNT状态下作一致性备份

1. Consistent RMAN Backup

A consistent backup occurs when the database is in a consistent state. 

A database is in a consistent state after being shut down with the SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL commands. A consistent shutdown guarantees that all redo has been applied to the data files. If you mount the database and make a backup at this point, then you can restore the database backup later and open it without performing media recovery.

1. Inconsistent RMAN Backups

Any database backup that is not consistent is an inconsistent backup. A backup made when the database is open is inconsistent, as is a backup made after an instance failure or SHUTDOWN ABORT command.

When a database is restored from an inconsistent backup, Oracle Database must perform media recovery before the database can be opened, applying changes from the redo logs that took place after the backup was created.

（三）Fractured Block of Online Backups

因为oracle blocks是由多个OS BLOCKS组成，在不使用RMAN的online备份时会产生碎块导致备份无法恢复使用

When performing a user-managed backup of an online tablespace or database, an operating system utility can back up a data file at the same time that the database writer (DBWR) is updating the file. It is possible for the utility to read a block in a half-updated state, so that the block that is copied to the backup media is updated in its first half, while the second half contains older data. This type of logical corruption is known as a fractured block, that is, a block that is not consistent with an SCN. If this backup must be restored and the block requires recovery, then recovery fails because the block is not usable.

在使用第三方快照机制备份时，你要同时用下面之一方法不产生碎块

For third-party snapshot technologies, you must use one of the following techniques to eliminate the risk of creating fractured blocks:

1. Ensure that the snapshot technology complies with Oracle requirements for online backups
2. Take the database or data files offline
3. Place the database in backup mode before using a third-party snapshot backup

RMAN有机制检查是否产生碎块，如果有则进行重读

Unlike user-managed tools, RMAN does not require extra logging or backup mode because it knows the format of data blocks. RMAN is guaranteed not to back up fractured blocks.

During an RMAN backup, a database server session reads each data block and checks whether it is fractured by comparing the block header and footer. If a block is fractured, then the session rereads the block. If the same fracture is found, then the block is considered permanently corrupt. Also, RMAN does not need to freeze the data file header checkpoint because it knows the order in which the blocks are read, which enables it to capture a known good checkpoint for the file.

（四）Backup Sets

Backup sets(BS)包含一个或多个Backup pieces(BP)

BS是逻辑概念，而BP对应备份后的物理文件

RMAN can store backup data in a logical structure called a backup set, which is the smallest unit of an RMAN backup. A backup set contains one or more binary files in an RMAN-specific format. Each of these files is known as a backup piece. A backup set can contain multiple data files.

1. Block compression and Binary compression for Backup Sets

备份集的压缩有两种方式block compression与binary compression

Block compression

RMAN block compression is not traditional binary compression. Rather, it is a set of techniques that RMAN uses to altogether avoid backing up certain blocks that are not needed in this backup.

The following types of block compression are available:

1. Unused Block Compression (Supports disk backup and Oracle Secure Backup tape backup)

Unused Block Compression指数据文件碎片，即频繁创建删除对象产生的碎片

When employing unused block compression, RMAN skips reading, and backing up, any database blocks that are not currently allocated to some database object. This is regardless of whether those blocks had previously been allocated.

So if a database table is dropped, RMAN will not back up the space that was occupied by that table until new objects are created in that space.

Unused block compression is used automatically when the following conditions are true:

1. The COMPATIBLE initialization parameter is set to 10.2 or higher.
2. There are currently no guaranteed restore points defined for the database.
3. The data file is locally managed.
4. The data file is being backed up to a backup set as part of a full backup or a level 0 incremental backup.
5. The backup set is created on disk, or Oracle Secure Backup is the media manager.

1. Null Block Compression (Supports all backups)

Null Block Compression指对象内碎片，即频繁增删记录产生的碎片，即它包括HWM以下未使用的blocks

When employing null block compression, RMAN omits from its output any block that has never contained data.

Null block compression is always used with level 0 or full backups that are created in backup set format.

Binary Compression

详见《Configuring the RMAN Environment》中关于压缩设置

You have two binary compression options:

1. You can use the BASIC compression algorithm, which does not require the Oracle Advanced Compression option. This setting offers a compression ratio comparable to MEDIUM, at the expense of additional CPU consumption.
2. If you have enabled the Oracle Advanced Compression option, you can choose from the compression levels outlined in "About Oracle Advanced Compression Option".

1. RMAN Backup Undo Optimization

In backup undo optimization, RMAN excludes undo not needed for recovery of a backup, that is, for transactions that have been committed.

Backup undo optimization works for disk backups and Oracle Secure Backup tape backups.

不同于RMAN Configure设置的优化选项，Undo Optimization是默认行为

Unlike backup optimization, backup undo optimization is not configurable.

1. RMAN Proxy Copies

在代理复制期间，RMAN 会将数据传输的控制权移交给支持此功能的媒体管理器

During a proxy copy, RMAN turns over control of the data transfer to a media manager that supports this feature.

Proxy copy can only be used with media managers that support it and cannot be used with channels of type DISK. The PROXY option of the BACKUP command specifies that a backup is a proxy copy.

For each file that you attempt to back up with the BACKUP PROXY command, RMAN queries the media manager to determine whether it can perform a proxy copy. If the media manager cannot proxy copy the file, then RMAN backs up the file as if the PROXY option had not been used. (Use the PROXY ONLY option to force RMAN to fail if a proxy copy cannot be performed.)

Control files are never backed up with proxy copy. If the PROXY option is specified on an operation backing up a control file, then it is silently ignored for the purposes of backing up the control file.

（五）RMAN Image Copies

Image copies are not stored in an RMAN-specific format. They are identical to the results of copying a file with operating system commands.

RMAN can use image copies during RMAN restore and recover operations, and you can also use image copies with non-RMAN restore and recovery techniques.

（六）RMAN Incremental Backups

An incremental backup copies only those data blocks that have changed since a previous backup. You can use RMAN to create incremental backups of data files, tablespaces, or the whole database.(控制及日志文件不会增量备)

非归档在mount下也可进行增量备份

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.

1. Multilevel Incremental Backups

A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy. Thus, an incremental level 0 backup is a full backup that happens to be the parent of incremental backups whose level is greater than 0.

RMAN> BACKUP INCREMENTAL LEVEL 0 AS COMPRESSED BACKUPSET DATABASE;

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

1. A differential incremental backup, which backs up all blocks changed after the most recent incremental backup at level 1 or 0
2. A cumulative incremental backup, which backs up all blocks changed after the most recent incremental backup at level 0

一般全备不能作为增量全备使用，0级备份可以为backupset或image cope，但后续增量需要为backupset

Incremental backups at level 0 can be either backup sets or image copies, but incremental backups at level 1 can only be backup sets.

1. Differential Incremental Backups(default) 差异增量备

In a differential level 1 backup, RMAN backs up all blocks that have changed since the most recent incremental backup at level 1 (cumulative or differential) or level 0.

如果在当前及父化身没有level 0备份，这时进行差异增量备份跟compatibility相关

If no level 0 backup is available in either the current or parent incarnation, then the behavior varies with the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all blocks that have been changed since the file was created. Otherwise, RMAN generates a level 0 backup.

RMAN>BACKUP INCREMENTAL LEVEL 1 [DIFFERENTIAL] AS BACKUPSET DATABASE;

1. Cumulative Incremental Backups 累积增量备

In a cumulative level 1 backup, RMAN backs up all blocks used since the most recent level 0 incremental backup in either the current or parent incarnation.

RMAN>BACKUP INCREMENTAL LEVEL 1 CUMULATIVE AS BACKUPSET DATABASE;

1. Block Change Tracking(BCT)

增量备份只减少备份空间，备份时间未明显减少，因为还要遍历整个数据文件块查看需要增量备份块，BCT可减少增量备份所需时间。

块变更跟踪在后台启动一个进程叫 CTWR，这个进程向change tracking file中记录每个已更改的块的地址，这个过程也是有性能损耗的，可以在DG备库上配置

If block change tracking is enabled, then RMAN uses the change tracking file to identify changed blocks for incremental backups, thus avoiding the need to scan every block in the data file. RMAN only uses block change tracking when the incremental level is greater than 0, because a level 0 incremental backup includes all blocks.

block change tracking file由Oracle自动管理重新利用的bitmap文件，默认创建目录为DB_CREATE_FILE_DEST指定。RAC需要放在共享设备上

The block change tracking file is a small binary file stored in the database area.Database area is a location for the Oracle managed data files, control files, and online redo log files. The database area is specified by the DB_CREATE_FILE_DEST initialization parameter. RMAN tracks changed blocks as redo is generated.

In an Oracle Real Application Clusters (Oracle RAC) environment, the change tracking file must be located on shared storage accessible from all nodes in the cluster.

Change trace file会只在最近的8个备份信息，你可以在定制增量备份策略时考虑此因素，如自0级备份后你做了7次差异增量，然后又做了一次累计增量，此累计增量将无法被优化，因为它覆盖了change trace file中的0级备份信息

Oracle Database automatically manages space in the change tracking file to retain block change data that covers the eight most recent backups. After the maximum of eight bitmaps is reached, the oldest bitmap is overwritten by the bitmap that tracks the current changes.

Consider the eight-bitmap limit when developing your incremental backup strategy. For example, if you make a level 0 database backup followed by seven differential incremental backups, then the block change tracking file now includes eight bitmaps.

If you then make a cumulative level 1 incremental backup, then RMAN cannot optimize the backup, because the bitmap corresponding to the parent level 0 backup is overwritten with the bitmap that tracks the current changes.

RMAN不支持对change tracking file的备份与恢复，当检测到change tracking file无效时会重置文件. 如果RESTORE或RECOVER也会重置此文件

RMAN does not support backup and recovery of the change tracking file. The database resets the change tracking file when it determines that the change tracking file is invalid. If you restore and recover the whole database or a subset, then the database resets the block change tracking file and starts tracking changes again. After you make a level 0 incremental backup, the next incremental backup can use change tracking data.

block change tracking file大小与数据库大小及redo线程数相关，与块更新频率无关

The size of the block change tracking file is proportional to the size of the database and the number of enabled threads of redo. The size is not related to the frequency of updates to the database.

Typically, the space required for block change tracking for a single instance is approximately 1/30,000 the size of the data blocks to be tracked. For an Oracle RAC environment, it is 1/30,000 of the size of the database, times the number of enabled threads.

The following factors that may cause the file to be larger than this estimate suggests:

1. To avoid the overhead of allocating space as your database grows, the block change tracking file size starts at 10 megabytes. New space is allocated in 10 MB increments. Thus, for any database up to approximately 300 gigabytes, the file size is no smaller than 10 MB, for up to approximately 600 gigabytes the file size is no smaller than 20 megabytes, and so on.
2. For each data file, a minimum of 320 kilobytes of space is allocated in the block change tracking file, regardless of the size of the data file. Thus, if you have a large number of relatively small data files, the change tracking file is larger than for databases with a smaller number of larger data files containing the same data.

示例：

alter database enable block change tracking;

alter database disable block change tracking;

alter database enable block change tracking using file '/xxx/change_tracking.dbf' reuse;

alter system set db_create_file_dest='/oracle' scope=both sid='*';

改此trace file位置要在mount下先把这个文件在OS上移动到对应位置，然后执行：

alter database rename file '/XXX/change_tracking.dbf' to '/XXX/1.dbf';

不能停机也可先关闭BCT再重新开启时指定新位置，这样会丢失之前文件数据

col status format a8

col filename format a60

select * from v$block_change_tracking;

STATUS   FILENAME                                                   BYTES

-------- ------------------------------------------------------------

ENABLED  /oracle/ORCL/changetracking/o1_mf_ft62nz97_.chg                11599872

1.  Incremental Backup Algorithm

1. Checkpoint SCN

Checkpoint SCN是数据文件保证所有块恢复到的SCN

Every data file has a data file checkpoint SCN, which you can view in V$DATAFILE.CHECKPOINT_CHANGE#. All changes with an SCN lower than this SCN are guaranteed to be in the file. When a level 0 incremental backup is restored, the restored data file contains the checkpoint SCN that it had when the level 0 was created.

增量备份是0级备份checkpoint scn之后的变动

When a level 1 incremental backup is applied to a file, the checkpoint SCN of the file is advanced to the checkpoint SCN that the file had when the incremental level 1 backup was created.

1. Incremental start SCN

Incremental start SCN是1级增量备份特有的SCN，它表示增量起始SCN

This SCN applies only to level 1 incremental backups. All blocks whose SCN is greater than or equal to the incremental start SCN are included in the backup. Blocks whose SCN is lower than the incremental start SCN are not included in the backup. The incremental start SCN is most often the checkpoint SCN of the parent of the level 1 backup.

1. Block SCN

Every data block in a data file records the SCN at which the most recent change was made to the block.

在做增量备份时RMAN会检查并备份所有BLOCKS SCN大于或等于INCREMENTAL SCN的BLOCK. 而在使用BCT时，RMAN使用bitmaps来避免了从INCREMENTAL SCN到当前数据文件的CHECKPOINT SCN期间未做更改的BLOCKS

When RMAN makes a level 1 incremental backup of a file, RMAN reads the file, examines the SCN of every block, and backs up blocks whose SCN is greater than or equal to the incremental start SCN for this backup. If the backup is differential, then the incremental start SCN is the checkpoint SCN of the most recent level 1 backup. If the backup is cumulative, then the incremental start SCN is the checkpoint SCN of the most recent level 0 backup.

When block change tracking is enabled, RMAN uses bitmaps to avoid reading blocks that have not changed during the range from incremental start SCN to checkpoint SCN. RMAN still examines every block that is read and uses the SCN in the block to decide which blocks to include in the backup.

增量备份可用恢复NOLOGGING操作

One consequence of the incremental backup algorithm is that RMAN applies all blocks containing changed data during recovery, even if the change is to an object created with the NOLOGGING option. Thus, if you restore a backup made before NOLOGGING changes were made, then incremental backups are the only way to recover these changes.

1. Recovery with Incremental Backups

If it has a choice, then RMAN always chooses incremental backups over archived redo logs because applying changes at a block level is faster than applying redo.

增量备份恢复时并不需要还原0级备份再应用增量备份

RMAN does not need to restore a base incremental backup of a data file to apply incremental backups to the data file during recovery. For example, you can restore data file image copies and recover them with incremental backups.

1. 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.

可以考虑在20%或更多数据改变时进行0级备份

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.

下面查询为1级增量写入blocks占整个备份文件的百分比超20%的数据文件

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.