記一次對DM數據庫的優化過程

某年某月某日的一個下午，接收到監控服務器的一條告警短信：尊敬的運維工程師 XX，你好：「192.168.136.200」數據庫服務器 CPU 異常，CPU 使用率 98.7%，請儘快處理。看到這個消息渾身一緊，趕忙掐滅手中的煙，跑回辦公室。

以上段子純屬捏造，若有雷同，我反正是不改。

言歸正傳，本文是記錄一次對達夢數據庫的優化過程。

處理問題的第一步，是須要了解當前服務器的情況，咱們經過如下兩種手段確認服務器瓶頸。

系統情況

• 經過服務器性能監控大盤觀察當前系統性能
  
  經過上圖咱們看出 CPU 基本耗盡，IO 飆升。
• 經過 sar 命令觀察服務器實時狀態
  sar 10 3
  
  確認 CPU 被耗滿，沒有空閒。

經過個人細緻觀察，發現服務器 CPU 被耗滿。接下來須要查看數據庫服務器的配置參數是否合理，是否有慢查詢腳本。

參數優化

• 查看 dm 配置文件
  cd /dm7/dmdbms/devdb cat dm.ini | grep -E "MEMORY_POOL|MEMORY_TARGET|BUFFER"
  
  發現數據庫參數配置爲安裝時候的默認配置，參數不合理，須要優化參數配置。
• 備份原配置文件
  cp dm.ini dm.ini.bak
• 修改配置
  修改以下幾個關鍵參數，根據以前文章數據庫優化-實例優化中的表格進行優化（ps：當前數據庫內存 2G）

參數	優化建議	優化後的值，單位 M
MEMORY_POOL	建議爲內存的 90%	1800
MEMORY_TARGET	建議爲內存的 90%	1800
BUFFER	建議爲內存的 60%	1200
MAX_BUFFER	建議爲內存的 70%	1400
MAX_SESSIONS		1000

• 重啓數據庫服務
  service DmServerdm restart

參數優化後咱們嘗試找出當前數據庫存在的慢查詢 SQL，看看是否能夠優化。

慢 SQL 優化

達夢數據庫不像 MySQL 能夠直接將慢查詢存放在指定位置，達夢須要經過 AWR 報告中找出慢查詢。(AWR 報告你們自行百度)
啓用 DM 快照須要調用 DBMSWORKLOADREPOSITORY 包。

• 使用 DBA 帳戶登陸數據庫
  disql SYSDBA/password
• 建立 DBMSWORKLOADREPOSITORY 系統包，開啓 AWR 快照功能。
  SP_INIT_AWR_SYS(1);
• 啓用狀態檢測。
  SELECT SF_CHECK_AWR_SYS;
• 設置 AWR 快照間隔時間（30 分鐘）
  CALL DBMS_WORKLOAD_REPOSITORY.AWR_SET_INTERVAL(30);
• 手動建立快照：
  DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();
  這裏咱們能夠間隔幾分鐘多執行幾遍建立幾個不一樣的快照。
• 查看建立的快照信息，包括快照 id：
  SELECT * FROM SYS.WRM$_SNAPSHOT;
  
• 查看 AWR 報告內容
  SELECT * FROM TABLE (DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(1,2));
  查看 snapshot 的 id 在 1~2 範圍內的 AWR 分析報告的帶 html 格式的內容。
  
  這個內容格式基本沒辦法看，咱們須要將其轉化成 html 頁面查看。
• 生成 HTML 文件(須要先對 awr 文件夾受權)

chmod 777 /awr
  SYS.AWR_REPORT_HTML(1,2,'/awr','awr1.html');複製代碼

• 經過 AWR 報告找出慢 SQL
  
  SQL Ordered by Elapsed Time 的內容就是慢查詢語句。
  在拿到慢查詢語句後咱們須要聯繫開發人員修改查詢語句，此次優化過程當中我經過給相關字段添加索引，改寫一部分 SQL 完成。

可是**數據表自己設計不合理**這個沒有優化，因爲設計不合理致使查詢沒辦法走索引；而有些查詢則須要從業務角度進行優化，好比是否有必要對大表進行全表查詢而後再排序？等等等等。。。（至於數據庫 SQL 優化的具體策略咱們下期再聊）複製代碼

在完成優化後重啓應用，再次經過sar 10 3觀察 CPU 性能，較優化前仍是有很多的提高的，又能夠抽空去抽根菸了。

獲取更多內容請關注公衆號：JAVA日知錄