请教data gurad主库闪回后的处理

lujiaguai

唐老师
   如果dataguard的主库因为误操作，删除了表之类的原因，或者插入了错误的数据，发现问题的时候备库已经应用了日志。
   如果这个时候我选择闪回数据库到1个小时之前，此时物理备库也要跟上，如下处理对不对：
   1，物理备库停止应用日志
   2，主库闪回到一小时前
   3，物理备库闪回到一小时10分钟前
   4，主库resetlogs 开启
   5，备库开始应用日志

  如果dataguard主库因为物理故障，例如表空间的数据文件被人为从磁盘直接rm删除等。
  那么发现的时候一般来说备库也已经应用，并在不久后，主库checkpoint失败导致主库shundown。
  那么此时备库还是可用的，直接转换做failover到主库即可，事后再尝试去恢复主库。
  如果是这种情况，故障恢复还是很快的。

  但是如果有人在主库上用命令 drop tablespace ** including contents and datafiles，删除了表空间，那么备库也会执行这条命令。
  当发现这属于恶意删除或者误删除时，闪回也不能用，failover也不能用，是不是只有不完全恢复这一条路？
  步骤如下对吗：
  1，停止备库应用日志
  2，主库做不完全恢复到故障时间，比如：9：00
  3，主库resetlogs打开
  4，备库不完全恢复到故障时间前一刻，比如：8：59
  5，备库不resetlogs，直接重新开始应用日志

botang

对的，具体操作时，有所谓的scn-2说法。即备库退回主库的scn-2就能接上。

总结一下dataguard和闪回：
1. reinstate（是borker的一部分）：主库failover到备库--》原主库自动被闪回到一段时间前（broker自己决定）--》成为新备库（自动完成）     需要原主库打开flashback database（其实两边都要打开flashback database）

2. activate 备库（11g包装成snapshot stnadby这个名称）： 备库可能暂时需要读写。备库在activate前需要create restore poinit ... guarantee flashback database。就能回到备库状态。  不需要打开flashback database，只要保障闪回还原点。

3. 主库做了不完全恢复resetlogs， 备库不要重建，只要flashback到主库resetlogs时的scn-2

lujiaguai

botang 发表于 2017-7-26 12:15
对的，具体操作时，有所谓的scn-2说法。即备库退回主库的scn-2就能接上。

总结一下dataguard和闪回：

2. activate 备库（11g包装成snapshot stnadby这个名称）： 备库可能暂时需要读写。备库在activate前需要create restore poinit ... guarantee flashback database。就能回到备库状态。  不需要打开flashback database，只要保障闪回还原点。
--------------------------------------------------------------
如果说备库用于测试，开启了snapshot standby
打开保障闪回还原点后，随着时间的增加，闪回区会不断被这个闪回日志填满
也就是说，这个测试的快照备库能用多久，取决于磁盘空间，如果闪回区满，则不得不切回到物理备用后再切换回快照。
这样做会丢失snapshot standby期间的数据，如果说测试人员有特殊要求，希望能再多保留一天，而闪回区的挂载点物理空间确实无法再支撑了，此时有没有办法转移闪回的日志信息到其他挂载点？
或者说这种snapshot standby的情况本来就是不能持续的，是需要人看护的，上述的情况需要有预判，而不是临时临头的去处理。

botang

lujiaguai 发表于 2017-7-26 13:55
2. activate 备库（11g包装成snapshot stnadby这个名称）： 备库可能暂时需要读写。备库在activate前需要 ...

要有足够的db_recvoery_file_dest_size，否则真不好处理