High Water Mark過高導致cache buffer chain等待嚴重

一、問題現象
資料庫wait event顯示latch free(cache buffer chains)等待嚴重，伺服器CPU使用率持續達100%，資料庫應用普遍出現效能問題。

二、原因分析
某分割槽表的其中一個分割槽只有4行記錄，但其data blocks數目卻與其他有著百萬行記錄的分割槽相當，資料高水位HWM（High Water Mark）較高（insert了大量資料，
後來又delete，導致HWM升高），導致每次訪問該分割槽時的buffer gets較高，約幾萬次buffer gets。
有一些sql語句在nest loop最裡層訪問到該分割槽，nest loop幾千次，多條sql併發，導致資料庫熱塊競爭嚴重：latch free(cache buffer chains) ，
同時因sql的buffer gets高成本導致CPU 使用率100%。

三、解決方法

（1）臨時緩解方法：在HWM問題解決之前，應用禁止問題sql再次執行，Kill當前running的問題sql程式。
（2）根本解決方法：降低分割槽的HWM，維護後sql執行時間從小時級下降到秒級。關於降低HWM的方法，
例如可以採用下面的步驟：
備份資料，truncate問題分割槽，恢復資料；需留意truncate分割槽動作會導致該分割槽表上的global index狀態變成unusable（local index狀態不受影響），
DBA還需要對global index進行rebuild，或者在truncate的同時指定update global indexes選項。如需保留統計資訊，可以先提前備份，操作完成後再將其匯入。

Partly command examples:
alter table odsmiddata.mid_policy_info truncate partition part0;
alter index odsmiddata.mid_policy_info_pk tablespace odsmiddata_idx rebuild parallel 6;
alter index odsmiddata.mid_policy_info_pk noparallel;

High Water Mark過高導致cache buffer chain等待嚴重

相關文章