?等待事件是數據庫十分重要的可觀測性接口，通過等待事件可以快速定位數據庫存在的問題，并及時掌握數據庫的運行狀態。二十年前的時候，我給一家銀行做服務的時候，他們要求核心系統監控，要求監控人員每隔五分鐘查看一次是否存在異常等待事件，從而確保核心業務的正常。

Oracle是首先提供等待事件接口的數據庫產品，而現在很多數據庫也都提供了等待事件接口，只不過提供的能力有些差別。國慶假期七天時間里，我每天看一點SQL SERVER的資料，首先發現微軟的文檔功力真的十分了得，看SQL SERVER的資料甚至比看Oracle的資料還要舒服。其次我也發現，SQL SERVER在等待事件接口方面也做的十分到位。

今天我就以Oracle、SQL SERVER、openGauss、Polardb四個數據庫為例，分析一下這些數據庫的等待事件接口的特點，以及如何使用這些接口來進行系統診斷。談起他數據庫之前，我們先來看看等待事件分析的鼻祖Oracle提供了哪些等待事件。我還是用Oracle 11g這個經典版本為例，雖然這個版本是十多年前推出的，不過在等待事件方面已經十分完善了。

實際上不管是現在的Oracle數據庫還是其他一些支持等待事件分析的數據庫，都已經和Oracle剛剛推出OWI的時候不同了，等待事件接口也豐富了很多。不過這些年里，我發現大家還在用20多年前OWI剛剛出現時的等待事件接口來分析數據庫系統，并沒有去使用在某些分析場景下更為有效的一些新的接口數據。這是一種慣性，就像十多年前，我還習慣于使用v$session_wait視圖去分析會話的等待事件，而不像一些年輕的DBA一樣使用v$session。V$session_wait是Oracle在7.3.2版本中就推出的一個等待事件接口的視圖，也是最經典的一個。不過這個視圖不是我們今天要討論的主角，因為目前數據庫系統的等待事件分析的數據接口已經極大豐富了。

我習慣于把等待事件接口數據分為明細數據、匯總數據、采樣數據以及這些數據的歷史數據。這些數據在不同的場景中能夠發揮不同的作用，用好了，可以滿足DBA的很多方面的分析工作。

明細數據是當前等待事件的實時狀態，對于做當前的實時分析是十分有價值的。如果故障問題一直存在，則分析當前的數據可以給我們一個直觀的反映。不過在使用v$session的時候，大家要注意一個問題，那就是Oracle的等待事件接口與其他數據庫有所不同。我們來看看有什么不同。

我們以往可能僅僅關注active狀態的會話，而很少去關注state，Oracle的v$session里顯示的等待事件不僅僅是顯示正在等待的，而且會顯示剛剛等待結束的，狀態。所以有時候我們看到的某個等待事件可能當時已經結束了，而不是正在發生，而有些則正在發生。注意到這個差別十分關鍵，可以幫助我們在細節上分析數據庫的等待事件。其他數據庫一旦結束某個等待事件，就會立即進入IDLE狀態，這樣在系統中，我們看到的更多的是IDLE。對等待事件相關視圖進行多次查詢，可能會有較大的差異。作為DBA，我更喜歡Oracle的這種輸出接口的方式。因為大多數情況下，我們不是需要了解準確的實時狀態，而是要了解在這個期間的一個大體趨勢，保留剛剛結束還沒有開始其他等待事件之前的狀態十分重要。

實際上明細數據更有助于分析當前的實時狀態，查找某個會話當時存在的問題，或者某些會話引發的某個問題。而要了解系統當期的等待事件的總體情況，從而發現系統存在的一些隱藏的很深的問題，往往需要統計數據。這也是DBA往往更容易從AWR報告中看到系統問題的所在，而不是通過v$session的主要原因。

在PG數據庫中pg_stat_activity提供了一部分會話等待事件的信息，不過缺少了等待時長。一些基于PG的開業或者國產數據庫里，也提供了這個視圖，同時還做了一些擴展。

依賴于PolarDB的polar_monitor/polar_monitor_reload這兩個插件，我們可以獲得很多的原生態PG數據庫所沒有的監控特性。其中最為重要的是，我們能夠獲得等待事件的等待時長的數據了。等待時長可以為運維分析提供更為準確的信息。這一點我前陣子發的幾篇關于openGauss的文章中也做了闡述。Polar_monitor插件為我們帶來了數個polar開頭的監控視圖。其中就有我們鎖期待的polar_stat_activity，這個和pg_stat_activity近似的監控接口有著我們需要的新數據。

SQL SERVER從2016（13.x）版本開始提供了一個dm_exec_session_wait_stats視圖，這個視圖可以提供類似v$session的數據接口。

Oracle實際上提供了十分豐富的等待事件統計信息，通過v$eventmetric，我們可以看到最近1分鐘的等待事件統計信息。

在這個系統接口里，我們可以看到每個等待事件在最近一分鐘內的等待次數，等待時間，等待的會話數量，以及前臺進程的等待次數與總時長數據。這些數據都十分有利于我們去分析某個等待事件在最近一分鐘發生的情況。

不過如果我們想了解等待事件在系統中的整體情況，v$eventmetric提供的信息是不夠的，我們還需要v$system_event的信息。

v$system_event提供了系統中按照等待事件類別的統計信息，這是一個從數據庫啟動以來的統計值。如果我們針對這個視圖的數據做定期采樣，那么就可以掌握系統中等待事件的總體情況。這個采樣數據可以用于任意時段的等待事件總體分析。

在openGauss和PolarDB中也提供了類似的統計數據接口。openGauss的dbe_perf.wait_events提供了和Oracle類似的統計數據，而且更為詳細。

因為openGauss不提供類似Oracle的histogram的信息，因此它提供了最大值，最小值這些統計值。雖然不如提供柱狀圖那么直觀，不過對于等待事件分析來說依然十分有價值。

SQL SERVER也提供了一個類似的統計數據接口dm_os_wait_stats。

可以看出，max_wait_time_ms這個字段也出現在了這里，觀察最大值對于分析等待事件來說十分關鍵。

上面兩種統計數據對于等待事件分析來說還不足夠，因為我們只掌握了平均值，如果在一個數十萬甚至數百萬的等待事件中，有幾千個是異常的，那么我們無法從平均等待時間發現這幾千個數據的異常。而v$event_histogram補上了這個缺陷。

通過柱狀圖，我們可以了解各種等待時長的等待事件的統計數據，從而發現在某個時段存在某個問題。這個接口也是一個從系統啟動來的統計值。不過我們通過LAST_UPDATE_TIME就可以分析出某個柱狀圖的數據在我們分析的時間段內是否被更新過。因此如果我們沒有定時采集這個數據，我們還是能夠看出一些端倪的。當然如果能夠實現對這個數據的定期采集肯定是有益的。AWR會定期采集這個數據并加以保存，不過其采集粒度過于粗了一點。

有些數據如果要完全保存歷史的明細數據是十分困難的，因此往往會采用采樣的方式。Oracle針對v$session這個十分重要的數據會做1秒鐘為單位的動態采樣。將活躍會話的全量采樣保存下來，openGauss、OceanBase等也做了類似的采樣。PolarDB在新版本中也將會提供類似的采樣。Oracle中，這個采樣可以通過v$active_session_history來訪問。不過大家要注意的是，既然是采樣數據，那么就會遺漏一些的，1秒鐘雖然是比較短的采樣周期，不過還是會漏掉一些等待事件。不過如果某個問題一直在發生，采樣中大概率會抓到這個等待事件。

除了Oracle數據庫外，openGauss率先提供了類似ASH的數據接口，Oceanbase和PolarDB也緊隨其后。我想今后越來越多的國產數據庫也會提供類似的接口。因為這個接口對于分析數據庫的問題，特別是性能問題，是十分關鍵的。

除此之外，歷史數據也是我們分析問題最常用的，因為我們經常要分析以前的某個時段數據庫存在的問題，而不僅僅是做當前分析。缺乏歷史事件積累，我們就無法進行分析了。借助于AWR等成熟的數據采樣機制，Oracle提供了多種歷史數據的保存機制。我們如果能夠加以充分利用，則可以幫助我們解決很多的問題。

與Oracle相比，國產、開業數據庫這方面的數據接口還是比較少，我想這也是今后國產數據庫會加以改進的地方。