Database Reference
In-Depth Information
If LMS database processes suffers from high gcs log flush sync wait event, then you would need to understand
why LGWR is not responding fast enough. In most cases, that would require a review of the output of script lfsdiag.sql
supplied by Oracle Support to understand the breakdown of the wait time suffered by LGWR process.
Defending LMS Process
As the performance of LMS process is quite essential, there are few features protecting LMS process overworking.
As I/O events usually exceed 5 ms, and since global cache latency is in the order of a few milliseconds, an I/O
event initiated by LMS process can induce longer latencies to the FG processes. So, LMS process does not initiate any
I/O calls at all. If LMS process has to initiate an I/O, for example, to read undo blocks required for CR fabrication as
those undo block may not be in the cache anymore, then LMS process will downgrade the lock on the BL resource and
send the buffer to the requestor. The requesting FG process will perform I/O calls and complete CR fabrication. This
feature is known as the “Light Works Rule.”
If a block is requested excessively, as detected by LMS process, then LMS process can downgrade the BL lock
and transfer the block to the remote FG process. For example, if a block is requested in CR mode aggressively, then
LMS process can downgrade the lock to a null mode and transfer the block to the FG process. This feature is known as
“Fairness Down Convert.”
An overworked LMS process can trigger delays in global cache transfer. These features protect LMS process from
working too hard due to an onslaught of excessive global cache requests. View gv$cr_block_server provide statistics
on these features.
GC Buffer Busy Acquire/Release
Wait events
gc buffer busy acquire
or
gc buffer busy release
are usually side effects of another root cause issue.
In a single-instance database, if a session
s1
is trying to read a block from the disk to the buffer cache, and if another
session s2 has issued a read call already for that block and has not completed the read call yet, then session s1 will
wait for the read call issued by session s2 to complete. Session s1 will account wait time to an event, namely,
read by
other session.
Additionally, subsequent sessions trying to read the same block, while the read call is still pending,
will wait and account time to
read by other session
event. Further, if a buffer is pinned by a session
s2
, then
another session
s1
trying to access the same buffer will wait for the
buffer busy wait
event.
In RAC, wait for
gc buffer busy
event is similar to single-instance counterparts
read by other session
and
buffer busy waits
. A wait for it indicates that there is a global cache operation pending on a buffer; subsequent
processes must wait for that global cache operation to complete before accessing the buffer. For example, process p1
may have requested a BL lock on the block, but GCS lock has not been completely acquired. So, another process p2
trying to access that buffer should wait for
gc buffer busy
event, essentially yielding to process p1 to complete
GC operation.
Rarely, gc buffer busy event itself is a root cause. Typically, it is a side effect of another problem. Here is an
example—in the AWR report section for instance 1 as follows, 10,382s was spent waiting for
gc buffer busy acquire
during an AWR period of 30 min, and the root cause, LGWR, was not able to complete log flushes quick enough in
instance 2. So, the LMS process in instance 2 was stuck waiting for LGWR to complete a log flush. Meanwhile, a few
processes requesting blocks in instance 1 are waiting on
gc cr request
or
gc current request
waits. Subsequent
processes accessing the same block are waiting for
gc buffer busy acquire
event, since a global cache request is
pending and the request was initiated from the local node.
