Chinaunix首页 | 论坛 | 博客
  • 博客访问: 130207
  • 博文数量: 38
  • 博客积分: 2431
  • 博客等级: 少校
  • 技术积分: 470
  • 用 户 组: 普通用户
  • 注册时间: 2006-12-20 09:49
文章分类

全部博文(38)

文章存档

2011年(2)

2010年(14)

2009年(10)

2008年(12)

我的朋友

分类: DB2/Informix

2010-10-28 14:30:28

注意:以下内容仅为个人研究,受限于水平,不保证结果准确与正确!

目的:了解逻辑日志是如何记录信息的;了解使用onlog实用程序
数据库版本:IDS V11.50UC6 for linux ,数据库使用log(buf或者unbuf均可)
使用到的相关表: tt2(
                  id char(10),
                  col1 char(20),
                  col2 integer,
                  col3 char(20),
                  col4 char(50),
                  col5 integer
                 );
               create index ix_tt2 on tt2(id);

    往tt2表中插入/更新/删除记录等操作的同时,informix将记录这一操作,并将其写入逻辑日志文件中。可以通过onlog实用程序读取逻辑日志中的记录,其语法如下: 

我们通过onlog -l -n 逻辑日志号 的方式来查看具体的事务信息(为方便查看,建议将逻辑日志移至新日志上,再执行事务操作)

  1,插入操作的逻辑日志记录:往表tt2中插入一条新记录
insert into tt2 values('003','test003',99,'CC003','DDD003',101);
  通过onlog -l -n 逻辑日志号 查看到的逻辑日志记录如下:
    其包含4部分操作:BEGIN(事务开始),HINSERT(插入记录),ADDITEM(增加索引记录),COMMIT(提交事务)。
    以HINSERT为例介绍:蓝色框标识了该操作所在逻辑日志中的addr,记录长度len,操作类型type,事务xid,id(?何义未知),与上一操作的链接标识地址link,以及其它操作特有信息;红色框内是具体的信息(16进制,其阅读方法78563412(每2位为1字节),4字节为一组)
    注:各数据库版本的逻辑记录方式可能不一样,但大概含义应是一致的
    当前蓝色框内的信息可知:此操作的逻辑日志记录地址是0xd04c,记录的大小为172字节,操作类型是HINSERT,事务xid为22,该操作是紧随逻辑日志记录地址0xd018记录的操作(BEGIN),HINSERT的对像是partnum为0x300009的表,操作相关的rowid是103等信息;
    红色框内的16进制数解释:
第1组4字节0x000000ac(172的16进制)为len,
第2组4个字节中的前2字节(阅读方式中的3412) 0x0028表示HINSERT操作、后2字节(7856)0x0000表示id 0,
第3-7组未知,
第8组的0x0000d018是链接至上一操作的地址,
第9组0x0015cc53是该操作的时间戳标识(具体如何转换,未知),
第10、11组均是操作对向表的partnum 0x00300009(至于为什么出现2个partnum未知,倾向第11组为当前操作对向partnum。另partnum的解析为123位(即1.5字节)为chunk号,另2.5字节为当前chunk的tblspace编号),
第12组在HINSERT操作时为操作的rowid,即插入的新记录的rowid为0x00000103,
第13-16组未知(猜想应当为位置定位)
第17组开始为HINSERT的记录信息(此时数据读取不按照78563412的方式,而是顺序读取,注意每次截位),对比表结构:前10字节30303320 20202020 2020为char(10)即'003'(不足用空(0x20)填充),然后20字节7465 73743030 33202020 20202020 20202020 2020为char(20)即'test003'(不足位用0x20填充),然后4字节0000 0063为integer值99的16进制形式(int是以16进制保存的),然后20字节4343 30303320 20202020 20202020 20202020 2020为char(20)即'CC003'(不足用0x20填充),然后的50字节4444 44303033 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020为char(50)即'DDD003'(不足用0x20填充),最后的4字节00000065为integer值101的16进制形式。

    在ADDITEM中:
第10、11组为索引的partnum,
第12组为索引所在表的partnum,第13组为索引操作的rowid,
第14、15组未知,
第16组开始10字节(同样不按照78563412的方式)30303320 20202020 2020为索引字段值'003'(不足也用0x20填充),
最后一组的除去数据后的2个字节6e65 表示含义未知。


    2,更新操作的逻辑日志记录:
    SQL为:update tt2 set col1='NEWAAAA' where id='003';(更新的不是索引字段)
     前16组4字节的含义一致,
第17组未知,
第18组前2字节0x000a是10的16进制,表示该条记录跳10字节(id char(10))开始更新;后2字节0x0008是8的16进制,表示更新的长度是8个字节
第19-20组中的8字节74657374 30303320即'test003'(补空0x20),是更新前的记录,
第21-22组中的8字节4e455741 41414120即'NEWAAA'(初空0x20),是更新后的记录。

    说明:若是同时更新多个字段,类似18-22组的记录将重复出现。另:由于使用是的默认的page锁,update更新时,只更新发生变化的相应的字节,而不是更新整个字段或者整条记录,如上:字段为char(20),但只更新了其中的8个字节。

    3,删除记录的逻辑日志记录
      SQL:delete from tt2 where id='003';
    在HDELETE操作中,
前16组4字节组的含义与HINSERT中的一致,
第17组开始为所有删除记录的信息,格式与HINSERT格式一致;

    在DELITEM操作中,
格式与ADDITEM操作中的格式完全一致,最后一组的最后2字节含义未知。


另附:IDS V9.40UC4W4上的插入操作逻辑日志记录

 



阅读(961) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册