一次數據庫性能問題的調試

2024-07-21 02:38:11

字體：大中小

來源：轉載

供稿：網友

　　基本情況：
　　
　　系統是一個基于web的業務系統，以online查詢為主，數據更新以批量為主，晚上執行。應該說系統還不算負載太大。5-1之后上班的時候客戶反映很慢，察看DB的cpu慢慢長到100%狀態。服務基本處于不可用狀態。i/o wait也挺高的。
　　經檢查，前些天的批量竟然有達到20多小時才完成，導致次日批量都跑不起來。
　　
　　打開statspack收集信息
　　
　　從系統中發現本應該夜間執行的批量作業還在運行。停掉后，rollback做了4個小時！（因為一個transaction中只有一個復雜的、數據量巨大的insert語句）
　　
　　然后做statspack分析，
　　
　　系統中存在問題：等待事件較嚴重，緩存命中率較低，
　　
　　語句分析：
　　
　　1、一些大量執行update/delete語句竟然沒有建立索引，其實可以建立pk，根據pk處理。
　　
　　where中使用常量（引起parse）
　　
　　2、存在大量這樣的語句：
　　
　　SELECT fieldx FROM Tablesname where trim（ServiceNUM） = 'DDDDDD' - 在ServiceNUM字段上是唯一索引，因為trim就不能使用index（敗筆） ——改！
　　- 使用常量查詢，造成每次查詢都要parse，沒有必要的占用的CPU —— 改！
　　
　　
　　3、在批量的存儲過程中，
　　
　　所有語句基本都是全表掃描！ —— 和開發人員溝通，需要修改邏輯。改進之后效果還是蠻大的。
　　
　　另外發現一個問題：
　　
　　客戶需要的是n百萬用戶數據中的活動用戶萬數據，他們卻全部把n百萬數據從其他系統中收集到自己的系統中，在批量的時候又使用full table scan，性能自然不會好。系統從剛開始設計的時候就存在隱患。這個問題就需要從長計議了。
　　
　　修改后，CPU高峰時間基本穩定在30-40%之間。
　　批量基本在2個小時內完成。
　　
　　其實是一個很簡單的系統，但是做到這種樣子，尤其是從設計到編碼都存在問題。

上一篇：Data Guard數據庫災難防護

下一篇：從調優強迫癥中恢復過來