RMAN备份概念
本篇介绍下关于RMAN备份的一些概念，主要包含下面的主题：
- 一致性和不一致性RMAN备份
- 在线备份和备份模式
- 备份集（BACKUP Sets）
- 镜像备份（Image Copies）
- Rman的多副本备份
- 控制文件和服务器参数文件自动备份
- 增量备份
- 备份保留策略
一致性和不一致性RMAN备份
RMAN备份的命令是BACKUP，该命令支持备份下面类型的文件：
- 数据文件和控制文件
- 服务器参数文件Spfile
- 归档重做日志
- RMAN备份
尽管Oracle数据库依赖于其他类型的文件，如网络配置文件、密码文件和Oracle Homer目录的内容，但是你不能使用RMAN备份这些文件。同样的，一些Oracle数据库的特性，比如外部表，可能依赖于其他文件，而不是数据文件和重做日志文件。RMAN也不能备份这些文件，对于没有在上面的列表中的其他文件，需要使用非RMAN备份方案。
当你在RMAN客户端执行BACKUP命令时，输出要么是一个或多个备份集，或者是一个或多个镜像副本。备份集是RMAN特有的一种格式，而镜像副本是文件的bit-for-bit副本。默认情况下，RMAN创建备份集。
一致性备份（Consistent Backups）
可以使用BACKUP命令进行数据库的一致性备份和不一致性备份。使用SHUTDOWN Normal、SHUTDOWN IMMEDIATE或者SHUTDOWN Tranactional命令关闭数据库时，数据库处于一致性状态，此时进行的数据库备份是一致性备份。一致性关闭数据库保证了所有的重做日志都已经应用于数据文件。如果此时Mount数据库并进行备份，那么稍后还原数据库备份并打开它时不需要进行介质恢复。
不一致性备份（Consistent Backups）
任何处于不一致状态下的数据库备份是不一致性备份。当数据库打开时进行的备份是不一致性备份，就像实例故障或者使用SHUTDOWN Abort命令后进行的备份。当数据库从不一致备份进行恢复时，Oracle数据库必须在数据库打开前进行介质恢复，并应用重做日志中挂起的更改。
注意：当数据库处于非归档（NOArchiveLog）模式时，RMAN不允许进行不一致性备份。
如果数据库运行于归档（ArchiveLog）模式，备份归档重做日志文件和数据文件，那么不一致性备份可以作为备份和恢复策略的基础。不一致性备份提供了更大的可用性，因为可以在不关闭数据库的情况下进行数据库的备份操作。
在线备份和备份模式
当执行一个在线表空间或数据库的用户管理的备份时，操作系统实用程序可以在数据库写（DBWR）进程更新数据文件的同时进行备份数据文件。在这种情况下，实用程序很可能在一个半更新状态（a half-updated state）读取一个数据块，因此被拷贝到备份介质的数据块被更新了它的前半部分，后半部分则包含着旧的数据。这种类型的逻辑损坏（Logical Corruption）称为分割块（Fractured block），也就是说该数据块和SCN不一致。如果这个备份以后被还原并且这个块需要恢复，那么将会因为块不可用而导致恢复失败。
当执行用户管理的在线备份时，必须使用带有Begin Backup的ALTER Database或者Alter Tablespace语句把数据文件置为备份模式（BACKUP mode）。当表空间处于备份模式时，数据库在更新块之前会把整个块的前映像写到重做流，数据库也会在在线重做日志中记录对数据块的更改。备份模式会冻结数据文件的检查点，直到备份过程结束，Oracle数据库会执行这个安全的保护机制，因为它不能保证第三方的备份工具在拷贝数据块之前先拷贝数据文件头信息。
与用户管理的备份不同，RMAN不需要额外的日志或者备份模式，因为它知道数据块的格式。RMAN不会备份断裂的块，在RMAN备份期间，数据库服务器会话读取每一个数据块并且通过比较块头和块尾来检查该块是否被分割，如果该块被分割，那么会话会重新读取该块。如果同样的分割被发现，那么这个块将被认为是永久性的损坏。另外，RMAN不需要冻结数据文件头检查点，因为它知道读取数据块的顺序，这使得它能够捕获文件的一个已知的良好的检查点。
备份集（BACKUP set）
当你在RMAN执行备份（BACKUP）命令时，将会创建一个或多个备份集或镜像拷贝。默认情况下，RMAN创建备份集，而不考虑目的地是磁盘或是介质管理器。通常情况下，备份集比数据文件镜像拷贝更小，而且写入时花的时间更少。
备份集和备份片（BACKUP Sets and Backup Pieces）
RMAN把备份数据存储在一个称为备份集的逻辑结构中，备份集是RMAN备份中最小的单元，备份集包含来自一个或多个数据文件、归档重做日志文件、控制文件或者服务器参数文件的数据。备份集由RMAN创建和访问，也是RMAN将备份写到介质管理器的唯一的形式。
备份集包含一个或多个RMAN格式的二进制文件，每一个备份文件称为备份片。一个备份集可以包含多个数据文件，例如：你可以将10个数据文件备份到一个由单个备份片组成的单个备份集，在这种情况下，RMAN创建一个备份片作为输出，则该备份集仅包含一个备份片。
如果你在BACKUP命令中指定Section Size参数，那么RMAN将产生一个Multisection backup。对于单个大文件的备份，由多个通道（Channel）并行产生，每一个通道产生一个备份片，每一个备份片包含备份的文件的一部分，这部分称为一个file section 。
对于Non-multisection备份，RMAN仅在信息库中记录成功完成的备份集。不会存在只备份一部分的备份集的情况，这与Mutisection备份失败时不同，当multisection backup备份失败时，它可能包含部分备份集的RMAN元数据，在这种情况下，需要使用Delete命令删除这部分备份集。
镜像备份（Image Copies）
镜像拷贝是单个数据文件、归档重做日志文件或者控制文件的精确副本，不以RMAN特有的格式存储。镜像拷贝和使用操作系统命令拷贝文件的结果相同，在RMAN还原和恢复操作中可以使用镜像副本，也可以在非RMAN还原和恢复技术中使用镜像副本。
RMAN创建的镜像副本
创建镜像副本并将它记录在RMAN信息库，你需要运行RMAN的BACKUP As Copy命令，你可以将磁盘的默认备份类型配置为镜像副本，数据库服务器会话用于创建副本，它还可以执行一些操作，例如验证文件中的数据块和把镜像副本记录在RMAN信息库中。
用户管理的镜像副本
RMAN也可以使用非RMAN建立的镜像副本，但是需要使用Catalog命令检查并把它的元数据导入到RMAN信息库。
Rman的多副本备份
在RMAN中，你可以通过下面方式创建多个、相同副本的备份：
- 使用BACKUP...Copies命令多重备份，它可以为每一个备份集创建多个副本；
- 备份你的文件为备份集或镜像拷贝，然后使用RMAN的BACKUP BACKUPSET或者BACKUP copy of命令备份已备份的备份集或镜像拷贝。
多重备份集（Duplexed Backup Sets）
当把数据文件、归档重做日志文件、服务器参数文件、控制文件备份为备份片时，RMAN能够创建多重备份集，使用一个Backup命令可以为在不同备份位置的备份集中的备份片生成多达4个相同的副本，多重备份不支持镜像拷贝（Image Copies）操作。
在使用Backup命令的时候，你可以在Configure、Set或者Backup命令的Copies参数中指定多重备份，RMAN可以在磁盘或者磁带上进行多重备份，但是不能同时备份到磁带和磁盘。备份到磁带时，需要确保拷贝数不能超过可用的磁带设备的数量。
Backup命令的Format参数指定多重备份的目的地，下面的例子为数据文件7创建3个备份副本：
BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7 FORMAT '/disk1/%U','?/oradata/%U','?/%U';
备份的备份（Backups of Backups）
你能够使用Backup命令备份已经存在的备份集或者镜像拷贝。
1、备份备份集
使用Backup Backupset命令备份备份集。
BACKUP DEVICE TYPE DISK AS BACKUPSET
DATABASE PLUS ARCHIVELOG;
BACKUP
DEVICE TYPE sbt
BACKUPSET ALL; # copies backup sets on disk to tape
BACKUP DEVICE TYPE sbt
BACKUPSET COMPLETED BEFORE 'SYSDATE-7'
DELETE INPUT;
2、备份镜像（Backups of Image Copies）
使用Backup Copy of指令备份已经存在的数据库文件镜像副本，它们可以是备份集或镜像备份。当使用这个命令时，指定的数据文件副本必须存在，如果有多个数据文件副本，那么将会使用最新的一个。如果指定了一个表空间或整个数据库，那么如果数据库或者表空间中存在没有镜像副本备份的数据文件，那么RMAN执行将会出现错误。
控制文件和服务器参数文件自动备份
使用控制文件自动备份，即使在当前控制文件、恢复目录或服务器参数文件不可访问的情况下，RMAN也能够恢复数据库，因为存储备份的路径遵从了一种已知的格式，RMAN能够从自动备份中搜索并恢复服务器参数文件。使用已恢复的服务器参数文件启动实例后，RMAN可以从自动备份恢复控制文件，在装载（Mount）控制文件后，进而可以使用控制文件中的RMAN信息库来恢复数据文件。
RMAN何时执行控制文件自动备份
如果配置Configure Controlfile Autobackup为On，那么RMAN在成功执行Backup命令完成备份后会自动备份控制文件和当前的服务器参数文件。如果数据库处于归档模式，当影响控制文件内容的数据库结构变化时，RMAN也将自动备份控制文件。
RMAN怎样执行控制文件自动备份
在备份作业分配的第一个通道创建自动备份，并将其放置到它自己的备份集中。对于数据库结构变化后的自动备份，与数据库结构变化相关的服务器进程会创建相应的自动备份。
如果数据库使用了服务器参数文件，那么RMAN将会把它备份到和控制文件自动备份相同的备份集中。在自动备份完成后，数据库会写一条包含备份片的完整路径和设备类型的信息到位于ADR（Automatic Diagnostic Repository）的警报日志（Alert log）中。
对于所有的设备类型，控制文件自动备份文件的名字都有一个默认的格式%F，这样RMAN就可以决定文件的位置，并能在没有信息库的情况下恢复它。你也可以使用Configure Controlfile Autobackup Format命令指定一个不同的格式，但是所有的自动备份格式都必须包含%F变量。如果不使用默认格式，那么在灾难恢复期间，必须指定其格式，否则，RMAN不能恢复它。
增量备份（Incremental Backups）
默认情况下，RMAN做全库备份。数据文件的全备包括文件中已分配的所有块，数据文件的全备可以是镜像拷贝，也可以是备份集，前者会备份所有数据块，后者则可能会跳过未使用的块。
完全备份是RMAN备份的默认类型，它不会对后续的增量备份有影响，但是它不是增量备份策略的一部分。镜像备份总是完全备份，因为它包含数据文件的每一个数据块。默认情况下，备份集是一个完全备份，因为它可能包含数据文件的每个数据块，尽管未使用的块压缩意味着从没被使用的块被排除，在某些情况下，当前未被使用的块也被排除。
和完全备份相比，增量备份只是备份自上次备份以来发生变化的数据块。你可以使用RMAN命令创建数据文件、表空间或者整个数据库的增量备份，完全备份不是增量备份策略的一部分，因为它不是后续增量备份的基础。
多级增量备份（Multilevel Incremental Backups）
RMAN可以创建多级增量备份，每一个增量级别表示为0或1。0级增量备份是后续增量备份的基础，它会复制包含数据的所有块，你可以创建一个0级数据库备份作为备份集或镜像副本。
0级增量备份和完全备份的唯一区别是完全备份不能作为增量备份策略的基础，因此，0级增量备份是一个完全备份，是增量备份级别大于0的父级，是增量备份的基础。
1级增量备份可以是下面类型之一：
- 差异增量备份：备份最近的0级或1级增量备份后，所有更改的数据块。
- 累积增量备份：备份最近的0级增量备份后所有更改的数据块。
增量备份默认使用差异增量备份。
差异增量备份
说明：
- 周日
增量0级备份备份数据库中使用过的所有数据块。
- 周一到周六
从周一到周六的每一天，一个差异增量1级备份备份从最近的0级或1级增量备份以来所有更改过的数据块。周一的备份拷贝从 周日0级备份以来更改过的数据块，周二的备份拷贝从周一1级备份以来更改过的数据块，以此类推。
累积增量备份
说明：
- 周日
增量0级备份备份数据库中使用过的所有数据块。
- 周一到周六
累积增量1级备份拷贝从最近的0级备份以来所有更改过的数据块。因为最近的0级备份在周日创建，那么从周一到周六的每一 天1级备份都会备份自周日备份以来所有更改过的数据块。
块更改跟踪（Block Change Tracking）
对于增量备份来说，块更改跟踪特性改善了增量备份的性能，它是通过在块更改跟踪文件中记录每一个数据文件的更改的数据块来实现。块更改跟踪文件是一个存储在数据库区域中的较小的二进制文件，当Redo产生的时候，RMAN跟踪更改的块。
如果启用了块更改跟踪特性，那么RMAN将使用更改跟踪文件来识别更改的数据块，从而避免扫描数据文件中所有的数据块。0级增量备份包括了所有数据块，因此RMAN仅仅在增量级别大于0时使用块更改跟踪。
增量备份算法
下面的概念对于理解RMAN用来进行增量备份的算法是非常必要的。
- 检查点SCN（Checkpoint SCN）
每个数据文件都有个数据文件检查点SCN，可以在视图V$DATAFILE.CHECKPOINT_CHANGE#看到，所有低于该SCN的更改 都会保证存在于文件中，当0级增量备份被恢复时，恢复的数据文件中包含创建0级备份时的检查点SCN；当1级增量备份被应 用到这个文件时，这个文件的检查点SCN被推进，推进到的SCN与进行1级增量备份时创建的文件的检查点SCN相同。
- 增量起始SCN（Incremental start SCN）
这个SCN仅适用于1级增量备份。所有的数据块都会被包含在备份中，如果块的SCN大于或等于增量起始SCN，反之，则不会 被包含在备份中。增量起始SCN通常是1级增量备份的父级检查点SCN。
- 数据块SCN（Block SCN）
数据文件中的每个数据块记录了对该块所做的最近更改的SCN。
当RMAN对一个文件进行1级增量备份时，RMAN读取文件，并检查每个块的SCN，并备份SCN大于或等于增量起始SCN的块。如果是差异备份，那么增量起始SCN是最近的1级备份的检查点SCN，如果是累积备份，那么增量起始SCN是最近的0级备份的检查点SCN。
当启用块更改跟踪时，RMAN使用位图来避免读取从增量起始SCN到检查点SCN之间没有变化的块，RMAN仍然检查被读取的每一个块，并使用块中的SCN来决定备份中应该包含哪些块。
增量备份算法的一个后果是，RMAN在恢复过程中应用包含更改的数据的所有数据块，即使更改是使用NOLOGGING选项创建的对象。如果在进行NOLOGGING更改之前还原了备份，那么增量备份时恢复这些更改的唯一方法。
使用增量备份恢复
在介质恢复期间，RMAN检查被恢复的文件，以确定是否可使用增量备份来恢复它们。如果可以，RMAN总是会选择使用增量备份，而不是使用归档重做日志，因为在块级别上应用更改比应用Redo更快。
备份保留策略
你可以使用Configure Retention policy命令来创建持久的和自动的备份保留策略。当备份保留策略生效时，RMAN会将数据文件或控制文件的备份作为过时的备份，即根据在Configure命令指定的标准，不再需要恢复。可以使用Report Obsolete命令查看过时的文件，使用Delete Obsolete命令来删除它们。
简言之：Obsolete表示一个文件不再需要，Expired表示该文件不能找到，即obsolete means a file is not needed, whereas expired means it is not found。
有两种备份保留策略，分别为：冗余和恢复窗口。
恢复窗口（Recovery Window）
恢复窗口是一个时间区间，从当前时间开始，并向后延长到可恢复的点的那个时间。可恢复的点是一个假设的时间点恢复的最早时间，也就是说，介质故障后你能够进行恢复的最早的那个时间点。例如，如果你实现了一个1周的恢复窗口，那么RMAN将保留完整的备份，需要的增量备份和归档的日志，以便可以在过去的7天内恢复数据库。可以使用下面的命令实现：
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
SYSDATE - Backup Checkpoint Time > = 7
所有满足此条件的最近的备份都是过时（Obsolete）的。
假设保留策略如下图，保留政策有以下几个方面：
- 恢复窗口是7天
- 数据库备份每两周在下面的天调度
- January 1
- January 15
- January 29
- February 12
- 数据库运行在归档模式，保留政策需要，归档日志保存在磁盘上
图一：
说明：
As illustrated , the current time is January 23 and the point of recoverability is January 16. Hence, the January 14 backup is needed for recovery, and so are the archived logs from log sequence 500 through 850. The logs before 500 and the January 1 backup are obsolete because they are not needed for recovery to a point within the window.
图二：
说明：
In this scenario, the current time is January 30 and the point of recoverability is January 23. Note how the January 14 backup is not obsolete even though a more recent backup (January 28) exists in the recovery window. This situation occurs because restoring the January 28 backup does not enable you to recover to the earliest time in the window, January 23. To ensure recoverability to any point in the window, you must save the January 14 backup and all archived logs from sequence 500 to 1150.
备份冗余（Backup Redundancy）
在某些情况下，使用恢复窗口可以使磁盘空间规划变得复杂，因为必须保留的备份数不是固定的，这取决于备份计划。相反，基于冗余的保留策略指定必须保留的每个数据文件的备份数量。默认冗余保留策略是1，例如，可以配置冗余为2 ：
RMAN> configure retention policy to redundancy 2;
old RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
批量删除过时的备份（Batch Deletes of Obsolete Backups）
根据备份保留策略，你可以运行Report Obsolete命令来决定哪些备份是过时的，然后可以使用Delete Obsolete命令删除过时的文件。你可以定时运行Delete Obsolete命令来释放空间，以减少过时的备份对空间的占用。
当然，你也可以通过指定Report或Delete命令的Redundancy或Recovery Window选项来覆盖已配置的保留策略，例如：配置的保留窗口为14天，你可以执行下面的命令：
RMAN> Delete obsolete recovery window of 7 days;
备份保留策略和快闪恢复区删除规则
RMAN的状态Obsolete取决于备份保留策略。如果在RMAN信息库一个数据库备份被认为是过时的，那是因为它要么在恢复窗口里不再需要恢复到某个时点，要么是冗余的。
如果配置了快速恢复区，那么数据库会使用一个内部算法来选择快速恢复区中不再满足备份保留策略的文件，这些备份的状态是Obsolete，可以删除以满足磁盘配额规则。当决定哪些文件从快闪恢复区删除来满足磁盘配额规则的时候，不会违背备份保留策略。
在快闪恢复区的过时（Obsolete）状态规则和磁盘配额删除规则之间有一个重要的区别，假设在磁盘上有序列号1000到2000 的归档日志，在当前恢复窗口内是需要的，因此不是过时的。如果把这些日志备份到磁带，那么保留策略认为这些磁盘日志也是需要的，因此，也不是过时的。然而，快速恢复区磁盘配额算法认为磁盘上的日志可以被删除，因为它们已经被备份到磁带。磁盘上的日志在RMAN信息库的状态不是过时（Obsolete）的，但是它们可以被快闪恢复区删除。
参考：Oracle官方文档