global cache cr request/gc current request
The session is waiting for all pending lock operations on the lock elements (le) attached to a lock context to complete. The session sits in a loop until all requests are complete, and this wait event is effectively a poll interval while waiting.
The event is waited for when a session is looking for a consistent read version of a block but cannot find it in its local cache. The wait implies that the current block is not cached locally. The wait ends when either a block or a grant arrives for all queued requests. Depending on whether the remote instance has the block cached or not, the requesting instance receives:
A CR block, resulting in the statistic "global cache cr block received" being incremented
A grant, resulting in the statistic "global cache gets" being incremented
A current block, resulting in the statistic "global cache current blocks received" being incremented.
In the second case, the global cache cr request wait completion is followed by a read I/O because a current block version must be read from disk. An example of this is a global cache CR request wait followed by a "db file sequential read" wait for the same block (P1 and P2 are the same) . If a remote instance has a CR version or a CURRENT version, it will in most cases ship the block. If the block is not cached anywhere else, the requestor will read the block from disk.
Parameters:
P1 = file#
P2 = block#
P3 = lenum
Reducing Waits / Wait times:
The average wait time for this event should be low because a CR request should not be blocked and therefore be bounded only by processing time and network latencies. In the event of high wait times and user response time complaints, the actions to be taken are:
Identify the session and SQL causing the CR requests and tune the SQL
Determine whether the cause is a small buffer cache by monitoring I/O rates on files and objects
Monitor statistics in <> to determine whether there are many CR reads of undo segment and/or violations of the lightweight rule (remote instances cannot produce a CR buffer because too much work is involved, such as reading data or undo from disk).
Distribute a workload more evenly to achieve better locality of access
Set the fairness threshold to 1 if blocks are more often read than modified
The session is waiting for all pending lock operations on the lock elements (le) attached to a lock context to complete. The session sits in a loop until all requests are complete, and this wait event is effectively a poll interval while waiting.
The event is waited for when a session is looking for a consistent read version of a block but cannot find it in its local cache. The wait implies that the current block is not cached locally. The wait ends when either a block or a grant arrives for all queued requests. Depending on whether the remote instance has the block cached or not, the requesting instance receives:
A CR block, resulting in the statistic "global cache cr block received" being incremented
A grant, resulting in the statistic "global cache gets" being incremented
A current block, resulting in the statistic "global cache current blocks received" being incremented.
In the second case, the global cache cr request wait completion is followed by a read I/O because a current block version must be read from disk. An example of this is a global cache CR request wait followed by a "db file sequential read" wait for the same block (P1 and P2 are the same) . If a remote instance has a CR version or a CURRENT version, it will in most cases ship the block. If the block is not cached anywhere else, the requestor will read the block from disk.
Parameters:
P1 = file#
P2 = block#
P3 = lenum
Reducing Waits / Wait times:
The average wait time for this event should be low because a CR request should not be blocked and therefore be bounded only by processing time and network latencies. In the event of high wait times and user response time complaints, the actions to be taken are:
Identify the session and SQL causing the CR requests and tune the SQL
Determine whether the cause is a small buffer cache by monitoring I/O rates on files and objects
Monitor statistics in <> to determine whether there are many CR reads of undo segment and/or violations of the lightweight rule (remote instances cannot produce a CR buffer because too much work is involved, such as reading data or undo from disk).
Distribute a workload more evenly to achieve better locality of access
Set the fairness threshold to 1 if blocks are more often read than modified
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15747463/viewspace-1068658/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/15747463/viewspace-1068658/
1004
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
