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中的enq: TS等待ENQ
- 11g rac 等待事件resmgr:cpu quantum事件
- oracle 11.2.0.4 rac叢集等待事件enq: TM - contentionOracle事件ENQ
- Solidity事件,等待事件Solid事件
- 【TUNE_ORACLE】等待事件之等待事件類別Oracle事件
- Selenium等待事件Waits事件AI
- Oracle 19c中的等待事件分類 Event WaitsOracle事件AI
- [20191125]探究等待事件的本源.txt事件
- latch等待事件彙總事件
- Latch free等待事件(轉)事件
- gc cr request等待事件GC事件
- 【等待事件】library cache pin事件
- 【等待事件】log file sync事件
- read by other session等待事件Session事件
- log file sync等待事件事件
- ORACLE 常見等待事件Oracle事件
- 【TUNE_ORACLE】等待事件之IO等待“direct path write”Oracle事件
- 【TUNE_ORACLE】等待事件之IO等待“read by other session”Oracle事件Session
- 【TUNE_ORACLE】等待事件之日誌等待“log file sync”Oracle事件
- 【TUNE_ORACLE】等待事件之IO等待“direct path read”Oracle事件
- Oracle常見UNDO等待事件Oracle事件
- LightDB/PostgreSQL等待事件 Lock transactionidSQL事件
- Cell smart table scan等待事件事件
- openGauss/MOGDB與PG等待事件事件
- Latch free等待事件二(轉)事件
- read by other session 等待事件分析Session事件
- 【等待事件】virtual circuit next request事件UI
- 【等待事件】standby query scn advance事件
- 【等待事件】db file sequential read事件
- 【等待事件】db file scattered read事件
- Latch free等待事件四(轉)事件
- Latch free等待事件三(轉)事件
- db file scattered read等待事件事件
- db file sequential read等待事件事件
- latch:library cache lock等待事件事件
- [20191126]探究等待事件的本源2.txt事件
- [20191127]探究等待事件的本源4.txt事件
- 基於等待事件的效能診斷(轉)事件
- 【TUNE_ORACLE】等待事件之日誌等待“log file parallel write”Oracle事件Parallel