使用informix的ontape实现指定时间点的数据恢复

要实现informix的数据恢复，只有2个方法，一个是onbar，一个是ontape，只有onbar才具有指定时间点恢复的功能，但onbar的配置相对复杂，而且限制不小。相对来说，ontape虽然没有提供指定时间点恢复的功能，但ontape的日志恢复原理上是恢复归档日志上的所有数据库操作，也就是说只要我们把归档日志上超过我们指定时间点的操作去掉，再用ontape －l做日志恢复，实际上是可以实现指定时间点恢复的。

换言之，我们第一步就是分析归档日志的结构，然后将所有操作收集起来，把超过指定时间点的操作去掉，最后再按照日志结构生成一份新的日志做日志恢复即可。当然了，如果能把归档日志结构分析出来，还能得到日志的增量数据，之前老板还问我能不能把在线日志的数据也拿过来，我当时还没研究好，现在想起来其实也是有办法的，也许后面会写篇关于获取informix在线日志数据的文章。

首先我们来看看归档日志的内容

图1

上图中的66号日志就是用来测试和分析的对象，用od打开可以看到内容如下

图2

我们看到第0000000行开头有6个字节的ffff ffff ffff，然后0100000行也有ffff ffff ffff，其实这部分是informix日志开头的固定信息，可以不用管往下看。从0100000行往下2k的地方，第0104000行，就是第一个page（相当于block）的地方，为什么是2k，因为我这里设置了page的长度是2k，而chunk数据文件以page为单位，所以我们后面以page为单位分析。至于从0100000行到0104000行之间的内容是什么，我还没解出来，但肯定是有用的，希望知道的大神可以告诉一下。

然后我们从第一个page开始分析。page的头部都是24个字节，page尾部有4个字节的标志位，所以我们先看第一个page的前24字节。

86d5 0001 0003 af85 0000 0d00 0044 0000
0042 0000 0000 0000

上面是第一个page的前24个字节也就是头部，这里有个大小端问题，因为数据库装在linux上，所以是小端，看的时候高位低位要换一下。首先12到14字节，也就是0044，这个表示的是这个page中所有操作的长度，包括头部的24个字节，那么0044从16进制转10进制就是68，再减去24就是44，也就是说这个page下面所有操作长度加起来就是44。然后是第16到20字节0042 0000，这里大小端反过来看就是0000 0042，转10进制就是66，其实这个就是日志的序号，刚好我们日志就是66号。再看第20到24字节0000 0000，这里不太明显，但这个其实是page的序号，从0开始。至于其他标识位，其实我还没解出来，希望大神们也告诉我一下。

好了，接下来往下读一个操作，先读4个字节，因为所有操作前4个字节都是表示这个操作的长度。这4个字节是第0104020行的第5列开始，002c 0000，因为大小端转过来就是，0000 002c，转10进制就是44，刚好我们之前读到page内容最大长度就是44，说明这个page就只有一个操作。

那么page的头部解读就差不多了，还有个尾部4个字节，这个我也是没有解出来，麻烦大神告知。

那么第一个page之后再往下2k就是第二个page，因为page size我设了2k，就是第0110000行就是第二个page的开始，如此类推，所有page都按照这个方法读。

那么日志最后的结尾呢？如下图。

图3

日志的结尾还是看到有6个字节的ffff ffff ffff，反正我们重新生成日志的时候直接copy这一段就行了。

page分析完，我们就要对数据库的操作进行分析，数据库操作中我们关注的只有begin和commit操作，因为commit的时间只要大于我们指定的时间就可以过滤掉从begin到commit的整个事务操作。那么commit操作的标识位又怎么解读呢？因为informix本身就有onlog用来做日志解读，我们可以借助来分析。

如下图是onlog分析的commit操作

图4

这里操作的标识位是第6到8字节，大小端转过来是2，2表示commit，1表示begin等等。

这里时间的标识位是第48到52字节，大小端转过来是5886B78D，转10进制1485223821就是时间戳，转为时间就是2017-01-24 10:10:21刚好吻合。

好了，剩下来只要把过滤好的操作再按照日志格式生成日志就可以了。但这里其实有一点要注意，就是ontape做日志恢复的时候，不是从头开始读日志的，它是从对应备份的那个checkpoint操作的offset位置开始读的，所以说如果这个日志刚好包含备份的那个checkpoint操作，那我们只能从这个checkpoint offset后面修改我们需要的操作。

这里就不贴代码了，只显示结果

先用原来的日志恢复，online.log显示日志恢复的时候有8个commit。

查询t5这张表有5条记录，最后一条记录是我在2017-01-24 10:15:33插入的。

这时候我创建一个最终时间点是2017-01-24 10:14:33的日志

再重新做一次恢复，可以看到只有7个commit

可以看到t5这张表已经只有4条记录了

终于做出来了，我感动得五体投地，仿佛历尽人生大起大落后终于得到全世界一样。。。。

接下来就是性能问题了，不过既然日志都分析出来了，优化有很多方案，那都是后话了。

下次我可能会分享些关于informix chunk的文章，希望大神们可以多多交流，谢谢。