Statspack will tell me there were 'X' number of log file sync timeouts
between snapshots....

1) Is there any way to find out exactly when each timeout occurred?
I'm trying to determine if there is correlation between these timeouts
and spikes in app performance.

2) After a timeout (1000ms in this case) what happens? It's
obviously still waiting on the post back from the log writer process.
Does it just switch context to another session and check again when
active?

Thanks,
Ron Boggs
St. Louis

Notes in-line

--
Regards

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

The educated person is not the person
who can answer the questions, but the
person who can question the answers -- T. Schick Jr


Next public appearance2:
March 2004 Hotsos Symposium - Keynote
March 2004 Charlotte NC - OUG Tutorial
April 2004 Iceland


One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html


Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK___February


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


"Ron Boggs" <rboggs@endian-networks.com> wrote in message
news:e53f59be.0401131500.40e83290@posting.google.c om...
> Statspack will tell me there were 'X' number of log file sync timeouts
> between snapshots....
>
> 1) Is there any way to find out exactly when each timeout occurred?
> I'm trying to determine if there is correlation between these timeouts
> and spikes in app performance.
>

Exactly - no, to within N seconds - yes.
If you know what you want to look for (e.g. v$system_event
for event "log file sync") then you could write a little pl/sql
procedure that loop for 30 minutes, doing a select for
that item every 10 seconds, and printing the delta from
the last cycle using utl_file. If it's really important to
get the answer, this is the cheapest option.


> 2) After a timeout (1000ms in this case) what happens? It's
> obviously still waiting on the post back from the log writer process.
> Does it just switch context to another session and check again when
> active?

You may be misinterpreting statspack - how are you
inferring that you had a timeout that lasted 1000ms ?
I'll guess for the moment that you've had many waits,
including one timeout, totallling 1,000 ms. (If this
is with a couple of dozen busy processing running
over a period of 15 minutes, I wouldn't be too bothered).

To enter a wait, a process sets an alarm clock (typically
in the small number of centiseconds, though some are 1,
2, or 3 seconds, and a few are five minutes) then goes to
sleep waiting for a callback. If the callback comes before
the alarm goes off, the wait time is recorded; if the alarm
goes off first, a timeout (and the wait time) is recorded.
Usually on a timeout, the process resets the alarm clock
and goes back to sleep.

>
> Thanks,
> Ron Boggs
> St. Louis