Oracle技術支援是如何分析資料庫效能問題的

 我的同事有幸參加了今年在上海的Oracle Open World，交流中有使用者說我們中文的部落格中跟效能相關的文章太少了。我們一貫非常重視使用者的反饋，所以從現在開始我們會盡可能多的寫一些大家感興趣的話題。

    調優是一個永恆的話題，貫穿於一個資料庫系統的完整生命週期。在這裡我們主要關注的是作為技術支援我們是如何看待調優問題的，面向的物件主要是負責維護資料庫系統的DBA。這個話題國內外有很多的大牛們寫了很多很牛的書了，真的很好，我們中國的Oracle愛好者在這方面也有很多很好的經驗。但是，我們還是會遇到有人問如何分析資料庫的效能問題？萬變不離其中。下邊就簡單闡述一下作為Oracle技術支援是如何分析一個效能問題的。首先宣告，這個不是我創造的，而是Oracle全球技術支援通用的一個方法論（聽起來是不是挺嚇人？）

    有幾個概念先要說清楚。對於使用者而言，效能就是響應時間，也就是我發起一個操作，到這個操作完成的時間間隔。比如在12306買火車票，使用者只關心從我開始發起買票這個操作，到什麼時候我買到了。但是從整個系統的角度看就不一樣了。一個三層架構的系統至少包含了客戶端，應用伺服器，資料庫伺服器。對於終端使用者而言，我只知道我點了確認鍵後等了10分鐘才跳轉到成功頁面，但是如果想要做最佳化，系統的維護者必須知道這10分鐘究竟是分別花在哪一個階段。一個典型的流程圖：
      客戶端發起請求→應用伺服器收到請求→應用用伺服器傳送請求→資料庫伺服器收到請求→資料庫伺服器處理請求→資料庫伺服器返回請求→應用用伺服器收到返回→客戶端收到返回

      所以，這中間任何一個環節的緩慢都會造成這個請求響應的緩慢。實際上，我們還可以進一步深入分析，究竟是在某一個環節中間慢，還是兩個環節在互動的時候有延遲？舉個例子，如果大量的時間消耗在資料庫伺服器收到請求到資料庫伺服器返回請求，那麼這個就是資料庫這個環節的問題；但如果時間是消耗在資料庫伺服器返回請求到應用用伺服器收到返回，那麼就是兩個環節之間的問題了。好在現在每一層都有自己的日誌，透過客戶端的日誌我們能知道總共的響應時間，應用程式和資料庫伺服器的日誌能知道這兩層消耗的時間，加加減減就知道問題出在哪了。

      好了，如果不幸問題確認是發生在資料庫層（為什麼總是我？！），我們該怎麼辦呢？從資料庫的角度，響應時間是這樣計算的：
    響應時間=服務時間+等待時間

    服務時間其實就是我們通常說的CPU時間，等待時間就比如等待I/O，等待鎖等等。絕大部分時候我們都是期望響應時間要儘可能接近服務時間，因為那樣CPU才是真正在幹活的；等待時間是我們通常需要去減小的，因為這意味著請求在等待某些資源，而沒有幹活。降低響應時間實際就是降低服務和等待時間，或者說降低CPU時間，I/O或鎖等待。我們今天講的是一個大的方法論，以後有機會會繼續講一些特定場景的最佳化。

    還有一個我想強調的是，對於作業系統而言，Oracle也是一個應用程式。我們依然需要從作業系統上獲得CPU，記憶體這樣的資源。如果作業系統有效能問題了的話，所有執行在上邊的應用程式都將出問題，Oracle也不例外。當然，你可能會說我這個伺服器就是資料庫伺服器，上邊只執行了Oracle，但你能保證沒有人用這個伺服器下載複製電影導致頻寬和I/O耗盡嗎？這個真的是可能的。

    嘚啵嘚說了一堆，下邊真的要說說我們是怎麼分析資料庫效能問題的了。

      - 使用者看到的現象是什麼樣的？所有的應用都慢，還是某一條特定的SQL慢？
      - 問題發生的起止時間點？現象是自己消失的還是DBA手工干預了？DBA做了什麼操作？
      - 問題發生的頻率？很多效能問題都是有規律可循的。
      - 發生問題的時候有什麼特殊的操作？對一張表新增了一個列？
      - 應用程式的負載是否有變化？比如正好是早晨剛開門時的業務高峰期？
      - 是否最近做過什麼變更？比如上了一套新的應用？資料庫剛打了一個補丁？作業系統加CPU了？ 

    回答了這些問題，說不定你自己也找到問題的原因了。如果你不說，技術支援，尤其是遠端技術支援，是不會知道這個系統的背景的。多說一句，不光是使用Oracle技術支援要這樣，大家在論壇或社群問問題的時候也要遵循這個原則，含糊的問題只能得到含糊的回答。

    + 問題描述清楚了，下邊該我們技術支援來驗證問題到底是不是這樣的了。你可能又會說你就是不相信我們唄，親，真的不是這樣的。要知道如果一個問題的描述都是錯誤的話，之後的分析再怎麼正確也是徒勞的。我們要避免這種情況，就算它只有萬分之一的可能，因為它會極大的浪費我們的精力。那麼怎麼驗證呢？
      - 對於整個系統的效能問題，大家都知道AWR/ASH report，但其實你還要提供一份基線作對比。嗯，你可能會說如果我是新上的系統呢？好吧，我只能說我們盡力而為，因為調優無極限，你要是就是想拿能併發100個使用者的系統併發10000個使用者我也沒辦法。
      - 對於某條SQL語句的問題，大家都知道SQL_TRACE，同樣，我們要基線。一條從來都沒有快過的SQL可能真的需要應用程式開發者看看是不是真的要這麼寫了。 

    + 分析問題。基於自上而下的原則：
      - 作業系統的效能有沒有問題？給我看看OSWatcher的輸出唄（MOS文件1526578.1，中文的哦）
      - 整個資料庫的效能有沒有問題？AWR/ASH。對於整個資料庫的效能問題，我的原則是看有問題時消耗最多DB Time的是什麼型別，當然，這個是基於基線的，有的系統可能物理I/O永遠是佔用DB Time最多的部分，但不見得有問題。
      - 資料庫hang住了？hanganalyze和systemstate dump。我們有個工具叫HANGFG（MOS文件362094.1），你就不用手工輸入那些複雜的命令了。
      - 只是某條語句有問題？看看SQL_TRACE吧

    + 解決問題。一旦問題的原因定位到，找一個最合適的解決方法實施就好了。對於效能問題，調優有時是漸進的，你可能需要調調這，改改那，最後徹底解決問題。我理解大家做一次變更走流程很麻煩，我們也會盡可能儘量一次性將需要做的變更都找到，但真的不能百分百保證。

    綜上，分析一個資料庫效能問題，我們需要
      - 一個清晰準確的問題描述。
      - 足夠的診斷資訊，推薦MOS文件1549179.1 - 最佳實踐：針對效能問題的主動型資料收集，也是中文的。 

    當然，最好所有問題都消滅在萌芽中（技術支援不會失業吧。。），推薦MOS文件1549184.1 - 最佳實踐：主動避免資料庫和查詢相關的效能問題。

    好了，今天就和大家說這麼多。