ITPub博客

首页 > Linux操作系统 > Linux操作系统 > object_id与data_object_id浅析(一)

object_id与data_object_id浅析(一)

原创 Linux操作系统 作者:realkid4 时间:2011-03-26 23:53:14 0 删除 编辑

我们经常使用的数据字典视图_objects(xxx代指dba/all/user)中,有数据列object_id用于标志数据对象。在很多时候,我们习惯于使用该标识进行对象信息跟踪和定位。但是,在该视图中,还包括一个名称data_object_id的列,它表示的是一个什么含义呢?我们一起来分析一下。

 

实验环境构建

 

//我们选择10gR2版本

SQL> select * from v$version;

 

BANNER

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

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

PL/SQL Release 10.2.0.1.0 - Production

CORE       10.2.0.1.0       Production

 

TNS for 32-bit Windows: Version 10.2.0.1.0 - Production

NLSRTL Version 10.2.0.1.0 – Production

//构建实验数据表

SQL> create table t as select * from dba_objects;

 

Table created

//数据字典信息展示

SQL> select object_id,data_object_id from user_objects where object_name='T';

 

 OBJECT_ID DATA_OBJECT_ID

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

54038          54038

 

SQL> select segment_name, header_file, header_block from dba_segments where segment_name='T' and wner='SCOTT';

 

SEGMENT_NAME         HEADER_FILE HEADER_BLOCK

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

T                              4         4203

 

 

此时,我们注意一下:试验的数据表T,其object_id为54038,data_object_id相同也为54038。物理段位置上,位于4号数据文件,头块编号为4203。

 

 

数据字典分析

 

首先我们分析一下dba_objects数据字典视图两个对应列的来源。从视图的解释信息上看,object_id和data_object_id分别为:

 

 

OBJECT_IDObject number of the object                                                 

DATA_OBJECT_ID Object number of the segment which contains the object                      

 

 

从视图注释信息上看,object_id的含义是对象的唯一性编号。而data_object_id表示的是数据表对应的段位置编号。简单的说,一个表示逻辑唯一编号,一个表示物理存储上的唯一编号。

 

分析数据字典dba_objects来源,可以抽丝剥茧。检查dba_objects视图的基础来源。这时候我们的方法很多,比如使用dbms_metadata.get_ddl方法。这次我们直接研究数据字典的生成脚本catalog.sql文件中的内容。

 

 

create or replace view DBA_OBJECTS

    (OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_ID, DATA_OBJECT_ID,

     OBJECT_TYPE, CREATED, LAST_DDL_TIME, TIMESTAMP, STATUS,

     TEMPORARY, GENERATED, SECONDARY)

as

select u.name, o.name, o.subname, o.obj#, o.dataobj#,

       decode(o.type#, 0, 'NEXT OBJECT', 1, 'INDEX', 2, 'TABLE', 3, 'CLUSTER',

                     (篇幅原因,省略部分……

                     'UNDEFINED'),

       o.ctime, o.mtime,

       to_char(o.stime, 'YYYY-MM-DD:HH24:MI:SS'),

       decode(o.status, 0, 'N/A', 1, 'VALID', 'INVALID'),

       decode(bitand(o.flags, 2), 0, 'N', 2, 'Y', 'N'),

       decode(bitand(o.flags, 4), 0, 'N', 4, 'Y', 'N'),

       decode(bitand(o.flags, 16), 0, 'N', 16, 'Y', 'N')

from sys.obj$ o, sys.user$ u

(篇幅原因,省略部分

 

上述为catalog.sql脚本中对dba_objects的定义片段,处于篇幅的考虑将于本篇无关的内容加以省略。注意:这个是Oracle10gR2的dba_objects定义,在11g中存在一些差异,留待以后的讨论。

 

从上面的脚本中,我们确定dba_objects视图对象的主要信息来源自底层数据字典表obj$和user$。我们之前讨论过关于Oracle层次结构的数据字典,http://space.itpub.net/17203031/viewspace-686814,obj$属于底层数据字典结构。其中,我们关注的object_id和data_object_id字段就是对应obj$数据表的obj#和dataobj#字段。

 

那么,这两个字段在obj$中的解释是什么呢?因为obj$数据表对应列没有comment信息。我们搜索sql.bsp文件,发现如下的文件片段。

 

 

create table obj$                                            /* object table */

( obj#          number not null,                            /* object number */

  /* DO NOT CREATE INDEX ON DATAOBJ#  AS IT WILL BE UPDATED IN A SPACE

   * TRANSACTION DURING TRUNCATE */

  dataobj#      number,                          /* data layer object number */

  owner#        number not null,                        /* owner user number */

(篇幅原因,省略部分

 

 

sql.bsp脚本中,定义了数据库基础结构表的内容,其中一些注释信息,往往包含着重要信息内容。这里我们发现了obj#和dataobj#的一些端倪。

 

首先,obj#是一个对象标志,在数据库中作为一个对象的唯一标识。而dataobj#给出的内部说明是“data layer object number”,是数据层对象的编号。并且最值得注意的是上面关于dataobj#的描述:Oracle要求不要对这个数据列加索引,因为该列取值会由于进行truncate操作而发生变化。

 

 

在数据字典obj$的内容说明中,我们可以猜测dataobj#是一种描述对象物理存储的标志。truncate操作虽然从效果上是快速进行数据删除,但是本质上是一种ddl语句,重构数据结构。下面我们通过实验进行说明。

 

 

Truncate Table实验

 

还是刚刚环境准备的实验数据表。我们分别进行一般性delete删除和truncate两种删除操作,比较变化效果。

//启用跟踪文件方法

SQL> alter session set events '10046 trace name context forever, level 4';

 

Session altered

 

SQL> delete t;

 

50355 rows deleted

 

SQL> commit;

 

Commit complete

 

SQL> select f_get_trace_name from dual;

 

F_GET_TRACE_NAME

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

D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP\orcl_ora_1236.trc

 

 

之后,我们观察数据表T的逻辑物理结构情况。

 

 

SQL> select object_id,data_object_id from user_objects where object_name='T';

 

 OBJECT_ID DATA_OBJECT_ID

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

54038          54038

 

SQL> col segment_name for a20;

SQL> select segment_name, header_file, header_block from dba_segments where segment_name='T' and wner='SCOTT';

 

SEGMENT_NAME         HEADER_FILE HEADER_BLOCK

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

T                              4         4203

 

 

发现,对象编号和物理编号都没有发生变化。对应的segment_name结构也没有任何的变化,包括文件位置和段头块编号等。同时分析跟踪文件orcl_ora_1236.trc,也没有发现更新obj$数据表的连带操作痕迹。

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

请登录后发表评论 登录
全部评论
求道~

注册时间:2010-11-30

  • 博文量
    545
  • 访问量
    7744998