asked on

oracle 10g Latch waits too high

I am having some performance problems sporadicallly on my database.

The only indicators of problems activated by Quest Spotlight are latch waits and lock waits.

So far I have read that the real solution for this is to re-use sql code more effectively, but I need to find a solution as fast as possible. Changing the applicaion will take a lot of time and money.

Below is the line of statistics for the library cache:

Latch name      Latches      Gets/s      % gets      Sleeps/s      % sleeps      Sleep rate
library cache        54      2,887.29      27.53      1.20      100.00      0.04

Misses/s      % misses      Miss rate
1.53      88.46      0.05

Sean Stuber

you can "try" to set cursor_sharing = similar or cursor_sharing = force

these will force binding of all literals in your sql. Even ones you don't want it to (like constants)
however it may let you limp along until you can get your code fixed.

jose_rijos

ASKER

thanks a lot sdstuber. I'll try that.

jose_rijos

ASKER

sdstuber:

I issued the command alter system set cursor_sharing=force;

Do you know if this will take effect imediately or do i have to bounce the db?

Thanks

ASKER CERTIFIED SOLUTION

Sean Stuber

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

schwertner

About LATCHES on library cache additionally to above suggestion you can try to increase the shared pool size.

About LOCKS:

Query V$LOCK to find the sessions holding the lock. For every session waiting for the event enqueue, there is a row in V$LOCK with REQUEST <> 0. Use one of the following two queries to find the sessions holding the locks and waiting for the locks.

If there are enqueue waits, you can see these using the following statement:

SELECT * FROM V$LOCK WHERE request > 0;

To show only holders and waiters for locks being waited on, use the following:

SELECT DECODE(request,0,'Holder: ','Waiter: ') ||
sid sess, id1, id2, lmode, request, type
FROM V$LOCK
WHERE (id1, id2, type) IN (SELECT id1, id2, type FROM V$LOCK WHERE request > 0)
ORDER BY id1, request;

jose_rijos

ASKER

alter system flush shared_pool fix the problem for the moment. I also altered the cursor sharing parameter.

For a long term solution should I look at the application, or there are other tuning options for the db regarding this particular kind of wait?

jose_rijos

ASKER

Thank you schwertner for the lock contention information?

In regards to latch free waits, what you suggest of increasing the shared pool, I tried once to do that and couldn't put a value > 2G, got the error out of memory. My server is Linux 32 bit. Is there a way to incerase the shared pool on a 32 bit linux server beyond 2Gb?

Sean Stuber

actually, for system that does not use binds increasing your shared pool might even make it worse since you'll have more statements that you do not want to use in the pool.

with binds, a larger pool will let you store more statements that are useful.

yes, you should definitely look at the application.

jose_rijos

ASKER

Thanks again sdstuber. What you suggested so far have solved the problem in terms of what I could do as a dba.
I will close this thread and will have to open another prbably to address other issues.
Thanks again to sdstuber and schwertner.