在 Oracle 數(shù)據(jù)庫中,經(jīng)??梢砸姷揭粋€特殊的等待事件:Sync ASM rebalance 。
西林網(wǎng)站制作公司哪家好,找成都創(chuàng)新互聯(lián)!從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項目制作,到程序開發(fā),運營維護。成都創(chuàng)新互聯(lián)2013年至今到現(xiàn)在10年的時間,我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗,來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)。
這個等待事件的基本含義是:在集群中,通過同步 ASM 的重平衡變化,以使得 ASM 的變更在集群之間可以保持一致。
這個事件來自于 11g 中的增強,在 10g 中,以下 BUG 揭示,當 ASM Rebalance 信息未能在全局同步引發(fā)的問題:
Bug 4430246 ASM Disk expel (after a rebalance) is not synchronous cluster-wide
然而在 Oracle 12.2 和 18c 中,這個事件的出現(xiàn),一些情形和磁盤的 Rebalance 無關(guān),而是由于某些BUG引起的,例如:
針對這些情況,官方提供的臨時解決方案是:
alter system set “_use_cached_asm_free_space”=TRUE scope=spfile;
當您遇到這種情形,請和您的技術(shù)支持伙伴聯(lián)系。
以下是一個 Sync ASM rebalance 等待事件占比最高的 AWR 實例:
Event Waits Total Wait Time (sec) Avg Wait % DB time Wait Class Sync ASM rebalance 10,997 470.3 42.77ms 20.6 Other log file sync 5,503 172.3 31.31ms 7.6 Commit control file sequential read 43,966 114.1 2.60ms 5.0 System I/O enq: IV - contention 95,614 72.1 753.93us 3.2 Other
以上內(nèi)容,僅供參考。
更多Oracle案例解析請戳: https://www.modb.pro/u/368?cyn