■ Block-oriented
■ gc current block 2-way
■ gc current block 3-way
■ gc cr block 2-way
■ gc cr block 3-way
■ Message-oriented
■ gc current grant 2-way
■ gc cr grant 2-way
■ Contention-oriented
■ gc current block busy
■ gc cr block busy
■ gc buffer busy
■ Load-oriented
■ gc current block congested
■ gc cr block congested
The block-oriented wait event statistics indicate that a block was received as either the
result of a 2-way or a 3-way message, that is, the block was sent from either the
resource master requiring 1 message and 1 transfer, or was forwarded to a third node
from which it was sent, requiring 2 messages and 1 block transfer.
The gc current block busy and gc cr block busy wait events indicate that the remote
instance received the block after a remote instance processing delay. In most cases, this
is due to a log flush. The existence of these wait events does not necessarily
characterize high concurrency for the blocks. High concurrency is instead evidenced
by the existence of the gc buffer busy event. This event indicates that the block was
pinned or held up by a session on a remote instance. It can also indicate that a session
on the same instance has already requested the block, which in either case is in
transition between instances and the current session needs to wait behind it.
These events are usually the most frequent in the absence of block contention and the
length of the wait is determined by the time it takes on the physical network, the time
to process the request in the serving instances and the time it takes for the requesting
process to wake up after the block arrives.
The average wait time and the total wait time should be considered when being
alerted to performance issues where these particular waits have a high impact.
Usually, either interconnect or load issues or SQL execution against a large shared
working set can be found to be the root cause.
The message-oriented wait event statistics indicate that no block was received because
it was not cached in any instance. Instead a global grant was given, enabling the
requesting instance to read the block from disk or modify it.
If the time consumed by these events is high, then it may be assumed that the
frequently used SQL causes a lot of disk I/O (in the event of the cr grant) or that the
workload inserts a lot of data and needs to find and format new blocks frequently (in
the event of the current grant).
The contention-oriented wait event statistics indicate that a block was received which
was pinned by a session on another node, was deferred because a change had not yet
been flushed to disk or because of high concurrency, and therefore could not be
shipped immediately. A buffer may also be busy locally when a session has already
initiated a cache fusion operation and is waiting for its completion when another
session on the same node is trying to read or modify the same data. High service times
for blocks exchanged in the global cache may exacerbate the contention, which can be
caused by frequent concurrent read and write accesses to the same data.
The load-oriented wait events indicate that a delay in processing has occurred in the
GCS, which is usually caused by high load, CPU saturation and would have to be
solved by additional CPUs, load-balancing, off loading processing to different times or
a new cluster node.For the events mentioned, the wait time encompasses the entire
round trip from the time a session starts to wait after initiating a block request until the
block arrives.
■ gc current block 2-way
■ gc current block 3-way
■ gc cr block 2-way
■ gc cr block 3-way
■ Message-oriented
■ gc current grant 2-way
■ gc cr grant 2-way
■ Contention-oriented
■ gc current block busy
■ gc cr block busy
■ gc buffer busy
■ Load-oriented
■ gc current block congested
■ gc cr block congested
The block-oriented wait event statistics indicate that a block was received as either the
result of a 2-way or a 3-way message, that is, the block was sent from either the
resource master requiring 1 message and 1 transfer, or was forwarded to a third node
from which it was sent, requiring 2 messages and 1 block transfer.
The gc current block busy and gc cr block busy wait events indicate that the remote
instance received the block after a remote instance processing delay. In most cases, this
is due to a log flush. The existence of these wait events does not necessarily
characterize high concurrency for the blocks. High concurrency is instead evidenced
by the existence of the gc buffer busy event. This event indicates that the block was
pinned or held up by a session on a remote instance. It can also indicate that a session
on the same instance has already requested the block, which in either case is in
transition between instances and the current session needs to wait behind it.
These events are usually the most frequent in the absence of block contention and the
length of the wait is determined by the time it takes on the physical network, the time
to process the request in the serving instances and the time it takes for the requesting
process to wake up after the block arrives.
The average wait time and the total wait time should be considered when being
alerted to performance issues where these particular waits have a high impact.
Usually, either interconnect or load issues or SQL execution against a large shared
working set can be found to be the root cause.
The message-oriented wait event statistics indicate that no block was received because
it was not cached in any instance. Instead a global grant was given, enabling the
requesting instance to read the block from disk or modify it.
If the time consumed by these events is high, then it may be assumed that the
frequently used SQL causes a lot of disk I/O (in the event of the cr grant) or that the
workload inserts a lot of data and needs to find and format new blocks frequently (in
the event of the current grant).
The contention-oriented wait event statistics indicate that a block was received which
was pinned by a session on another node, was deferred because a change had not yet
been flushed to disk or because of high concurrency, and therefore could not be
shipped immediately. A buffer may also be busy locally when a session has already
initiated a cache fusion operation and is waiting for its completion when another
session on the same node is trying to read or modify the same data. High service times
for blocks exchanged in the global cache may exacerbate the contention, which can be
caused by frequent concurrent read and write accesses to the same data.
The load-oriented wait events indicate that a delay in processing has occurred in the
GCS, which is usually caused by high load, CPU saturation and would have to be
solved by additional CPUs, load-balancing, off loading processing to different times or
a new cluster node.For the events mentioned, the wait time encompasses the entire
round trip from the time a session starts to wait after initiating a block request until the
block arrives.
