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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > 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: [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.net -- Author: Richard Foote INET: [EMAIL PROTECTED] 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: [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).
