我的Oracle ROWID解读

一、rowid简介

       rowid就是唯一标志记录物理位置的一个id,在oracle 8版本以前,rowid由file#+block#+row#组成,占用6个bytes的空间,10 bit 的 file# ,22bit 的 block# ,16 bit 的row#。 

       从oracle 8开始rowid变成了extend rowid,由data_object_id#+rfile#+block#+row#组成,占用10个bytes的空间, 32bit的 data_object_id#,10 bit 的 rfile#,22bit 的 block#,16 bit 的 row#。由于rowid的组成从file#变成了rfile#,所以数据文件数的限制也从整个库不能超过1023个变成了每个表空间不能超过1023个数据文件。

        说了rowid的组成,那么我们再来看看rowid在索引里面占用的字节数又是什么样子的。在oracle 8以前索引中存储的rowid占用字节数也是6bytes,在oracle8之后,虽然oracle使用了extend rowid,但是在普通索引里面依然存储了bytes的rowid,只有在global index中存储的是10bytes的extend rowid,而extend rowid也是global index出现的一个必要条件,下面我们会解释原因。 
      
9399028_201012281435241.jpg
        上图为oracle8之后的rowid的组织结构图。数据对象编号:000000,文件编号:FFF, 块编号:BBBBBB,行编号:RRR。        

        怎么依据这些编号得到具体的十进制的编码值呢,这是经常遇到的问题。这里需要明白rowid的是基于64位编码的18个字符显示(数据对象编号(6) +文件编号(3) +块编号(6)+  行编号(3)=18位),其中
A-Z <==> 0 - 25 (26)
a-z <==> 26 - 51 (26)
0-9 <==> 52 - 61 (10)
+/ <==> 62 - 63 (2)

共64位,明白这个后,就可以计算出10进制的编码值,计算公式如下:
d * (b ^ p)
其中:b就是基数,这里就是64,p就是从右到左,已0开始的位置数
比如上面的例子,文件号AAF,具体的计算应该是:
5*(64^0)=5;
0*(64^1)=0;
0*(64^2)=0;
文件号就是0+0+5=5

        刚才提到的是rowid的显示方式:基于64位编码的18个字符显示,其实rowid的存储方式是:10 个字节即80位存储,其中数据对象编号需要32 位,相关文件编号需要10 位,块编号需要22,位行编号需要16 位,由此,我们可以得出:
        32bit的object number,每个数据库最多有4G个对象
        10bit的file number,每个对象最多有1022个文件(2个文件预留)
        22bit的block number,每个文件最多有4M个BLOCK
        16bit的row number,每个BLOCK最多有64K个ROWS

        为什么golbal index需要把data_object_id#也包含在index rowid entry中呢?如果不包含会怎么样?首先我们需要知道index的rowid entry的存在是为了能根据它找到表的这条记录存在哪个具体的物理位置,我们需要知道它在哪个数据文件,在哪个block,在哪一行。普通的索引oracle根据rfile#、block#、row#就可以知道了,但是partition table可以分布在多个表空间,也就是可以分布在多个数据文件,当我们建立local index时,index rowid entry并不包含data_object_id#,因为oracle可以知道这个index对应的是哪一个table分区,并可以得到table分区的 ts#(tablespace号),那么oracle根据ts#和rfile#就可以找到具体的数据文件。但是如果换成是golbal index,如果不包含data_object_id#,那么我们并不能知道这个索引对应着哪个表分区,也自然不能知道它的rfile#和file#的转换关系,所以它将找不到所对应的记录。包含data_object_id#后,oracle可以根据data_object_id#实现rfile#和file#的转换,然后找到记录对应的物理位置。需要注意的是要理解以上概念我们还是需要了解file#和rfile#的区别。

二、比较file#和rfile#

        oracle数据文件为什么存在file#和rfile#? 


        归根结底的原因是因为ROWID 的存储格式造成的,因为rowid 中文件编号标志只有10bit,最大数据容量1024,由于不存在0编号文件,所以实际上只允许1023个文件编号。在oracle8 之前的版本的数据库中,rowid是受限的,只包括 file# /block#  /row# ,则数据库最多只允许1023个文件。

        从oracle8开始rowid 包括 data_object_id# / Rfile#  /block# /rowid# 。data object id 的引入,同时支持了表分区的概念,一个表可以拥有多个分区(segment),而一个分区可以在不同的表空间中(由Rfile# 表示在segment对应的表空间中对应的 相对文件编号)。这样表的容量也增大了。扩展的rowid使得oracle不再局限于数据文件只能有1023个的限制,而一个表可以分区,也使得表的容量不再局限于单个表空间中(1023个文件的限制)。 

        你或许要问,为什么oracle不调整rowid中表示 file# 的  bit数量,这个应该是由于兼容性的考虑引起的,在 oracle7 的索引中存储的rowid就是 file# +  block# + row# ,,因为这样处理后关于索引的存储,oracle8和oracle7没有发生变化(在oracle8中一个索引(可能分区)segment肯定对应了一个 表(可能分区)的segment,这个可以由数据字典关系得到,从而确立了索引中的rowid 对应哪个表空间中的数据文件),在升级的时候就不用关心索引的问题,而直接升级oracle软件以及运行相关的包,否则将会大动干戈解决索引的问题。这就是oracle实现物理文件升级的基础。

        当然,真正升级的时候,一些数据文件头的rfile# 需要发生变化,这也是由文件的一些存储特性决定的,为了不和oracle8的格式发生冲突,才需要修改。这个修改代价非常的小,所以oracle选择了这个方案。详细的信息,大家可以去参考metalink相关内容,有详细的存储(byte 中字节位)的变化关系。
 
三、rowid相关的有用的sql

        最简单的基于rowid的显示方式得到的响应的64位编码对应值的sql:
SQL> select rowid,
           substr(rowid, 1, 6) "OBJECT_ID",
           substr(rowid, 7, 3) "FILE#",
           substr(rowid, 10, 6) "BLOCK#",
           substr(rowid, 16, 3) "ROW#"
      from t1
     where rownum <= 2;

ROWID              OBJECT_ID    FILE#  BLOCK#       ROW#
------------------ ------------ ------ ------------ ------
AAAuTyAAFAABJu8AAA AAAuTy       AAF    AABJu8       AAA
AAAuTyAAFAABJu8AAB AAAuTy       AAF    AABJu8       AAB

        通过dbms_rowid这个包,可以直接得到具体的rowid包含的信息:

SQL> select rowid,
           dbms_rowid.rowid_object(rowid) object_id,
           dbms_rowid.rowid_relative_fno(rowid) file_id,
           dbms_rowid.rowid_block_number(rowid) block_id,
           dbms_rowid.rowid_row_number(rowid) num
      from t1
     where rownum <= 2;
ROWID               OBJECT_ID    FILE_ID   BLOCK_ID        NUM
------------------ ---------- ---------- ---------- ----------
AAAuTyAAFAABJu8AAA     189682          5     302012          0
AAAuTyAAFAABJu8AAB     189682          5     302012          1
        还可以通过dbms_rowid.rowid_info函数,以参数的形式获得rowid的各种信息。

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

转载于:http://blog.itpub.net/9399028/viewspace-682698/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值