关于Data Guard在我原来印象中是有阴影的,起源是在OCM考试中,有很多同学在一个小时内搭建出Data Guard环境,但是做了主备切换,反复切换的时候出了问题。而自己在搜狐畅游的一大收获也算是Data Guard了,因为接触各类的环境,碰到了太多的问题,所以就触发了很多的感受或者不满。
所以在某种程度上对已有的方案就有很多的改进。
其实在2017年的时候,就已经在规划一本新书是关于灾备,但是拖延症的我确实拖了太久,事情悬而未决,想起来就上火。
其实很多人都会带着疑问说,现在Data Guard技术已经很成熟,而且文档齐全,做这件事情的意义是什么?我的想法如下:
1.官方文档本身写了Data Guard的很多内容,从文档来说,内容已经相当全面了,所以我的入手点绝对不是官方文档的内容。
2.在11g开始,Data Guard已经不简单是一个备库的角色了,它开始承载很多更有实际价值的任务,比如批量查询任务,比如通过快照数据库来评估DML,DDL等,所以基于这个重大的变化和方向,我觉得对Data Guard值得深入研究。
3.从实际的使用来看,Data Guard出现问题的情况很多和官方文档的系统性差别很多,或者说官方文档是实用不实用的内容都有,需要甄别,比如备库有两种类型,几乎99%以上都是Physical Standby,而Logical Standby的应用场景是截然不同的。
4.问题的场景化程度不够,解决问题比较好的入手方式就是案例,通过案例可以举一反三,触类旁通,搞明白一个问题,才可能搞定一类问题。比如解决问题的时候,问题现象是同一个,但是对于不同的版本,解决方案和入手点就截然不同。
5.目前对于新版本的技术解读还比较少,如果能够与时俱进,算是一个亮点吧。
所以这些算是我对于这个灾备书籍的一个入手点和出发点。至于稿酬,如果你认真了,开始你就输了。还有个不是理由的理由,那就是这算是自己规划的一个方向,这个任务解决了,自己就不用那么纠结了。
细节的内容暂时先不公开,我就列出来一部分之前整理的大纲。
比如搭建Data Guard,其实有一些基本的技巧和策略,不同的场景可以选择使用,总之在这种情况下,你的思想就是一个百宝箱,最终的结果是解决问题,但是如果高效快速的解决问题才是王道。
如果我要写这本书,大家从自己的理解来说,是否靠谱。
想听听你们的想法。