| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: What use is OCP? they did it again!
"Connor McDonald" <connor_mcdonald_at_yahoo.com> wrote in message
news:3DDD30A1.DB4_at_yahoo.com...
> Richard Foote wrote:
> >
> > "mario" <mario_jvn_at_yahoo.it> wrote in message
> > news:b84ce0d2.0211200929.85ed698_at_posting.google.com...
> > > From the last issue (November/December 2002) of
> > > Oracle Magazine, page 134:
> > >
> > > " Select two characteristics of locally managed tablespaces:
> > >
> > > A. extents are managed by the data dictionary.
> > >
> > > B. a bitmap in the datafile keeps track of the free
> > > or used status of blocks (sic!) in the datafile.
> > >
> > > C. Each segment stored in the tablespace can have a
> > > different storage clause.
> > >
> > > D. no coalescing is required.
> > >
> > > E. UNDO is not generated when allocation or
> > > deallocation of extents occurs.
> > >
> > > For locally managed tablespaces, the correct answers
> > > are B (sic!), D and E. "
> > >
> > > Each bit in the 64K bitmap corresponds to one extent in the file,
> > > and not, as stated, a single block.
> >
> > Hi Mario,
> >
> > Actually you are both right.
> >
> > If a LMT has a uniform size, then yes, all bits correspond to an extent
(as
> > all extents must be of the same size)
> >
> > However, if the LMT is autoallocate, then it can have a number of
difference
> > extent sizes, when can appear anywhere within the tablespace. Therefore
in
> > this case, each bit does indeed correspond to a block and Oracle
searches
> > for a range of bits that corresponds to the required extent size. It
makes
> > the bitmap less efficient as a result but you can still fit a mamma of a
lot
> > of bits in the bitmaps initially allocated.
> >
> > All that said, answer B may or may not be correct and it's an ambiguity
> > that's makes the question a bit stinky.
> >
> > Cheers
> >
> > Richard
> > >
> > >
> > > Mario from Rome
>
>
>
>
>
>
>
>
>
>
>
>
> FILE#
> ----------
> 9
>
>
>
>
>
>
Hi Norman,
Your not 'quite' reading it correctly.
Your example only illustrates an object with the one extent which happens to be the minimum allowable size in an autoallocate tablespace. The value of '1' is therefore somewhat deceptive and appears to oversimplify what's actually going on.
What you are seeing is Oracle effectively saying that the first group of blocks is currently allocated, not that only one extent is allocated. Let me try and demonstrate with a slightly different example.
SQL> create tablespace dummy
2 datafile 'c:\bowie\dummy01.dbf' size 100m
3 autoallocate;
Tablespace created.
SQL> create table x1 (x number)
2 tablespace dummy
3 storage (initial 50M);
Table created.
SQL> select file# from v$datafile where name like '%DUMMY%';
FILE#
12
SQL> select extents from user_segments
2 where segment_name = 'X1'
3 ;
EXTENTS
50
SQL> alter system dump datafile 12 block 3;
System altered.
Note that the 50M I requested was allocated as 50 x 1M extents. Note also that this represents 800 64K chunks of data and this is being represented by 100 pairs of bitmap bits (each looking after 8 data chunks).
These pairs of bitmap values are required to determine if there is a "hole" with a bitmap pair. For example, with your experiment, now create another table (X2) of 1 extent. Then alter your first X1 table and allocate an extent. Then allocate an extent to the second table and so on for say 8 extents in total. You (should) see the first bitmap pair being updated to reflect the allocation of blocks within the range covered by the first bitmap pair (8 chunks of blocks in total). Now drop the second table (resulting the 2nd and 4th and 6th ... chunks of blocks being free). Notice how the first bitmap pair (should) change to reflect the free blocks referenced within the pair.
So in summary, with autoallocate, the bitmaps behave in a manner somewhat similar to a uniform size of 64K and the bitmap act as references or pointers to blocks, in multiples of 8 x 64K in size, *not* to allocated extents. 64K effectively becomes the uniform size with autoallocate. These only represent actual *extent* sizes in LMT with the uniform clause. When a "larger" extent size needs to be allocated, Oracle will search for a sequence of bitmaps that represents the amount of free space required, not an individual bitmap per se. Perhaps not much of a difference but a subtle difference none the less. And as 'uniform' sizes can be somewhat larger than 64K, the bitmaps are more efficient as a result in representing this used/free space.
Or so I think ;)
Cheers
Richard
> hth
> connor
>
>
 |
 |