數據庫系統是一個十分神奇的系統，我們以前習慣于監控某個指標是否出現了異常。不過單一指標的波動與異常往往很難定位故障或者問題。不同的應用系統中，指標之間的關聯度會有很大的差異。如果在類似業務場景，類似的負載情況下，數據庫的指標波動與相互影響還是具有一定的相似性的。這也是智能化運維的算法具有一定的普適性應用范圍的理論基礎。

我們探究指標后面的復雜關系是為了分析問題時能夠盡快抓住要點，從而避開錯誤的路徑分叉，直擊問題的根源于本質。因此我們對數據庫的指標體系理解的越為深刻，分析問題的能力也就越強。在二十多年的Oracle數據庫運維工作中，我就是通過不斷的理解指標與指標后面的復雜關聯關系，再結合Oracle數據庫內部原理與基礎概念，去不斷的提升自己的分析問題的能力的。

接下來我們來看一個例子，這個例子來自于一套負載比較高的Gaussdb數據庫系統，這套數據庫的配置比較豪華，有6個CN節點，12個DN節點，運行于華為云上，每個CN節點配置了16個CPU核心。Gaussdb的CN是采用負載均衡的模式接受來自應用的負載的，這套應用系統是十分典型的后臺交易型業務，大部分業務負載來自于前端過來的流式交易數據。數據庫是均勻分區在多個DN上的，應用負載也是較為均勻的分布在多個CN上的。

在一般情況下，這幾個CN承載的業務與業務負載十分相近，也不存在特別差的SQL語句。我們選取相同的時間片切面，用“每秒返回行數”這個指標，看看在同一時間切片上，不同的CN節點中，與這個指標具有較為相似的波動特性的指標有哪些。

圖片

首先我們來看187節點的情況，有較強關聯性的指標是每秒邏輯讀、每秒獲取行數、活躍會話數（低相似性）這幾個指標。

圖片

再來看看224節點的情況，也十分類似，關聯性最強的是每秒邏輯讀和每秒獲取行數。

圖片

235節點的情況又會如何呢？也差不多，不過每秒獲取行數的指標波動更為相近一些。

圖片

從上面的數據可以看出，每秒邏輯讀與每秒獲取行數是關聯性最強的兩個指標。邏輯讀是與返回行數與并發SQL執行量是十分強關聯的指標，因此這個指標的波動特性與每秒返回行數的關聯系很強，在大多數場景中都可能會出現。

而每秒獲取行數指標看上去和每秒返回行數的血緣關系十分相近。不過實際上在不同的應用場景中，二者可能會有較大的差異。每秒獲取行數是在掃描表或者訪問表時讀取的行的數量，而每秒返回行數是每秒返回到客戶端的行的數量。這二者在不同的SQL中可能會有較大的差異。比如SELECT COUNT(*)可能統計了1萬條數據，但是只返回了1條數據，這樣訪問數和返回數可能會相差萬倍。再比如說我們通過索引找出了一萬行數據，再根據SQL中的和索引無關的過濾條件從中篩選出1000條，那么二者會有10倍的差異。從這兩個指標的波動關聯性強弱可以看出數據庫執行的SQL是否發生了變化，亦或是SQL訪問的數據或者使用的參數是否發生了變化。一般來說探索這些問題需要很復雜的過程，而通過指標波動關聯性的分析就可以比較簡單，粗略的獲得了。

下面我把時間窗口調整到0點系統做批處理報表的時間段，我們會發現指標波動的規律完全改變了。

圖片

白天的業務特點是大量的小型的查詢語句并發執行，因此與之關聯的指標數量較多，集中度較低。而晚上是少量的批處理作業在執行，因此指標波動的集中度很高，波動相似性也較強，每秒邏輯讀與返回行數的關系十分相近。

雖然說某種業務下的某個指標的波動關聯性會發生一些變化，不過有些東西是不會變的，那就是指標之間的波動關聯性都是與數據庫的基本原理有關的。一般情況下不會存在兩個完全不相干的指標之間存在較強的波動關聯性。

數據庫系統中的指標波動特性是存在內在的必然聯系的。比如說我們這個例子中的每秒返回行數指標，與每秒獲取行數（獲取是指從數據庫中訪問到了，但是并不一定返回客戶端了）、每秒邏輯讀、每秒物理讀、長查詢數量等，這些指標之間都是存在較大的關聯關系的。活躍會話數雖然與這些指標直接不存在直接的關系，不過是能夠標識出數據庫的活躍程度的，與之存在稍微弱一點的波動關聯性也是解釋得過去的。

研究與分析指標之間的關系，有助于理解某個數據庫產品的基本特性，有助于在分析問題時抓住隱藏在表面之下的問題。這些年我們對Oracle數據庫的研究已經十分深入了，這方面的知識很豐富。不過不幸的是，目前的國產數據庫廠家并沒有對外公布任何這方面的知識，這對于我們今后運維國產數據庫形成了一定的障礙。我想現在肯定有一些從事數據庫服務的企業與個人已經開展了這方面的研究，我們也希望數據庫廠商除了完善用戶文檔外，也發布一些這方面的知識，從而豐富國產數據庫運維生態中的知識庫。我們團隊也會通過我的公眾號，不斷的向外公開一些我們的研究成果。