Re: : Decoding rowid in a datablock.
- From: "Kurt Van Meerbeeck" <kurtvm@xxxxxxxxxx>
- To: "Mathias Magnusson" <mathias.magnusson@xxxxxxxxx>, kurtvm@xxxxxxxxxx, oracle-l@xxxxxxxxxxxxx
- Date: Fri, 10 Apr 2009 15:12:13 +0000
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@xxxxxxxxx]
>Verzonden
: vrijdag
, april
10, 2009 02:29 PM
>Aan
: kurtvm@xxxxxxxxxx
>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@xxxxxxxxxx>wrote:
>
>>
>> This happens when a database is migrated from 7 to 8.0 when absolute
>> and relative filenumbers were introduced.
>>
>>
>>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
