oracle esb 灾备,两地三中心双活系统灾备切换场景和数据补录问题？

感谢TWT社区的邀请。根据我们江苏农信多年的灾备建设和切换经验，向您提出一些建议，如果说的不好请别介意。 1，灾备的目的：灾备的目的不是为了备份，更不是为了实现技术上的成就，花这么多的钱根本上是实现银行的业务连续性管理目标。 2，双活的目的：有次我参加一次讲座，还没讲完，有家银行的领导就问我：“切换？你们都双活了还切换个啥？”这个问题能代表很多人的疑惑。双活这个技术手段为了实现的目标是更快的恢复业务，也就是说为实现更小的RTO和RPO而已。冷备切换要2个小时，双活只需10分钟。假如你不演练的话，怎么说明你的双活建设的牛呢？你没有在10分钟内切换到灾备接管业务，怎么说明你们银行的钱花的值呢？冷备摆在那不是蛮好的嘛，还省钱。您想想是不是？ 3，双活怎么切：双活的系统，演练的时候优先切换数据库，再切换应用系统。切换数据库是重点，如果失败就不用再往下切换应用系统了。Oracle数据库的ADG切换效率很高，两三分钟的事情，但是你们要花10分钟进行检查(检查工作远比调度切换脚本更重要)。数据库切换没问题的话，再用DNS切换流量到灾备中心，生产端的应用根本不用停。如果检查没有问题的话，就把生产端和灾备端的应用交易日志取下来，留作监管单位来审计用。到时候你可以给他们看看，“领导您看，这个时候生产端的日志已经不滚动了，灾备端的交易日志还在滚动，灾备还在承接业务，说明我们交易已经成功切换到了灾备中心”。你就这样讲就行了，所以生产端的应用你没有必要停到，正好用来做日志对比说明你们的战果。 4，数据补录问题：我能熟练背诵很多监管文件，人行、银监、省金融办的文件里只是要求我们演练要以真实业务场景为前提进行切换(杜绝一些银行用桌面演练应付监管审计)，从来没有哪一家监管单位要求我们非要做计划外的切换。计划外的切换，我建议你们千万不要做，就算你想做，你们行长同意吗？真出了问题，太严重，尤其现在很多交易都是24小时交易，通过自助设备接入完成的。如果数据真的有损失，后果不堪设想，补录非常非常麻烦。收起