oracle数据文件为什么存在 Rfile# and file#

归根结底的原因是因为 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 中字节位)的变化关系。

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