AnySQL.net

    过去两年中断断续续地研究了一些Oracle日志文件的格式, 只是为了研究而开发了一个工具, 不具有任何实用的意义. 也比较清楚Quest Shareplex或DSG Realsync这样的软件的强大功能, 要做出这样的一个工具, 是非常难的, 也是非常耗时间的, 这是日志格式研究的终极目标. Oracle 11g的新Standby模式是很好, 不过那是在11g刚推出来的, 估计要到12X才能真正地广泛使用吧, 而且这么好的功能, Oracle不会不收许可证的值, 而且是相当地贵的.

    Standby还是有缺限的, 不支持异构, 比如源结点是比较贵的小型机系统, 而目标结构想选择比较便宜的x86系统时, 就不可能了. 相反地, 基于日志文件分析的逻辑复制软件则要灵活得多, 不仅可以异构, 还可以灵活地折分数据.

    在过去的一段时间中, 有钱的公司用Shareplex, 没有钱的公司则用了实体化视图日志或自已写触发器的方式, 来捕捉增量数据, 然后自已写角本来实现两边数据同步. 这种方式遇到的最大的题是维护复杂, 并且对源端的数据库影响较大. 对于Log格式的研究也有一段时间了, 最初研究8i/9i的, 后来花了一个星期的业余时间完成了10g的格式的研究, 因此11g或12x的格式也是可以出来的. 但是这个研究可以做到什么呢?

    最现实的是可以通过分析日志来获得与实体化视图日志同样的数据, 这比分析所有数据要简单多了, 但是可以避免在源数据库上对要复制的表加上触发器或实体化视图日志, 要达到这样一个中间的产品或半成品, 则在看得见的时间范围之内.

    正准备好好研究一下如何实现这个中间目标.

    象Log文件格式这样的研究,　是非常怕新版本的发布的. Oracle 11g的发布给我有点压力, 因为Oracle肯定会或多或少地对它作一些修改, 而象我这样没有官方支持的研究, 就比较难办了, 只能多作些测试了. 下午稍稍测试了一下MyLOG对Oracle 11g版本日志文件支持性.

    原来以为什么都不用改的想法是落空了, 不过从目前看来, 我所关心的部份改动不会很大, 因为我稍稍修改了一下程序后, 已经可以解出SQL了, 基本上应当达到了对10g的研究水平.

LOG> extract table t_11glog start 2
Start extract redo SQL ...
RBA=0x000006.00017662.0010,  XID=0x0001.01c.000000a7
  RID=AAAC7bAAEAAAAPQAAA
  INSERT INTO T_11GLOG ( COL1 , COL2 ) VALUES (11988,'TEST');
  RID=AAAC7bAAEAAAAPQAAB
  INSERT INTO T_11GLOG ( COL1 , COL2 ) VALUES (11991,'TEST_IDX');
  RID=AAAC7bAAEAAAAPQAAC
  INSERT INTO T_11GLOG ( COL1 , COL2 ) VALUES (11995,'T_11GLOG');

    上面的例子是向一个有两个字段的表插入了三行记录的结果, 用的是INSERT...SELECT..的方法.

    虽然已经能从Oracle 10g和Oracle 11g中解出Redo SQL了, 但这个只适合于记录没有Row Chain和Row Migration的情况. 然而在真实的环境中无法全部避免这些, 也不能丢下这样的记录不管啊!

    因此需要继续做的两个研究是: 1, 对于Row Chain和Row Migration的研究, 要处理这两种情况肯定要懂Oracle的数据块格式, 这方面已经有基础了; 2, 研究Supplemental Log Data的格式及如何发挥它的作用, Oracle的这个功能就是为Stream加上去的, 基于Log捕捉的所有程序都可以从这些设置中得到好处, 在Shareplex中验证了这一点.

    虽然只有两件事情, 不过任务可不轻松的. 有时还需要大家的帮忙, 如果有兴趣可以一起研究这两点. 最近国内不少的公司都在项目中遇到了如何捕捉增量数据的问题, 最后不约而同地想到从Log中去获取, 而因此展开了一些对于Oracle Log的研究, 并想快速应用到项目中, 不容易啊, 研究这个的前途未见光明啊!

    而我继续是没有压力地, 自由地进行研究. 有公司会赞助我的这种研究吗?

    上一次在火车上发呆是在研究Log文件格式时, 想了好久都没有想清楚, 于是将一段Log的二进制代码打了张纸, 终于在火车上发呆时想出来了. 今天同样发呆了一次, 不在火车上, 也没有打印出纸来, 而是对着屏幕发呆, 而结果则是快要搞清楚Oracle压缩块的格式了.

    上一次研究压缩块已经是一年多以前的事了. 在过去的一年中, 没有为此事着急, 因为压缩块存在很多的Bug, 有的已经修正, 但有的则因为用得人少可能还没有发现, 因此没有压缩表支持的AUL还是得到了大家的欢迎. 不过从Oracle 11g大力推广压缩功能来看, 应当是改进了不少. 根跨版本使用新功能的原则, 在Oracle 11g中应当会有正式开始应用的例子了. 为了让AUL活得更久, 就得支持它.

    qiuyb版主最近在写DUL的文档, 并确认DUL 10已经支持压缩块了, 看来AUL已经落后一步了. 这也是今天发呆的原因, 没想到还真管用. 预计支持压缩表的AUL 5将会在明年上半年推出.

    正在开心中, 当研究突破一些东西后, 总是这样.