When a user session COMMITs (or rolls back), the sessions redo information needs to be flushed to the redo log file. The user session will post the LGWR to write all redo required from the log buffer to the redo log file. When the LGWR has finished it will post the user session. The user session waits on this wait event while waiting for LGWR to post it back to confirm all redo changes are safely on disk.
The rest of the information in this section is only valid for this metric when it appears in either the Enterprise Manager Grid Control or the Enterprise Manager Database Control (if applicable).
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
|
Target Version |
Evaluation and Collection Frequency |
Upload Frequency |
Operator |
Default Warning Threshold |
Default Critical Threshold |
Consecutive Number of Occurrences Preceding Notification |
Alert Text |
|
pre-10g |
Every Minute |
After Every Sample |
> |
30 |
Not Defined |
5 |
%value%%% of service time is spent waiting on the 'log file sync' event. |
(DeltaLogFileSyncTime/DeltaServiceTime)*100 where:
DeltaLogFileSyncTime: difference of 'sum of time waited for sessions of foreground processes on the 'log file sync' event' between sample end and start
DeltaServiceTime: difference of 'sum of time waited for sessions of foreground processes on events not in IdleEvents + sum of 'CPU used when call started' for sessions of foreground processes' between sample end and start
See Idle Events
There are 3 main things you can do to help reduce waits on "log file sync":
Tune LGWR to get good throughput to disk.
Do not put redo logs on RAID 5.
Place log files on dedicated disks.
Consider putting log files on striped disks.
If there are lots of short duration transactions, see if it is possible to BATCH transactions together so there are fewer distinct COMMIT operations. Each commit has to have it confirmed that the relevant REDO is on disk. Although commits can be piggybacked by Oracle, reducing the overall number of commits by batching transactions can have a very beneficial effect.
Determine whether any activity can safely be done with NOLOGGING / UNRECOVERABLE options.
Related Topics
About Alerts
About the Metric Detail Page
Editing Thresholds
Understanding Line Charts
Copyright © 1996, 2009, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.