I'm sorry - I assumed you were talking about the system datafile having file# 4.

Anyways - in short - the extended rowid is data objectid + rdba + slot in row directory.
dataobjectid = 4bytes
(r)dba = 4bytes
slot = 2 bytes
so total 10bytes

You mention "01 00 03 00 00 00" in your mail.
That's 6bytes - so I'm guessing you're referring to the pointer part in a row header of a migrated or chained row ?
If so - that consists of dba+slot.
The dba contains the file# and can be decoded as follows:
( dba[ 0 ] << 2 ) + ( dba[ 1 ] >> 6 )
So let's take the first 2 bytes of your example

in hex 01 00
in binary 0000 0001 0000 0000
shift left 2 00 000100 0000 0000
shift right 6 00 000100 00

add byte 1+2 00 000100+00 = 00000100 + 00 = 00000100 or in hex 0x04.

I hope this helped (and I hope I didn't make any mistakes here;-) )

Kurt Van Meerbeeck
----- Oorspronkelijk bericht -----
: Mathias Magnusson
: vrijdag, april
10, 2009 02:29 PM
: kurtvm_at_pandora.be
: Re: : Decoding rowid in a datablock.

The explanation is good, but this database was never a release 7 database.
It was installed as a 11Gr1 Database by me on my computer. relative_fno and
file_id in dba_data_files are the same (4) which makes sense as it is users
and system, sysaux and aundo would be created before. Those are also
showing up with 1,2 and 3 in file_id and relative_fno.

Somehow hex 010 maps to 4 as relative and absolute file number. The question
is why and how to map back to the relative_fno from what is in the symbolic
block dump.

relfile# in file$ is what we see as relative_fno in dba_data_files, right?
Or is some magic at plat that makes your explanation work even for

Reading your explanation, I think it could possibly be true that the last 0
in 010 represents two high order bits for the file number. Could it be that
the first byte is not used at all for the file id, the second is what is
used most of the time and the last seldom and when it is should be placed
before the second when converting to a decimal value? That is if the value
was 123, then 1 could be ignored and would currently not be used, 3 is
placed before 2 so the value to convert would be 32 still in hex? If that
holds up, then does this work for all platforms for databases installed
after release 7?

On Fri, Apr 10, 2009 at 12:44 PM, Kurt Van Meerbeeck wrote:

This happens when a database is migrated from 7 to 8.0 when absolute
and relative filenumbers were introduced.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 3 | next ›
Discussion Overview
grouporacle-l @
postedApr 10, '09 at 10:44a
activeApr 10, '09 at 3:26p



site design / logo © 2022 Grokbase