AnySQL.net

    周日闲来无事, 因为周五忙到比较晚, 所以干脆不回南京了, 一个人的周末能做什么呢? 洗了一大堆衣服和床单, 留下了一点时间来改进一下MyLOG软件, 增加了一个OSDUMP命令, 用于将日志文件中的块以十六进制的形式打印出来, 有点象Linux/Unix下的od命令, 但这个更有专业性.

OSDUMP START start_block END end_block TO output_file
OSDUMP BLOCK block_id TO output_file

    这个功能是一切文件格式研究的第一步, 使用例子:

LOG> osdump block 1
Start osdump redo block ...
0x   : -0-1 -2-3 -4-5 -6-7 -8-9 -a-b -c-d -e-f  0123456789abcdef
-----: ---------------------------------------  ----------------
00000: 0000 5e30 0000 0001 23b7 dfca 0000 63b4  ..^0....#.....c.
00010: 0920 0000 0920 0000 9d67 1cf9 4742 4355  . ... ...g..GBCU
00020: 5354 3100 000c 8148 003e 8000 0000 0200  ST1....H.>......
00030: 0008 0002 a281 284c 0000 0000 0000 0000  ......(L........
00040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00050: 0000 0000 0000 0000 0000 0000 5468 7265  ............Thre
00060: 6164 2030 3030 312c 2053 6571 2320 3030  ad 0001, Seq# 00
00070: 3030 3032 3431 3132 2c20 5343 4e20 3078  00024112, SCN 0x
00080: 3033 3166 3035 6330 3038 3234 2d30 7830  031f05c00824-0x0
00090: 3331 6630 3563 3030 3939 3000 0000 3ebb  31f05c00990...>.
......

    当初研究数据文件格式时, 也是先写这个功能的.

    周日闲来无事, 因为周五忙到比较晚, 所以干脆不回南京了, 一个人的周末能做什么呢? 洗了一大堆衣服和床单, 留下了一点时间来改进一下MyLOG软件, 增加了一个TAIL命令, 用于将日志文件中的所有操作列出来, 当时想写一个Linux/Unix下"tail -f"这样的工具(tailredo), 可是发现这样显示出来的信息没什么用, 因此停写那个工具. 但这条命令本身在研究时还是有用的.

TAIL START start_block END end_block TO output_file
TAIL BLOCK block_id TO output_file

    这个命令主要是将日志操作的类型列举出来:

LOG> TAIL BLOCK 2
 Start tailing redo operation ...

 0x00005e30.00000002.0010 2006-08-23 19:08:22
          [05.01] [Trans Undo ] Undo block or under segment header - KTURDB
          [11.02] [Row Access ] Insert Row Piece

 0x00005e30.00000002.0188 2006-08-23 19:08:22
          [05.01] [Trans Undo ] Undo block or under segment header - KTURDB
          [11.05] [Row Access ] Update Row Piece

    实在没有想出来这条命令有多大的用处, 但还是加了它.

    周日闲来无事, 因为周五忙到比较晚, 所以干脆不回南京了, 一个人的周末能做什么呢? 洗了一大堆衣服和床单, 留下了一点时间来改进一下MyLOG软件, 增加了按Layer和Opcode进行查找的功能, 周一晚上继续改进, 居然给我加成了按对对象号(Object ID)来查找的功能, 但目前还仅限于对表或索引进行维护的类型, 不过这已以是一个很大的进步了. 另外在上篇中写的TAIL命令也集成了这个查找功能.

SEARCH option value [option value]
TAIL   option value [option value]
DUMP   option value [option value]
   OPTION
       OP       layer
       SUBOP    opcode
       START    start redo block
       END      end redo block
       BLOCK    in given block
       OBJECT   object id

    分别来偿试一下这些命令的查找功能吧!

LOG> tail object 61 start 2
Start tailing redo operation ...

0x00005e30.00003eb8.0010 2006-08-23 19:08:58
          [05.02] [Trans Undo ] Update rollback segment header - KTURDH
          [05.01] [Trans Undo ] Undo block or under segment header - KTURDB
          [11.05] [Row Access ] Update Row Piece
          [05.19] [Trans Undo ] Transaction start audit log record
LOG> search object 61 start 2
Start search opcode = [00.00] ...
Seq=24112, Start=16056, Offset=0x0010=16, End=16057, Time=2006-08-23 19:08:58
LOG> dump object 61 start 2
Start dump redo operation ...
REDO RECORD -- RBA=0x00005e30.00003eb8.0010 LEN=0x0284 VLD=0x01 SCN=0x031f.05c0098c
  CHANGE#=0x01 OP=5.2 SEQ=1 TYP=0 CLS=43 OFFS=0x000c LEN=0x003c DBA=0x6280b402 ...
    PIECE#=2 OFFS=0x001c LEN=0x0020 SIZE=0x0020
    ktudh redo: slt=0x0045 sqn=0x000daa80 flag=0x0412 siz=228 fbi=0
                uba=0x3b41c2dd.3bce.00  pxid=0x0000.000.00000000
  CHANGE#=0x02 OP=5.1 SEQ=8 TYP=0 CLS=44 OFFS=0x0048 LEN=0x0114 DBA=0x3b41c2dd ...
    PIECE#=2 OFFS=0x0038 LEN=0x0014 SIZE=0x0014
    ktudb redo: siz=0x00e4 spc=0x000000ac flag=0x0012 seq=0x00ce rec=0x00
                xid=0x000e.045.000daa80
    PIECE#=3 OFFS=0x004c LEN=0x0030 SIZE=0x0030
    ktubu redo: slt=69 rci=0 opc=11.1 objn=61 objd=61 tns=0
    PIECE#=4 OFFS=0x007c LEN=0x0020 SIZE=0x0020
    ......

    有了这些命令, 我想谁都可以研究日志格式了.

    由于精力所限, 一年半之间开始研究Oracle日志文件格式, 到现在都没有突破的成就, 一方面是因为工作越来越忙了, 另一方面是因为个人的精力实在有限, 因此在这一年半内, 基本上没有投入多一点点的时间去研究. 经过这么长的时间, 是应当继续向前走一步了, 今天就改造了一下我的MyLOG小工具, 以如何解出Redo SQL和搞清楚事务控制为中心.

    现在不区分事务, 已经可以解出SQL语句了, 不过还需要进行很多的验证, 才能确定其准确性. 现在我是在Windows上打开了一个Solaris下的Oracle的日志文件:

LOG> set byte_order big
BYTE_ORDER = BIG
LOG> open c:\mydul\utility\gbcust1_24112.arc
DBID = 0x9d671cf9 = 2640780537
GROUP      = 8, SEQUENCE   = 24112
File Type  = 2, Next Block = 16059
Start SCN  = 0x031f.05c00824 = 3431775340580
Start Time = 2006-08-23 19:08:21
End SCN    = 0x031f.05c00990 = 3431775340944
End Time   = 2006-08-23 19:08:58

    接下来看看第二个块中有什么DML(Insert/Update/Delete)操作?

LOG> extract block 2
Start extract redo SQL ...
INSERT INTO OBJ_1044190 (COL1,COL2,COL3,COL4,COL5) VALUES (?,?,?,?,?);

    再来看看对表(Object ID: 1044190)上的所有DML操作?

LOG> extract object 1044190
Start extract redo SQL ...
INSERT INTO OBJ_1044190 (COL1,COL2,COL3,COL4,COL5) VALUES (?,?,?,?,?);
INSERT INTO OBJ_1044190 (COL1,COL2,COL3,COL4,COL5) VALUES (?,?,?,?,?);
INSERT INTO OBJ_1044190 (COL1,COL2,COL3,COL4,COL5) VALUES (?,?,?,?,?);
INSERT INTO OBJ_1044190 (COL1,COL2,COL3,COL4,COL5) VALUES (?,?,?,?,?);
INSERT INTO OBJ_1044190 (COL1,COL2,COL3,COL4,COL5) VALUES (?,?,?,?,?);
INSERT INTO OBJ_1044190 (COL1,COL2,COL3,COL4,COL5) VALUES (?,?,?,?,?);
......
LOG>

    随便挑了几条和DUMP LOGFILE的结果进行对比, 基本上是吻合的, 终于有了一个良好的开始.如果感觉上面的信息象在骗你, 那就下载这个文件看看吧!

    到目前为止, 形成Redo的SQL语句(先不考虑Row Chain, Row Migration及LOB等情况)是没有问题了. 留下的一个很艰难的任务是如何区分事务. 即解出来的那一些语句是属于一个事务(Transaction)的? 因为Redo SQL解出来已经按照先后顺序了, 只要找出属于同一个事务的Redo记录中的共同点就可以了.

    先不考虑日志中的内容, 则会话的SID和SERIAL#值到是很可以用来作为这一样的一根线的, 可惜的是在日志中并没有记录这两个值, 因此这是不行的. 为了找出这一条线, 我们先来看一下标记一个事务为提交的Redo记录(Layer=5, OP=4) :

REDO RECORD - Thread:1 RBA: 0x005e30.00000006.0028 LEN: 0x0050 VLD: 0x01
SCN: 0x031f.05c00827 SUBSCN:  1 08/23/2006 19:08:22
CHANGE #1 TYP:0 CLS:43 AFN:394 DBA:0x6280b402 SCN:0x031f.05c00822 SEQ:  1 OP:5.4
ktucm redo: slt: 0x0018 sqn: 0x000daa6f srt: 0 sta: 9 flg: 0x2
ktucf redo: uba: 0x3b41c2dd.3bce.2d ext: 28 spc: 3560 fbi: 0

    从这里面, 我第一眼看到, 以为可以用uba来作为这样的一根线, 但很快发现可能是错误的. 另一个可能的线是XID, 这里面可以找到XID的usn(slt: 0x0018)和wrap(sqn: 0x000daa6f), 但是我不确定有没有slot(ext: 28). 本就对这些东西半懂不懂的, 因为以写MyDUL时是不管回滚段的, 所以还是很不熟悉其格式的.

    今天又修改了一下MyLOG程序, 程序的Extract命令输出例子如下:

RBA=0x005e30.00000002.0010,  SCN=0x031f.05c00824,  XID=0x0012.049.000dc2bb,  UBA=0x62c263c4.498b.08
   INSERT INTO OBJ_1044190 (COL1,COL2,COL3,COL4,COL5) VALUES (?,?,?,?,?);

RBA=0x005e30.00000002.0188,  SCN=0x031f.05c00824,  UBA=0x3b41c2dd.3bce.2d
   UPDATE OBJ_28267 SET COL84 = ?,COL95 = ?,COL96 = ? WHERE COL84 = ? AND COL95 = ? AND COL96 = ?;

RBA=0x005e30.00000004.0128,  SCN=0x031f.05c00824,  UBA=0xb4000fe3.1a0a.0e
   UPDATE OBJ_28267 SET COL3 = ?,COL20 = ?,COL23 = ?,COL34 = ?,COL35 = ?,COL36 = ?,COL39 = ?,COL40 = ?,COL41 = ?,COL45 = ?,COL51 = ?,COL82 = ?,COL83 = ?,COL84 = ?,COL95 = ?,COL96 = ? WHERE COL3 = ? AND COL20 = ? AND COL23 = ? AND COL34 = ? AND COL35 = ? AND COL36 = ? AND COL39 = ? AND COL40 = ? AND COL41 = ? AND COL45 = ? AND COL51 = ? AND COL82 = ? AND COL83 = ? AND COL84 = ? AND COL95 = ? AND COL96 = ?;

RBA=0x005e30.00000006.0028,  UBA=0x3b41c2dd.3bce.2d,  Commit Transaction

RBA=0x005e30.00000007.0044,  UBA=0xb4000fe3.1a0a.0e,  Commit Transaction

    输入出中的UBA将会被替换掉, 依我的估计, usn和slot结合起来可以作为控制事务的一条线. 看来一个数据库最多只能有64K(16位)个回滚段, 每个回滚段只能有4096个事务槽(12位). 你可以下载这个文件看看MyLOG的进展.