oracle 11g归档日志研究_4

change的内容，是oracle日志转化为SQL语句的核心，也是最麻烦，变化最多的地方。

先说opcode，opcode的含义网上随便一搜有很多，真正对我有用的，只有增删改，至于什么搜索、索引等操作，我根本就不关心。

5.1：包含信息较多，每个增删改一定对应一个有效的5.1，这个5.1中将包含原始数据，用来在回滚（undo）时使用。另外还会有大量的5.1操作，目前我并不理解其他5.1操作的含义，并将这些我认为“无效”的5.1忽略。5.1的数据内容按照如下顺序排列：

typedef struct ktudb {
    uint16_t siz;
    uint16_t spc;
    uint16_t flg;
    uint16_t unknown0;
    uint16_t xid0;
    uint16_t xid1;
    uint32_t xid2;
    uint16_t seq;
    uint8_t rec;
    uint8_t ufo;    //0x84: ktubu; 0x00: ktubl
}Redo_ktudb;

这是5.1的change向量表之后的第一段数据，其中的xid也许可以作为txn的id，其他值我并不知道有什么用。

typedef struct ktubl {
    uint32_t objn;
    uint32_t objd;
    uint32_t tsn;       //maybe
    uint32_t noname;    //maybe
    uint8_t opc0;
    uint8_t opc1;
    uint16_t slt;
    uint32_t unknown1;
    uint32_t unknown0;  //00 00 00 00
    uint32_t uba0;
    uint16_t uba1;
    uint8_t uba2;
    uint8_t unknown2;   //00
    uint32_t max_scn1;
    uint16_t max_scn0;
    uint16_t unknown3;
    uint32_t tx_scn1;
    uint16_t tx_scn0;
    uint16_t unknown4;
    uint32_t unknown5;  //00 00 00 00
    uint32_t txn_scn1;  //位置不确定
    uint16_t txn_scn0;
    uint16_t unknown6;  //00 00
    uint32_t brb;
    uint32_t unknown7;  //00 00 00 00
    uint8_t user;
    uint8_t bcl;    //maybe
    uint8_t idx;    //maybe
    uint8_t flg2;   //maybe
}Redo_ktubl;

这是第二段，其中opc0.opc1应该为11.1，以对应我们的增删改操作，其他值被我忽略。objd被我当做obj，在数据字典中查找对应项。虽然ktubl的结构被我定义成这样，但实际数据是变长的，其可能只有24字节，故可能使用时只有前几个元素的值才是真实的。

typedef struct KTB {
    uint8_t op0;
    uint8_t unknown0[7];
    uint16_t xid0;
    uint16_t xid1;
    uint32_t xid2;
    uint32_t uba0;
    uint16_t uba1;
    uint8_t uba2;
    uint8_t unknown1;
    uint16_t unknown2;
    uint16_t scn0;
    uint32_t scn1;
}Redo_KTB;

本段也是变长的，事实上很多操作都会有KTB段，但是它们的结构却不相同。

typedef struct KDO {
    uint32_t bdba;
    uint32_t hdba;
    uint16_t maxfr;
    uint8_t unop0;
    uint8_t unop1;  //maybe
    uint8_t itli;
    uint8_t unknown1[3];
    uint8_t slot;
    uint8_t unknown2[3];
}Redo_KDO;

本段也是变长的，好吧，看来5.1里面没有什么是固定的了。

在这4段之后的数据，就属于undo段了，其数据摆放格式都差不多，可以按照向量表将其内容打印分析。

 

5.2：包含的信息较少，可能应该作为一个事务（txn）的开始，但目前被我忽略。

typedef struct ktudh {
    uint16_t xid1;      //slt
    uint16_t unknown0;
    uint32_t xid2;      //sqn
    uint32_t uba0;
    uint16_t uba1;
    uint8_t uba2;
    uint8_t unknown1;
    uint16_t flg;
    uint16_t siz;
    uint8_t unknown3[12];
}Redo_ktudh;

这似乎是5.2包含的唯一一段数据，固定为32个字节，似乎5.2应该包含xid作为一个txn的标示，但它只包含了xid的一部分。

 

5.4：表示一个事务（txn）的结束，应该是意味着用户提交了一次commit，可能应该与5.2对应。

typedef struct ktucm {
    uint16_t slt;
    uint16_t unknown0;
    uint32_t sqn;
    uint32_t srt;   //长度1-4
    uint32_t sta;   //长度1-4
    uint32_t flg;   //长度1-4
}Redo_ktucm;

5.4的第一段数据，固定为20字节。

typedef struct ktucf {
    uint32_t uba0;
    uint16_t uba1;
    uint8_t uba2;
    uint8_t unknown0;   //00
    uint16_t ext;
    uint16_t spc;
    uint16_t unknown1;
    uint16_t fbi;   //maybe
}Redo_ktucf;

5.4的第二段数据，固定为16字节。

之后5.4可能还会有其他数据，我并不知道那是什么，并且，似乎最后一段总是以4字节数据结束。

 

11.2：插入，对应insert语句。

11.2的第一段数据是KTB，其结构可以使用5.1的，但是长度却不同，可能比5.1的要短。

typedef struct KDO_11_2 {
    uint32_t bdba;
    uint32_t hdba;
    uint16_t maxfr;
    uint16_t unknown0;
    uint8_t itli;
    uint8_t unknown1[3];
    uint16_t unknown2;
    uint16_t cc;
    uint8_t unknown3[20];
    uint16_t size_delt;
    uint8_t slot;
    uint8_t unknown4[10];
}Redo_KDO112;

第二段是11.2的KDO。

从第三段开始，就是insert的内容了，每一段对应一个字段，对于insert语句来说，所有的字段都会在11.2中列出。

 

11.3：删除，对应delete语句。

typedef struct KTB_11_3 {
    uint8_t op0;
    uint8_t unknown0[7];
    uint16_t xid0;
    uint16_t xid1;
    uint32_t xid2;
    uint32_t uba0;
    uint16_t uba1;
    uint8_t uba2;
    uint8_t unknown1;
    uint32_t zero0;
    uint32_t zero1;
    uint32_t zero2;
    uint32_t zero3;
    uint32_t zero4;
    uint32_t unknown2;
    uint32_t unknown3;
    uint32_t unknown4;
    uint16_t unknown5;
    uint16_t scn0;
    uint32_t scn1;
}Redo_KTB113;

第一段，虽然名字都叫KTB，内容却不一样。

第二段是KDO，可以使用5.1的KDO结构。

 

11.5：修改，对应update语句。

typedef struct KTB_11_5 {
    uint8_t op0;
    uint8_t unknown0[7];
    uint32_t uba0;
    uint16_t uba1;
    uint8_t uba2;
    uint8_t unknown1;
}Redo_KTB115;

第一段，又是一只独特的KTB。

typedef struct KDO_11_5 {
    uint32_t bdba;
    uint32_t hdba;
    uint16_t maxfr;
    uint16_t unknown0;
    uint8_t itli;
    uint8_t unknown1[3];
    uint8_t flag;
    uint8_t lock;
    uint8_t unknown2[2];
    uint8_t slot;
    uint8_t size;   //maybe
    uint8_t ncol;
    uint8_t nnew;
    uint8_t unknown4[5];
}Redo_KDO115;

以及独特的KDO。

第三段开始是update的数据，第三段本身，是类似于向量表的一个数组，只是它其中存储的是要修改的数据字段id-1。

 

11.17：对应于有LOB字段的增、改操作，用来表示LOB字段的总长度。还有一种不包含LOB长度的11.17，其意义不明，被我忽略。

typedef struct LOB_11_17 {
    uint16_t xid0;
    uint16_t xid1;
    uint32_t xid2;
    uint32_t OBJ;
    uint32_t unknown2;
    uint32_t unknown3;      //00
    uint32_t unknown4;      //00
    uint32_t lobsize;
    uint32_t unknown5;      //00
}Redo_LOB_11_17;

这是11.17的第三段，前两段被我忽略掉了，我并不知道它们是什么。并不是所有11.17都有这个结构，所以需要进行判断，如果此段的长度不是32字节，则认为这个11.17不是我们需要的。本段中lobsize就是本次操作的LOB字段的总长度。

 

19.1：对应于有LOB字段的增、改操作，存储着LOB字段的内容，目前我所操作的oracle 11g，会将LOB切割成8168-36（LOB头）=8132字节的块，每块分别放在一个19.1中。LOB的总长度需要通过11.17获取，然后通过19.1获取LOB数据。LOB头格式：

typedef struct LOB_19_1_1 {
    uint32_t unknown0;
    uint32_t unknown1;
    uint16_t unknown2;
    uint32_t lob_set;
    uint16_t unknown3;
    uint32_t seq;           //2 or 4 byte, lob编号, 1 to n
    uint32_t unknown5;      //00
    uint32_t subseq;        //2 or 4 byte, lob分段编号, 0 to n
    uint32_t unknown7;
    uint32_t unknown8;      //00
}Redo_LOB_19_1;

LOB头中有2个编号，这两个编号表示LOB的排列顺序，而且，由于insert和update使用的方式不同（java脚本、sqldeveloper等），LOB数据可能有重复（此时LOB第1个编号会+1，第2个编号会从0开始）。

 

以上是增删改对应的基本数据结构。以下进行简单总结说明：

我们进行的是增删改操作，即11.2、11.3、11.5是我们真正操作的内容。

如果我们的增、改操作带有LOB字段，则会出现11.17和19.1。

每个操作（指的是11.2、11.3、11.5），一定有其对应的5.1，其中含有undo所需的内容。

11.3最简单，因为其中没有需要解析的数据，只要通过5.1的undo段确定所在行即可，而通常只需要一个主键就解决了。

11.2中等，需要插入的数据都在11.2的数据段，其5.1的undo段是空的，因为插入的undo就是删除。

11.5最复杂，需要修改的数据在11.5的数据段，而需要定位的行则必须从其对应的5.1的undo段解析，undo段存的其实就是11.5中对应字段的原值。

 

程序运行示例：

程序指定数据字典为dictionary.ora，归档日志文件为o1_mf_1_3279_brn6w2fm_.arc，程序运行结果非常巨大，只贴出其中一小部分。

解析数据字典，得出用户名、表名、字段名。从日志文件只能解出对应obj即id，需要通过数据字典查到名称。其中数据字典中的字段id从1开始，日志文件中从0开始，故需对日志文件中的字段id+1，其他id不需要。


以5.2、5.1开始，5.4结束，中间11.2表示insert操作。图片中的ERR是DEBUG输出，请无视~~

解析结果存为SQL语句。