I was going to mention the paper - but don't take it
as an extreme condemnation of ASSM.  It's just an
example of one detail of the implementation that still 
hasn't been corrected - and the example is doing
something which you shouldn't do anyway.  It does
hint, however, that there may be other traps in the 
implementation waiting to catch the unwary.


As Greg says, there have been cases where using
ASSM with RAC has resulted in an easy and comfortable 
reduction in contention on freelist blocks - but the price
you pay is that instead of having a very small number
of freelist blocks per segment, you end up with a
couple of bitmap space management blocks per segment - 
and that could turn into a significant fraction of the
blocks from your total db_cache_size.

More importantly, at the Miracle Masterclass in 
Copenhagen this year, Steve Adams listed a few
outstanding (9.2) bugs with the way in which the
bitmap space management blocks are maintained.
In particular, it is very easy to 'leak' space and end
up with bitmaps declaring that a data block is FULL
when it isn't.

As an easy example try this:
    create table in ASS managed tablespace
    insert 10,000 large rows into table
    rollback;
    dump all relevant bitmap blocks.

You will find that every single block that was
used id marked as FULL.  Rolling back does
not reset the bitmaps correctly.

There are other, slightly more subtle, issues
which might be a little more realistic in other
cases - largely they revolve around rolling
back or mixtures of deletes and inserts.


Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

Coming soon one-day tutorials:
Cost Based Optimisation
Trouble-shooting and Tuning
Indexing Strategies
(see http://www.jlcomp.demon.co.uk/tutorial.html )

____UK_______March 19th
____USA_(FL)_May 2nd


Next Seminar dates: 
(see http://www.jlcomp.demon.co.uk/seminar.html )

____USA_(CA, TX)_August


The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html


-----Original Message-----
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Date: 19 February 2003 20:12


>See Jonathan Lewis' paper on ASS Management:
>http://www.jlcomp.demon.co.uk/bustbits.html
>
>HTH,


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jonathan Lewis
  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).

Reply via email to