数据库备份 一致性问题2

1  consistent backup:

一致性备份一个数据库或者数据库的一部分，那么这部分的数据文件及控制文件必须被checkpointed并且拥有相同的scn(system change number)，oracle 决定是否一致性备份通过检查数据文件头以及这个数据文件头的在控制文件里的信息，如果是一致的，则表示为一致性备份。

 

这里补充一点知识：

当发生checkpoint时，会把SCN写到四个地方去。 三个地方于control file内，一个在datafile header。

1.    System checkpoint SCN ===========> (SYSTEM CHECKPOINT SCN in control file)

2.    Datafile checkpoint SCN ===========> (DATAFILE CHECKPOINT SCN in control file)

3.    Stop SCN ======================> (STOP SCN in control file)

4.    Start SCN ======================> (DATAFILE HEADER)

         正是因为这些SCN，我们才保证了一致性。详细内容参考：

                   RedoLog Checkpoint 和 SCN关系

                   http://blog.csdn.net/tianlesoftware/archive/2010/01/25/5251916.aspx

 

   

只有当数据库正常关闭，既通过normal,immediate,transactional选项关闭数据库，而后进行的备份才是一致的，如果instance fails或者shutdown abort进行关闭，那么数据文件是不一致的，这时当数据库打开时是需要instance 恢复，（当然数据库是read-only database不需要进行instance 恢复）

 

Oracle 通过checkpoint进程使控制文件和数据文件拥有一致的scn，当表空间处于只读（read-only）或者offline normal tablespace 时，允许使用旧的scns，这时该表空间中的数据文件跟其他的数据文件仍然被认为是一致的，因为在脱机后，表空间没有进行任何新的改变。

当数据库restore 一致性数据库全备份后，打开数据库将不需要应用redo，因为数据已经是一致的，不需要新的动作使数据文件变正确。

在noarchivelog模式下，一致性全备份是唯一有效的选择，因为如果选择了不一致性备份，那么恢复需要apply redo，而非归档模式下，所需要的redo logs有可能是不存在磁盘上。

 

2  Inconsistent backup:

非一致性备份是备份中的数据文件和控制文件他们没有被checkpointed至相同的scn，oracle将不能打开数据库直到所有的文件头header scns是consistent，也就是说，直到在线重做日志中所有的改变的记录都应用到磁盘中数据文件中。
   这里是我们讨论的重点。 因为如果数据库处与open 状态，那么数据块就会被修改，SCN 也会发生相应的变化。 但是RMAN 在备份前是通过快照控制来参考的。这就会造成不一致状态。

 

控制文件存储数据库的结构信息，这些信息包括用于恢复的检查点SCN信息。但是控制文件是一个非常繁忙的文件，连续的SCN 和文件管理对于数据库的生命期来说至关重要，因此RDBMS 必须能够持续的使用控制文件。

而RMAN 开始备份每一个数据文件时需要得到一个一致的控制文件视图， RMAN需要知道备份开始时最新的检查点信息和文件信息。开始备份后，RMAN 需要这些信息在备份操作期间保持一致，也就是说RMAN需要一个读取一致的控制文件视图。除非RMAN 在备份持续时间内锁定控制文件，否则数据库会不断更新控制文件，所以不可能。 但是，锁定控制文件意味着数据库不能执行检查点操作和切换日志，或则不能产生新的归档日志，这些操作是不可能的。

所以就有了快照控制文件（snapshot controlfile），快照控制文件是控制文件的副本。 RMAN 只在备份和同步操作期间使用快照控制文件。 这些操作开始时，RMAN 会根据实际控制文件来刷新快照控制文件，这样会短暂的锁住控制文件，随后，RMAN 会切换到快照并在备份持续使用这个快照。 这种方式具有读取一致性，且不妨碍数据库活动。

 

 作为24*7的系统，唯一的选择是进行非一致性的备份，这时数据库必须是归档模式，当offline a tablespace进行备份时，那么这时这个表空间中的数据文件将跟其他表空间是不一致的了，因为数据库在进行活动，数据库中的其他部分会被修改，那么这是offline和online的数据文件可能会包含不一致的scn。
    当数据库处于归档模式下，可以建立一个全备份使用备份在线数据文件在不同的时间，例如，在不同时间分别备份数据库中所有的表空间及控制文件，我们认为这种交错排列的备份是一个全备份。
    关闭状态下，可以进行非一致性备份，当数据库处于归档模式下，如果关闭时使用了shutdown abort，那么关闭后进行的备份，就是不一致性备份，但这个备份是有效的，因为可以应用在线和归档重做日志使数据库在打开的时候处于一致。
    而在noarchivelog模式下，进行的非一致性全数据库备份，仅仅当redo logs包含所有在上次backup以来的改变，这种情况很少也不希望发生。oracle强烈建议别在noarchivelog 模式下进行shutdown abort命令，如果没有归档重做日志，那么将是不可能恢复。

3  重做日志，备份归档日志 和 控制文件
       重做里面存放的是未归档的信息。 这些信息对恢复来说非常重要，因为当online backup 和inconsistent closed backup, 总会应用重做日志进行恢复，所以有时需要为未归档的重做日志进行归档，具体方式如下：

当数据库处于open状态：   alter system archive log current;

当mounted,open or colsed: alter system archive log all;

当mounted,open or colsed归档特定组:      alter system archive log group integer;

 

在打开或非一致性备份关闭的备份后，oracle推荐备份所有在备份期间产生的归档日志，并且在备份完成后备份控制文件。

 

我们在来理解一下归档日志的作用：

RMAN备份是一种物理的备份，它直接去读取数据块，因此rman是块级别的备份。从备份的那个时间点开始rman将锁定此刻的数据文件信息，也就是说只是备份数据文件到此刻的信息为之。

但是rman并不锁定数据文件的使用，也就是说rman的备份，不是数据库一致性状态的备份，由于rman备份是块级别的，它只备份控制文件中已经存在的数据块，同时数据库还在运行之中，那么就有可能会出现某些已经提交的操作，但是dbwn还没有写入数据文件，或者已经被rman备份过的数据块，又重新被修改，等等。

这些信息rman备份都不会记录，也是rman无法记录的。但是记录这些信息的是redo file，所以在rman完毕建议马上执行日志切换，然后备份归档日志，因为在rman恢复过程中，对于inconsistent backup，RMAN要靠这些已经归档的redo file信息恢复和保持数据库的一直状态。

 

由此，我们可以可以看出，其实归档文件中真正有用的是从rman备份开始到rman备份结束时刻系统产生的归档日志。同时rman在恢复的时候，restore database完毕后，会依次利用归档日志和联机日志进行完全恢复。此时利用的这些归档就是从rman备份开始到rman备份结束产生的归档日志。

 

因此备份归档日志是很必要的，当然联机日志也是必须的，这些日志保证了rman能够完全的恢复数据库。

 

 

4. 热备份和RMAN 在redo 上的区别：

 

关于热备份的一些知识见blog：

对 Oracle 备份与恢复 的补充说明

http://blog.csdn.net/tianlesoftware/archive/2010/06/04/5647494.aspx

 

 

热备份下 归档增加 的原因： 

热备份的时候redo log会增长较快，归档较平时增多，是由于在begin backup之后，如果正在备份（也就是OS命令拷贝cp）的数据块恰好又在被用户修改(因为是热备份，用户可以操作)，那么可能会产生split block的情况(split block被oracle认为是corrupt block)，也就是说，一个Oracle Block可能包含多个OS Block, OS Level的拷贝可能正拷贝的是一个Oracle Block的一部分(比如Header)，而另一部分(比如尾端)被用户更新，发生变化，这样导致一个Oracle Block内部的不一致(不是consistent version),可能出现一个数据块包含了几个不同版本的操作系统块,被称为Split Block。

 

注意：这里split block是Oracle Block不是OS Block，是因为一个Oracle Block中不同版本的OS Block才导致产生Split Oracle Block的。

 

Oracle处理Split block的方法是将整个当前Oracle split block(变更后的)写入online redo log中,恢复的时候如果发现datafile中某个Oracle Block中有不同版本(的OS Block)，就从redo把这个变更后的镜像拷贝回来，在这个版本一致的镜像上开始恢复。 不是像原来那样只写入更新部分到redo log, 所以热备期间redo log会激增 。

 

通过以上面的分析，可以看出，如果用热备份，那么会产生大量的redo log。 因为热备份把不一致的内容全部写入了redo log。

而RMAN 备份允许不一致备份，那些不一致的数据块也会直接备份，但是，在这种情况下，必须通过应用归档文件，使数据块一直之后才能打开数据库。 所以RMAN 不会产生大量的redo，这也是RMAN的优点之一。

 

 

 

 

 

P S：

         整理这篇文章是费了很多的脑细胞，因为理论的东西确实不好理解。 现在我把我对这块的理解整理了一下。 正确与否，还有待时间的考验。 因为随着时间的流逝，对Oracle的理解也在慢慢的变化。 以后会越来越清楚。 和 杭州恒生 这位朋友的讨论的收获就是加深了对 RMAN 数据块 这方面的理解。 也算是进步吧。 还是感觉做实验比较直观，按照文档一步一步下来，然后结果出来，正确，就大功完成了。 但理论这东西属于做学问，要花时间去理解，去研究。 费脑细胞啊….