metalink 上對"global cache cr request"的wait event發生原因的描述如下:
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.