RAC中的等待事件
■ 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.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7728585/viewspace-691077/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- RAC 資料庫中的'log file sync' 等待事件資料庫事件
- RAC全域性等待事件分析事件
- 【RAC】RAC 效能分析 - 'log file sync' 等待事件事件
- ORACLE中的等待事件Oracle事件
- RAC中的enq: TS等待ENQ
- statspack中報告中的等待事件事件
- 11g rac 等待事件resmgr:cpu quantum事件
- 10g中的transaction等待事件事件
- 【等待事件】ORACLE常見等待事件事件Oracle
- 【等待事件】等待事件系列(5.1)--Enqueue(佇列等待)事件ENQ佇列
- 【效能調整】等待事件(十) 10g中的latch等待事件
- Oracle的等待事件Oracle事件
- 等待事件事件
- oracle 11.2.0.4 rac叢集等待事件enq: TM - contentionOracle事件ENQ
- 等待事件在10G中的加強事件
- 網路上的等待事件事件
- 【TUNE_ORACLE】等待事件之等待事件類別Oracle事件
- 【等待事件之二】log 相關的等待事件
- 等待事件分析事件
- oracle等待事件Oracle事件
- Oracle 等待事件Oracle事件
- px等待事件事件
- 等待事件 二事件
- oracle 11.1.0.6 版本中的resmgr:cpu quantum 等待事件Oracle事件
- 等待事件在10G中的加強(二)事件
- 【等待事件】等待事件系列(1)--User I/O型別事件型別
- 【效能調整】等待事件(三) 常見等待事件(一)事件
- 【效能調整】等待事件(四) 常見等待事件(二)事件
- Oracle等待事件的種類Oracle事件
- 兩個重要的等待事件!事件
- 常見的oraclet等待事件Oracle事件
- Oracle 常見的等待事件Oracle事件
- Oracle Mutex 等待事件OracleMutex事件
- 等待事件指令碼事件指令碼
- oracle等待事件一Oracle事件
- ASH, AWR , 等待事件事件
- latch free等待事件事件
- 【Oracle概念】-等待事件Oracle事件