select view_definition from v$fixed_view_definition where view_name = 'GV$SESSION_WAIT' /
This gives the definition of (g)v$session_wait in terms of the underlying X$ objects, and shows you the way in which some of the v$ columns are derived by decodes from (particularly) the microsecond wait time.
'Client' in this wait event is simply a session at the far end of an SQL*Net link - i.e. incoming database link or normal end-user/batch connection.
In a normal client/server dialogue, e.g. SQL*Plus running a simple query and fetching lots of rows one at a time, you would expect to see this event coming and going very rapidly (alternating with SQL*Net message from client).
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk/faq/ind_faq.html The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html Cost Based Oracle: Fundamentals
http://www.jlcomp.demon.co.uk/appearances.html Public Appearances - schedule updated 4th Nov 2005
Let me first give thanks for your help.
If you don't mind teaching me to fish, how could I have ascertained this explanation on my own?
Little more can be collected on this event. The impatient dba took the sledge hammer approach to the log switch-hung db.
There were no user sessions listed in v$session. The other wait events were the log switch and a 220 buffer busy, both waiting for the same period of time. Oradocs say the 220 is, "during buffer lookup for a CURRENT copy of a buffer we have found the buffer but someone holds it in an incompatible mode so we have to wait."
So, I'm curious who this client might have been. There is no knowing for certain since the evidence has been destroyed. What are the possible "clients?" Seems like a bug, unless client means something I don't think it means.
On Wed, Nov 23, 2005 at 07:56:01PM -0000, Jonathan Lewis wrote:wait_time=-1 means less than 1 hundredth of a second for 8i, and less than 50 milliseconds for later versions of 9.
-- //www.freelists.org/webpage/oracle-l