Re: V$LATCH question

>PMFJI
I've not seen this acronym before. What does it mean ?

>What can I say? :-)

How about

    "There, there, diddums"

>I'm currently looking after a db that gets approx 2500 latch free
>events every 24 hours, taking all of 18.7 secs in total during this
>period.

It is likely that this is TOTALLY irrelevant. Especially since latch free waits are likely to escalate with the number of concurrent users at peak periods - i.e. if I'm holding a latch and the system is very busy, it's much more likely that two or three other users will want the latch and end up waiting for it - so the 18.7 seconds could arguably be divided by the number of concurrent users when compared to the 24 hours. (Better still, look at v$session_event over snapshot periods to prove the point, rather than v$system_event).

It's a pity to have to stick with 'relatively' - but I dislike quoting meaningless numbers as a guide, and like to encourage people to think about what is most relevant to their own systems.

A useful guideline is to compare the CPU used by a session with the time lost of latches - and ask if user would actually notice a difference in performance if you eliminated the time they had spent waiting on latches - if the answer is ''maybe', then add the time spent on I/O to the CPU time and repeat.

--
Jonathan Lewis
http://www.jlcomp.demon.co.uk

Host to The Co-Operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

Author of:
Practical Oracle 8i: Building Efficient Databases

Screen saver or Life saver: http://www.ud.com
Use spare CPU to assist in cancer research.

Nuno Souto wrote in message <3c08c775.9850311_at_news>...


>Jonathan Lewis doodled thusly:

>

>

>>

>>To decide if you need to tune the

>>latches, (a) check v$system_event

>>for the event 'latch free'.  This is the

>>amount of time lost in latch sleeps;

>>if this is relatively high, then you may

>>need to investigate latch contention.

>

>This is interesting.  I've had a few "fights" about exactly what

>constitutes "relatively high".

>