Re: Does a datafile know *its* blocksize ?

From: Steve Howard <stevedhoward_at_gmail.com>
Date: 5 Sep 2006 13:32:46 -0700
Message-ID: <1157488366.913942.128950@d34g2000cwd.googlegroups.com>

Brian Peasland wrote:
> To add to the exercise...... (I think I'm going to kill a cat here!)
>
> First, I'll dump the data file headers:
>
> SQL> alter session set events 'immediate trace name FILE_HDRS level 10';
>
> Session altered.
>
>
> Next, I'll look at the resulting trace file:
>
> DUMP OF DATA FILES: 8 files in database
>
> DATA FILE #1:
> (name #4) /edcsns18/oradata2/gast/gast/system01.dbf
> creation size=19200 block size=16384 status=0xe head=4 tail=4 dup=1
> tablespace 0, index=1 krfil=1 prev_file=0
> unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
> Checkpoint cnt:2167 scn: 0x0000.00922c7b 09/05/2006 00:19:36
> Stop scn: 0xffff.ffffffff 09/01/2006 06:47:06
> Creation Checkpointed at scn: 0x0000.00000006 01/09/2006 15:40:20
> thread:1 rba:(0x1.3.10)
> <rest snipped for brevity>
>
> As you can see, when I dump the file header, it showed the block size is
> 16KB. The first file belongs to tablespace 0, which is the SYSTEM
> tablespace (no surprise) as can be verified in SYS.TS$ should one be
> curious. You can even see the checkpoint SCN's.
>
> I'm not sure where all of this is stored, byte-wise, looking at a strict
> binary dump of the datafile. And I'm not really sure I care exactly
> *where* it is as I can always dump the file header as seen above and
> look at it in a more human form.
>
>

Just to extend the geekery one more step, I create (several) 4k, 8k, and 16K tablespaces, and read the first 8K of each. As expected, the 4K one had bytes that were not null after 4096. They each invariably had the following structure for the first 32 bytes (new tablespace with same block size, new datafile in tablespace)...

BYTE 2 value is 82.
BYTE 7 value is c0.
BYTE 8 value is ff.
BYTE 17 value is c6.

BYTE 18 value is 6e.
BYTE 22 value is 10.
BYTE 26 value is 5.

BYTE 29 value is 7d.
BYTE 30 value is 7c.
BYTE 31 value is 7b.
BYTE 32 value is 7a.

BYTE 2 value is a2.
BYTE 7 value is c0.
BYTE 8 value is ff.
BYTE 17 value is 46.
BYTE 18 value is 79.

BYTE 22 value is 20.
BYTE 25 value is 80.
BYTE 26 value is 2.

BYTE 29 value is 7d.
BYTE 30 value is 7c.
BYTE 31 value is 7b.
BYTE 32 value is 7a.

16K

BYTE 2 value is c2.
BYTE 7 value is c0.
BYTE 8 value is ff.
BYTE 17 value is 86.
BYTE 18 value is 7a.

BYTE 22 value is 40.
BYTE 25 value is 40.
BYTE 26 value is 1.

BYTE 29 value is 7d.
BYTE 30 value is 7c.
BYTE 31 value is 7b.
BYTE 32 value is 7a.

My *guess* is the block size is a set of hardcoded constant values in the kernel code, that is probably represented by the 26th byte (or one of them) in a datafile.

As noted earlier, a complete waste of time, but I am always curious :)

Regards,

Steve Received on Tue Sep 05 2006 - 15:32:46 CDT