Hi Mladen,
Don't desert me now, I thought we've come a long way !!
Although, I'm not a listed Oracle guru, let me try and explain further ;)
PCTFREE works in almost exactly the same way as it does for non-ASSM
objects. PCTFREE determines how much of the block we want to reserve for
subsequent update growth. An insert that would violate this figure would
result in the block being taken off the freelist (and other block being
considered). However, with ASSM we don't have freelists, instead the
corresponding BMB is updated to now reflect the block as being full. So an
insert that would violate pctfree causes the block to be considered full and
a full block is longer considered for subsequent inserts.
Note an advantage of ASSM is that blocks can be filled more effectively
because we know the relative free space in a given block thanks to the BMBs.
So for example, if we have a row that is greater than 25% of a block in
length, those blocks with less than 25% free space are not considered for
inserts as we know such inserts would not succeed (in these blocks). Only
blocks with over 25% free space are therefore considered. This way, rows of
a relatively large size are less likely to prematurely make a block
unavailable for inserts as is possible with non-ASSM tables. Thus, tables
with widely variable row lengths are more suited to ASSM and could pack data
in more tightly.
For a block to be made available again for inserts, we need the available
free space to be reduced below one of the free space boundaries. So for
example, if a PCTFREE of 10% is used, once we have more than 25% free space
(ie. the free space is between 25% and 50%) the block becomes "unfull" and
the corresponding BMB is updated. Therefore the effective PCTUSED in this
case is 75%. If however the PCTFREE were set to 30%, then we need to get
below the 50% free space boundary (ie. free space is between 50-75%) in
order to be insertable again, an effective PCTUSED of 50%.
So in summary, PCTFREE is effectively used in a similar manner with ASSM,
but rather than being taken off a freelist, the block is marked as full by
the corresponding BMB. The PCTFREE value also has an influence on what with
effective "PCTUSED" is used within the block as well.
Hope this clears things up a bit(map ;)
Cheers
Richard (Non Oracle Guru / All Round Nice Guy )
- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
Sent: Wednesday, November 12, 2003 6:24 AM
> Int the note 247752.1 named "Oracle9i Space Management Demystified" oracle
says
> the following:
> --------------------------------------------------------------------------
> AUTOMATIC SEGMENT SPACE MANAGEMENT
> ARCHITECTURE Oracle9i introduces a new way of managing free space within a
> segment using bitmaps. In the new scheme, a set of bits describes the
space
> utilization for each block in a segment as well as whether it is formatted
or
> not. Using these Paper # 32707 Oracle9i Database bits, for example, it is
> possible to represent the state of any given data block as follows: " Free
> space in the block is less than 25% " Free space in the block is greater
than
> 25% and less than 50% " Free Space in the block is greater than 50% but
less
> than 75% " Free space in the block is more than 75% " The block is FULL
i.e.
> there is no free space in the block " The block is unformatted. It can be
noted
> here that unlike freelists, where a block was either available for new
rows or
> not, bitmaps provide a more granular and accurate idea of space
utilization
> within blocks of segment. For LOBs and indexes, the bitmap just indicate "
> Whether the block is formatted or not and, " Whether the block is
considered
> free or not. The Automatic Segment Space Management feature can only be
used
> with Locally Managed Tablespaces. BITMAP BLOCKS The bitmaps are contained
in a
> set of meta-data blocks known as bitmap blocks or BMBs. The number of
BMBs in
> a segment depends on its size and the space consumed by the bitmap blocks
is
> typically a very small part (less than 1%) of the total segment size for
any
> reasonable sized segment. As shown in the table below, the space overhead
of
> bitmap blocks decreases as the segment grows and becomes close to
negligible
> for large segments.
> Segment Size Block Size No. Of BMBs Space Used by BMBs BMB Space Overhead
> 25 MB 2 KB 201 400 KB .8%
> 500 MB 8 KB 251 2 MB .4%
> 100 TB 16KB 6555941 100 GB .05%
> --------------------------------------------------------------------------
>
> From that, it would follow that free lists as such are gone in ASSM
tablespaces
> and are replaced by bitmaps. As Richard Foote has shown, PCTFREE is not
ignored,
> but without free lists, it doesn't make much sense. Does any of the gurus
(Cary, Steve,
> Jonathan, Wolfgang, Pete Sharman) have any knowledge of how exactly
PCTFREE is
> implemented in the ASSM situation? I can see and verify that it is not
ignored, but
> I can't figure how does it work.
>
> Mladen Gogala
> Oracle DBA
>
>
>
> Note:
> This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Wang Trading LLC and any of its subsidiaries each reserve the
right to monitor all e-mail communications through its networks.
> Any views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorized to
state them to be the views of any such entity.
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Mladen Gogala
> INET: mladen_at_wangtrading.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (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.net
--
Author: Richard Foote
INET: richard.foote_at_bigpond.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (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).
Received on Wed Nov 12 2003 - 02:59:24 CST
