RE: 10Gr2 and Library Cache Lock Waits
- From: "Milen Kulev" <makulev@xxxxxxx>
- To: <ian@xxxxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Sun, 4 Feb 2007 12:13:49 +0100
Ian,
What waits events (from v$session_wait) do you get ?
If it is "CURSOR: PIN S WAIT ON X" you can try
_kks_use_mutex_pin = FALSE.
I have several databases , that are running since years well, but after 10g
upgrade
I have got many "CURSOR: PIN S WAIT ON X".
Perhaps it is a coinsidence, but all the databases that are experiencing this
problem are
Runnung on HPUX. Perhaps this problem has something to do with mutexes
implementation
On HPUX.
Regards. Milen.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of MacGregor, Ian A.
Sent: Sunday, February 04, 2007 11:04 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: 10Gr2 and Library Cache Lock Waits
Is there anything in 10GR2 which makes it more prone to library cache lock
waits. This would be something peculiar to
10.2 and not 10.1. The locks occur when one process creates a table, drops
the original, renames the new back to the
original name while another process creates or replaces any associated views
which have gone invalid. Not the way, I
would have written the system. However, it's worked for over a decade.
Anyhow, in 10Gr2 timing issues result in in
intermittent library cache lock waits which were not seen before.
Ian MacGregor
Stanford Linear Accelerator Center
ian@xxxxxxxxxxxxxxxxx
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
