It only takes two truly concurrent updates on a block
to produce a BBW - only one actual current block
change can take place at a time. However, the
sequence of events would probably be something
like:
Session 1: pin block exclusively
Sessions 2 - 6: join waiter list - into BBW
Session 1: update block, release block pin
Session 2: out of BBW - pin block exclusively
Sessions 3 - 6: still waiting in BBW
and so on.
It might be quite hard to prove this though, as the
high precision concurrency might be hard to achieve.
(Perhaps you could fake it through discrete transactions).
In practice, you might find that you got very rapid serialisation
of updates most of the time, which could allow the pattern to
be more like:
Session 1: pin block, update and release
Session 2: clone block to CU, change prior copy to CR
pin clone, update and release
Session 3: repeat.
which would leave a chain of CR copies of the same block.
The limit on CR blocks is a pretty soft limit -
I believe its purpose is to keep to a minimum
the time that the cache buffers chains latch for
a given block is held as the chain is searched.
It is still possible, however, for processes that
NEED a CR block simply to grab the most
appropriate one (i.e. legal and furthest back
in time) and clone it to a new one. (You've reminded
me that I still have to write a reply to Gerald Cunningham
about his 160+ CR copies of numerous blocks in
the buffer - sorry about the delay, Gerald).
I believe that there are points in time that Oracle
will 'new' (aka 'free') a buffer if it finds that there
are too many copies - but I haven't proved that
this is true, or figured out when it would do it.
Of course, it would arguably make sense to do
it, as 'free' blocks are used preferentially as the
target for physical reads - so wiping the Nth CR
copy of a block probably makes more sense than
dumping a block with only a few recent clones.
BTW - if there were
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:07
>Arup,
>
>Just picking up the thread on the BBWs. (Btw, I asked this question
in this
>list - never got an answer!) The following undocumented parameter
limits the
>numbe of CR copies in the Block buffers.
>
>Name Value
>--------------------------------------------- -----------------------
-------
>Description
>---------------------------------------------------------------------
-------
>---
>_db_block_max_cr_dba 6
>Maximum Allowed Number of CR buffers per dba
>
>What if there are more than 6 concurrent update requests for the same
block.
>Would that not result in BBW?
>
>John Kanagaraj
>Oracle Applications DBA
>DBSoft Inc
>(W): 408-970-7002
>
--
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).
