一次10g failover的经历，以及一些问题

显示全部楼层 · 2015-10-8 17:57:58

这是一次演习，但是，遇到了不少情况。
基本配置：
一台主服务器，上面运行主数据库(P)。
一台备份服务器，上面运行物理备份数据库(S)和逻辑备份数据库(L)。
所有的数据库都配置了flashback。data guard运行在max availability.
2点钟，模拟P出现问题（网络断，数据库其实没有问题）。于是failover到S。用户转到S上继续工作。用户开始输入一些假数据以验证系统是否工作正常（问题就出在这里，后面详述）。
此时DG报告P需要reinstate以便成为新的物理备份。
而L已经自动转为S的逻辑备份。
3点半，模拟网络修复。通过EM进行reinstate，失败。关闭P再重新打开，重复reinstate，成功。P成为新的物理备份。
然后进行swithover，成功。整个系统恢复到出错以前的情况，正常情况下，整个过程可以结束了。
但是由于用户在测试S的时候输入了假数据，需要恢复数据库到failover以前的状态。
以为用flashback可以轻松搞定，谁知道出现很多问题：
1. 关闭P再启动到mount状态，还没来得及发出flashback命令，data guard就自动把P打开到open状态。无法进行flashback。oracle的建议是把dg_broker_start改成false，重启数据库。我后来是进入dgmgrl ddisable configuration。似乎可行，但是：
2. flahback报告说没有足够的log。检查後发现，reinstate之后的flashback log全都被DG（或者是RMAN？）自动删除了！这是为什么？
备份机上还有flashback log，但是如果先failover到S，flashback到第一次faliover之前，那么P就要重建，我不想重建数据库。
最后只好用一个failover前的data pump备份覆盖了用户数据。由于备份数据库在线，所以整个过程中所有数据库都是同步的。
问题总结：
1. 为什么第一次reinstate不成功？一定要关闭P再打开？
2. 为什么DG(RMAN)把reinstate之前的flahsback log 全都删掉了？
3. 如果重建数据库，是不是整个P都要从头重建？
4. 带有standby的数据库flashback应该怎么做？
5. 如果有几天前的rman full backup和最近几天的incremental backup，加上直到出问题之前的archive log，怎样恢复数据库到出问题以前的状态？

千问 · 2015-10-8 17:57:58

ding

千问 · 2015-10-8 17:57:58

为啥要用em或broker呢，我觉得即使纯手工也很方便啊
其实只需在你的S上查询select STANDBY_BECAME_PRIMARY_SCN from v$database
然后把P闪回到前面的那个scn-1，你的P就能成为新的物理备用库
我觉得reinstate本质上也是做的类似的操作吧
无论你对P做怎样的恢复，用增量备份也好归档日志也好，restore之后的操作都是要根据前面的那个scn来的，如果你把P恢复到大于
这个scn就不能成为备用库