查看: 5137|回复: 15

Oracle技术嘉年华的一个案例,redo的那些事,连载二

[复制链接]
论坛徽章:
86
2015中国数据库技术大会纪念徽章
日期:2015-04-24 16:04:24马上有车
日期:2014-02-19 11:55:14马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11优秀写手
日期:2013-12-18 09:29:11日产
日期:2013-10-17 08:44:39马自达
日期:2013-08-26 16:28:022013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-23 16:55:51马上有房
日期:2014-02-19 11:55:14
发表于 2011-10-31 09:49 | 显示全部楼层 |阅读模式
本帖最后由 sundog315 于 2011-10-31 16:11 编辑

电梯
Oracle技术嘉年华的一个案例,redo的那些事,连载一
Oracle技术嘉年华的一个案例,redo的那些事,连载三
前篇的结论是,由于没有开启附加日志,导致这条记录无法正确的解析。那么进一步,到底是什么原因导致这条记录不能得到正确的解析呢?决定进一步探究一下

我们再来看一下logfile dump的结果,在eygle大师的PPT里,信息并不完整,下面是完整的信息:

REDO RECORD - Thread:1 RBA: 0x00309e.00028b4d.0010 LEN: 0x0114 VLD: 0x01
SCN: 0x0001.4be86fb9 SUBSCN:  1 07/05/2011 16:41:54
CHANGE #1 TYP:0 CLS:22 AFN:2 DBA:0x00801542 OBJ:0 SCN:0x0001.4be86efe SEQ:  1 OP:5.1
ktudb redo: siz: 116 spc: 7530 flg: 0x0022 seq: 0xaf17 rec: 0x05
            xid:  0x0003.022.0019482c  
ktubu redo: slt: 34 rci: 4 opc: 11.1 objn: 66237 objd: 67018 tsn: 8
Undo type:  Regular undo       Undo type:  Last buffer split:  No
Tablespace Undo:  No
             0x00000000
KDO undo record:
KTB Redo
op: 0x04  ver: 0x01  
op: L  itl: xid:  0x000a.01e.001a0c96 uba: 0x00800c0a.b193.29
                      flg: C---    lkc:  0     scn: 0x0001.4bb7744a
KDO Op code: URP row dependencies Disabled
  xtype: XA flags: 0x00000000  bdba: 0x0bc01db2  hdba: 0x0900e509
itli: 3  ispac: 0  maxfr: 4863
tabn: 0 slot: 47(0x2f) flag: 0x0c lock: 0 ckix: 0
ncol: 33 nnew: 2 size: -1
col  7: [ 1]  35
col 15: [ 1]  80

CHANGE #2 TYP:2 CLS: 1 AFN:47 DBA:0x0bc01db2 OBJ:0 SCN:0x0001.4be1efdb SEQ:  1 OP:11.5
KTB Redo
op: 0x01  ver: 0x01  
op: F  xid:  0x0003.022.0019482c    uba: 0x00801542.af17.05
KDO Op code: URP row dependencies Disabled
  xtype: XA flags: 0x00000000  bdba: 0x0bc01db2  hdba: 0x0900e509
itli: 3  ispac: 0  maxfr: 4863
tabn: 0 slot: 47(0x2f) flag: 0x0c lock: 3 ckix: 0
ncol: 33 nnew: 2 size: 1
col  7: [ 1]  31
col 15: [ 2]  c3 05

是不是觉得很奇怪?这里的object id居然是0?那么到底是不是这个原因导致logminer无法解析呢?我们来做个实现。我们直接对归档日志进行修改,看看是否能够让logminer正确解析。

这里需要使用BBED工具

BBED: Release 2.0.0.0.0 - Limited Production on Thu Oct 27 16:22:22 2011

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

************* !!! For Oracle Internal Use only !!! ***************

BBED> SET FILENAME '/1_12446.dbf'
        FILENAME        /1_12446.dbf

BBED> set blocksize 512
        BLOCKSIZE       512

BBED> set block 166733
        BLOCK#          166733

BBED> d
File: /1_12446.dbf (0)
Block: 166733           Offsets:    0 to  511           Dba:0x00000000
------------------------------------------------------------------------
0000309e 00028b4d 2d0b49d2 0010fb83 00000114 01010001 4be86fb9 05010016
#####这里是OP:5.1
00000002 00801542 4be86efe 00010000 01000000 00100014 00180020 001d0004
#####红色部分是5.1OBJ部分,等下我们要修改
00010001 00741d6a 00220000 00030022 0019482c af170500 000102bd 000105ca
00000008 00000000 0b012204 00000000 04010000 00000000 000a001e 001a0c96
00800c0a b1932900 80000001 4bb7744a 0bc01db2 0900e509 12ff0501 03000000
0c000000 002f2102 ffff0000 00010000 0007000f 35040014 80010100 0b050001
#####这里是OP:11.5
0000002f 0bc01db2 4be1efdb 00010000 01020000 000c0018 001d0004 00010002
#####红色部分是11.5OBJ部分,等下我们要修改
01010000 00000000 00030022 0019482c 00801542 af170500 0bc01db2 0900e509

<32 bytes per line>

找到了位置,我们做一下修改

BBED> set offset 50
        OFFSET          50

BBED> m /x deb8
File: /1_12446.dbf (0)
Block: 166733           Offsets:   50 to  511           Dba:0x00000000
------------------------------------------------------------------------
deb80010 00140018 0020001d 00040001 00010074 1d6a0022 00000003 00220019

BBED> set offset 210
        OFFSET          210

BBED> m /x f050
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /1_12446.dbf (0)
Block: 166733           Offsets:  210 to  511           Dba:0x00000000
------------------------------------------------------------------------
f050000c 0018001d 00040001 00020101 00000000 00000003 00220019 482c0080


OK,修改完毕,我们来重新logminer挖掘一下:

SQL> select t.RBABLK,t.RBABYTE,t.DATA_OBJ#,t.ROW_ID,t.OPERATION,t.SQL_REDO,t.INFO from v$logmnr_contents t where t.RBABLK=166733;
select t.RBABLK,t.RBABYTE,t.DATA_OBJ#,t.ROW_ID,t.OPERATION,t.SQL_REDO,t.INFO from v$logmnr_contents t where t.RBABLK=166733
                                                                                  *
ERROR at line 1:
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 166733 change 5568491448 time 07/05/2011 16:41:54
ORA-00334: archived log: '/1_12446.dbf'

额,报错了,checksum有问题,导致Oracle根本就不去读这个redo。我们试着清除一下checksum

继续使用BBED,修改checksum

BBED> SET FILENAME '/1_12446.dbf'
        FILENAME        /1_12446.dbf

BBED> set blocksize 512
        BLOCKSIZE       512

BBED> set block 166733
        BLOCK#          166733

BBED> set offset 14         
        OFFSET          14

这里需要注意的是,REDO BLOCKchecksum在第1416字节处

BBED> m /x 0000              --checksum清空为0
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /1_12446.dbf (0)
Block: 166733           Offsets:   14 to  511           Dba:0x00000000
------------------------------------------------------------------------
00000000 01140101 00014be8 6fb90501 00160000 00020080 15424be8 6efe0001

我们再来用logminer读取一下

SQL> select t.RBABLK,t.RBABYTE,t.DATA_OBJ#,t.ROW_ID,t.OPERATION,t.SQL_REDO,t.INFO from v$logmnr_contents t where t.RBABLK=166733;

166733  16  66237  AAAQXKAAAAAAAAAAAA  UNSUPPORTED  Unsupported  Object or Data type Unsupported

居然没有报错,checksum清除以后,即使内容发生了变化,也可以顺利的读取。
一个引申的问题,一般当我们的数据库出现ORA-00368错误时,基本都是采用清空logfile的方式(非当前在线日志),或resetlogs,那么我们是否也可以通过修改checksum来使Oracle跳过checksum错误呢?这值得有时间时试验一下。

但是,我们的问题依然没有解决,到底我们的修改有没有生效?logfile dump看一下:
CHANGE #1 TYP:0 CLS:22 AFN:2 DBA:0x00801542 OBJ:57016 SCN:0x0001.4be86efe SEQ:  1 OP:5.1

CHANGE #2 TYP:2 CLS: 1 AFN:47 DBA:0x0bc01db2 OBJ:61520 SCN:0x0001.4be1efdb SEQ:  1 OP:11.5

已经更新了,看来不是这个问题。
再仔细看一下logfile dump文件,找找看还有什么可疑的地方

itli: 3  ispac: 0  maxfr: 4863
tabn: 0 slot: 47(0x2f) flag: 0x0c lock: 3 ckix: 0
ncol: 33 nnew: 2 size: 1
col  7: [ 1]  31
col 15: [ 2]  c3 05

flag,大家想到了什么?这里怎么好像是data block里的row flag?在DSI里,有这部分的详细描述
4.jpg

flag: 0x0c=First data piece and Last data piece

正常的记录,row flag应该是0x2c,对应—H-FL--,而现在是0x0c,对应----FL--,这个不就是行迁移以后的数据段么?难道是因为这个原因?最简单的验证方法,即将0x0c强制修改为0x2c,虽然这样修改后,ROWID应该是错误的,但至少应该可以正确解析

BBED> f /x 0c000000
File: /1_12446.dbf (0)
Block: 166733           Offsets:  160 to  511           Dba:0x00000000
------------------------------------------------------------------------
0c000000 002f2102 ffff0000 00010000 0007000f 35040014 80010100 0b050001

<32 bytes per line>

BBED> m /x 2c000000
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /1_12446.dbf (0)
Block: 166733           Offsets:  160 to  511           Dba:0x00000000
------------------------------------------------------------------------
2c000000 002f2102 ffff0000 00010000 0007000f 35040014 80010100 0b050001

这回再logminer看看

166733  16  66237  AAAQXKAAvAAAB2yAAv  UPDATE  update "UNKNOWN"."OBJ# 66237" set "COL 8" = HEXTORAW('31'), "COL 16" = HEXTORAW('c305') where "COL 8" = HEXTORAW('35') and "COL 16" = HEXTORAW('80') and ROWID = 'AAAQXKAAvAAAB2yAAv';
Dictionary Mismatch

可以正确解析了。


大致猜测一下logminer的原理吧,logminer在解析标准SQL时,where中会带着这条记录的ROWID,但是,请大家注意,如果这条记录不是行头,那么,根据这个redo 向量中记录的object id,file#,block#,slot#算出的ROWID其实不是这条记录真正的ROWID,而当没有开启附加日志时,Header piece是不会进行记录的,所以,logminer根本就没有办法得到准确的ROWID。
论坛徽章:
1088
金色在线徽章
日期:2007-04-25 04:02:08金色在线徽章
日期:2007-06-29 04:02:43金色在线徽章
日期:2007-03-11 04:02:02在线时间
日期:2007-04-11 04:01:02在线时间
日期:2007-04-12 04:01:02在线时间
日期:2007-03-07 04:01:022008版在线时间
日期:2010-05-01 00:01:152008版在线时间
日期:2011-05-01 00:01:342008版在线时间
日期:2008-06-03 11:59:43ITPUB年度最佳技术原创精华奖
日期:2013-03-22 13:18:30
发表于 2011-10-31 09:53 | 显示全部楼层
nice job

使用道具 举报

回复
论坛徽章:
14
奥运会纪念徽章:拳击
日期:2008-04-24 10:00:15CTO参与奖
日期:2009-02-12 11:45:482012新春纪念徽章
日期:2012-02-07 09:59:35ITPUB季度 技术新星
日期:2012-02-16 14:53:16鲜花蛋
日期:2012-03-19 18:10:462013年新春福章
日期:2013-02-25 14:51:242014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11
发表于 2011-10-31 09:55 | 显示全部楼层
学习

使用道具 举报

回复
论坛徽章:
27
会员2007贡献徽章
日期:2007-09-26 18:42:102011新春纪念徽章
日期:2011-02-18 11:43:342010广州亚运会纪念徽章:排球
日期:2011-03-03 12:19:332010广州亚运会纪念徽章:篮球
日期:2011-03-10 14:25:06ITPUB十周年纪念徽章
日期:2011-09-27 16:30:47ITPUB十周年纪念徽章
日期:2011-11-01 16:21:15灰彻蛋
日期:2011-12-28 16:56:322012新春纪念徽章
日期:2012-01-04 11:50:44迷宫蛋
日期:2012-03-09 15:14:20蜘蛛蛋
日期:2012-03-26 09:46:32
发表于 2011-10-31 10:03 | 显示全部楼层
不错 我都看不懂 ^_^  
在北京就是好啊  没事就可以 参加个 会 提高提高技术

使用道具 举报

回复
论坛徽章:
86
2015中国数据库技术大会纪念徽章
日期:2015-04-24 16:04:24马上有车
日期:2014-02-19 11:55:14马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11优秀写手
日期:2013-12-18 09:29:11日产
日期:2013-10-17 08:44:39马自达
日期:2013-08-26 16:28:022013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-23 16:55:51马上有房
日期:2014-02-19 11:55:14
 楼主| 发表于 2011-10-31 10:05 | 显示全部楼层
carcase 发表于 2011-10-31 10:03
不错 我都看不懂 ^_^  
在北京就是好啊  没事就可以 参加个 会 提高提高技术


欢迎来北京啊

使用道具 举报

回复
论坛徽章:
3
2011新春纪念徽章
日期:2011-02-18 11:43:35ITPUB十周年纪念徽章
日期:2011-11-01 16:21:152013年新春福章
日期:2013-02-25 14:51:24
发表于 2011-10-31 10:20 | 显示全部楼层
太专业了!

使用道具 举报

回复
论坛徽章:
6
ITPUB季度 技术新星
日期:2011-08-31 15:27:58ITPUB十周年纪念徽章
日期:2011-11-01 16:26:292012新春纪念徽章
日期:2012-01-04 11:57:36咸鸭蛋
日期:2012-03-05 13:10:24ITPUB 11周年纪念徽章
日期:2012-10-09 18:16:00优秀写手
日期:2013-12-18 09:29:09
发表于 2011-10-31 10:31 | 显示全部楼层

使用道具 举报

回复
招聘 : Linux运维
论坛徽章:
2
2012新春纪念徽章
日期:2012-01-04 11:58:18双黄蛋
日期:2012-02-29 11:03:35
发表于 2011-10-31 11:02 | 显示全部楼层
牛啊, 新手表示看不懂

使用道具 举报

回复
认证徽章
论坛徽章:
764
2014年世界杯参赛球队: 加纳
日期:2014-05-20 17:24:592014年世界杯参赛球队:墨西哥
日期:2014-05-20 17:25:142014年世界杯参赛球队: 波黑
日期:2014-05-20 17:27:292014年世界杯参赛球队: 希腊
日期:2014-07-15 11:05:212014年世界杯参赛球队: 阿尔及利亚
日期:2014-07-15 11:05:212014年世界杯参赛球队: 厄瓜多尔
日期:2014-07-15 14:14:452014年世界杯参赛球队: 哥斯达黎加
日期:2014-06-16 15:29:332014年世界杯参赛球队: 智利
日期:2014-06-16 17:03:11 2014年世界杯参赛球队: 德国
日期:2014-06-16 17:10:512014年世界杯参赛球队: 葡萄牙
日期:2014-06-18 09:28:47
发表于 2011-10-31 11:36 | 显示全部楼层
连载三在哪?

使用道具 举报

回复
论坛徽章:
86
2015中国数据库技术大会纪念徽章
日期:2015-04-24 16:04:24马上有车
日期:2014-02-19 11:55:14马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11优秀写手
日期:2013-12-18 09:29:11日产
日期:2013-10-17 08:44:39马自达
日期:2013-08-26 16:28:022013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-23 16:55:51马上有房
日期:2014-02-19 11:55:14
 楼主| 发表于 2011-10-31 11:40 | 显示全部楼层
songmingliang 发表于 2011-10-31 11:36
连载三在哪?

敬请期待

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表