Re: : Decoding rowid in a datablock.

From: Kurt Van Meerbeeck <kurtvm_at_pandora.be>
Date: Fri, 10 Apr 2009 15:12:13 +0000
Message-ID: <W7625730715831239376333_at_nocme1bl6.telenet-ops.be>


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 ;-) )

cheers,
Kurt Van Meerbeeck

>----- Oorspronkelijk bericht -----
>Van

: Mathias Magnusson [mailto:mathias.magnusson_at_gmail.com]
>Verzonden

: vrijdag
, april
 10, 2009 02:29 PM
>Aan

: kurtvm_at_pandora.be
>Onderwerp

: Re: : Decoding rowid in a datablock.
>
>Kurt,
>
>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?
>
>Mathias
>
>On Fri, Apr 10, 2009 at 12:44 PM, Kurt Van Meerbeeck <kurtvm_at_pandora.be>wrote:
>
>>
>> This happens when a database is migrated from 7 to 8.0 when absolute
>> and relative filenumbers were introduced.
>>
>>
>>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Apr 10 2009 - 10:12:13 CDT

Original text of this message