Following on from my previous note:

Jeremiah, 

>From your bitmap control,

You have FF occurring 3 times followed by 3F which is 
255, 255, 255, 63 which is
11111111 11111111 11111111 00111111

So, least signficant bit first, 

11111111 11111111 11111111 11111100 which is 

used, used, ... (30 times) , free, free 

This corresponds with the first: 30 (the bit before the first free bit)

Paul


-----Original Message-----
Sent: Monday, April 08, 2002 3:23 PM
To: '[EMAIL PROTECTED]'


>From the 'Data Management and Storage Internal" notes,

Bitmapped Tablespace File Structure

A new bitmapped tablespace file has the following structure:
File Header                                             1 block
Bitmapped File Space Header                     1 block
Head portion of of Bitmap Blocks                N blocks
Useful file blocks                              U units (A unit is a number
of blocks)
Tail portion of Bitmap Blocks                   M blocks

If a Unit = B blocks, then the total file size = 1 + 1 + N + U*B + M

Bitmapped File Space Header

......  (lots to type, I can if you really need it)

Bitmap blocks have 2 parts :

Bitmap control structure
Vector Dump

The fields in the bitmap control structure are:
RelFNo: Relative file number to which the bitmap belongs
BeginBlock:     Which block number does the first bit represent
Flag:           Zero for permanent files, one for temp files
First:  Where to start looking for the free space (bit before first free
bit)
Free:           Number of free slots (bits) in the bitmap (not the file)

To read the bitmap, take each two-byte pair, least significant bit first.
If there are not eight bits, pad to eight bits with zeroes.  Hence 0x0F = 15
= 00001111.  When written least significant bit first, the bitmap looks like
this 
11110000 --> used, used, used, used, free, free, free, free

Scanning for the first free extent will start at the 4th bit.

HTH

Paul


-----Original Message-----
Sent: Monday, April 08, 2002 3:44 PM
To: Multiple recipients of list ORACLE-L


Out of curiosity I decided I wanted to look at what composed the
extent map in locally-managed tablespaces.

I dumped the first 5 blocks of the tablespace's first datafile with
'alter system dump datafile ...'  The results surprised me, as they
appeared to consist of almost no data.  The LMT in question contains a
variety of segments and extents.  How is the LMT bitmap organized?

Start dump data blocks tsn: 1 file#: 2 minblk 1 maxblk 1
Block 1 (file header) not dumped: use dump file header command

Start dump data blocks tsn: 1 file#: 2 minblk 2 maxblk 2
frmt: 0x02 chkval: 0x0000 type: 0x1d=KTFB Bitmapped File Space Header
File Space Header Block:
Header Control:
RelFno: 2, Unit: 8192, Size: 524352, Flag: 1
Initial Area: 3, Tail: 524292, First: 30, Free: 34

Start dump data blocks tsn: 1 file#: 2 minblk 3 maxblk 3
frmt: 0x02 chkval: 0x0000 type: 0x1e=KTFB Bitmapped File Space Bitmap
File Space Bitmap Block:
BitMap Control:
RelFno: 2, BeginBlock: 5, Flag: 0, First: 30, Free: 128994
FFFFFF3F00000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
... all zeros

Start dump data blocks tsn: 1 file#: 2 minblk 4 maxblk 4
frmt: 0x02 chkval: 0x0000 type: 0x1e=KTFB Bitmapped File Space Bitmap
File Space Bitmap Block:
BitMap Control:
RelFno: 2, BeginBlock: 1056964613, Flag: 0, First: 0, Free: 129024
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
... all zeros


FWIW:

SQL> select count (*) from dba_extents where file_id = 2;

  COUNT(*)
----------
        30

SQL> select extent_management from dba_data_files df, dba_tablespaces
ts where df.tablespace_name = ts.tablespace_name and file_id = 2;

EXTENT_MAN
----------
LOCAL



--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jeremiah Wilton
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to