而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 中字节位)的变化关系。

http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=122926.1

这样可以解释很多ｏｒａｃｌｅ限制问题，如一个表空间最多１０２３个数据文件，一个数据文件最多２的２２次幂个ｂｌｏｃｋ　　

但我還是不很明白 在什么情況下 Rfile# 和 file# 會不相同。

我晕，很显然 file# > 1023 的时候就不一样啊！！！！

这两个值之间并无规律可寻,要做转换还得从系统表来进行查询，在索引的叶结点中也是只存了RDBA和SLOT，最后还是要根据所在表的DATA_OBJECT_ID查出相应的表空间来读取记录。

也许以后的版本会突破这一限制。

biti的师兄吗？你在linux下装过oracle吗？

linux 下安装oracle？

仔细按照文档做，就ok了
偶在 linux/AIX/HP unix 等os上安装oracle，按照oracle 文档做，基本没出过什么问题。

oil purifier Oil tank oil water separator ONO SOKKI organic pigment Outdoor furniture Oven Oven óxido de hierro panda tour