Usual caveat:
looking a v$system_event can be very misleading,
you need to examine v$session_event to determine
if anyone is actually noticing a problem.
Usual caveat 2:
A statspack report without a time interval
is almost meaningless. However, in this case,
log file sync at the top is sufficiently unusual to
warrant a little hypothesis.
Question: Was log file write really number two,
or have you knocked out one or two lines between
the two log-related waits ?
Log file syncs are from the sessions,
log file writes are from LGWR
A log file sync is a call from a session to lgwr
to write some log buffer to disc. As such, you
could get multiple sessions calling at about the
same time - and only the first one in gets lgwr
to write, the rest have to wait until lgwr returns
and notices that there is now a queue and does
a piggyback write.
Consequently, it is possible on a highly concurrent
system for log file sync to have far more WAITS
then log file write, and therefore look a much bigger
problem than it really is.
However, in your case, the number of log file sync
WAITS is about the same as the number of log file write
WAITS - so the fact that the TIME is five times as long
suggests that concurrency of waits is not the issue, and
you may have a proper problem.
I suspect that the problem is the number of processes
running on your system. Session A issues a log file sync,
and goes off the run queue; some time later, lgwr gets the
message and writes and posts session A to allow it to go
back on the run queue. Session A sits on the run queue
for ages, and finally becomes runnable. Solution -
look at MTS, or get more CPUs on the box.
But having said that - do check if any sessions are
actually noticing a significant loss of time due to
log file sync before worry about it.
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
Coming soon a new one-day tutorial:
Cost Based Optimisation
(see http://www.jlcomp.demon.co.uk/tutorial.html )
Next Seminar dates:
(see http://www.jlcomp.demon.co.uk/seminar.html )
____England______January 21/23
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
-----Original Message-----
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Date: 02 January 2003 07:48
>
>What ALL may be Done to Address the Following ?
>Any /etc/system , init.ora parameter Changes too ?
>Moving the Online Redo Logfiles onto RAID 1 NOT possible as that may
warrant Additional Hardware . Moreover T3+ does NOT Support RAID 1
(Only RAID 1+ )
>
>
>Concurrent Oracle processes = 1500 Approx.
>Statspack Taken during Mostly OLTP Operations :-
>
>Top 5 Wait Events
>~~~~~~~~~~~~~~~~~ Wait
% Total
>Event Waits Time (cs)
Wt Time
>-------------------------------------------- ------------ -----------
- -------
>log file sync 970,563
2,597,831 57.46
>log file parallel write 831,141
484,948 10.73
>
>log_buffer = 2MB
>Online Redo Logfiles Exist on RAID 1+
>Storage Box is T3+
>File System = UFS
>
>Application = Banking (Hybrid )
>Oracle 8.1.7.4
>Solaris 8
>Machine Box = SF6800
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jonathan Lewis
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
