Oracle技術支持是如何分析數據庫性能問題的 | Oracle官方博客轉載

　　?

　　編輯丨TeacherWhat

　　公眾號轉載自：Oracle官方博客 - 數據庫產品技術支持

　　題圖：Oracle Headquarter

　　作者：Dongwei Wang

　　原文鏈接：https://blogs.oracle.com/database4cn/oracle-v5

　　正文共2752字，建議閱讀時間5分鐘

　　調優是一個永恒的話題，貫穿于一個數據庫系統的完整生命周期。在這里我們主要關注的是作為技術支持我們是如何看待調優問題的，面向的對象主要是負責維護數據庫系統的DBA。這個話題國內外有很多的大牛們寫了很多很牛的書了，真的很好，我們中國的Oracle愛好者在這方面也有很多很好的經驗。但是，我們還是會遇到有人問如何分析數據庫的性能問題?萬變不離其中。下邊就簡單闡述一下作為Oracle技術支持是如何分析一個性能問題的。首先聲明，這個不是個人創造的，而是Oracle全球技術支持通用的一個方法論(聽起來是不是挺嚇人?)

　　有幾個概念先要說清楚。對于用戶而言，性能就是響應時間，也就是我發起一個操作，到這個操作完成的時間間隔。比如在12306買火車票，用戶只關心從我開始發起買票這個操作，到什么時候我買到了。但是從整個系統的角度看就不一樣了。一個三層架構的系統至少包含了客戶端，應用服務器，數據庫服務器。對于最終用戶而言，我只知道我點了確認鍵后等了10分鐘才跳轉到成功頁面，但是如果想要做優化，系統的維護者必須知道這10分鐘究竟是分別花在哪一個階段。一個典型的流程圖:

　　客戶端發起請求→應用服務器收到請求→應用用服務器發送請求→數據庫服務器收到請求→數據庫服務器處理請求→數據庫服務器返回請求→應用用服務器收到返回→客戶端收到返回

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

　　好了，如果不幸問題確認是發生在數據庫層(為什么總是我?!)，我們該怎么辦呢?從數據庫的角度，響應時間是這樣計算的:

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

　　還有一個我想強調的是，對于操作系統而言，Oracle也是一個應用程序。我們依然需要從操作系統上獲得CPU，內存這樣的資源。如果操作系統有性能問題了的話，所有運行在上邊的應用程序都將出問題，Oracle也不例外。當然，你可能會說我這個服務器就是數據庫服務器，上邊只運行了Oracle，但你能保證沒有人用這個服務器下載復制電影導致帶寬和I/O耗盡嗎?這個真的是可能的。

　　下邊要說說我們是怎么分析數據庫性能問題的了。

　　+ 問題描述。我一直以為性能問題比有錯誤或告警報出的問題更難解決，其中一個原因就是有錯誤的問題描述很簡單，比如我運行了一條SQL，返回了942錯誤。性能問題的一個難點就是到底什么是問題，好多人都只會說”我的數據庫慢“或者”我的應用沒有響應“，從我上邊畫的流程圖你就能知道這樣的描述真的是沒有意義的，那么什么樣的描述是好的呢?

　　- 用戶看到的現象是什么樣的?所有的應用都慢，還是某一條特定的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 - 最佳實踐:主動避免數據庫和查詢相關的性能問題。

　　相關閱讀

　　?數據庫性能問題分析和診斷方法概論

　　?數據庫的“黑匣子”--故障診斷日志基礎

　　?通過寄存服務來“理解”Oracle數據庫基本體系結構和動作流程

　　?在線Oracle SQL學習環境--Live SQL

　　?【怎么辦】004 如何找到刪庫跑路的人--監控數據庫用戶登錄