Don't worry - that paragraph is wrong. The number
of latches was set to a the next prime anyway - it was
only the parameter that was set to double the number of
buffers, which is why the author got confused.
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person
who can answer the questions, but the
person who can question the answers -- T. Schick Jr
One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html
Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK___November
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
"Rick Denoire" <100.17706_at_germanynet.de> wrote in message
news:7lrksv8nkusa8u0735vajp5iqj12lgote2_at_4ax.com...
> Yes of course, it is a block level contention.
>
> The easiest way would be to reorganize the object, that is quite
> straigforward, if it happens to work (I mean records could end up in
> the same block again).
>
> I found an interesting hint at
> http://otn.oracle.com/oramag/oracle/03-mar/o23expert.html
>
> "If the hot block is the index root block, a reverse-key index won't
> help. Setting _DB_BLOCK_HASH_BUCKETS to the prime number just larger
> than twice the number of buffers (DB_CACHE_SIZE/DB_BLOCK_SIZE) will
> usually eliminate this problem. Prior to Oracle9i, this parameter had
> a default that caused tremendous contention for this latch; the
> default is correctly set to a prime number in Oracle9i."
>
> I don't like using underscore parameters in a production DB, but if
> Oracle itself endorses it...
>
> Bye
> Rick Denoire
>
>
>
Received on Mon Dec 01 2003 - 00:52:18 CST
