Wait events for Oracle RAC include the following categories:
1.Block-Related Wait Events
2.Message-Related Wait Events
3.Contention-Related Wait Events
4.Load-Related Wait Events
Block-Related Wait Events
The main wait events for block-related waits are:
gc current block 2-way
gc current block 3-way
gc cr block 2-way
gc cr block 3-way
*******************
在node1的cache里面沒有找到需要的數(shù)據(jù),于是出現(xiàn)了跨node的 fusion cache 從node2 的Cache中得到數(shù)據(jù)。
在gc current block 2-way or gc current block 3-way等待事件上的過多等待,通常要么是由于(a)一種低效的執(zhí)行計(jì)劃,導(dǎo)致了大量的塊訪問,
或者(b)應(yīng)用數(shù)據(jù)相似度(應(yīng)用親和力)沒有被實(shí)施。如果對(duì)象訪問本地化,考慮實(shí)施應(yīng)用親和力(應(yīng)用數(shù)據(jù)的相似度)。
*********************
The block-related 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.
If the average wait times are acceptable and no interconnect or load issues can be diagnosed, then the accumulated time waited can usually be attributed to a few SQL statements which need to be tuned to minimize the number of blocks accessed.
The column CLUSTER_WAIT_TIME in V$SQLAREA represents the wait time incurred by individual SQL statements for global cache events and will identify the SQL which may need to be tuned.
Message-Related Wait Events
The main wait events for message-related waits are:
gc current grant 2-way
gc cr grant 2-way
*********************
如果被請(qǐng)求的塊沒有駐留在任何緩沖區(qū)中,需要請(qǐng)求master讀取物理磁盤上的數(shù)據(jù),出現(xiàn)物理讀寫。就會(huì)遭遇gc cr grant 2-way 和 gc current grant 2-way等待事件。
*********************
The message-related 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).
Contention-Related Wait Events
The main wait events for contention-related waits are:
gc current block busy
gc cr block busy
gc buffer busy acquire/release
******************
一般是并發(fā)的讀寫,各個(gè)session 中間出現(xiàn)資源競(jìng)爭(zhēng),需要等其他session 把修改的數(shù)據(jù)寫入redo log,才會(huì)把控制權(quán)返回給其他session。如果一個(gè)競(jìng)爭(zhēng)沒有結(jié)束,再有其他的競(jìng)爭(zhēng)增加,會(huì)出現(xiàn)雪崩的效應(yīng),系統(tǒng)性能急劇下降。
繁忙事件(Busy events)表明,LMS執(zhí)行了額外的工作去處理并發(fā)相關(guān)的問題。
******************
The contention-related 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.
Load-Related Wait Events
The main wait events for load-related waits are:
gc current block congested
gc cr block congested
***************
如果LMS進(jìn)程在接收到請(qǐng)求后沒有在1毫秒內(nèi)處理該請(qǐng)求,那么LMS進(jìn)程標(biāo)記這個(gè)響應(yīng)為:該塊正遭遇擁堵相關(guān)的等待事件。
堵塞相關(guān)的等待事件有很多原因,比如說,LMS進(jìn)程被大量全局高速緩存的請(qǐng)求所淹沒。LMS進(jìn)程正遭遇CPU的調(diào)度延遲,LMS進(jìn)程已經(jīng)遇到了另一種資源耗盡(如內(nèi)存)等。
通常情況下,LMS進(jìn)程運(yùn)行在實(shí)時(shí)CPU調(diào)度優(yōu)先級(jí),因此,CPU調(diào)度的延遲將是最小的。大量這類的等待此事件表明出現(xiàn)了全局緩存請(qǐng)求的突然飆升,且LMS進(jìn)程無法快速處理這些請(qǐng)求。
服務(wù)器內(nèi)存匱乏也可能導(dǎo)致LMS進(jìn)程的分頁(yè),影響全局緩存的性能。
您可以去檢查為什么LMS進(jìn)程不能夠有效地處理請(qǐng)求。
就是硬件不足需要增加硬件資源,最常見的只增加node。也可以考慮升級(jí)硬件。
**************
The load-related 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.
文章名稱:RAC相關(guān)的等待及原因
網(wǎng)頁(yè)路徑:
http://weahome.cn/article/pchcjs.html