本文為墨天輪數據庫管理服務團隊第152期技術分享，內容原創，作者為技術顧問肖傑，如需轉載請聯繫小墨（VX：modb666）並註明來源。如需查看更多文章可關注【墨天輪】公眾號。

故障概述

客户一Oracle數據庫發生出現大量gc cr multi block request,gc buffer busy acquire,read by other session 等等與物理讀相關的等待，CPU使用率接近100%，相關業務受到嚴重影響。

故障分析過程

等待事件：

從截圖部分可以看到，發生等待事件的sql主要是dmu51gr65qnqj,gr2cn8vcx7z8n,而此類等待事件均與物理讀相關，初步懷疑SQL執行計劃發生了變化，導致了大表全掃描，繼續分析這兩個sql的歷史執行計劃：

可以看到這兩個sql的執行計劃均在8點發生了執行計劃變化，繼續分析執行計劃變更的原因：

發現其中存在ROLL\_INVALID\_MISMATCH的原因，説明在晚上8點前5個小時內（oracle為了防止硬解析風暴，統計信息收集完畢之後並不會立即對SQL執行計劃進行失效，而是在18000s即5個小時之內陸續失效）個某個時間統計信息發生了變化，同時開發人員反饋，將SQL中的L\_HOT表去除之後SQL執行速度很快，説明問題可能出現在L\_HOT這張表上面，同時對此表進行select 以及select count()操作都非常慢甚至無法查出，接下通過對此表的統計信息分析：

發現num\_rows=56和blocks=27731594是嚴重不匹配的，説明此表高水位情況非常嚴重，曾經經歷過大量的delete，繼續分析此表的delete情況：

可以看到此表的delete次數達到了2億多次，確認此表是因為大量的delete導致了高水位，但是客户繼續反饋以前沒有出現過這樣的情況，並且這些delete操作都是很久之前的，那接下來繼續查看此錶的歷史統計信息情況：

可以看到此表是從10.3日開始收集統計信息，11月6日下午7.11才收集完畢，這個時間正好在故障前的5個小時內，同時在這之前，表中的row\_nums是1472022，由於數據量比較大，oracle選擇了走索引，但是統計信息收集完之後僅有56行數據，所以oracle選擇了走全表：

由於高水位的存在，雖然只有56行數據，但是全表掃描還是需要掃描高水位下面的所有block，所以導致了SQL產生了大量的物理讀，短時間內物理讀達到了800g左右，從而產生了大量的物理讀相關的等待事件，消耗了大量的CPU：

故障結論

L\_HOT表因為歷史存在大量的delete，所以導致了嚴重的高水位，同時統計信息收集持續了一個多月，正好在今天收集完畢，從而導致SQL執行計劃發生了變化，短時間的物理IO達到了800多G，CPU使用率接近100%。

故障處理建議

清理L\_HOT表的高水位，清理方式：

1、expdp->impdp到臨時表->rename表名

2、shrink space

3、move table

墨天輪從樂知樂享的數據庫技術社區蓄勢出發，全面升級，提供多類型數據庫管理服務。墨天輪數據庫管理服務旨在為用户構建信賴可託付的數據庫環境，併為數據庫廠商提供中立的生態支持。
墨天輪數據庫服務官網：https://www.modb.pro/service