分析數據庫的問題，需要手頭有足夠的數據來做支撐。不過很多朋友不知道什么情況下需要什么樣的數據來做分析，也有些朋友手頭有不少數據，但是不知道該如何去分析。
今天我用一個前幾天一個微信群里大家討論的案例來做個分析，因為當時正好在參加一個活動，因此有一搭沒一搭的看群里大家在聊這個CASE，具體需要分析什么問題不太清楚，不過這個案例的數據還挺有代表性的。
這是一個Oracle的例子，分析依據是兩份awr報告，簡單的從awr報告入手，可能看不出特別明顯的問題。此類案例普遍存在，分析起來其實不難，不過如果不掌握方法，就不知道該如何入手了。另外，如果我們要分析其他數據庫，可能沒有Oracle這么強大的AWR數據，能夠獲得的數據與這個案例差不多，因此這個案例的分析思路對于分析國產數據庫也有一定的參考價值。
如果有朋友缺乏用于國產或者開源數據庫分析的數據和工具，老白在這里做個廣告。可以到“DBAIOPS社區”下載一份D-SMART社區版，1元錢激活，就可以用來監控與分析你的數據庫了。D-SMART能夠以2-3分鐘的頻率采集數據庫的各種指標，每種數據庫都會有數百個到上千個指標可供分析，目前對MySQL/PG/達夢/人大金倉/瀚高/海量/openGauss等數據庫的支持還是不錯的。近期還將推出支持OceanBase/GaussDB等分布式數據庫的專版。
因為我前幾天沒有仔細看群里的討論，因此不知道用戶到底出了什么問題，只能根據數據來進行分析。從DB TIME這個指標上，我看到兩個AWR報告中存在明顯的不同。從上面可以看出，8-9點的DB TIME明顯要高于5-6點的。不過這種比較一般來說也不大有代表性，因為8-9點可能業務負載要遠高于5-6點。分析一個數據庫是否存在問題，DB TIME是一個十分重要的分析元素，目前絕大多數國產數據庫和開源數據庫中也都有這個指標。DB TIME與持續時間的比值，對于本案例來說就是每分鐘DB TIME這個指標是有對比價值的，當日如果采樣時間是相同的，直接比較這個值就可以了。日常做數據庫運維的時候可以關注這個指標，通過這個指標雖然不能定位數據庫的問題在哪，不過可以大體判斷數據庫是否存在異常。
如果數據庫支持等待事件，通過等待事件可以對數據庫在宏觀上是否存在問題做一個初步的判斷。看上面的案例，8-9點的TOP EVENT中的等待事件，似乎沒有明顯的宏觀問題。DB CPU排在第一位是大多數系統的常態，因為系統中一般都會存在一些CPU開銷較大的SQL。單塊讀平均響應時間6毫秒，占比16.11%，不知道存儲是什么，如果中低端存儲這個指標也還可以，如果是高端存儲，那么就偏低了。在看TOP EVENTS的時候，我們要注意，11.2.0.3只列出TOP 5，這對于發現系統中存在的問題不一定有效。在這個案例中第五位的等待事件只占1.63,說明其他的等待事件已經對數據庫的影響不大了。雖然如此，查看完整的前臺進程和后臺進程的等待事件的完整數據還是十分必要的。
在這個案例中，和負載略低時的指標相比較，就一眼可以看出問題了，這個案例里，出問題時段的單塊讀延時慢了1倍，這是一個明顯的疑點。在分析這個指標的時候，一定要看waits這個值，如果這個值很小，那么一倍的差異也不一定能說明問題，因為可能存在統計誤差。89萬和292萬次的等待，這種統計值相對來說還是靠譜的，因此這個問題可能真的存在。
除此之外，等待事件是十分正常的，在故障時間段里存在library cache:mutex x等待，不過占比2.46%，在這個案例中可以先作為次要因素來看待。
接下來我們需要看看負載數據，對于Oracle AWR來說，Load Profile是能夠完全反映出負載的。其他數據庫也存在類似的負載數據。
比如上面是D-SMART采集的部分PG數據庫的負載數據。上面的AWR數據中，可以看出數據庫的負載并不算高，物理讀每秒大約50M左右，每秒執行數不到3000，硬解析10個。疑點是每秒20個的logon，5-6點的報告中，這個指標是1.3，不過8-9點很可能是大量用戶正在登錄的時候。因為對整個項目背景不了解，因此不清楚這么多LOGON是否是正常的。
CPU上看，CPU資源還是出現了輕微的瓶頸的，這個服務器的配置不高，不知道是老的服務器還是虛擬機，總共4 socket 16核。
接下來可以看看等待事件的明細情況。從總體的情況來看，還是沒有太大問題的。Ksdxexeotherwait這個問題很可能是11.2.0.3的BUG導致，這也可能是引發共享池與CURSOR相關等待的主因，從上面的等待事件看，確實是這些指標存在一些問題。其他指標還算合理。Log file sync 7毫秒是有點高的，在5點的報告里是2毫秒。看一下后臺進程的log file parallel write指標是4毫秒，而5點時是2毫秒。從這些指標上看，業務高峰期，存儲的性能是存在一定的問題的。因為這份報告是不全的，因此我無法去通過數據文件IO去分析是否文件IO存在性能問題。同時通過分析TOP SEGMENTS的數據來查看哪些表或者索引上物理讀較高。
對于Oracle數據庫，如果發現數據庫層面的IO性能問題，是可以通過osw數據來進行驗證的，看看OS層面是否也存在IO性能問題，并判斷問題是出在OS本身還是后端存儲系統上。不過11.2.0.4以后的Oracle 才會在GI里自帶OSWBB，11.2.03里并沒有自動安裝，因此如果需要進一步分析IO的問題，需要安裝一個OSW。
在國產數據庫中，可能也沒有更多的數據可以供分析。這種情況下我們也不是束手無策的，可以通過TOP SQL來繼續分析。
因為從上面發現的問題CPU使用率較高、IO延時異常，所以在分析TOP SQL的時候我們重點要看CPU開銷較高的、物理讀、邏輯讀較高的SQL。同時執行時間較長的SQL也是值得我們去分析的。
如果能對某些關鍵SQL做趨勢分析或者比對分析，那么是很容易找到問題點的。不過AWR報告不具備這個能力。不過我們也可以通過執行效率存在差別的SQL的awrsqrpt報告來分析其中的差別。
比如我們看這個例子中的執行時間最長的這條SQL。平均執行時間2.98秒。一小時內執行了6566次。
在5-6點的報告中，執行次數198次，平均每次執行1.71秒，慢了1.2秒多。對比CPU消耗來看，在兩份報告中分別是1.58秒和1.42秒，從這個數據上看，執行計劃大概率沒有惡化。
在平均UIO上差得比CPU要高得多，倍率與單塊讀延時增加的倍率是同樣數量級的。因為數據的問題，今天無法更為深入的去解析這個問題。主要疑點是IO延時的問題和LOGON的問題。
不過如果我們面對的是國產數據庫，那么也有可能只有這些數據可以供我們分析。我們該如何來分析呢？首先從宏觀上分析，這個分析可以通過負載數據、主要緩沖池命中率、TOP 等待事件等方面來分析。就本案例而言，從總體上看，沒有特別明顯的問題，因此和相類似負載時段正常的指標數據進行比對就十分關鍵了。
比如對比IO延時指標時，如果能把負載類似時段的數據疊加在一起分析，那么就會有很好的參考。本案例中的對比分析數據并不太有代表性，不過也能從中發現了IO方面的延時變壞的問題。
如果從宏觀層面能夠發現的問題不多，那么就需要通過微觀層面去分析了。AWR報告特別適合宏觀層面的分析，如果問題很嚴重，成為系統的主要問題，那么很容易從AWR中發現問題。而如果AWR中看似較為正常，那么Oracle就提供了ASH工具，用于做微觀分析。目前也有部分國產數據庫，比如openGauss/Polardb等提供了類似ASH的工具，那么我們也可以通過ASH進行分析，發現潛在問題。
如果沒有ASH可以用于分析，那么TOP SQL分析可能就變成了唯一有效的工具了。因此我們需要對自己生產系統采集TOP SQL指標，并對SQL在某個時間段內的執行情況進行分析。比如針對同一條SQL語句，在邏輯讀、物理讀、執行數量、執行延時等維度進行時段對比分析，一般來說就能夠看出其中可能存在的問題了。
