本文共 3154 字，大约阅读时间需要 10 分钟。
当主备同步中断了，备库想快一点恢复，偏偏这个时候归档太多恢复不过来或者说需要的归档直接丢了，有些人可能会选择重新搭建备库。如果库小的话还是可以的，但是如果主库比较大可能耗费的时间会很久，而且容易出一些问题。单单是全库备份恢复这个时间就不会短，更何况中间还会涉及到很多东西。
那么我们今天就是来聊聊有没有什么更好的办法来处理这种情况。因为这种情况还是比较常见的，至少我遇到过好几次了。
这里我们回顾一下dg的三种同步模式；
1.最大保护模式
这种保护模式是为了确保主库故障时，不会发生数据丢失。要提供这种级别的保护，恢复所需的重做数据必须在事务提交之前，同时写到本地联机重做日志和至少一个备用数据库上的备重做日志。若如果主库无法写重做流到备库，主库将会关闭。
2.最大可用模式
提供了可能的最高级别的数据保护，而不用与主数据库的可用性相折中。
与最大保护模式的区分
与最大保护模式相同：在恢复所需的重做数据，必须在事务提交之前同时写到本地联机重做日志和至少一个备用数据库上的备重做日志。
与最大保护模式不相同：如果故障导致主数据库无法写重做流到异地备库重做日志时，主数据库不会关闭，在没有达到net_timeout之前主库会hang住，但是并不是shutdown。而后主数据库以最大性能模式运行直到故障消除，并且解决所有重做日志文件的中断。当所有中断解决之后，主数据库自动继续以最大可用性模式运行。
这种模式确保如果主数据库故障，但是只有当第二次故障没有阻止完整的重做数据集从主数据库发送到至少一个备用数据库时，不发生数据丢失。
3.最大性能模式
这种保护模式（默认）提供了可能的最高级别的数据保护，而不影响主数据库的性能。这是通过允许事务在恢复该事务所需重做日志在写到本地联机重做日志后，可以立即提交而实现的。
主数据库的重做数据流也写到至少一个备用数据库，但是那个重做流相对于创建重做数据的事务是异步导入的，就不用 LGWR SYNC了，而之前两种模式都要用LGWR SYNC。
当所用的网络连接有足够的带宽，这种模式提供了近似于最大可用性模式的数据保护级别，并且对数据库性能的影响最小。
最大保护和最大可用性模式需要备库重做日志文件配置在配置中至少一个备用数据库上
为了保证主库不受影响，至少到目前为止我接触的生产环境的dg都是最大性能模式。但是这种环境会出现一种情况。由于某种原因，当备库出了一些故障、网络不通或者其他情况，导致主备同步中断，主库的在线日志或者归档没办法正常传输到备库。这样主库产生一个又一个的归档，但是这些归档都没办法传到备库。当然我们在恢复了出现的问题之后会从断了的地方重新传到备库以完成同步。
不过这中间可能会有一些情况，比如：我们本地的归档空间有限，主备的同步一时半会恢复不了，如果一直留着归档，当归档空间满了就会影响主库正常运行。不得不删除一部分。也有可能主备恢复时间过长，产生了很多很多归档，将它们传到备库应用会消耗很多很多时间。
理解原理
当主备同步中断了，备库想快一点恢复，偏偏这个时候归档太多恢复不过来或者说需要的归档直接丢了。这个时候我们该怎么办？
其实我们这次的题目已经提出了解决方法，就是利用基于scn的备份去恢复我们的备库，从而绕开中间过多或者丢失的归档。
那么基于scn备份究竟是什么意思呢?
我们都知道我们传统的dg都是属于物理dg，下面是物理dg的简单解释：
物理备用数据库：以基于块对块的主数据库同样的磁盘数据库结构，物理备用数据库物理等同于主数据库。
特性：
大家看了物理备库的简单解释之后需要注意的是，其实主备保持一致是不是就是主备的每一个块内容都一样？数据库一般的块是8K，如果每个8K都一样，是不是就意味着两边数据库内容是一样的？
假如当前备库应用到了100号归档，这个时候主备的网络断了，主库一直生成归档生成到了150号，这期间一直没有传递归档到备库。当我们恢复了主备的网络，主库生成的101到150这50个归档都传送到了备库。
那么此时，备库应用完这50个归档是不是备库就和主库保持一致了，都是150号归档的时候块的内容？如果我们将101到150这一段时间块的改变找出来，在备库上面进行修改，这样是不是就等同于应用了这50个归档？
我们单独拿一个块来说，假如100号归档的时候数据库内这个块记录了一列的值为5，150号归档的时候数据库内这个块记录这一行的值为6。当我们将这个5改成6时，是否就意味着这个块完成了101-150号归档的所有改变？
反过来说，假如100号归档的时候数据库内这个块记录了一列的值为5，150号归档的时候数据库内这个块记录这一行的值还是为5那么我们就可以不修改他，他还是完成了101-150号归档的所有改变。
所以到这里我们应该明白了，找到这段时间块的改变，全部应用到备库，我们就不用去恢复那些过多的或者缺失的归档。
如何完成一次基于scn的恢复？
所以回到我们的方法，我们找到备库端数据文件中最低的scn，然后在主库去基于这个scn进行备份，这个时候rman回去扫描整个主库的块，如果块内的scn小于备库端数据文件中最低的scn，则证明这个块从备库应用到的时间点到现在是没有改变的，就忽略掉这个块。
如果块内的scn大于备库端数据文件中最低的scn证明在这个阶段这个快进行了修改，就记录下这个块的内容。等拿到备库端去恢复的时候就替换这个块的内容。
当然我们是有官方文档的支撑的，并不是我们凭空想象出来的处理方法，这里提供官方mos的id，供大家自行去查看：
Steps to perform for Rolling Forward aPhysical Standby Database using RMAN Incremental Backup. (Doc ID 836986.1)
我们需要注意的是这个方法适用的版本在10.2以后：
Oracle Database - Enterprise Edition - Version 10.2.0.1 to later
操作演示
1、查找备库数据文件最低的scn
select CHECKPOINT_CHANGE# fromv$datafile_header order by 1;
select CHECKPOINT_CHANGE# fromv$database order by 1;
2、执行增量备份
rman target /run{configure controlfile autobackup on;sql 'alter system switch logfile';BACKUP INCREMENTAL FROM SCN 15078013867424 DATABASE FORMAT '/IC_%d_%u/'tag 'FORSTANDBY';} 3、恢复控制文件
restore standby controlfile ;
4、恢复数据库
recover database;
原文发布时间为：2017-11-7
本文作者： 黄堋
本文来自云栖社区合作伙伴“”，了解相关信息可以关注“”微信公众号
转载地址：http://tyuix.baihongyu.com/