Focus on Oracle

Some lob internal

2010-07-26T15:35:23Z

这篇文章源于我昨天和今天跟老熊的无数次电话交流，老熊是极其强悍的，每次我跟他讨论完问题后，我对某个知识点的认识都能得到质的提高，再次感谢老熊！

1、402e里这么提到----When a LOB is stored out-of-line in an "enable storage in row" LOB column between 36 and 84 bytes of control data remain in-line in the row piece. 这里的control data到底是指什么？

答：这里的control data就是指的12个chunk的起始RDBA。

col 0: [ 2] c1 02

col 1: [ 7] 63 75 69 68 75 61 31

col 2: [84]

00 54 00 01 01 0c 00 00 00 01 00 00 00 01 00 00 00 01 1e b9 00 40 05 00 00

00 00 36 1a d8 00 00 00 00 00 02 01 00 01 ad 01 00 02 75 01 00 02 7d 01 00

02 85 01 00 03 0d 01 00 03 15 01 00 03 1d 01 00 03 25 01 00 03 2d 01 00 03

35 01 00 03 3d 01 00 03 45

这里的lob id是00 00 00 01 00 00 00 01 1e b9，这里的第36个byte到第84个byte就是12个RDBA，第1个RDBA是01 00 01 ad，......，第12个RDBA是01 00 03 45，注意这里记录的RDBA是以chunk为单位的起始RDBA，比如我这里的chunk size是32K（库的block size是8K），所以01 00 01 ad, 01 00 01 ae, 01 00 01 af, 01 00 01 b0都属于第一个chunk，即它们的page number都是0，但因为这四个block是连续的，且属于同一个chunk，所以oracle这里只需记录一个起始RDBA就可以了。

2、lob index的结构到底是怎样的？

答：lob index的结构类似于unique index的结构，它长度为50个byte，具体组成如下：

行头（1个byte）＋ lock byte（1个byte）＋ lob index key ( 32个byte，要么由16个byte的lob inode+4个RDBA组成，要么由8个RDBA组成) ＋ lob id的长度（1个byte）＋ lob id（10个byte）＋ page number的长度（1个byte）＋ page number（4个byte）

所以一共是1+1+32+1+10+1+4=50个byte

3、当lob index损坏后如何恢复？

答：DUL10号称是支持lob index损坏后的恢复的，但这里有一个最大的问题就是假如是disable storage in row，那么lob inode会存储在page number为0的lob index里，假如这个page number为0的lob index损坏了，那么我们就无法知道最后一个page里到底有多少byte是有效的。

col 0: [ 2] c1 02

col 1: [ 7] 63 75 69 68 75 61 31

col 2: [84]

00 54 00 01 01 0c 00 00 00 01 00 00 00 01 00 00 00 01 1e b9 00 40 05 00 00

00 00 36 1a d8 00 00 00 00 00 02 01 00 01 ad 01 00 02 75 01 00 02 7d 01 00

02 85 01 00 03 0d 01 00 03 15 01 00 03 1d 01 00 03 25 01 00 03 2d 01 00 03

35 01 00 03 3d 01 00 03 45

比如上述例子里，我们知道最后一个lob page里有效的byte是1a d8

SQL> select to_number('1ad8','XXXXXXXX') from dual;

TO_NUMBER('1AD8','XXXXXXXX')

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

6872

再来看相应的lob index：

row#0[7986] flag: ------, lock: 2, len=50, data:(32):

01 00 03 4d 01 00 03 55 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00

col 0; len 10; (10): 00 00 00 01 00 00 00 01 1e b9

col 1; len 4; (4): 00 00 00 0c

这里可以看到，最后一个chunk的起始RDBA是01 00 03 55，但是朋友们千万不要以为这个就是那6872个byte所在的block，实际上，我dump后发现01 00 03 55里是个空的lob块（实际上这里也是一个full块，只不过所有的byte都是0x00，看起来就跟空块一样），真正的存储那6872个byte的block是01 00 03 57，而且我通过比对我insert的图片的最后几个byte和01 00 03 57中存储的内容，算出来刚好里面的有效的byte是6872：

SQL> select 286*24+8 from dual;

286*24+8

----------

6872

另外，这里也可以这么定位最后一个lob块：

在1da8（即6872）前面的那4个byte是0x00000036，表示这个LOB full block的块数，注意是块数，而不是chunk数。这里0x00000036=54个块，表示有54个块是满的，第55个不是满的，里面有6872字节。

再看下面那个lob index，page number从0x0c，即12开始，从0开始算的。那么这个chunk里面，之前已经有12*4=48个块是满的，这里01 00 03 4d开始的chunk，4个块也是满的，48+4=52，所以这个以01 00 03 55开头的chunk，有2个块是满的，就是01 00 03 55和 01 00 03 56，最后那个块我之前说的01 00 03 57了。

这就提示我们，当极端的情况下（disable storage in row且lob inode所在的lob index已经损坏），则我们需要扫描lob segment，取出其中存储的lob id和page number（相当于重构lob index），但是这里在扫描某个data object id所属的lob id和page number的时候，需要额外处理同一个lob id下的最大的page number----要去扫描这个page number下的所有block，且最大的RDBA里最后一个不为0的byte就是lob inode记录的最后一个page的有效byte数。

Lob的字符集和字节序

2010-07-23T09:19:29Z

402e里这么描述CLOB和NCLOB所用的字符集：

CLOB is used to store character data using the database character set. The internal

code is 112.

NCLOB is used to store character data using the national character set. The internal

code is 112.

但这是不对的，至少是不全面的，我们来看一下真相是什么。

对于定长的字符集而言，如WE8MSWIN1252 , AR8ISO8859P6等，确实就如402e里所描述的那样，CLOB所用的字符集就是和库里所用的字符集一致。

对于变长的字符集而言，如ZHS16GBK、UTF8、AL32UTF8等，oracle这里实际上会做一个字符集间的转换，也就是说，实际存储在CLOB/NCLOB里的字符集其实是internal fixed-width Unicode character set，这个internal fixed-width Unicode character set目前来看，只能是UCS2 或者AL16UTF16。

UCS2和AL16UTF16的大致区别为：

* UCS2 is a subset of the UTF16 standard.

* UCS2的字节序跟库所在的platform的字节序一致

* AL16UTF16的字节序始终是big endian

从这里我们可以推断出，在big endian的platform上UCS2就等于AL16UTF16

如下的这张图非常经典，已经说明了一切：

关于这个图的详细信息大家可以去看"CLOBs and NCLOBs character set storage in Oracle Release 8i, 9i, 10g and 11g. [ID 257772.1]"，里面解释的非常清楚。

里面有一段话这么说：

On Big Endian platforms, when a database with a varying-width database or national character set is migrated to Oracle Database 10g, no conversion of the stored CLOB and NCLOB data is necessary as UCS2 and AL16UTF16 are equivalent. On Little Endian platforms, the storage character set is not changed as part of the upgrade. Only column meta-data is updated to indicate that the CLOB/NCLOB columns are in Little Endian format. There is no usage impact after the migration because the internal format is not exposed to users, and proper conversions will happen implicitly in the system.

这里的meta-data是指lob$里的字段property，sql.bsq里明确指出：

property number not null, /* 0x00 = user defined lob column */

/* 0x01 = kernel column(s) stored as lob */

/* 0x02 = user lob column with row data */

/* 0x04 = partitioned LOB column */

/* 0x0008 = LOB In Global Temporary Table */

/* 0x0010 = Session-specific table */

/* 0x0020 = lob with compressed header */

/* 0x0040 = lob using shared segment */

/* 0x0080 = first lob using shared segment */

/* 0x0100 = klob and inline image coexist */

/* 0x0200 = LOB data in little endian format */

最后我们的结论为：

1、如果库的字符集是定长字符集，则CLOB所用的字符集和库的字符集一致，字节序也和库所在的platform的字节序一致。

2、当库的字符集是变长字符集的时候，CLOB/NCLOB所用的字符集只能是UCS2或者AL16UTF16，AL16UFT16始终是big endian，UCS2的字节序则和库所在的platform的字节序一致。具体又分为如下这几种情况：

1) 如果是8i/9i，则CLOB/NCLOB所用的字符集都是UCS2

2) 如果是10g，CLOB/NCLOB所用的字符集基本上都是AL16UTF16，为UCS2的只有上图中所描述的那两种情况

其实这篇文章只是上述那篇metalink文档的一个翻译和总结，我为什么要写这篇文章来源于我昨天跟老熊之间的一次电话交流，他纠正了我长久以来的一个错误观点并且使我对lob internal的认识已经变得异常清晰，非常感谢老熊！

如何修改核心bootstrap$对象

2010-07-21T08:59:23Z

其实这篇文章的题目本应该叫做"9i下Move系统表DEPENDENCY$导致索引失效的恢复（续4）"，只是我觉得这么做有点拖沓，所以就把这篇文章中我们的核心处理方法提炼了出来，即如何修改核心bootstrap$对象。

我在

"9i下Move系统表DEPENDENCY$导致索引失效的恢复"、

"9i下Move系统表DEPENDENCY$导致索引失效的恢复（续）"、

"9i下Move系统表DEPENDENCY$导致索引失效的恢复（续2）"和

"9i下Move系统表DEPENDENCY$导致索引失效的恢复（续3）"这四篇文章里分别用了两种方法成功将上述库起起来了，但是我文中有提到----这种用BBED的处理方法已经接近完美。

所谓的接近完美的含义就是说还留有遗憾，我们来看一下遗憾是什么。I_DEPENDENCY1和I_DEPENDENCY2的obj#分别是127和128：

SQL_testdb>select count(*) from ind$ where obj#=127;

COUNT(*)

----------

SQL_testdb>select /*+ full(ind$) */count(*) from ind$ where obj#=127;

COUNT(*)

----------

SQL_testdb>select * from ind$ where obj#=127;

OBJ# DATAOBJ# TS# FILE# BLOCK# BO# INDMETHOD# COLS PCTFREE$ INITRANS MAXTRANS PCTTHRES$ TYPE# FLAGS PROPERTY BLEVEL LEAFCNT DISTKEY LBLKKEY DBLKKEY CLUFAC ANALYZETI SAMPLESIZE ROWCNT INTCOLS DEGREE INSTANCES TRUNCCNT SPARE1 SPARE2 SPARE3 SPARE4

---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- 30387 30387 0 1 4737 96 0 3 10 2 255 1 0 1 3 3

SQL_testdb>select count(*) from ind$ where obj#=128;

COUNT(*)

----------

SQL_testdb>select /*+ full(ind$) */count(*) from ind$ where obj#=128;

COUNT(*)

----------

SQL_testdb>select * from ind$ where obj#=128;

---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- 30388 30388 0 1 50945 96 0 2 10 2 255 1 0 0 2 2

这当然是因为我们只把ind$中的I_DEPENDENCY1和I_DEPENDENCY2用BBED给删掉了，但是ind$上还有索引I_IND1，I_IND1中I_DEPENDENCY1和I_DEPENDENCY2所对应的索引行还在，所以就导致出现了上述不一致的情况。

而I_IND1是核心bootstrap$（obj# < 56）对象，所以event 38003和startup migrate都对I_IND1无效：

SQL> select obj#,dataobj#,name from obj$ where name='I_IND1';

OBJ# DATAOBJ# NAME

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

39 39 I_IND1

SQL_testdb>drop index I_IND1;

drop index I_IND1

ERROR at line 1:

ORA-00701: object necessary for warmstarting database cannot be altered

SQL_testdb>shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL_testdb>startup mount pfile=/dras20/testdb/inittestdb.ora

ORACLE instance started.

Total System Global Area 504858456 bytes

Fixed Size 743256 bytes

Variable Size 285212672 bytes

Database Buffers 218103808 bytes

Redo Buffers 798720 bytes

Database mounted.

SQL_testdb>alter database open migrate;

Database altered.

SQL_testdb>drop index I_IND1;

drop index I_IND1

ERROR at line 1:

ORA-00701: object necessary for warmstarting database cannot be altered

在我看来，核心不核心的其实对我来说都无所谓。

好了，我们现在来用BBED来修正上述不一致。

修正的关键在于如下三个地方：

1、在I_IND1的对应索引行头递增01，并且修改相应的lock byte；

2、将kdxlende递增你删掉的索引行数；

3、将ktbbh中对应itl的lock count递增你删掉的索引行数；

现在我们来看一下修改完的效果：

SQL_testdb>startup pfile=/dras20/testdb/inittestdb.ora

ORACLE instance started.

Total System Global Area 504858456 bytes

Fixed Size 743256 bytes

Variable Size 285212672 bytes

Database Buffers 218103808 bytes

Redo Buffers 798720 bytes

Database mounted.

Database opened.

SQL_testdb>select count(*) from ind$ where obj#=127;

COUNT(*)

----------

SQL_testdb>select count(*) from ind$ where obj#=128;

COUNT(*)

----------

SQL_testdb>select * from ind$ where obj#=30387;

---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- 30387 30387 0 1 4737 96 0 3 10 2 255 1 0 1 3 3

SQL_testdb>select * from ind$ where obj#=30388;

---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- 30388 30388 0 1 50945 96 0 2 10 2 255 1 0 0 2 2

至此，这种用BBED来处理Move系统表DEPENDENCY$导致索引失效的恢复已经几无破绽。

9i下Move系统表DEPENDENCY$导致索引失效的恢复（续3）

2010-07-20T11:46:25Z

我在"9i下Move系统表DEPENDENCY$导致索引失效的恢复"、"9i下Move系统表DEPENDENCY$导致索引失效的恢复（续）"和"9i下Move系统表DEPENDENCY$导致索引失效的恢复（续2）"这三篇文章里分别用了两种方法成功将上述库起起来了。但是，我们还留了一个遗憾，那就是由于昨天我还不能够绕开oracle对index cluster block的block check机制，使得我们最后不得不用到了隐含参数*._db_always_check_system_ts=FALSE后才把上述库起起来。

今天，我终于，终于猜出来了怎样绕开index cluster block的block check机制，这就使得用BBED来处理上述问题的手段已接近完美。

之前会报错：

[P550_04_LA:oracle@:/cadrasu01/app/oracle/product/9.2.0/bin]#dbv file=/dras20/testdb/system01.dbf blocksize=8192

DBVERIFY: Release 9.2.0.6.0 - Production on Mon Jul 19 16:35:53 2010

DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf

Block Checking: DBA = 4194336, Block Type = KTB-managed data block

data header at 0x11015805c

kdbchk: key comref count wrong

keyslot=7

Page 32 failed with check code 6121

DBVERIFY - Verification complete

Total Pages Examined : 52480

Total Pages Processed (Data) : 36943

Total Pages Failing (Data) : 1

Total Pages Processed (Index): 4085

Total Pages Failing (Index): 0

Total Pages Processed (Other): 1750

Total Pages Processed (Seg) : 0

Total Pages Failing (Seg) : 0

Total Pages Empty : 9702

Total Pages Marked Corrupt : 0

Total Pages Influx : 0

Highest block SCN : 676215 (0.676215)

如果你尝试去修改上述block，可能会碰到下述错误，五花八门，不一而足：

DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf

Block Checking: DBA = 4194336, Block Type = KTB-managed data block

data header at 0x11015805c

kdbchk: bad row tab 3, slot 5

Page 32 failed with check code 6258

DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf

Block Checking: DBA = 4194336, Block Type = KTB-managed data block

data header at 0x11015805c

kdbchk: fsbo(282) wrong, (hsz 280)

Page 32 failed with check code 6129

DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf

Block Checking: DBA = 4194336, Block Type = KTB-managed data block

data header at 0x11015805c

kdbchk: row count in table index incorrect

Page 32 failed with check code 6125

DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf

Block Checking: DBA = 4194336, Block Type = KTB-managed data block

data header at 0x11015805c

kdbchk: table index offset incorrect

tab 4

Page 32 failed with check code 6124

DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf

Block Checking: DBA = 4194336, Block Type = KTB-managed data block

data header at 0x11015805c

kdbchk: non-existent key referenced

table=1 slot=0

Page 32 failed with check code 6140

DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf

Block Checking: DBA = 4194336, Block Type = KTB-managed data block

data header at 0x11015805c

kdbchk: key curref < comref

slot=7 curref=15 comref=17

Page 32 failed with check code 6119

我就是从上述最后一个报错中猜出来了应该怎么改了，其实说到底考验的还是你对index cluster block的熟悉程度。

好了，我们来看一下改完后的效果：

[P550_04_LA:oracle@:/cadrasu01/app/oracle/product/9.2.0/bin]#dbv file=/dras20/testdb/system01.dbf blocksize=8192

DBVERIFY: Release 9.2.0.6.0 - Production on Tue Jul 20 18:57:23 2010

DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf

DBVERIFY - Verification complete

Total Pages Examined : 52480

Total Pages Processed (Data) : 36707

Total Pages Failing (Data) : 0

Total Pages Processed (Index): 4431

Total Pages Failing (Index): 0

Total Pages Processed (Other): 1751

Total Pages Processed (Seg) : 0

Total Pages Failing (Seg) : 0

Total Pages Empty : 9591

Total Pages Marked Corrupt : 0

Total Pages Influx : 0

Highest block SCN : 698090 (0.698090)

现在去掉隐含参数_db_always_check_system_ts后我们一样可以把上述库打开了：

[P550_04_LA:oracle@:/dras20/testdb]#cat inittestdb.ora|grep _db_always_check_system_ts

[P550_04_LA:oracle@:/dras20/testdb]#sqlplus '/ as sysdba';

SQL*Plus: Release 9.2.0.6.0 - Production on Tue Jul 20 19:27:41 2010

Connected to an idle instance.

SQL_testdb>startup pfile=/dras20/testdb/inittestdb.ora

ORACLE instance started.

Total System Global Area 504858456 bytes

Fixed Size 743256 bytes

Variable Size 285212672 bytes

Database Buffers 218103808 bytes

Redo Buffers 798720 bytes

Database mounted.

Database opened.

9i下Move系统表DEPENDENCY$导致索引失效的恢复（续2）

2010-07-19T09:25:36Z

我在"9i下Move系统表DEPENDENCY$导致索引失效的恢复"和"9i下Move系统表DEPENDENCY$导致索引失效的恢复（续）"这两篇文章里用BBED成功将上述库起起来了，但是这里有一个问题----我处理的思路是把一切都恢复到以前未move的状态，但是如果DEPENDENCY$在move很长时间后才shutdown，那么原先DEPENDENCY$所属的旧block可能已经被覆盖了，此时上述两篇文章里的方法就不起作用了。

此时有没有办法处理上述情况呢？

当然有。

此时我们的处理思路就是骗过oracle，让oracle不知道索引I_DEPENDENCY1和I_DEPENDENCY2的存在。

注意，index cluster不能随便改的，所谓的牵一发而动全身在这里体现的太明显了。

此时最核心的处理思路就是我们在用BBED把I_DEPENDENCY1和I_DEPENDENCY2删掉后要用到一个隐含参数*._db_always_check_system_ts=FALSE，接着把库起起来后要删掉一系列数据字典表里跟上述两个索引相关联的数据，让I_DEPENDENCY1和I_DEPENDENCY2彻底的成为尸体。

我们来看一下，当我把I_DEPENDENCY1和I_DEPENDENCY2删掉后：

[P550_04_LA:oracle@:/cadrasu01/app/oracle/product/9.2.0/bin]#dbv file=/dras20/testdb/system01.dbf blocksize=8192

DBVERIFY: Release 9.2.0.6.0 - Production on Mon Jul 19 16:35:53 2010

DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf

Block Checking: DBA = 4194336, Block Type = KTB-managed data block

data header at 0x11015805c

kdbchk: key comref count wrong

keyslot=7

Page 32 failed with check code 6121

DBVERIFY - Verification complete

Total Pages Examined : 52480

Total Pages Processed (Data) : 36943

Total Pages Failing (Data) : 1

Total Pages Processed (Index): 4085

Total Pages Failing (Index): 0

Total Pages Processed (Other): 1750

Total Pages Processed (Seg) : 0

Total Pages Failing (Seg) : 0

Total Pages Empty : 9702

Total Pages Marked Corrupt : 0

Total Pages Influx : 0

Highest block SCN : 676215 (0.676215)

你如果尝试去修正上述错误，会陷入无尽的痛苦之中，oracle的block check太严格了。

SQL_testdb>startup pfile=/dras20/testdb/inittestdb.ora

ORACLE instance started.

Total System Global Area 504858456 bytes

Fixed Size 743256 bytes

Variable Size 285212672 bytes

Database Buffers 218103808 bytes

Redo Buffers 798720 bytes

Database mounted.

Database opened.

SQL_testdb>select count(*) from dba_tables;

COUNT(*)

----------

816

[P550_04_LA:oracle@:/dras20/testdb]#exp scott/tiger@testdb file=emp.dmp tables=emp

Export: Release 9.2.0.6.0 - Production on Mon Jul 19 16:38:28 2010

Connected to: Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.6.0 - Production

Export done in US7ASCII character set and AL16UTF16 NCHAR character set

server uses ZHS16GBK character set (possible charset conversion)

About to export specified tables via Conventional Path ...

. . exporting table EMP 14 rows exported

EXP-00091: Exporting questionable statistics.

Export terminated successfully with warnings.

SQL_testdb>delete from icol$ where obj#=127;

3 rows deleted.

SQL_testdb>delete from icol$ where obj#=128;

2 rows deleted.

SQL_testdb>delete from ind$ where obj#=127;

delete from ind$ where obj#=127

ERROR at line 1:

ORA-00600: internal error code, arguments: [13011], [2], [4194336], [5],[4194336], [3], [], []

SQL_testdb>delete from obj$ where obj# =127;

1 row deleted.

SQL_testdb>delete from obj$ where obj# =128;

1 row deleted.

SQL_testdb>delete from seg$ where ts#=0 and file#=1 and block#=977;

1 row deleted.

SQL_testdb>delete from seg$ where ts#=0 and file#=1 and block#=985;

1 row deleted.

SQL_testdb>commit;

Commit complete.

SQL_testdb>create unique index SYS.I_DEPENDENCY1_BCK on SYS.DEPENDENCY$ (D_OBJ#, D_TIMESTAMP, ORDER#) tablespace SYSTEM;

Index created.

SQL_testdb>create index SYS.I_DEPENDENCY2_BCK on SYS.DEPENDENCY$ (P_OBJ#, P_TIMESTAMP) tablespace SYSTEM;

Index created.

SQL_testdb>select count(*) from DEPENDENCY$;

COUNT(*)

----------

49930

SQL_testdb>select owner,index_name,tablespace_name,status from dba_indexes where table_name='DEPENDENCY$';

OWNER INDEX_NAME

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

TABLESPACE_NAME STATUS

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

SYS I_DEPENDENCY1_BCK

SYSTEM VALID

SYS I_DEPENDENCY2_BCK

SYSTEM VALID

SQL_testdb>select object_id,data_object_id from dba_objects where object_name='DEPENDENCY$';

OBJECT_ID DATA_OBJECT_ID

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

96 30367

这是我能想到的比较好的拯救方法。有朋友不断的在跟我要这个系列文章的详细处理过程，我不愿意给的原因是处理过程过于internal和复杂，而且我其实已经把最核心的思路和方法都写出来了。其实我只是把我的想法变成了现实而已，如果你也对internal感兴趣，为什么一定要指望别人呢？为什么不尝试自己动手试一下？

事实上，如果你有完善的备份，上面的处理方面是完全不必要的，也是没有意义的。

9i下Move系统表DEPENDENCY$导致索引失效的恢复（续）

2010-07-16T05:53:24Z

昨天写了"9i下Move系统表DEPENDENCY$导致索引失效的恢复"，eygle留言说我已经走火入魔，呵呵，是有一点----真实的生产环境不会像我这么干的----太麻烦了，直接用DUL或者ODU就好了。

今天终于把昨天那个库彻底改好了，至此，我可以说----我已经可以通过BBED完全修正上述错误，虽然修正的过程极其艰难！

我觉得这个例子是极其经典的，因为我综合运用到了下述知道点和手段：

1、 move internal；

2、 index unusable internal；

3、 index cluster internal；

4、 update internal；

5、如何安全的修改system表空间下的block；

6、 ODU（因为我需要借助ODU才能知道move后的新段头和新data object id）；

7、 bootstrap$ internal；

最后我在用到了上述知识点的情况下修改了ind$，tab$，obj$和seg$后终于艰难的恢复了上述库。

我们首先来看一下昨天的遗留问题，昨天虽然库起来了，但我说过这个库基本上是不能用的，因为：

SQL_testdb>alter index I_DEPENDENCY1 rebuild online;

alter index I_DEPENDENCY1 rebuild online

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-01410: invalid ROWID

SQL_testdb>drop index I_DEPENDENCY1;

drop index I_DEPENDENCY1

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-01410: invalid ROWID

SQL_testdb>select count(*) from dba_objects;

select count(*) from dba_objects

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-01410: invalid ROWID

[P550_04_LA:oracle@:/dras20/testdb]#exp userid=scott/tiger@testdb tables=emp file=emp.dmp

Export: Release 9.2.0.6.0 - Production on Thu Jul 15 16:30:17 2010

EXP-00008: ORACLE error 604 encountered

ORA-00604: error occurred at recursive SQL level 1

ORA-01410: invalid ROWID

EXP-00000: Export terminated unsuccessfully

这当然是因为我只改了ind$的缘故。

今天，我后续修改了tab$，obj$和seg$后我们再来看一下效果：

SQL_testdb>select count(*) from dba_tables;

COUNT(*)

----------

818

SQL_testdb>create table t1(id number,name varchar2(10));

create table t1(id number,name varchar2(10))

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-00607: Internal error occurred while making a change to a data block

ORA-00600: internal error code, arguments: [kcoapl_blkchk], [1], [122], [6110],[], [], [], []

SQL_testdb>select count(*) from dba_tables;

select count(*) from dba_tables

ERROR at line 1:

ORA-01578: ORACLE data block corrupted (file # 1, block # 122)

ORA-01110: data file 1: '/dras20/testdb/system01.dbf'

SQL_testdb>shutdown immediate;

ORA-00604: error occurred at recursive SQL level 2

ORA-01578: ORACLE data block corrupted (file # 1, block # 122)

ORA-01110: data file 1: '/dras20/testdb/system01.dbf'

出现了坏块，此时，就要用到我先前交待的"如何安全的修改system表空间下的block"这个知识点了，未用到这个知识点前是这样：

[P550_04_LA:oracle@:/dras20/testdb]#dbv file=/dras20/testdb/system01.dbf blocksize=8192

DBVERIFY: Release 9.2.0.6.0 - Production on Fri Jul 16 12:18:55 2010

DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf

Block Checking: DBA = 4194336, Block Type = KTB-managed data block

data header at 0x11015805c kdbchk: xaction header lock count mismatch

trans=2 ilk=3 nlo=0

Page 32 failed with check code 6108

Block Checking: DBA = 4194426, Block Type = KTB-managed data block

data header at 0x11020c044 kdbchk: the amount of space used is not equal to block size

used=7260 fsc=0 avsp=858 dtl=8120

Page 122 failed with check code 6110

DBVERIFY - Verification complete

Total Pages Examined : 55040

Total Pages Processed (Data) : 38951

Total Pages Failing (Data) : 2

Total Pages Processed (Index): 4085

Total Pages Failing (Index): 0

Total Pages Processed (Other): 1757

Total Pages Processed (Seg) : 0

Total Pages Failing (Seg) : 0

Total Pages Empty : 10247

Total Pages Marked Corrupt : 0

Total Pages Influx : 0

Highest block SCN : 898818 (0.898818)

在用到上述知识点修改上述block后，上述错误已经被我们修正：

P550_04_LA:oracle@:/cadrasu01/app/oracle/product/9.2.0/bin]#dbv file=/dras20/testdb/system01.dbf blocksize=8192

DBVERIFY: Release 9.2.0.6.0 - Production on Fri Jul 16 13:03:33 2010

DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf

DBVERIFY - Verification complete

Total Pages Examined : 55040

Total Pages Processed (Data) : 38951

Total Pages Failing (Data) : 0

Total Pages Processed (Index): 4085

Total Pages Failing (Index): 0

Total Pages Processed (Other): 1757

Total Pages Processed (Seg) : 0

Total Pages Failing (Seg) : 0

Total Pages Empty : 10247

Total Pages Marked Corrupt : 0

Total Pages Influx : 0

Highest block SCN : 898818 (0.898818)

好了，现在世界终于清净了：

[P550_04_LA:oracle@:/dras20/testdb]#exp scott/tiger@testdb file=emp.dmp tables=emp

Export: Release 9.2.0.6.0 - Production on Fri Jul 16 13:05:03 2010

Connected to: Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.6.0 - Production

Export done in US7ASCII character set and AL16UTF16 NCHAR character set

server uses ZHS16GBK character set (possible charset conversion)

About to export specified tables via Conventional Path ...

. . exporting table EMP 14 rows exported

EXP-00091: Exporting questionable statistics.

Export terminated successfully with warnings.

SQL_testdb>create table t1(id number,name varchar2(10));

Table created.

SQL_testdb>insert into t1 values(1,'cuihua1');

1 row created.

SQL_testdb>insert into t1 values(2,'cuihua2');

1 row created.

SQL_testdb>commit;

Commit complete.

SQL_testdb>select * from t1;

ID NAME

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

1 cuihua1

2 cuihua2

SQL_testdb>select owner,index_name,tablespace_name,status from dba_indexes where table_name='DEPENDENCY$';

OWNER INDEX_NAME TABLESPACE_NAME STATUS

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

SYS I_DEPENDENCY1 SYSTEM VALID

SYS I_DEPENDENCY2 SYSTEM VALID

SQL_testdb>select object_id,data_object_id from dba_objects where object_name='DEPENDENCY$';

OBJECT_ID DATA_OBJECT_ID

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

96 96

看到了吗，DEPENDENCY$虽然move了，但是我已经将其data object id恢复成原来的样子了。

上述恢复的过程真的太艰难了！我希望有一天我能有机会在恩墨的备份恢复培训中完整的和大家分享一下这个案例。

9i下Move系统表DEPENDENCY$导致索引失效的恢复

2010-07-15T09:59:59Z

eygle曾经在"案例:Move系统表DEPENDENCY$导致索引失效的数据库故障"里描述了他的一位朋友在将DEPENDENCY$ move后，忘记了rebuild上面的索引就shutdown后发现库再也起不来了。

有没有办法可以把上述库起起来呢？答案是有的，注意，我这里的方法过于internal，我希望朋友们永远不要在生产环境中用到。我曾经对很多朋友都说过----外科医生做手术的时候用的是手术刀，我们的手术刀就是BBED。

[P550_04_LA:oracle@:/dras20/testdb]#sqlplus '/ as sysdba';

SQL*Plus: Release 9.2.0.6.0 - Production on Thu Jul 15 12:41:08 2010

Connected to an idle instance.

SQL_testdb>startup pfile=/dras20/testdb/inittestdb.ora

ORACLE instance started.

Total System Global Area 504858456 bytes

Fixed Size 743256 bytes

Variable Size 285212672 bytes

Database Buffers 218103808 bytes

Redo Buffers 798720 bytes

Database mounted.

Database opened.

SQL_testdb>alter table DEPENDENCY$ move tablespace system;

Table altered.

SQL_testdb>select owner,index_name,tablespace_name,status from dba_indexes where table_name='DEPENDENCY$';

OWNER INDEX_NAME TABLESPACE_NAME STATUS

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

SYS I_DEPENDENCY1 SYSTEM UNUSABLE

SYS I_DEPENDENCY2 SYSTEM UNUSABLE

SQL_testdb>shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL_testdb>startup pfile=/dras20/testdb/inittestdb.ora

ORACLE instance started.

Total System Global Area 504858456 bytes

Fixed Size 743256 bytes

Variable Size 285212672 bytes

Database Buffers 218103808 bytes

Redo Buffers 798720 bytes

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

[P550_04_LA:oracle@:/cadrasu01/app/oracle/admin/testdb/bdump]#tail -n 200 alert_testdb.log

log_archive_start = TRUE

......省略显示部分内容

SMON: enabling cache recovery

Thu Jul 15 12:46:50 2010

Errors in file /cadrasu01/app/oracle/admin/testdb/udump/testdb_ora_5038294.trc:

ORA-00704: bootstrap process failure

ORA-00604: error occurred at recursive SQL level 1

ORA-01502: index 'SYS.I_DEPENDENCY1' or partition of such index is in unusable state

Thu Jul 15 12:46:50 2010

Error 704 happened during db open, shutting down database

USER: terminating instance due to error 704

Instance terminated by USER, pid = 5038294

ORA-1092 signalled during: ALTER DATABASE OPEN...

好了，现在我们来尝试修改，修改的过程中综合应用到了下述知识点：

1、 index unusable的实质；

2、 update internal；

3、 index cluster internal；

4、通过bootstrap$找到C_OBJ#进而找到ind$的存储位置；

其中核心的修改过程有两个，其中的一个为：

BBED> find /x 03c2021d03c2021d0180

File: /dras20/testdb/system01.dbf (1)

Block: 32 Offsets: 536 to 1047 Dba:0x00400020

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

03c2021d 03c2021d 018002c1 0203c20a 56018002 c10302c1 0b02c103 03c20338

ff02c102 02c10201 80ffffff ffffffff ffff02c1 03ffffff 02c103ff ffffff07

......省略显示部分内容

ff02c111 018003c2 093502c1 02018001 8002c114 6c001409 02c11002 c11003c2

<32 bytes per line>

BBED> set offset 532

OFFSET 532

BBED> x /rnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

rowdata[0] @532

----------

flag@532: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)

lock@533: 0x02

cols@534: 33

ckix@535: 7

col 0[3] @536: 128

col 1[3] @540: 128

......省略显示部分内容

col 12[2] @572: 1

col 13[1] @575: 0

......省略显示部分内容

col 32[7] @599: -0

BBED> f

File: /dras20/testdb/system01.dbf (1)

Block: 32 Offsets: 536 to 1047 Dba:0x00400020

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

03c2021d 03c2021d 018002c1 0203c20a 56018002 c10302c1 0b02c103 03c20338

ff02c102 02c10201 80ffffff ffffffff ffff02c1 03ffffff 02c103ff ffffff07

......省略显示部分内容

ff02c111 018003c2 093502c1 02018001 8002c114 6c001409 02c11002 c11003c2

<32 bytes per line>

BBED> f

File: /dras20/testdb/system01.dbf (1)

Block: 32 Offsets: 2122 to 2633 Dba:0x00400020

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

03c2021d 03c2021d 018002c1 0203c20a 56018002 c10302c1 0b02c103 03c20338

ff02c102 01800180 ffffffff ffffffff ff02c103 ffffff02 c103ffff ffff0778

......省略显示部分内容

0311236c 00090403 c2020c02 c10302c1 03018001 80018002 c1030180 01806c00

<32 bytes per line>

BBED> f

BBED-00212: search string not found

BBED> set offset 2118

OFFSET 2118

BBED> x /rnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

rowdata[1586] @2118

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

flag@2118: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)

lock@2119: 0x00

cols@2120: 33

ckix@2121: 7

col 0[3] @2122: 128

col 1[3] @2126: 128

......省略显示部分内容

col 10[0] @2154: *NULL*

col 11[2] @2155: 1

col 12[1] @2158: 0

col 13[1] @2160: 0

......省略显示部分内容

col 32[7] @2184: -0

SQL> select 532-92 from dual;

532-92

----------

440

SQL> select 2118-92 from dual;

2118-92

----------

2026

SQL> select to_char(440,'XXXXXXXX') from dual;

TO_CHAR(440,'XXXXXXXX')

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

1B8

SQL> select to_char(2026,'XXXXXXXX') from dual;

TO_CHAR(2026,'XXXXXXXX')

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

7EA

BBED> p kdbr

sb2 kdbr[0] @130 8074

......省略显示部分内容

sb2 kdbr[25] @180 515

sb2 kdbr[26] @182 440

sb2 kdbr[27] @184 1898

......省略显示部分内容

sb2 kdbr[121] @372 3061

BBED> set offset 182

OFFSET 182

BBED> dump

File: /dras20/testdb/system01.dbf (1)

Block: 32 Offsets: 182 to 693 Dba:0x00400020

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

01b8076a 0704069e 06390bda 0bbf0ba4 0b890b6e 0b080aed 0ad20a6d 0a5209ec

09d1096b 095008eb 08d008b5 084f0834 07cf07b4 074f06e9 06831ee6 06001e74

......省略显示部分内容

02c104ff ffff02c1 04ffffff ff077866 050d0311 236c0224 0704c304 05080180

<32 bytes per line>

BBED> modify /x 07ea

Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y

File: /dras20/testdb/system01.dbf (1)

Block: 32 Offsets: 182 to 693 Dba:0x00400020

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

07ea076a 0704069e 06390bda 0bbf0ba4 0b890b6e 0b080aed 0ad20a6d 0a5209ec

09d1096b 095008eb 08d008b5 084f0834 07cf07b4 074f06e9 06831ee6 06001e74

......省略显示部分内容

02c104ff ffff02c1 04ffffff ff077866 050d0311 236c0224 0704c304 05080180

<32 bytes per line>

BBED> sum apply

Check value for File 1, Block 32:

current = 0x2ad9, required = 0x2ad9

朋友们能看懂我在做什么吗？

改完后我们现在来看一下效果：

[P550_04_LA:oracle@:/dras20/testdb]#sqlplus '/ as sysdba';

SQL*Plus: Release 9.2.0.6.0 - Production on Thu Jul 15 16:18:06 2010

Connected to an idle instance.

SQL_testdb>startup pfile=/dras20/testdb/inittestdb.ora

ORACLE instance started.

Total System Global Area 504858456 bytes

Fixed Size 743256 bytes

Variable Size 285212672 bytes

Database Buffers 218103808 bytes

Redo Buffers 798720 bytes

Database mounted.

Database opened.

SQL_testdb>select count(*) from scott.emp;

COUNT(*)

----------

其实我这里虽然把库起起来了，但基本上还是不能用的，朋友们能看出为啥吗？

越来越有趣了，今天来不及研究了，明天吧，明天尝试把后续问题处理一下。

ASM里的条带化和extent大小

2010-07-13T04:07:00Z

有很多朋友不清楚什么是ASM里的条带化以及什么是ASM里的extent，我这里把我的理解写下来，供朋友们参考。

要理解上述概念，有一些背景知识需要我们了解：

1、 ASM实例不会去修改database的数据块，ASM实例只会去修改其metadata block（即ASM disk header跟ASM extent map）；

2、 Database instance会在share pool里维护ASM实例传过来的extent map blocks，每一个extent map block需要8个byte；

在ASM的世界里，AU（Allocation Units）和extent都是空间分配的单位，只不过它们代表了两个不同的角度，AU是站在ASM disk的角度，而extent则是站在file的角度。

在10g里，如果你没有改参数_asm_ausize、_asm_stripesize且你没有用如下的命令将ASM file templates改为fine，则AU和extent的大小就都是固定的1M，并且它们是一一对应的关系：

SQL> ALTER DISKGROUP diskgroup_name ALTER TEMPLATE ATTRIBUTES (FINE);

_asm_ausize的默认值是1M，_asm_stripesize默认值是128K：

SQL> select name,value from sys.all_parameters where name like '_asm%';

NAME VALUE

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

_asm_disk_repair_time 14400

_asm_ausize 1048576

_asm_blksize 4096

_asm_acd_chunks 1

_asm_libraries ufs

_asm_maxio 1048576

_asm_allow_only_raw_disks TRUE

_asmlib_test 0

_asm_allow_resilver_corruption FALSE

_asmsid asm

_asm_wait_time 18

_asm_stripewidth 8

_asm_stripesize 131072

_asm_droptimeout 60

_asm_emulmax 10000

_asm_emultimeout 0

_asm_kfdpevent 0

17 rows selected

在这种默认设置下，oracle在ASM disk上分配了一个AU，也就随之分配了一个extent。

所谓的ASM的条带化实际上决定了在ASM disk上分配的AU和extent的对应关系，比如，如果你用上述sql把ASM file templates改为了fine，则oracle在分配一个1M的extent的时候，实际上是会分配8个1M的AU，然后上述extent会被打散存储在这8个AU里，每个AU里都分配128K。

由前面所讲述的背景知识我们知道，oracle在database instance的share pool里存储一个extent map block需要8个byte，如果我现在库的大小是1T，则我们可以计算出现在share pool如果要容纳下所有的extent map block，则需要8G的内存空间（10g里，默认情况下1个extent大小是1M，所以1T的库会有100万个extent map block，一个extent map block需要8个byte，所以总共需要8G）：

SQL> select 8*1024*1024/1024 Memory_M from dual;

MEMORY_M

----------

8192

Oracle意识到如果用ASM管理一个1T的库就需要8G的share pool的话，那随着所管理的库的容量越来越大，效率问题不荣忽视。

于是在11g里，oracle改变了extent的大小，extent的大小将不再永远是1M，而是会随着分配extent数量的递增而改变，具体的规则如下：

Extent size grow automatically according to file size and extent size increments are: 1, 8, 64

1*AU extents up to 20,000 extents
8*AU extents up to 40,000 extents
64*AU extents >40,000

好了，现在我们来计算一下在11g里相应的extent分配的情况。

1、11g，AU=1M，库的大小为1T，则按照上述算法，oracle现在仅需分配53572个extent，占用419M的share pool：

SQL> select 20000+20000+(1024*1024-20000-20000*8)/64 from dual;

20000+20000+(1024*1024-20000-2

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

53571.5

SQL> select 8*53572/1024 from dual;

8*53572/1024

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

418.53125

2、11g，AU=64M（11g里在创建disk group的时候可以手工指定AU的大小），库的大小为1T，则按照上述算法，oracle现在仅需分配16384个extent，占用128M的share pool：

SQL> select (1024*1024/64) from dual;

(1024*1024/64)

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

16384

SQL> select 8*16384/1024 from dual;

8*16384/1024

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

128

3、11g，AU=64M（11g里在创建disk group的时候可以手工指定AU的大小），库的大小为100T，则按照上述算法，oracle现在仅需分配62788个extent，占用491M的share pool：

SQL> select 20000 + 20000 + (100*1024*1024-20000*64-20000*64*8)/(64*64) from dual;

20000+20000+(100*1024*1024-200

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

62787.5

SQL> select 8*62788/1024 from dual;

8*62788/1024

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

490.53125

以上观点仅仅是我个人的理解，可能会有疏漏及错误的地方，欢迎朋友们指正。

Insert操作会导致ITL等待吗

2010-07-08T09:40:59Z

有朋友在MSN上问我："Insert操作会导致ITL等待吗？"

答案是：不会的，oracle这里非常聪明的规避了此类问题。

我们来看一个例子，这里以9i为例，9i以上版本maxtrans已被废弃，这里开3个session：

Session 1：

SQL> create table t(id number,name varchar2(10)) maxtrans 2;

Table created

SQL> select table_name,max_trans from dba_tables where table_name='T';

TABLE_NAME MAX_TRANS

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

T 2

SQL> insert into t values(1,'cuihua1');

1 row inserted

SQL> select * from t;

ID NAME

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

1 cuihua1

Session 2：

SQL> insert into t values(2,'cuihua2');

1 row inserted

SQL> select * from t;

ID NAME

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

2 cuihua2

SQL> alter system checkpoint;

System altered

SQL> select id,name,dbms_rowid.rowid_relative_fno(rowid)||'_'||dbms_rowid.rowid_block_number(rowid) location from t;

ID NAME LOCATION

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

2 cuihua2 116_44490

此时，去看一下116,44490这个块：

BBED> set file 116 block 44490

FILE# 116

BLOCK# 44490

BBED> p ktbbh

struct ktbbh, 72 bytes @20

ub1 ktbbhtyp @20 0x01 (KDDBTDATA)

union ktbbhsid, 4 bytes @24

ub4 ktbbhsg1 @24 0x00015158

ub4 ktbbhod1 @24 0x00015158

struct ktbbhcsc, 8 bytes @28

ub4 kscnbas @28 0x384d71e5

ub2 kscnwrp @32 0x076d

b2 ktbbhict @36 7426

ub1 ktbbhflg @38 0x02 (NONE)

ub1 ktbbhfsl @39 0x00

ub4 ktbbhfnx @40 0x00000000

struct ktbbhitl[0], 24 bytes @44

struct ktbitxid, 8 bytes @44

ub2 kxidusn @44 0x0006

ub2 kxidslt @46 0x0029

ub4 kxidsqn @48 0x00016f8b

struct ktbituba, 8 bytes @52

ub4 kubadba @52 0x13000054

ub2 kubaseq @56 0x4063

ub1 kubarec @58 0x37

ub2 ktbitflg @60 0x0001 (NONE)

union _ktbitun, 2 bytes @62

b2 _ktbitfsc @62 0

ub2 _ktbitwrp @62 0x0000

ub4 ktbitbas @64 0x00000000

struct ktbbhitl[1], 24 bytes @68

struct ktbitxid, 8 bytes @68

ub2 kxidusn @68 0x0005

ub2 kxidslt @70 0x002d

ub4 kxidsqn @72 0x0001bd61

struct ktbituba, 8 bytes @76

ub4 kubadba @76 0x12c00032

ub2 kubaseq @80 0x486f

ub1 kubarec @82 0x01

ub2 ktbitflg @84 0x0001 (NONE)

union _ktbitun, 2 bytes @86

b2 _ktbitfsc @86 0

ub2 _ktbitwrp @86 0x0000

ub4 ktbitbas @88 0x00000000

BBED> p kdbr

sb2 kdbr[0] @110 8082

sb2 kdbr[1] @112 8054

BBED> p *kdbr[0]

rowdata[28]

-----------

ub1 rowdata[28] @8174 0x2c

BBED> dump

File: /cadras01/oradata/astca/drastbs_19.dbf (116)

Block: 44490 Offsets: 8174 to 8191 Dba:0x1d00adca

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

2c010202 c1020763 75696875 613171e5 0601

<32 bytes per line>

BBED> x /rnc

rowdata[28] @8174

-----------

flag@8174: 0x2c (KDRHFL, KDRHFF, KDRHFH)

lock@8175: 0x01

cols@8176: 2

col 0[2] @8177: 1

col 1[7] @8180: cuihua1

BBED> p *kdbr[1]

rowdata[0]

----------

ub1 rowdata[0] @8146 0x2c

BBED> dump

File: /cadras01/oradata/astca/drastbs_19.dbf (116)

Block: 44490 Offsets: 8146 to 8191 Dba:0x1d00adca

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

2c020202 c1030763 75696875 61323c02 0202c102 07637569 68756131 2c010202

c1020763 75696875 613171e5 0601

<32 bytes per line>

BBED> x /rnc

rowdata[0] @8146

----------

flag@8146: 0x2c (KDRHFL, KDRHFF, KDRHFH)

lock@8147: 0x02

cols@8148: 2

col 0[2] @8149: 2

col 1[7] @8152: cuihua2

一切都如我们预料的那么完美，从结果里我们可以非常清晰的看到现在上述block里两个ITL已经被全部占满了。

好了，现在问题来了，如果我再开一个session，并且再次执行insert操作，这个insert操作会不会由于ITL wait而hang住？

我们来看一下结果：

Session 3：

SQL> insert into t values(3,'cuihua3');

1 row inserted

SQL> select * from t;

ID NAME

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

3 cuihua3

从结果里我们看出，此时上述insert操作并没有因为ITL wait而hang住，为什么会这样？

因为oracle这里非常聪明的选择了下一个block，从而避免了上述ITL wait：

SQL> select id,name,dbms_rowid.rowid_relative_fno(rowid)||'_'||dbms_rowid.rowid_block_number(rowid) location from t;

ID NAME LOCATION

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

3 cuihua3 116_44491

看到了吗？前两个session对应的是116_44490，这里已经变成了116_44491。