Exadata X5-2 Hardware
 
Oracle Database - Standard Edition
 

PLA-Support>Database>DB Foundation>DB Admin>DB: Process Management
 

In this Document

Symptoms

Changes

Cause

Solution

References

Applies to:

Symptoms

The customer is reporting trace files being generated with the following message:

Changes

The problem surfaced after upgrading to 10.2.0.4.

Cause

The above warning messages has been introduced in 10.2.0.4 patchset.

The warning message will be generated most likely if the log write time is more than 500 ms and it will be written to the lgwr trace file. 

Solution

Download lfsdiag.sql from <note 1064487.1> and run it at bad time frame, then identify if "log file parallel write" is also slow.

In case "log file parallel write" wait time is also slow, then the warning is most likely caused by slow IO or OS resource starvation.

The original bug referenced here only showed the code where the endtime was determined
and then compared to the begintime.
However it never revealed where the begin time is recorded.
From looking at kcrfw.c one can see that the start time is just about when LGWR is posted
or wakes up from being idle.

Thus it covers writes to the local redo log groups (i.e. "log file parallel write" waits), writing to LNS for remote standbys in SYNC mode (e.g. some of the LNS wait events), sending messages to other RAC nodes (i.e. the broadcast on commit or BOC which is usually done asynchronously but will generate it's own "warning" message if it does have to wait and it also takes significant time), and finally it also covers time taken to wake up all the sessions waiting on "log file sync" or update the internals structures those sessions will read while doing polling (adaptive log file sync polling mode).
In 12.2 it becomes potentially more complex as now it includes the time LGWR takes to decide to divvy up the IO work across LGnn slaves if necessary and then waiting for those LGnn processes to respond with success or errors...
So the warnings may not strictly be IO related.
There also could be issues if LGWR (or LGnn) processes cannot get enough
CPU time or need to wait on the
OS if there is memory starvation and
a bunch of memory paging activity going on.
And even that can be more complex in Virtual Machine environments if
the whole VM has to be frozen so other VMs sharing
the same hardware can run while resources are tight.
Time will still appear to elapse to the VM without
the VM itself knowing why the time skipped forward...

So, probably you need to check if the disk is slow or not or for any potential OS causes.
If everything looks fine at the hardware level or OS level i.e if enviroment is unable to deliver a faster service because of its own nature,then you can ignore this message.then you can safely ignore these messages. The trace file can easily be deleted or truncated.

Also, according to <Bug:7559549> , these trace can be disabled by setting event 10468 level 4.

New hidden parameter in 11.2.0.2

The warning threshold can be configured via parameter "_long_log_write_warning_threshold"
The parameter exists in 11.2.0.2 and is referenced in bug 13244860.
For older versions, you may have to verify whether the parameter exists or not.

References

This solution has no attachment