| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle8 ROWIDs - data file numbers
In article <89uet8$e6d$1_at_nnrp1.deja.com>,
Ben Ryan <benryan_at_my-deja.com> wrote:
> Thomas,
> Thanks again. Picking up again where we left off and incorporating
> what you said about Oracle7 to Oracle8 migrations, my personal
> explanation for the new extended ROWID format follows. At the end of
> it is my question to you.
>
[snip]
>
> So do extended ROWIDs in Oracle8 contain the absolute data file
> number and restricted ROWIDs contain relative data file numbers?
>
No, they include the object_id of the underlying object and a relative file id for that segment.
from the concepts guide:
Extended Rowids
Extended rowids use a base 64 encoding of the physical address for each
row selected. The encoding characters are A-Z, a-z, 0-9, +, and /. For
example, the following query
SELECT ROWID, ename FROM emp WHERE deptno = 20;
might return the following row information:
ROWID ENAME
------------------ ----------
An extended rowid has a four-piece format, OOOOOOFFFBBBBBBRRR:
n OOOOOO: The data object number that identifies the database segment
(AAAAao in the example). Schema objects in the same segment, such as a
cluster
of tables, have the same data object number.
n FFF: The tablespace-relative datafile number of the datafile that
contains the
row (file AAT in the example).
n BBBBBB: The data block that contains the row (block AAABrX in the
example).
Block numbers are relative to their datafile, not tablespace.
Therefore, two rows
with identical block numbers could reside in two different datafiles of
the same
tablespace.
n RRR: The row in the block.
> Thanks, Ben
>
-- Thomas Kyte tkyte_at_us.oracle.com Oracle Service Industries http://osi.oracle.com/~tkyte/index.html -- Opinions are mine and do not necessarily reflect those of Oracle Corp Sent via Deja.com http://www.deja.com/ Before you buy.Received on Sun Mar 05 2000 - 00:00:00 CST
 |
 |