| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Automatic Segment Space Management
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.
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 <ORACLE-L_at_fatcity.com>
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
>--------------------------------------------- -----------------------
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis INET: jonathan_at_jlcomp.demon.co.uk 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 Feb 19 2003 - 15:05:07 CST
 |
 |