oracle学习小结(一)-ROWID（转）
日期：2014-05-16 浏览次数：20503 次
oracle学习总结(一)---ROWID（转）
搞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出现的一个必要条件，下面我们会解释原因。
为什么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举例
1.创建一临时表
create table test_rowid (id number, row_id rowid);
2.插入一行记录
insert into test_rowid values(1,null);
3.修改刚插入的记录
update test_rowid set row_id = rowid where id = 1;
4.查看rowid
select rowid,row_id from test_rowid;
返回结果为：
rowid row_id
AAAO0DAAJAAAAMYAAA AAAO0DAAJAAAAMYAAA
Oracle的物理扩展ROWID有18位，每位采用64位编码，分别用A~Z、a~z、0~9、+、/共64个字符表示。A表示0，B表示1，……Z表示25，a表示26，……z表示51，0表示52，……，9表示61，+表示62，/表示63。
ROWID具体划分可以分为4部分。
(1).OOOOOO：前6位表示DATA OBJECT NUMBER，将起转化位数字后匹配DBA_OBJECTS中的DATA_OBJECT_ID，可以确定表信息。
如上面例子中的DATA OBJECT NUMBER是AAAO0D，转化位数字是14×64×64 ＋52×64 ＋ 3。
输入以下查询：
select owner, object_name from dba_objects where data_object_id = 14*64*64 + 52*64 + 3;
返回：
OWNER OBJECT_NAME
搞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出现的一个必要条件，下面我们会解释原因。
为什么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举例
1.创建一临时表
create table test_rowid (id number, row_id rowid);
2.插入一行记录
insert into test_rowid values(1,null);
3.修改刚插入的记录
update test_rowid set row_id = rowid where id = 1;
4.查看rowid
select rowid,row_id from test_rowid;
返回结果为：
rowid row_id
AAAO0DAAJAAAAMYAAA AAAO0DAAJAAAAMYAAA
Oracle的物理扩展ROWID有18位，每位采用64位编码，分别用A~Z、a~z、0~9、+、/共64个字符表示。A表示0，B表示1，……Z表示25，a表示26，……z表示51，0表示52，……，9表示61，+表示62，/表示63。
ROWID具体划分可以分为4部分。
(1).OOOOOO：前6位表示DATA OBJECT NUMBER，将起转化位数字后匹配DBA_OBJECTS中的DATA_OBJECT_ID，可以确定表信息。
如上面例子中的DATA OBJECT NUMBER是AAAO0D，转化位数字是14×64×64 ＋52×64 ＋ 3。
输入以下查询：
select owner, object_name from dba_objects where data_object_id = 14*64*64 + 52*64 + 3;
返回：
OWNER OBJECT_NAME
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
