我是從Oracle 5開始使用Oracle的，不過Oracle 5、6的時代，我只是幫用戶安裝Oracle而已，真正的開始關注數據庫的內部，嘗試調優數據庫和解決數據庫的故障是從Oracle 7.1開始的。因此我對v$sysstat有著十分深厚的感情，雖然從Oracle 7到Oracle 9，以至于到Oracle 11，v$sysstat中的指標數量增加了許多，但是對這個系統視圖的用法沒有改變。

2007年的時候，我和一個當時供職于Oracle ACS的朋友一起為某個運營商優化一套短信平臺系統，那個朋友一看到用戶的數據庫是Oracle 10g，立馬就說：“老徐，這個項目還是你來干吧，我從Oracle 6干到現在，不準備再去更新10g的知識了”。那個時代Oracle基本上5年迭代一個版本，而且每個版本都有一些顛覆性的技術出現。對于運維的可觀測性來說，從Oracle7到Oracle 10g正是Oracle的可觀測性體系日漸完善的時期，變化尤其大。

作為一個老DBA，用戶一般都是挺尊重我的，記得我剛剛用10g的時候還鬧過一個笑話，當時是給一個東北的運營商優化系統。當我要求在Oracle 10g上安裝一個statspack的時候，甲方的DBA雖然沒聽說過啥叫statspack，不過還是很配合的幫我安裝了。不過生成完第一份spreport的時候，那個DBA不禁笑了，這個不是和AWR報告很類似嗎？這是我最后一次讓讓用戶在10g上安裝statspack報告。

因為慣性，在好長一段時間里，我一直沒有意識到Oracle數據庫發生的變化，也依然使用v$sysstat幫助用戶分析問題。在10g和11g上，我會使用ASH來彌補v$sysstat在微觀分析能力上的不足。

直到有一天，公司的小伙伴告訴我實際上沒必要那么復雜的去通過統計v$sysstat來計算指標，Oracle 已經和提供了一個叫v$metric的系統視圖，我們可以更加方便的獲得這些指標。

圖片

后來我仔細分析了一下，確實如此，原來從Oracle 10g開始Orace已經提供了如此強大的指標接口。在Oracle 12.1版本中，v$metric已經包含了200個指標，并且為這些指標提供了1秒、5秒、15秒、1分鐘等多種統計值，用于不同需求的分析。Oracle還提供了一系列的Metric視圖，向用戶提供更加豐富的可觀測性指標。比如eventmetric/sysmetric等。

目前大多數數據庫都提供類似v$sysstat的系統視圖，用于運維人員采集與分析相關的指標。不過v$sysstat還是太籠統了，還不夠友好。如果能夠像Oracle一樣將sysstat在內核中加工，生成各種metric，那么數據庫的可觀測性能力將會得到極大的提升。去年的時候，一個用戶經常會出現活躍會話數異常的情況，那個時段里經常會出現核心交易抖動。不過他們的監控哪怕把采樣周期調整得很低，也抓不到這個現象。我看了一下他們的監控系統，原來是通過統計v$session的瞬間值來采集這個指標的，于是我讓他去v$metric和v$metric_history中查找，一下子就抓到了好幾個異常點。

可能有朋友會覺得奇怪，在數據庫內核中做一個類似Oracle metric的功能難道很難嗎？確實很難，因為內核既要兼顧性能與可靠性，又要提供更多的可觀測性，確實很考驗架構師和研發人員的水平。通過埋點實現的指標采集必須代碼性能十分優越，否則會影響數據庫的性能和穩定性。因此這些埋點的代碼越簡潔，做的事情越少越好。一個數據庫產品要做好這一點確實是要花大力氣的。

可喜的是，目前已經有一些數據庫產品開始提供這方面的可觀測性接口了，雖然接口還不夠完善，提供的數據也沒有Oracle豐富，起碼已經看到我們的國產數據庫廠商也已經關注到了這方的用戶需求了。