你的位置:首页 > 数据库

[数据库]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;

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;

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;

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;

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;

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;

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;

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;

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;

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;

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;

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;

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;

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语句。