Oracle Database 12c RMAN全量+增量备份+归档日志恢复详解

Oracle可以非常方便的把数据库恢复到具体某个时间的状态，而且还支持全备和多级增备，备份无需停止应用服务。比起DB2需要手动逐级恢复增量备份和归档日志，RMAN是非常简单好用的数据库商业解决方案。

下面是我的环境：

操作系统：CentOS 6.7

Oracle版本：Oracle Database 12c Release 2（12.2.0.1.0）

数据库Sid：recovery

数据库归档：开启

数据库归档位置：/home/alex/db_backup

fast_recovery_area:开启

fast_recovery_area位置：/u01/fast_recovery_area/

 

背景为今天2017年9月22日，昨天做了一次全备，数据库是20号建立的，21号执行了一些建表语句。

 

进入RMAN的命令是

su - 数据库用户名
rman target sys/管理员密码@数据库ip地址:端口/数据库实例名

昨天在建表完成后使用RMAN执行的全备+归档日志全备命令是：

 

backup database plus archivelog ;

 

今天也执行这样一跳命令进行备份，下面是今天备份前和备份后各个目录内容的变化。

首先是表空间目录

【备份前】

【备份后】

可以发现表空间目录除了修改日期变了之外其他没什么变化。

再来看一下快速恢复区：/u01/fast_backup_area/recovery/RECOVERY/backupset

【备份前】

【备份后】

可以看到每一次执行全备就会多出一个文件夹，文件夹的名字是备份时的日期。

再来看看本分完之后这个文件夹里面有什么东西

会发现里面有两个1G多的文件，这应该就是数据库全备完的东西了，具体几个文件里面存的是什么下文会说。

在看看sqlplus中archive log list中返回的内容

 

【备份前】

 

 

【备份后】

当前的归档序列从12一下子升到14

 

在看看rman的list backup;命令返回的项目

 

【备份前】

可以看到，上一次备份有两个1G一上的大文件，一个是备份的表空间，一个是备份的归档。其中归档是备份的序号1到序号8

 

【备份后】

 

可以看出本次备份也备份了一个表空间和一个归档日志的集合，不同的是这次归档日志从序号1-12，看一下备份前后产生了哪些新的归档

从文件的创建日期可以看出，序号12和序号13都是在备份的时刻生成的，其中归档13只有很小的一点，才2K，而归档12也没有满，只有100M左右就进入归档13了。归档11是凌晨执行的而且已经快满了。也就是说在执行备份的瞬间会终止掉当前的归档并新开一个归档，然后过一小会这个新开的归档也被终止，又新开一个归档进行正常使用。这就是为什么当前归档文件从12一下子跳到了14的原因。本次全备只会收录全备前一刻产生的归档文件，也就是只到12。13,14均不会被备份。

 

下面执行一个LEVEL=0的数据库备份，也就是全备，执行语句是

 

backup incremental level =0 database;

下图为执行效果

 

可以看出，执行这条语句会对表空间做一次全备，并且把表空间数据备份到了/u01/fast_recovery_area/recovery/RECOVERY/backupset/2017_09_22/ ，也就是我们之前backup database plus archivelog ; 与全备命令执行后所放置备份文件的文件夹相同，然后控制文件和SPFILE文件被备份到了/u01/fast_recovery_area/recovery/RECOVERY/autobackup/2017_09_22/，目录。换句话说，LEVEL=0的增量备份和全量备份的效果是一模一样的。

我们可以看一下backupset文件夹和autobackup文件夹，观察里面的文件创建日期，上午10点半那个是普通的全备，中午12点那个是LEVEL=0的增备。

上面还使用昨天（21号只做了全备）来对比。证明LEVEL=0的增备确实和全备是一样一样的。不同的是全备的时候还会把所有的归档文件聚合起来生成一个很大的备份文件，如backupset中最大的那个文件，1813859328大小的这个文件就是聚合归档日志全备而来的。由于归档日志记录了每一条SQL执行的时间和顺序，所以这个备份文件会比表空间备份大很多。上午10点办全备时的表空间大小1344995328，和刚刚的