唯一性索引（Unique Index）与普通索引（Normal Index）差异（中）

 

声明：本篇知识方法受到dbsnake相关文章启发，特此感谢！

 

在本系列的前篇（http://space.itpub.net/17203031/viewspace-700089）里，我们探讨了唯一索引和普通索引在应用角度上的差异。实验中，我们发现在基础数据相同的情况下，两类型索引在体积上有细微的差异，这使得我们可以猜测两种类型索引在存储结构上的可能差异。

 

本篇打算从存储结构入手，探讨两种类型索引的差异。

 

1、  环境准备

 

同前篇相同，准备相同的数据索引列取值，创建不同类型的索引。为了减少整理数据量，所以选择较小的数据集。

 

 

SQL> select * from v$version where rownum<2;

BANNER

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

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

 

SQL> create table t (id number, vid number);

Table created

 

SQL> select * from t;

        ID        VID

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

         1          1

         2          2

         3          3

 

//创建普通索引

SQL> create index idx_t_normalid on t(id);

Index created

 

//创建唯一性索引

SQL> create unique index idx_t_uniqueid on t(vid);

Index created

 

SQL> exec dbms_stats.gather_table_stats(user,'T',cascade => true);

PL/SQL procedure successfully completed

 

SQL> col object_name for a20;

SQL> select object_name, object_id from dba_objects where object_name in ('IDX_T_NORMALID','IDX_T_UNIQUEID');

 

OBJECT_NAME           OBJECT_ID

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

IDX_T_NORMALID            75141

IDX_T_UNIQUEID            75142

 

 

 

2、  普通索引逻辑结构分析

 

思路是从索引树入手，现将索引段结构Dump出去，检查整体分布情况。

 

//获取跟踪文件位置

SQL> select name, value from  v$diag_info where name='Default Trace File';

 

NAME                           VALUE

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

Default Trace File             /u01/diag/rdbms/wilson/wilson/trace/wilson_ora_5850.trc

 

//将索引树Dump出到Trace文件

SQL> alter session set events 'immediate trace name treedump level 75141';

Session altered

 

 

注意：v$diag_info视图是Oracle 11g中新推出的视图类型，其中包括了所有诊断文件的位置和目录。其中Default Trace File项目就是当前会话对应的Trace File路径和名称，不需要我们过去那样使用自定义函数查询。

 

此时，我们检索Trace File内容，核心片段如下：

 

 

*** 2011-06-15 01:47:04.350

*** SESSION ID:(20.13) 2011-06-15 01:47:04.350

*** CLIENT ID:() 2011-06-15 01:47:04.350

*** SERVICE NAME:(wilson) 2011-06-15 01:47:04.350

*** MODULE NAME:(PL/SQL Developer) 2011-06-15 01:47:04.350

*** ACTION NAME:(Command Window - New) 2011-06-15 01:47:04.350

 

----- begin tree dump

leaf: 0x415af1 4283121 (0: nrow: 3 rrow: 3)

----- end tree dump

 

上面的Tree Dump结果，说明因为索引很小（只有三行记录），只有一个索引块中包括数据。其中叶子节点为3个，该索引块的地址为（0x415af1，十进制表示为4283121）。

 

索引块4283121对应的实际文件和数据块信息是什么呢？使用dbms_utiliy包的相关方法，可以帮助获取到对应文件和块号。

 

 

SQL> select dbms_utility.data_block_address_file(4283121), dbms_utility. data_block_address_block(4283121) from dual;

 

DBMS_UTILITY.DATA_BLOCK_ADDRES DBMS_UTILITY.DATA_BLOCK_ADDRES

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

                             1                          88817

 

 

索引块在文件1，对应块号为88817。

 

使用逻辑dump出块的结构信息。

 

 

SQL> alter system dump datafile 1 block 88817;

System altered

 

 

DUMP在跟踪文件上的核心内容为：

 

 

--核心片段

Block dump from cache:

Dump of buffer cache at level 4 for tsn=0, rdba=4283121

BH (0x2dff3578) file#: 1 rdba: 0x00415af1 (1/88817) class: 1 ba: 0x2dea0000

 

Block header dump:  0x00415af1

 Object id on Block? Y

 seg/obj: 0x12585  csc: 0x00.396f48  itc: 2  flg: -  typ: 2 - INDEX

     fsl: 0  fnx: 0x0 ver: 0x01

 

row#0[8020] flag: ------, lock: 0, len=12

col 0; len 2; (2):  c1 02

col 1; len 6; (6):  00 41 5a e9 00 00

row#1[8008] flag: ------, lock: 0, len=12

col 0; len 2; (2):  c1 03

col 1; len 6; (6):  00 41 5a e9 00 01

row#2[7996] flag: ------, lock: 0, len=12

col 0; len 2; (2):  c1 04

col 1; len 6; (6):  00 41 5a e9 00 02

----- end of leaf block dump -----

End dump data blocks tsn: 0 file#: 1 minblk 88817 maxblk 88817

 

 

实际Dump出的信息很多，篇幅原因，笔者只是将最核心的部分加以展现。

 

首先关注最后的三个row#信息，该部分表示三个叶子节点的核心内容。其中[]中包括的是叶子节点在索引块中的相对偏移量。Len表示该叶子所占用空间长度是多少（注意：此处的Normal Index叶子节点占用12长度）。

 

最后，观察行与行之间的偏移量差（7996-8008-8020），正好是行间的距离12位。

 

每个叶子节点包括两个column内容，分别占据2位和6位。由于是使用16进制形式保存，我们不能直接看出内容含义。下面实验可以帮助我们进行猜测：

 

 

--关键数据演算：

 

SQL> select dump(1,1016) from dual;

DUMP(1,1016)

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

Typ=2 Len=2: c1,2

 

SQL> select dump(2,1016) from dual;

DUMP(2,1016)

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

Typ=2 Len=2: c1,3

 

SQL> select dump(3,1016) from dual;

DUMP(3,1016)

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

Typ=2 Len=2: c1,4

 

 

我们的索引列取值就是1、2、3、4，上面使用DUMP函数的结果，告诉我们跟踪文件中每个row的第一列表示的是索引列取值。索引叶子节点内容无非就是rowid和索引键值。那么row的第二列含义必然可能就是rowid相关内容。

 

只对第三行数据进行试算：

 

 

16进制取值：00 41 5a e9 00 02

 2进制取值：00000000 01000001 01011010 11101001 00000000 00000010

 

 

根据相关资料，我们进行如下设定：

 

 

File_ID：前10位：00000000 01=1

Block_id 中间22位：000001 01011010 11101001=88809

Slot_id：00000000 00000010=2

 

 

如果改值是rowid，那么一定和数据表T行的rowid存在对应关系。

 

 

SQL> select t.*,t.rowid, dbms_rowid.rowid_relative_fno(t.rowid) fno, dbms_rowid.rowid_block_number(t.rowid)

blockn,dbms_rowid.rowid_row_number(t.rowid) rown from t;

 

        ID        VID ROWID                     FNO     BLOCKN       ROWN

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

         1          1 AAASWCAABAAAVrpAAA          1      88809          0

         2          2 AAASWCAABAAAVrpAAB          1      88809          1

         3          3 AAASWCAABAAAVrpAAC          1      88809          2

 

 

Rowid中包括的信息：文件编号+对象编号+块编号+块内slot编号；索引叶子中的第二列数据，已经能够提供文件编号、块编号和内部slot编号。对象编号是进行选取Select时候就带入的。

 

 

3、普通索引物理结构分析

 

从上面的逻辑结构，我们看到了存储的逻辑结构。下面根据信息，我们到物理存储层面看普通索引结构。注意，此处我们只关注一行数据，就是row2[7996]的叶子节点。

 

我们现在有该索引的文件编号和块编号，缺乏就是实际的偏移量。下面首先计算出实际的偏移量。

 

 

SQL> select file_name, tablespace_name from dba_data_files where file_id=1;

 

FILE_NAME                                                                        TABLESPACE_NAME

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

/u01/oradata/WILSON/datafile/o1_mf_system_6bcsnqfc_.dbf                          SYSTEM

 

 

SQL> select tablespace_name,SEGMENT_SPACE_MANAGEMENT from dba_tablespaces where tablespace_name='SYSTEM';

 

TABLESPACE_NAME                SEGMENT_SPACE_MANAGEMENT

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

SYSTEM                         MANUAL

 

 

数据表索引对应的表空间SYSTEM，是使用MSSM进行Segment Space Management。所以，计算出的偏移量就是：

 

 

7996+68+(2-1)*24=8088

 

 

下面使用BBED工具直接进行块读取，注意，首先需要关闭数据库。

 

 

==将dump筷

[oracle@oracle11g test]$ bbed parfile=par.txt

Password:

 

BBED: Release 2.0.0.0.0 - Limited Production on Wed Jun 15 02:05:20 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

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

 

BBED> info  

 File#  Name                                                        Size(blks)

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

     1  /u01/oradata/WILSON/datafile/o1_mf_system_6bcsnqfc_.dbf         106240

     （篇幅原因，有省略……）

 

//定位到指定的文件和块位置（也可以使用set file 1 block 88817）

BBED> set dba 0x00415af1

        DBA             0x00415af1 (4283121 1,88817)

 

//定位块内的偏移量

BBED> set offset 8088

        OFFSET          8088

 

//DUMP显示出来

BBED> dump

 File: /u01/oradata/WILSON/datafile/o1_mf_system_6bcsnqfc_.dbf (1)

 Block: 88817            Offsets: 8088 to 8191           Dba:0x00415af1

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

 000002c1 04060041 5ae90002 000002c1 03060041 5ae90001 000002c1 02060041

 5ae90000 0d000040 15000002 00401500 000203c2 085eac00 01150015 00004015

 00000100 40150000 0103c208 5aac0001 11001100 0040110f 00090040 110f0009

 03c20858 0106496f

 

 <32 bytes per line>

 

 

再看一下我们将row2导出的信息：

 

 

row#2[7996] flag: ------, lock: 0, len=12

col 0; len 2; (2):  c1 04

col 1; len 6; (6):  00 41 5a e9 00 02

 

 

注意：两个标记0x02和0x06的作用是标记列Column信息，用于分割。

 

4、  局部结论

 

对普通索引结构来说，索引叶子节点上保存索引键值和对应数据行rowid。两者是以行中不同column的方式进行存储，键值在前，rowid在后。

 

 

下面我们使用相同的流程处理Unique Index，检查相关的存储结构。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/17203031/viewspace-700163/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/17203031/viewspace-700163/