Thanks Jonathan.
>I think you'll find that generally the initial amount
>of file allocated is 64K (including the two header
>blocks) - the fact that you noted the bitmap was in
>the "next 6 blocks" suggests you were using an
>8K block size.
>The actual space allocated at file creation time
>is d
There's a funny thing about the:
| Tail portion of Bitmap Blocks M blocks
It doesn't really exist despite Oracle documents
to the contrary. Try creating a file with some
waste space at the end of it so that the
'Tail' points to the start of the waste space; then
increase the file size by
I think you'll find that generally the initial amount
of file allocated is 64K (including the two header
blocks) - the fact that you noted the bitmap was in
the "next 6 blocks" suggests you were using an
8K block size.
The actual space allocated at file creation time
is dependent on the file siz
That looks the way it should be.
You have 30 extents in the tablespace, and
30 bits near the start of the bitmap are set.
You'll have to create a bitmap tablespace and
use extents in it one at a time, but quite literally
from the block 3 onwards the bitmap is one bit
per extent - it's just a q
Hi Jeremiah,
>How is the LMT bitmap organized?
I did some research about the bitmap structure for an LMT tablespace a while ago.
The first 2 blocks are
Block 1 - For File Header
Block 2 - For File Space Bitmap Header
The bitmap itself is stored in 6 blocks after that , blocks 3 thru 8. Eac
Jeremiah,
Everything looks normal. Block #3 shows the first couple bytes as
"FF3F000...". When you decipher "FF3F", you will see 30 (out of
a possible 32) bits in those 4 bytes (a.k.a. 8 "nibbles") set to "1" instead
of "0", indicating that those are used extents. Your COUNT(*) on
Jeremiah,
Let me explain before guru X$GOPAL woke up. I guess time is midnight
in India.
Here are the some lines before your dump:
Start dump data blocks tsn: 1 file#: 2 minblk 3 maxblk 3
frmt: 0x02 chkval: 0x type: 0x1e=KTFB Bitmapped File Space Bitmap
File Space Bitmap Block:
BitMap Control
>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 Bitm
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
0011
So, least signficant bit first,
1100 which is
used, used, ... (30 t
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 qu
10 matches
Mail list logo
