bbed修改 update 字段的值

2015/08/30

desertxu

在网上看了 Roger写的一篇文章，关于global_name被update为空，导致无法启动的问题 http://www.killdb.com/2012/08/14/update-global_name%E4%B8%BA%E7%A9%BA%E7%9A%84%E6%81%A2%E5%A4%8D.html ，看了Roger 写的这篇文章，我自己就想了解oracle update 的原理，更加深入理解一下哦。
试验环境：

sys@ORA10G@143> select * from v$version;

BANNER

----------------------------------------------------------------

Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Prod

PL/SQL Release 10.2.0.2.0 - Production

CORE 10.2.0.2.0 Production

TNS for Solaris: Version 10.2.0.2.0 - Production

NLSRTL Version 10.2.0.2.0 - Production

scott@ORA10G@147> select dbms_rowid.rowid_relative_fno(rowid) file#,
2 dbms_rowid.rowid_block_number(rowid) block#,
3 dbms_rowid.rowid_row_number(rowid) row# ,deptno,dname,loc from dept;

FILE# BLOCK# ROW# DEPTNO DNAME LOC
---------- ---------- ---------- ---------- -------------- -------------
4 14 0 10 ACCOUNTING NEW YORK
4 14 1 20 RESEARCH DALLAS
4 14 2 30 SALES CHICAGO
4 14 3 40 OPERATIONS BOSTON

我们在update 第二行数据之前，先用bbed 看看这行数据存储位置
bbed parfile=par.txt
BBED>set file 4 block 14
BBED> p kdbr[2]
sb2 kdbr[2] @122 8020 --行头指针，这里与行头相差100offset，版本10.2.0.2,Roger环境 10.2.0.5 是相差 92

BBED> p *kdbr[2]
rowdata[24]
-----------
ub1 rowdata[24] @8120 0x2c --行头

BBED> x/rcccc
rowdata[24] @8120
-----------
flag@8120: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8121: 0x01
cols@8122: 3

col 0[2] @8123: ..
col 1[5] @8126: SALES
col 2[7] @8132: CHICAGO

现在update
update dept set loc='SHANGHAI' where deptno=30;
commit;
alter sysem flush buffer_cache;-- 强制刷磁盘

在看看更新后的第2行数据存储位置信息

退出重新进入bbed
看看 update 之前的值，是否还在数据文件里
BBED> d /v offset 8132

File: /export/home/oracle/oradata/ora10g/users01.dbf (4) --oracle update 并没有把原来的值，删除掉，只是把行指针移动到新的位置里。
Block: 14 Offsets: 8132 to 8191 Dba:0x0100000e
-------------------------------------------------------
07434849 4341474f 2c000302 c1150852 l .CHICAGO,......R
45534541 52434806 44414c4c 41532c00 l ESEARCH.DALLAS,.
0302c10b 0a414343 4f554e54 494e4708 l .....ACCOUNTING.
4e455720 594f524b 02063316 l NEW YORK..3.

BBED> p kdbr[2]
sb2 kdbr[2] @122 7975 --相差 100

BBED> p *kdbr[2]
rowdata[0]
----------
ub1 rowdata[0] @8075 0x2c

BBED> x/rncc
rowdata[0] @8075
----------
flag@8075: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8076: 0x02
cols@8077: 3

col 0[2] @8078: 30 ---这里看出来了 3个offset 与原来的offset 都变动了，update某个字段，oracle是整行迁移到新位置，
col 1[5] @8081: SALES 只是把update的字段值变了一下，所以如果要通过bbed改回到update 之前的值，只要修改一下行头
col 2[8] @8087: SHANGHAI 行头指针的值

行头指针的位置在 offset 122
update之前行头指针值为 8020 转为16机制为1f54,而x86系统 oracle 是把它反转了存在数据文件中，实际修改是 541f
开始修改如下：

BED> set offset 122
OFFSET 122

BBED> d
File: /export/home/oracle/oradata/ora10g/users01.dbf (4)
Block: 14 Offsets: 122 to 633 Dba:0x0100000e
------------------------------------------------------------------------
271f3c1f 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<32 bytes per line>

BBED> m/x 541f
File: /export/home/oracle/oradata/ora10g/users01.dbf (4)
Block: 14 Offsets: 122 to 633 Dba:0x0100000e
------------------------------------------------------------------------
541f3c1f 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<32 bytes per line>

BBED> sum apply
Check value for File 4, Block 14:
current = 0x0023, required = 0x0023

BBED> verify
DBVERIFY - 开始验证
FILE = /export/home/oracle/oradata/ora10g/users01.dbf
BLOCK = 14

Block Checking: DBA = 16777230, Block Type = KTB-managed data block
data header at 0x81c8064
kdbchk: xaction header lock count mismatch
trans=2 ilk=1 nlo=0
块 14 失败, 校验代码为 6108

DBVERIFY - 验证完成

检查的总块数: 1
处理的总块数 (数据): 1
失败的总块数 (数据): 1
处理的总块数 (索引): 0
失败的总块数 (索引): 0
空的总块数: 0
标记为损坏的总数块: 0
流入的块总数: 0

查看验证是否变成udpate 原来的值了

scott@ORA10G@147> select dbms_rowid.rowid_relative_fno(rowid) file#,
2 dbms_rowid.rowid_block_number(rowid) block#,
3 dbms_rowid.rowid_row_number(rowid) row# ,deptno,dname,loc from dept;

FILE# BLOCK# ROW# DEPTNO DNAME LOC
---------- ---------- ---------- ---------- -------------- -------------
4 14 0 10 ACCOUNTING NEW YORK
4 14 1 20 RESEARCH DALLAS
4 14 2 30 SALES CHICAGO
4 14 3 40 OPERATIONS BOSTON

大功告成！

这个实际对工作中不太会用到，比如误删除表、误更新、delete操作，一般都是用 flashback drop flashbackup table、闪回数据库等技术，不过可以加深对oracle block 结构的理解。

ITPub博客

bbed 修改update值

最新文章