April 2010 Archives

ACOUG已经完全具备恢复ASM故障的能力

By cui hua on April 28, 2010 6:30 PM | 7 Comments

ACOUG已经完全具备恢复ASM故障的能力，这主要表现在如下两个方面：

1、我们非常清楚ASM disk header的每一个byte的含义，我们具备重构ASM disk header的能力，即使你没有备份，即使你的每一块ASM disk的disk header都已经损坏。

2、在某些特定的条件下，当ASM disk header已经不可重构，我们具备直接从ASM disk上恢复数据的能力，在极端的情况下，这需要我们对ASM disk header做适当修改后才可以从ASM disk上恢复数据。

 

在重构ASM disk header的过程中，我们推荐使用dd＋ultraEdit或者打了补丁5039964后的kfed，而不是用未打上述补丁的kfed，因为未打上述补丁的kfed在某些特定的条件下，会往你的ASM disk header里写入一些垃圾byte，此时，你在nomount状态下查看目标disk的时候你会发现其状态为INCOMPATIBLE：

SQL> select path, header_status from v$asm_disk;

 

PATH                HEADER_STATUS

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

/dev/raw/raw1           FOREIGN

/dev/raw/raw2           FOREIGN

/dev/raw/raw5           INCOMPATIBLE

/dev/raw/raw4           MEMBER

/dev/raw/raw3            MEMBER

 

这时目标disk group当然也会mount不起来：

SQL> alter diskgroup DGRECOVERY mount;

alter diskgroup DGRECOVERY mount

*

ERROR at line 1:

ORA-15032: not all alterations performed

ORA-15063: ASM discovered an insufficient number of disks for diskgroup

"DGRECOVERY"

 

当你清掉上述垃圾byte后，你可能会发现目标disk的状态变为了PROVISIONED：

SQL> select path, header_status from v$asm_disk;

 

PATH                HEADER_STATUS

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

/dev/raw/raw1           FOREIGN

/dev/raw/raw2           FOREIGN

/dev/raw/raw5          PROVISIONED

/dev/raw/raw4           MEMBER

/dev/raw/raw3            MEMBER

 

此时ASM的alert log里会报错：

SQL> alter diskgroup DGRECOVERY mount

Wed Apr 28 17:21:25 2010

NOTE: cache registered group DGRECOVERY number=1 incarn=0xcb33f5f8

Wed Apr 28 17:21:25 2010

ERROR: no PST quorum in group 1: required 2, found 0

Wed Apr 28 17:21:25 2010

NOTE: cache dismounting group 1/0xCB33F5F8 (DGRECOVERY)

NOTE: dbwr not being msg'd to dismount

ERROR: diskgroup DGRECOVERY was not mounted

这个错误的本质原因是因为目标disk的check value不对了。

 

如果你的每一块ASM disk的disk header都已经彻底损坏，则我们重构disk header的思路就是先找到file directory，再通过file directory找到disk directory。我们可以用shell脚本来找file directory，当然，这里你也可以通过AMDU（AMDU可以在10g里用）来找disk directory。

 

如下是一个极端的例子：

我们把所有的ASM disk的disk header全部清零，然后用上述手段重构disk header后可以看到现在所有的disk group已经可以正常mount：

SQL> alter diskgroup DGRECOVERY mount;

 

Diskgroup altered.

 

SQL> alter diskgroup DGDATA mount;

 

Diskgroup altered.

 

珍惜你身边的人

By cui hua on April 23, 2010 10:28 AM | 2 Comments

同身边的人吵架是一种艺术，最终的目的是越吵越了解对方，越吵越好。 

后院失火是我们一定要尽全力避免的！那种焦头烂额的滋味不是什么人都可以承受的。

 

吵架的时候一定要把握好如下几点：

1、当你身边的人气极夺门而出的时候，你一定要去追！

2、吵架的时候一定一定不能说伤感情的话！感情不像数据库，库坏了我们还可以恢复，感情坏了，你拿什么去恢复？

 

其实吵架是在所难免的事情，吵架可以，但不要把事态升级、扩大。这就需要我们去了解对方，如果你的另外一半是那种宁折不弯的人，那么这时候任何的威胁、过激的话语都是没有用的，这种情况下一定不要用强！

 

请一定要珍惜身边的人！工作上的负面情绪尽量不要带到家里去，有时间的话就多陪陪家人、多陪陪孩子，他们比什么都重要！

如何跳过缺失的归档

By cui hua on April 21, 2010 9:36 AM | No Comments

如果你的系统有完善的备份，那么我下面写的内容你就可以直接跳过，完善的备份永远是针对此类问题的最有效措施！

 

这篇文章仅仅用于在没有有效备份，或者虽然有备份但归档日志有缺失的情况下尽全力挽救数据----这是通过我们骗过oracle，让其不应用缺失的归档，转而应用剩余的归档来实现的。

 

请注意，实际的恢复过程中，出现的问题可能比你相像的要复杂太多！如果有可能，我会在恩墨科技的一个关于备份与恢复的培训中与大家详细分享这个案例。

 

我们来看这个例子：

SQL_testdb>create tablespace testrecover datafile '/dras20/testdb/testrecover_01.dbf' size 10M extent management local uniform size 1M segment space management auto;

 

Tablespace created.

 

SQL_testdb>create table t1 tablespace testrecover as select * from dba_objects;

 

Table created.

 

SQL_testdb>create table t2 tablespace testrecover as select * from dba_users;

 

Table created.

 

SQL_testdb>create table t3 tablespace testrecover as select * from dba_users;

 

Table created.

 

SQL_testdb>archive log list;

Database log mode              Archive Mode

Automatic archival             Enabled

Archive destination            /dras20/testdb

Oldest online log sequence     18

Next log sequence to archive   20

Current log sequence           20

 

SQL_testdb>alter system switch logfile;

 

System altered.

 

SQL_testdb>select count(*) from t1;

 

  COUNT(*)

----------

     29391

 

SQL_testdb>select count(*) from t2;

 

  COUNT(*)

----------

        29

 

SQL_testdb>select count(*) from t3;

 

  COUNT(*)

----------

        29

 

SQL_testdb>delete from t2 where rownum<2;

 

1 row deleted.

 

SQL_testdb>delete from t3 where rownum<2;

 

1 row deleted.

 

SQL_testdb>commit;

 

Commit complete.

 

SQL_testdb>alter system switch logfile;

 

System altered.

 

SQL_testdb>delete from t1 where rownum<10001;

 

10000 rows deleted.

 

SQL_testdb>delete from t2 where rownum<2;

 

1 row deleted.

 

SQL_testdb>delete from t3 where rownum<2;

 

1 row deleted.

 

SQL_testdb>commit;

 

Commit complete.

 

SQL_testdb>select count(*) from t1;

 

  COUNT(*)

----------

     19391

 

SQL_testdb>select count(*) from t2;

 

  COUNT(*)

----------

        27

 

SQL_testdb>select count(*) from t3;

 

  COUNT(*)

----------

        27

 

SQL_testdb>alter system switch logfile;

 

System altered.

 

SQL_testdb>alter system switch logfile;

 

System altered.

 

SQL_testdb>alter system switch logfile;

 

System altered.

 

SQL_testdb>alter system switch logfile;

 

System altered.

 

这个时候我们如果把归档日志/dras20/testdb/1_21.dbf和数据文件/dras20/testdb/testrecover_01.dbf给rm掉，再恢复的时候，oracle一定会报错1_21.dbf找不到，这时候如果我们能骗过oracle，让其忽略掉1_21.dbf，且继续应用剩余的归档日志，则最后恢复出来的结果一定是表t1中有19391条记录，表t2中有28条记录，表t3中有28条记录：

ORA-00308: cannot open archived log '/dras20/testdb/1_21.dbf'

ORA-27037: unable to obtain file status

IBM AIX RISC System/6000 Error: 2: No such file or directory

Additional information: 3

 

运气好的话，我们只需要改一下RBA和checkpoint SCN就行了：

SQL_testdb>recover datafile 2;

ORA-00279: change 560013 generated at 04/21/2010 08:30:29 needed for thread 1

ORA-00289: suggestion : /dras20/testdb/1_22.dbf

ORA-00280: change 560013 for thread 1 is in sequence #22

 

 

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

/dras20/testdb/1_22.dbf

ORA-00279: change 560524 generated at 04/21/2010 08:36:22 needed for thread 1

ORA-00289: suggestion : /dras20/testdb/1_23.dbf

ORA-00280: change 560524 for thread 1 is in sequence #23

ORA-00278: log file '/dras20/testdb/1_22.dbf' no longer needed for this

recovery

 

 

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

 /dras20/testdb/1_23.dbf

Log applied.

Media recovery complete.

 

SQL_testdb>alter database open;

 

Database altered.

 

SQL_testdb>select count(*) from t1;

 

  COUNT(*)

----------

     19391

 

SQL_testdb>select count(*) from t2;

 

  COUNT(*)

----------

        28

 

SQL_testdb>select count(*) from t3;

 

  COUNT(*)

----------

        28

 

如果运气不好，你可能会碰到多种错误，比如：

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

/dras20/testdb/1_16.dbf

ORA-00283: recovery session canceled due to errors

ORA-00600: internal error code, arguments: [3020], [8388621], [1], [17], [431],

[16], [], []

ORA-10567: Redo is inconsistent with data block (file# 2, block# 13)

ORA-10564: tablespace TESTRECOVER1

ORA-01110: data file 2: '/dras20/testdb/testrecover1_01.dbf'

ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 30277

 

ORA-01112: media recovery not started

 

SQL_testdb>recover datafile 2 test;

ORA-10589: Test recovery had to corrupt 277 data blocks in order to proceed

ORA-10573: Test recovery tested redo from change 557485 to 558213

ORA-10570: Test recovery complete

 

这种情况下处理起来相对来说会麻烦一些。

其实没关系的，一个库只要不是坏的太离谱，我们总是可以强制打开的。

接下来的一段时间会很忙很忙

By cui hua on April 19, 2010 7:18 PM | 2 Comments

2010年，我自己的生活在悄然发生着变化，除了感觉自己身体变差了，另外一个很直接的感觉就是越来越忙了......

这主要表现在工作上的忙碌（我跟进的一个项目就要上线了，现在我被要求一周至少要加3天班）。另外就是和志同道合的朋友们的合作，使得我的业余生活也变得忙碌起来。

 

朋友们，请允许我在我自己的blog上为我和我老婆做一下广告：

 

1、如果条件允许，我将会在5月份和李轶楠（Ora-600）联手完成恩墨科技的一个关于备份与恢复的培训，kamus说----"至少到目前为止，这份课程，除了恩墨科技，在国内还没有任何一个培训机构可以做出来。"

 

我希望通过600与我的共同努力，使上述话语成为现实！

 

2、我老婆所在的公司常年招聘oracle dba，工作地点在上海，年薪在20万左右，有兴趣的朋友可以直接联系她：

MSN：frances3496@hotmail.com

Email：yue.zou@hp.com

 

如下是这个职位的JD：

RESPONSIBILITIES:

Provide services of production database support, including the following activities:

•Support of application teams with database requests - data migration, database security, schema maintenance, etc

•Monthly and weekly data loads with various database tools

•Database jobs and space monitoring

•Resolving database related application performance issues

•Involvement in application and database DR activities

•Data model design

•Implementation and System rollout support

•Solving ad-hoc application issues related to database

 

Qualifications:

•Computer Science or related degree

•Demonstrated problem solving, resolution and performance monitoring skills.

•Excellent interpersonal skills and team player. Flexible approach to working across multiple teams, and willingness to rotate between teams and activities. Must have a positive attitude with a 'can do' approach to both day to day support and challenging new tasks. Must have a strong Customer focus.

•Excellent English skills in writing & reading, strong English in oral communication, CET6

•Minimum 3 years working experience as a DBA in Oracle on UNIX platform.

•Excellent knowledge in SQL is required.

•Working experience on application DBA tasks.

mount状态下如何dump一个block

By cui hua on April 15, 2010 1:35 PM | 4 Comments

有朋友在MSN上问我----"mount状态下如何dump一个block？"

我说你自己先去google上搜一下吧，能搜到答案的就别过来问我了。

他回答说搜不到。

 

既然搜不到，那我就说一说吧。

 

其实在mount状态下dump block的方法不止一种，最常规的就是如下这样。

比如现在我要在mount状态下dump system回滚段的段头，这么做是不行的：

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

ORACLE instance started.

 

Total System Global Area  505382744 bytes

Fixed Size                   743256 bytes

Variable Size             285212672 bytes

Database Buffers          218103808 bytes

Redo Buffers                1323008 bytes

Database mounted.

 

SQL_testdb>oradebug setmypid

Statement processed.

 

SQL_testdb>alter system dump datafile 1 block 9;

 

System altered.

 

SQL_testdb>oradebug tracefile_name

/cadrasu01/app/oracle/admin/testdb/udump/testdb_ora_9576500.trc

 

[P550_04_LA:oracle@:/cadrasu01/app/oracle/admin/testdb/udump]#cat  /cadrasu01/app/oracle/admin/testdb/udump/testdb_ora_9576500.trc

/cadrasu01/app/oracle/admin/testdb/udump/testdb_ora_9576500.trc

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

ORACLE_HOME = /cadrasu01/app/oracle/product/9.2.0

System name:    AIX

Node name:      P550_04_LA

Release:        3

Version:        5

Machine:        0001D085D600

Instance name: testdb

Redo thread mounted by this instance: 1

Oracle process number: 12

Unix process pid: 9576500, image: oracle@P550_04_LA (TNS V1-V3)

 

*** 2010-04-15 10:14:00.317

*** SESSION ID:(9.3) 2010-04-15 10:14:00.307

alter system dump datafile/tempfile: file 1 not readable

 

怎么办？我们这么做就可以了：

SQL_testdb>oradebug setmypid

Statement processed.

 

SQL_testdb>alter system dump datafile '/dras20/testdb/system01.dbf' block 9;

 

System altered.

 

SQL_testdb>oradebug tracefile_name

/cadrasu01/app/oracle/admin/testdb/udump/testdb_ora_8454328.trc

 

[P550_04_LA:oracle@:/cadrasu01/app/oracle/admin/testdb/udump]#cat /cadrasu01/app/oracle/admin/testdb/udump/testdb_ora_8454328.trc

/cadrasu01/app/oracle/admin/testdb/udump/testdb_ora_8454328.trc

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

ORACLE_HOME = /cadrasu01/app/oracle/product/9.2.0

System name:    AIX

Node name:      P550_04_LA

Release:        3

Version:        5

Machine:        0001D085D600

Instance name: testdb

Redo thread mounted by this instance: 1

Oracle process number: 12

Unix process pid: 8454328, image: oracle@P550_04_LA (TNS V1-V3)

 

*** 2010-04-15 10:18:13.941

*** SESSION ID:(9.5) 2010-04-15 10:18:13.934

Start dump data block from file /dras20/testdb/system01.dbf minblk 9 maxblk 9

 FILE HEADER:

        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000

        Db ID=2489685178=0x946594ba, Db Name='TESTDB'

        Activation ID=0=0x0

        Control Seq=537=0x219, File size=51200=0xc800

        File Number=1, Blksiz=8192, File Type=3 DATA

Dump all the blocks in range:

buffer rdba: 0x00400009 (1/9)

scn: 0x0000.000853ee seq: 0x01 flg: 0x04 tail: 0x53ee0e01

frmt: 0x02 chkval: 0xebe6 type: 0x0e=KTU UNDO HEADER W/UNLIMITED EXTENTS

  Extent Control Header

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

  Extent Header:: spare1: 0      spare2: 0      #extents: 6      #blocks: 47   

                  last map  0x00000000  #maps: 0      offset: 4128 

      Highwater::  0x0040000f  ext#: 0      blk#: 5      ext size: 7    

  #blocks in seg. hdr's freelists: 0    

  #blocks below: 0    

  mapblk  0x00000000  offset: 0    

                   Unlocked

     Map Header:: next  0x00000000  #extents: 6    obj#: 0      flag: 0x40000000

  Extent Map

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

   0x0040000a  length: 7    

   0x00400011  length: 8    

   0x00400181  length: 8    

   0x00400189  length: 8    

   0x00400191  length: 8    

   0x00400199  length: 8    

 

  TRN CTL:: seq: 0x0036 chd: 0x0014 ctl: 0x005c inc: 0x00000000 nfb: 0x0000

            mgc: 0x8002 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)

            uba: 0x0040000f.0036.1c scn: 0x0000.0008028e

Version: 0x01

  FREE BLOCK POOL::

    uba: 0x00000000.0036.1b ext: 0x0  spc: 0x8ac  

    uba: 0x00000000.0032.13 ext: 0x2  spc: 0x18e4 

    uba: 0x00000000.002f.41 ext: 0x5  spc: 0x33c  

    uba: 0x00000000.0000.00 ext: 0x0  spc: 0x0    

    uba: 0x00000000.0000.00 ext: 0x0  spc: 0x0    

  TRN TBL::

 

  index  state cflags  wrap#    uel         scn            dba            parent-xid    nub     stmt_num

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

   0x00    9    0x00  0x002e  0x0028  0x0000.00080292  0x0040000c    0x0000.000.00000000  0x00000002   0x00000000

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

   0x61    9    0x00  0x002e  0x005d  0x0000.0008536a  0x0040000f  0x0000.000.00000000  0x00000001   0x00000000

End dump data block from file /dras20/testdb/system01.dbf minblk 9 maxblk 9

用ODU恢复数据的一点注意事项

By cui hua on April 11, 2010 3:53 PM | No Comments

用ODU恢复数据的时候，scan extent是非常必要的，因为这样即使在段头损坏（或者段头的extent map和auxiliary map不准）的情况下，也能够正确恢复出数据：

我们来看一个极端的例子：

SQL> select count(*) from t1;

 

  COUNT(*)

----------

     29515

 

当我把t1的段头中的extent map、auxiliary map、t1的extent数量、t1的block数量改了后oracle这里只能读出其中的一部分数据了：

SQL> select count(*) from t1;

 

  COUNT(*)

----------

     27051

 

可以看到这里oracle少读了29515－27051＝2464条记录。

 

此时，如果我们不用scan extent，则ODU也只能恢复出27051条记录：

ODU> unload dict

CLUSTER C_USER# file_no: 1 block_no: 89

TABLE OBJ$ file_no: 1 block_no: 121

CLUSTER C_OBJ# file_no: 1 block_no: 25

CLUSTER C_OBJ# file_no: 1 block_no: 25

found IND$'s obj# 19

found IND$'s dataobj#:2,ts#:0,file#:1,block#:25,tab#:3

found TABPART$'s obj# 230

found TABPART$'s dataobj#:230,ts#:0,file#:1,block#:1657,tab#:0

found INDPART$'s obj# 234

found INDPART$'s dataobj#:234,ts#:0,file#:1,block#:1689,tab#:0

found TABSUBPART$'s obj# 240

found TABSUBPART$'s dataobj#:240,ts#:0,file#:1,block#:1737,tab#:0

found INDSUBPART$'s obj# 245

found INDSUBPART$'s dataobj#:245,ts#:0,file#:1,block#:1777,tab#:0

found IND$'s obj# 19

found IND$'s dataobj#:2,ts#:0,file#:1,block#:25,tab#:3

found LOB$'s obj# 156

found LOB$'s dataobj#:2,ts#:0,file#:1,block#:25,tab#:6

found LOBFRAG$'s obj# 258

found LOBFRAG$'s dataobj#:258,ts#:0,file#:1,block#:1881,tab#:0

 

ODU> unload table sys.t1

 

Unloading table: T1,object ID: 30337

Unloading segment,storage(Obj#=30337 DataObj#=30337 TS#=9 File#=9 Block#=523 Clu

ster=0)

27051 rows unloaded

 

如果我们用了scan extent，则ODU能将所有的29515条记录正确的unload出来：

ODU> scan extent tablespace 9 datafile 9

 

scan extent start: 2010-04-11 14:13:05

scanning extent...

scanning extent finished.

scan extent completed: 2010-04-11 14:13:06

 

ODU> unload table sys.t1 object 30337

 

Unloading table: T1,object ID: 30337

Unloading segment,storage(Obj#=30337 DataObj#=30337 TS#=9 File#=9 Block#=523 Clu

ster=0)

29515 rows unloaded

 

记一次极其困难的数据库恢复

By cui hua on April 6, 2010 12:30 AM | 2 Comments

今天，ACOUG成员eygle和我联手经过好几天的不懈努力，终于在今晚11点左右的时候成功将一个库open，当我把这个库open的时候，eygle对我说：崔华你还是非常厉害----我觉得这就是对我最大的肯定。

 

这个库之所以极其困难的原因主要在于如下两个方面：

1、  从存储中恢复出来的好几个datafile header都已经彻底损坏，oracle不认；

2、  无论eygle和我如何努力，open的时候始终报错：

ORA-01555: snapshot too old: rollback segment number with name "" too small

 

这次恢复的总体感受是：

1、  eygle的基本功非常扎实！

2、  两个人合作的力量要远大于其中的某一个人。

 

非常感谢eygle给了我这样一次实战的机会，我很珍惜每一次这样的机会！

详细解析system回滚段损坏导致的ora-600[4193]错误

By cui hua on April 2, 2010 1:44 PM | 13 Comments

之前已经写过：

"详细解析9i和10g的datafile header"

"详细解析LMT的datafile的物理结构"

"详细解析datafile的status"

"详细解析oracle中的transaction"

"详细解析truncate引发的object checkpoint"

"详细解析ASSM的Segment Header的结构"

 

这里是详细解析系列的第七篇文章，在这篇文章里，我们详细解析了由于system回滚段的不一致而导致的ora-600[4193]的含义并给出了解决方法。

 

详情请参见 "详细解析system回滚段损坏导致的ora-600[4193]错误"

普通B树索引跟IOT的一点差异

By cui hua on April 1, 2010 12:59 PM | 2 Comments

当没有system表空间，且从存储上恢复出来的各个datafile的datafile header已经损坏的情况下，我们被迫要去这些datafile里随机抽一些block来看看，以区分这些datafile到底是干嘛用的，现在的问题是：

你如何判断一个出一个block是普通index block还是IOT？

 

答案是通过kdxle. kdxcoopc，普通index block的kdxle. kdxcoopc的值是80，IOT的kdxle. kdxcoopc的值是90，如下所示：

 

普通B树索引：

BBED> p kdxle

struct kdxle, 32 bytes                      @100    

   struct kdxlexco, 16 bytes                @100    

      ub1 kdxcolev                          @100      0x00

      ub1 kdxcolok                          @101      0x00

      ub1 kdxcoopc                          @102      0x80

      ub1 kdxconco                          @103      0x01

      ub4 kdxcosdc                          @104      0x00000000

      sb2 kdxconro                          @108      479

      b2 kdxcofbo                           @110      994

      b2 kdxcofeo                           @112      1810

      b2 kdxcoavs                           @114      816

   b2 kdxlespl                              @116      0

   sb2 kdxlende                             @118      0

   ub4 kdxlenxt                             @120      0x224002bb

   ub4 kdxleprv                             @124      0x224002b9

   ub1 kdxledsz                             @128      0x06

   ub1 kdxleunuse                           @129      0x00

 

IOT：

BBED> p kdxle

struct kdxle, 32 bytes                      @92     

   struct kdxlexco, 16 bytes                @92     

      ub1 kdxcolev                          @92       0x00

      ub1 kdxcolok                          @93       0x00

      ub1 kdxcoopc                          @94       0x90

      ub1 kdxconco                          @95       0x02

      ub4 kdxcosdc                          @96       0x00000000

      sb2 kdxconro                          @100      5

      b2 kdxcofbo                           @102      46

      b2 kdxcofeo                           @104      7957

      b2 kdxcoavs                           @106      7911

   b2 kdxlespl                              @108      0

   sb2 kdxlende                             @110      1

   ub4 kdxlenxt                             @112      0x00000000

   ub4 kdxleprv                             @116      0x00000000

   ub1 kdxledsz                             @120      0x00

   ub1 kdxleunuse                           @121      0x00

 

注意无论是普通B树索引还是IOT，它们的block type都是06，这和data block的block type是一样的：

BBED> p kcbh

struct kcbh, 20 bytes                       @0      

   ub1 type_kcbh                            @0        0x06

   ub1 frmt_kcbh                            @1        0x02

   ub1 spare1_kcbh                          @2        0x00

   ub1 spare2_kcbh                          @3        0x00

   ub4 rdba_kcbh                            @4        0x224002ba

   ub4 bas_kcbh                             @8        0xaa087503

   ub2 wrp_kcbh                             @12       0x0008

   ub1 seq_kcbh                             @14       0x02

   ub1 flg_kcbh                             @15       0x04 (KCBHFCKV)

   ub2 chkval_kcbh                          @16       0xaf37

   ub2 spare3_kcbh                          @18       0x0000

 

所以不能通过block type来区分是data block，还是index block或者IOT。
« March 2010 | Main Index | Archives | May 2010 »

Search

Recent Comments

  • never fail list building system: the written content on this submit is really a single read more
  • never fail list building system: Awesome article which has got me considering about the potential read more
  • how to stop panic attacks: I couldn't agree with you more, anyway l love your read more
  • never fail list building bonus: Remarkable article which has received me considering concerning the prospective read more
  • never fail list building system: Actually truly beneficial weblog article which has got me considering. read more
  • never fail list building review: Nice piece of info that you've got in this website read more
  • Buck The Deer: Hi there!I like your post.Where by did you got all read more
  • The Diet Solution Program: I quite agree with your submission, however, lam having problem read more
  • crtea1: 汗，不是有意的，多余的帖子请删。 read more
  • crtea1: 回帖貌似有问题，总是跳到错误页，也不知道到底有没有重复回帖。 根据我原先的理解： 当需要一个数据块时，ORACLE会根据BLOCK的HASH值去读对应的HASH CHAIN，查看需要的块是否存在。而不是去查找LRU LIST，因此会有cache buffers chain latch (cbc latch)。 read more

Recent Entries

Tag Cloud

About this Archive

This page is an archive of entries from April 2010 listed from newest to oldest.

March 2010 is the previous archive.

May 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.