If the data_object_id
is not unique within a database as Tanel Poder demonstrated (albeit from 2008), then how does Oracle uniquely determine the tablespace from the ROWID
in order to make use of the ROWID
's relative_fno
?
For example, a global index on a partitioned table whose partitions are in different tablespaces would require the extended ROWID
in the global index to uniquely identify the tablespace of the row to which the index entry refers.
I am using Oracle Enterprise Edition 19c, but I suspect the answer only requires Oracle 8+.
Poder's article demonstrates
ROWID
duplication within a database, but not within a table. When using aROWID
, whether from an index or explicitly in aWHERE
clause, Oracle knows what table its coming from. That narrows down the possible reference of thedata_object_id
to only one possible partition/segment, which means only one possible tablespace.The example Poder gives of a potential problem is the unrealistic scenario of a program using
ROWID
as a kind of global identifier across tables with a uniqueness relied on by user code, which nobody should be doing. (Not only is it nonsensical to attempt a global identifier across entities, butROWID
should never be used by code outside of the lifetime of the cursor that fetched it, let alone as a permanent identifier. It's volatile, and will change if the row moves due to update of a partition key column or partitions are split, merged or exchanged, or if a DBA or scheduled management script does any move/reorg/compression work.) So it's a "problem" that probably nobody, or nearly nobody, will have run into since this was introduced in Oracle 8.