Re: waited too long for row cache enqueue lock

From: <steveadams_at_acslink.net.au>
Date: Fri, 24 Apr 1998 05:57:33 -0600
Message-ID: <6hpr6t$55m$1@nnrp1.dejanews.com>

Hi Joan,

This is just to confirm what Jonathan has said. All of these bugs that I can recall were cases where the locking order of taking library cache locks before data dictionary cache locks had been reversed. The bugs are well known by Oracle support, and are largely fixed by 7.2, however backports to 7.1 are available. If you contact support they will help you to diagnose which bug it is that you are hitting and will be able to give you a patch. In the mean while Jonathan's recommendation of increasing the shared pool is the best you can do, in the hope of avoiding the library cache locking step entirely. One more things that might help in this regard would be to set the parameter cursor_space_for_time to true.

Hope this helps,
Regards,
Steve Adams
steveadams_at_acslink.net.au

---

In article <01bd6ed7$c2673690$294b989e_at_WORKSTATION>,   "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote:
>
>
> There are a number of bugs (especially at 7.1.4) that could be
> causing
> this to happen. It isn't necessarily any tuning parameter.
>
> For example, if you try to create a unique index on a table in one
> session
> and simultaneously analyze the table from another table you can get
> a deadlock of this type irrespective of the resources available.
>
> However, you might try increasing the library cache (by increasing
> the
> shared pool) since some of the problems are caused by over active
> systems with library cache and row cache flushing occurring too
> rapidly.
>
>

-----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading Received on Fri Apr 24 1998 - 06:57:33 CDT