When a session requests access to a data block in CR/CUR ( Consistent Read / Current) mode , it sends a request to the lock master for proper authorization. However , whether it will receive the block via the cache fusion mechanism or a permission to read from the disk is not known until the request is satisfied. Two placeholder events – “gc cr request” and “gc current request” - keep track of the time a session spends in this state.
For example, in a two node cluster when a session sends a request for CR block, its wait time is counted against “gc cr request”. Let’s assume that the lockmaster grants the lock to the requestor, there by authorizing it to read the lock from the disk so all the wait time is now logged against the wait event “ gc cr grant 2 –way”. Similarly, the wait time would be logged against “gc cr block 2-way” if the requesting instance received the CR copy of the block from the master.
The cluster wait events belong to one of the following categories
1) Block Oriented waits
2) Message – Oriented waits
3) Contention Oriented waits
4) Load Oriented waits
No comments:
Post a Comment