论Oracle备库的设计方案

Oracle的ADG那是自不必多说,用存储圈的话说,现在存储正在从被动被动变为主动,但是总体上是被软件抢,RAID被ASM抢,快照被Flashback抢,DR被ADG抢。

如果这几种方案结合在一起那会是什么结果。这就涉及到一个备库的设计方法。

我也是抛砖引玉。环境都是基于11g的dg来说。

首先基本的,一个主库一个备库是很多系统都在采用的备库设计方式,如果数据库比较关键,这种方案有什么缺点呢。

11g的备库现在也被赋予了更多的责任。

容灾,首先就是容灾如果主库挂掉,备库能够进行failover,这个没有问题,那么11g的备库现在也被赋予了更多的责任。

批量查询。可能会有一些批量查询,报表查询的任务。那么这部分功能就可以放到备库来。

人为操作的防范。如果出现了误操作和人为操作,是否能够及时合理的预防。

所以一主一备的方案就会有几个弊端,

首先批量查询,如果批量任务压力较大,本身对于CPU资源消耗较大,如果长年累月,其实本身硬件消耗就不可忽略,如果长此以往,可能出了问题切过来也不见得保险。

如果出现人为误操作,这种防范怎么来说,如果延时怕丢太多数据,不延时,人为误操作不可避免,一年出一次这样的情况就够我们好好折腾一番了。

那么我们设计一主两备?

论Oracle备库的设计方案

如果这样设计,对于关键业务也不错的。不过有几个需要考虑的地方,还是要满足刚刚的几个需求,灾备,支持大查询,人为误操作防范。

那么standby 1就可以设计为在同一个相邻的区域内,而standby2则可以考虑成为异地灾备,异地灾备也是很重要的一个考虑,如果机房掉电,几个备库都在都一个机房,那就很可能受到牵连。

所以异地灾备也很重要。那么怎么满足上面三个需求呢。

首先灾备,一主两备,考虑了异地灾备,这个本身就是一个不错的解决方案。

然后支持大查询,那么可以考虑把大查询的人物分散开来,在两个备库上跑,比如一个60%,一个40%等等,也不要让备库彻底闲着。同时压力也降低了不少。

然后就是人为误操作了。这个怎么防范,如果按照目前的一主两备的环境,也有几种方案,一种就是对另外一个备库开启延迟应用归档。

论Oracle备库的设计方案

比如对于异地灾备standby2,设置延时2个小时,那么这种情况下出现了人为误操作,比如truncate就还有可能追回被误删的数据。不过仅仅是可能,因为到底是几个小时谁也说不清楚。万一出现了3个小时前的误操作,大家最后发现是因为误操作导致的,那么这种方案也得掉链子了。

可能有的朋友会说了,如果在2个小时之内,比如切换了20个归档,truncate操作是在最后的归档中,即第20个归档中的操作,那么第20个归档中的数据变化可能类似下面的形式。

transaction 1

transaction 2

transaction 3

transaction 4

….

transaction 10

truncate 那么你怎么保证一定能够严格恢复回来,可能有的朋友说,可以使用logminer,恩,也可以,不过还是需要点功夫。而且不一定能够100%保证吧。

还有什么方案能够继续改进呢。可以试试闪回数据库

论Oracle备库的设计方案

其实在11g中,闪回数据库早已不是什么新鲜特性了。那么他怎么来完成上面的三个需求呢。

灾备自不必说,大查询也可以支持,那么人为误操作呢。那就是下面的绿色箭头所示。

论Oracle备库的设计方案

通过在异地灾备2上做闪回,然后穿越之后得到了需要的数据,接着exp导出,然后部署到主库中。然后备库继续开启日志应用即可。

看来这种方法还是能够满足这几个需求了。

那么我们再把这些需求再梳理一下。那么在这种情况下,大查询就可以分担一下了,在备库1上可以多分担一些,备库2上就可以少分担一些。还有就是异地灾备需要额外再加入一些闪回日志的空间了。

论Oracle备库的设计方案

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

论Oracle备库的设计方案

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:http://www.heiqu.com/39625092fa64abffafb8b038ea0de8d9.html