Oracle 10g 索引结构信息查看问题

Question

环境：虚拟机V7.0.1 + [红帽Linux.5.5] + Oracle 10g建表：create table index_test (id char(2000));创建索引：create index idx_test on index_test(id);插入数据：insert into index_test values (rpad(to_char(1*2),2000,'a'));
insert into index_test values (rpad(to_char(2*2),2000,'a'));
commit;alter system checkpoint;查询object_id:SQL> select data_object_id,object_id from user_objects where object_name='INDEX_TEST';
 
DATA_OBJECT_ID  OBJECT_ID
-------------- ----------
         52937      52937
dump索引结构信息：alter session set events 'immediate trace name treedump level 52937;
查看dump信息：[oracle@xiaohu-linux udump]$ ls -l
total 16
-rw-r----- 1 oracle dba  625 Dec  6 12:20 first_ora_16359.trc
-rw-r----- 1 oracle dba  682 Dec  6 12:20 first_ora_16385.trc
-rw-r----- 1 oracle dba 1836 Dec  6 12:20 first_ora_16387.trc
-rw-r----- 1 oracle dba  756 Dec  6 12:21 first_ora_16395.trc
[oracle@xiaohu-linux udump]$ cat first_ora_16395.trc 
/opt/data/oracle/admin/first/udump/first_ora_16395.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /opt/data/oracle/product/10.2.0/db_1
System name:    Linux
Node name:      xiaohu-linux
Release:        2.6.18-194.el5xen
Version:        #1 SMP Tue Mar 16 22:08:06 EDT 2010
Machine:        i686
Instance name: first
Redo thread mounted by this instance: 1
Oracle process number: 14
Unix process pid: 16395, image: oracle@xiaohu-linux (TNS V1-V3)
 
*** ACTION NAME:() 2012-12-06 12:21:30.522
*** MODULE NAME:(SQL*Plus) 2012-12-06 12:21:30.522
*** SERVICE NAME:(SYS$USERS) 2012-12-06 12:21:30.522
*** SESSION ID:(160.5) 2012-12-06 12:21:30.522
kdxdtr: specified index object 52937 does not exist
[oracle@xiaohu-linux udump]$ cat first_ora_16395.trc 提示信息：
specified index object 52937 does not exist在网上找到一篇文章如下处理： 
(文章来源：http://space.itpub.net/10248702/viewspace-668006  作者：gdutllf2006)DATA_OBJECT_ID  OBJECT_ID SUBOBJECT_NAME
-------------- ---------- ------------------------------
         33631      33631alter session set events 'immediate trace name treedump level 33632';不知为何查出来的object_id是33631，而dump时却用33632？？？按照此种方法试了一下：[oracle@xiaohu-linux udump]$ cat first_ora_16395.trc 
/opt/data/oracle/admin/first/udump/first_ora_16395.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /opt/data/oracle/product/10.2.0/db_1
System name:    Linux
Node name:      xiaohu-linux
Release:        2.6.18-194.el5xen
Version:        #1 SMP Tue Mar 16 22:08:06 EDT 2010
Machine:        i686
Instance name: first
Redo thread mounted by this instance: 1
Oracle process number: 14
Unix process pid: 16395, image: oracle@xiaohu-linux (TNS V1-V3)
 
*** ACTION NAME:() 2012-12-06 12:21:30.522
*** MODULE NAME:(SQL*Plus) 2012-12-06 12:21:30.522
*** SERVICE NAME:(SYS$USERS) 2012-12-06 12:21:30.522
*** SESSION ID:(160.5) 2012-12-06 12:21:30.522
kdxdtr: specified index object 52937 does not exist
*** 2012-12-06 12:25:21.267
----- begin tree dump
leaf: 0x10001e4 16777700 (0: nrow: 2 rrow: 2)
----- end tree dump
[oracle@xiaohu-linux udump]$ 虽然也有那个提示信息，但索引结构信息出来了：
kdxdtr: specified index object 52937 does not exist
*** 2012-12-06 12:25:21.267
----- begin tree dump
leaf: 0x10001e4 16777700 (0: nrow: 2 rrow: 2)
----- end tree dump不明白是何原因，Oracle 11g，dump时直接用的object_id即可，有一同事用Oracle 10g，也直接用object_id dump索引结构信息，请大牛们指点一二！！！

Answer 1

10g R2
SQL> select object_id from dba_objects where object_name='TT_INDEX'; OBJECT_ID
----------
     53042SQL> alter session set events 'immediate trace name treedump level 53042';会话已更改。SQL> show parameter user_dump_destNAME                                 TYPE
------------------------------------ ----------------------
VALUE
------------------------------
user_dump_dest                       string
G:\ORACLE\PRODUCT\10.2.0\ADMIN
\ORCL\UDUMP
SQL> select distinct sid from v$mystat;       SID
----------
       147SQL> select paddr from v$session where sid=147;PADDR
--------
CA280DDCSQL> select spid from v$process where addr='CA280DDC';SPID
------------------------
5360*** 2012-08-07 01:21:34.944
*** ACTION NAME:() 2012-08-07 01:21:34.902
*** MODULE NAME:(SQL*Plus) 2012-08-07 01:21:34.902
*** SERVICE NAME:(SYS$USERS) 2012-08-07 01:21:34.902
*** SESSION ID:(147.92) 2012-08-07 01:21:34.902
----- begin tree dump
branch: 0x10001bc 16777660 (0: nrow: 7, level: 2)
   branch: 0x100595f 16800095 (-1: nrow: 578, level: 1)
      leaf: 0x10001bd 16777661 (-1: nrow: 513 rrow: 513)
      leaf: 0x10001be 16777662 (0: nrow: 513 rrow: 513)
      leaf: 0x10001bf 16777663 (1: nrow: 513 rrow: 513)
      leaf: 0x10001c0 16777664 (2: nrow: 513 rrow: 513)
      leaf: 0x10001c1 16777665 (3: nrow: 513 rrow: 513)
      leaf: 0x10001c2 16777666 (4: nrow: 513 rrow: 513)
      leaf: 0x10001c3 16777667 (5: nrow: 484 rrow: 484)
      leaf: 0x10001c4 16777668 (6: nrow: 478 rrow: 478)
      leaf: 0x10001c5 16777669 (7: nrow: 478 rrow: 478)
      leaf: 0x10001c6 16777670 (8: nrow: 478 rrow: 478)
      leaf: 0x10001c7 16777671 (9: nrow: 478 rrow: 478)
      leaf: 0x10001c8 16777672 (10: nrow: 478 rrow: 478)
      leaf: 0x10001ca 16777674 (11: nrow: 481 rrow: 481)
      leaf: 0x10001cb 16777675 (12: nrow: 478 rrow: 478)
      leaf: 0x10001cc 16777676 (13: nrow: 478 rrow: 478)
      leaf: 0x10001cd 16777677 (14: nrow: 478 rrow: 478)
      leaf: 0x10001ce 16777678 (15: nrow: 478 rrow: 478)
      leaf: 0x10001cf 16777679 (16: nrow: 478 rrow: 478)直接从memory中dump，这之前先 alter system flush buffer_cache试试

Answer 2

对文件进行了跟踪，如果直接用object_id：（值：53135）SQL> alter session set events 'immediate trace name treedump level 53135';dump出来的结构信息依旧提示“index object 53135 does not exist”用object_id+1进行dump：SQL> alter session set events 'immediate trace name treedump level 53136';*** 2012-12-12 15:40:14.772
*** ACTION NAME:() 2012-12-12 15:40:14.766
*** MODULE NAME:(SQL*Plus) 2012-12-12 15:40:14.766
*** SERVICE NAME:(SYS$USERS) 2012-12-12 15:40:14.766
*** SESSION ID:(160.15) 2012-12-12 15:40:14.766
kdxdtr: specified index object 53135 does not exist
*** 2012-12-12 15:42:13.156
----- begin tree dump
leaf: 0x10019e4 16783844 (0: nrow: 2 rrow: 2)
----- end tree dump之前先 alter system flush buffer_cache试试，结果还是和以前一样