论oracle备库的设计方案

oracle的ADG那是自不必多说，用存储圈的话说，现在存储正在从被动被动变为主动，但是总体上是被软件抢，RAID被ASM抢，快照被Flashback抢，DR被ADG抢。
如果这几种方案结合在一起那会是什么结果。这就涉及到一个备库的设计方法。
我也是抛砖引玉。环境都是基于11g的dg来说。
首先基本的，一个主库一个备库是很多系统都在采用的备库设计方式，如果数据库比较关键，这种方案有什么缺点呢。
11g的备库现在也被赋予了更多的责任。
容灾，首先就是容灾如果主库挂掉，备库能够进行failover，这个没有问题，那么11g的备库现在也被赋予了更多的责任。
批量查询。可能会有一些批量查询，报表查询的任务。那么这部分功能就可以放到备库来。
人为操作的防范。如果出现了误操作和人为操作，是否能够及时合理的预防。


所以一主一备的方案就会有几个弊端，
首先批量查询，如果批量任务压力较大，本身对于CPU资源消耗较大，如果长年累月，其实本身硬件消耗就不可忽略，如果长此以往，可能出了问题切过来也不见得保险。
如果出现人为误操作，这种防范怎么来说，如果延时怕丢太多数据，不延时，人为误操作不可避免，一年出一次这样的情况就够我们好好折腾一番了。
那么我们设计一主两备？



如果这样设计，对于关键业务也不错的。不过有几个需要考虑的地方，还是要满足刚刚的几个需求，灾备，支持大查询，人为误操作防范。
那么standby 1就可以设计为在同一个相邻的区域内，而standby2则可以考虑成为异地灾备，异地灾备也是很重要的一个考虑，如果机房掉电，几个备库都在都一个机房，那就很可能受到牵连。
所以异地灾备也很重要。那么怎么满足上面三个需求呢。
首先灾备，一主两备，考虑了异地灾备，这个本身就是一个不错的解决方案。
然后支持大查询，那么可以考虑把大查询的人物分散开来，在两个备库上跑，比如一个60%，一个40%等等，也不要让备库彻底闲着。同时压力也降低了不少。
然后就是人为误操作了。这个怎么防范，如果按照目前的一主两备的环境，也有几种方案，一种就是对另外一个备库开启延迟应用归档。

比如对于异地灾备standby2，设置延时2个小时，那么这种情况下出现了人为误操作，比如truncate就还有可能追回被误删的数据。不过仅仅是可能，因为到底是几个小时谁也说不清楚。万一出现了3个小时前的误操作，大家最后发现是因为误操作导致的，那么这种方案也得掉链子了。
可能有的朋友会说了，如果在2个小时之内，比如切换了20个归档，truncate操作是在最后的归档中，即第20个归档中的操作，那么第20个归档中的数据变化可能类似下面的形式。

transaction 1

transaction 2

transaction 3

transaction 4

….

transaction 10

truncate

那么你怎么保证一定能够严格恢复回来，可能有的朋友说，可以使用logminer，恩，也可以，不过还是需要点功夫。而且不一定能够100%保证吧。
还有什么方案能够继续改进呢。可以试试闪回数据库。

其实在11g中，闪回数据库早已不是什么新鲜特性了。那么他怎么来完成上面的三个需求呢。
灾备自不必说，大查询也可以支持，那么人为误操作呢。那就是下面的绿色箭头所示。

通过在异地灾备2上做闪回，然后穿越之后得到了需要的数据，接着exp导出，然后部署到主库中。然后备库继续开启日志应用即可。
看来这种方法还是能够满足这几个需求了。
那么我们再把这些需求再梳理一下。那么在这种情况下，大查询就可以分担一下了，在备库1上可以多分担一些，备库2上就可以少分担一些。还有就是异地灾备需要额外再加入一些闪回日志的空间了。


那么如果出现了同城机房两台机器奔溃的情况，而且更为严重的是在崩溃的前一分钟，出现了人为误删除操作，那么异地灾备会不会给力呢。

这种情况下，就需要先做闪回数据库，exp出来需要的数据，然后做failover，然后关掉闪回数据库的功能，接着就是重新部署搭建灾备环境了，所以还是依旧可以保证，可能有一点美中不足就是可能闪回，如果表比较大，可能导出数据都需要花费些时间了。
所以一主两备的方式就能玩出这么多花样来，只要保证方案的稳定性，这么来看闪回数据库在一主两备的条件下还是可以考虑采用。