資料是自動化與智慧化的基礎

週五下午的DTCC智慧運維專場(專場19)因為臨時原因，讓我客串主持人，幸虧是線上會議，對主持人的形象要求不高，否則因為疫情原因兩個月沒去理髮店的本尊真的很難上鏡。

說到智慧運維或者說自動化運維，實際上主要依靠的還是資料智慧和知識智慧。而知識智慧的分析基礎還是資料，因此說資料無論對於自動化運維還是智慧化運維來說，都是最為關鍵的。本週二DBAIOPS社群的培訓是由我來介紹如何利用工具來運維自己的資料庫系統，其中我強調了“知識自動化”的基礎就是資料，一個知識自動化系統從資料採集開始就已經充滿了專家經驗和知識了。

既然資料如此重要，那麼我們需要什麼樣的資料呢?傳統的運維自動化系統都僅僅採集用於告警的資料，當告警發生後，再去補充分析其他資料。這種模式在智慧化運維時代已經越來越不適合了。要想實現自動化的智慧分析，必須擁有較為完整的資料，利用這些資料，可以在故障現象發生時第一時間被捕捉到，並被分析與分類，告知運維人員的同時已經把大體的問題分類一併告知了。這樣的告警可以加速故障定位，縮短消缺時間。

我臨時畫了一張草圖，並不完整，如果對資料庫需要採集哪些資料有興趣的朋友，可以安裝一套D-SMART社群版，在監控資訊裡可以看到D-SMART使用的監控資訊，在基本資訊裡可以看到配置相關的資訊。在叢集拓撲裡可以看到相關的關聯資訊。這些資料有些是可以自動化採集到的，不過有些是無法採集的，需要在配置的時候人工輸入。

有道是書到用時方恨少，實際上資料只有到了要分析問題的時候才會發現是不夠的。昨天網上有個朋友發了一個AWR報告，讓人幫助看看，我正好有空，就下載下來看了看。這個案例挺有意思的，初一看，系統的問題有好幾條線索。

從AWR上看，DB TIME確實很高，和Load Profile完全對不上，從上面的資料可以看出，系統的負載極小，每秒的執行數僅為153。不過負載不高有兩種可能性，一種是從上游來的SQL併發量就很小，還有一種可能性是當時系統出現問題，形成了一定的阻塞，因此併發量下降了。

從TOP等待事件上看，排在第一位的是lru鏈的閂鎖等待，這種等待並不常見，我們見得比較多的是CBC閂鎖等待。這個閂鎖等待一般來說是DB CACHE不夠用的時候才會出現的。在如此小的併發訪問下出現此類等待確實是十分罕見的。不過看到排在第三位的free buffer waits以及後面的write complete waits等待心裡就有點數了，從這裡可以看出是因為DBWR寫髒塊太慢才導致了free buffer wais，從而引發了LRU鏈閂鎖等待。

原本想著只要確認了寫IO存在效能問題，就基本上可以定位問題在哪了。於是立即檢視後臺程式的寫IO相關的指標。

沒想到寫IO的效能指標並無大礙，檔案寫平均延時3毫秒，日誌寫平均延時不到1毫秒，按理說這樣的寫IO效能不會產生如此大的影響。不過從後臺程式等待中我們也發現了一些特殊的東西，比如發現當時存在備份相關的等待。因為無法直接得出結論，所以必須繼續檢視更多的資訊。

從IO情況分析看，確實讀寫IO都不大，表空間的讀寫延時也看不出什麼問題。

不過從檔案IO情況的彙總資訊上還是能看出一些特殊的東西來。

這套RAC系統居然把資料檔案存放在ACFS上了，在11.2.0.4上使用ACFS還是有很多坑的。從這裡我們又發現了一條新的線索，是不是因為ACFS的BUG導致了IO效能問題，進而引發了這個問題呢?這就需要日誌和TRACE的資訊了，在AWR報告裡我們是找不到答案的。

從引數小節裡，我們也發現了一些異常，很多配置是來自於Oracle ODA一體機的配置模板，難道這是一臺Oracle一體機?另外cpu_count=8也是有些異常的，因為從OS資訊可以看出這是一臺兩路伺服器，36核的。難道說這臺伺服器上還有其他資料庫例項?

這些問題從AWR報告裡都是沒有的。必須和運維人員溝通才能獲得到相關的資訊。對於這些問題的不同回答，很可能問題分析的方向也會發生變化。如果這個資料庫不是跑在Oracle一體機上的，那麼很多引數設定就值得商榷了。如果說這臺伺服器只有一個例項使用，CPU_COUNT=8就是一個容易引發閂鎖問題的設定，而且剛才我們看到的IO負載很小的結論也不存在了。因為我們必須看整個伺服器上所有例項的IO負載，才能瞭解到IO是否存在負載過高的問題，這就需要OSW的資料作為分析的補充了。

傳統的以人為中心的分析往往都是一點點的去採集資料的，而需要實現自動化或者智慧化分析，這些資料採集必須能夠自動的、高質量的進行，才能讓整個分析過程能夠順利的自動化完成。甚至有些資料很可能都無法實現自動化的採集，必須由運維人員手工輸入。比如redo是放在SSD上的嗎?從REDO的寫IO延時上似乎能看到這樣的意思。資料檔案是存放在SATA HDD還是NVME SSD上的呢?如果是存放在SATA SSD上，那麼3毫秒的寫延時雖然有點慢，但是還可以接受，如果是NVME SSD，那就說明IO效能下降的很厲害了。

透過這個案例，我們也可以看出完整的資料對智慧化運維的意義。實際上這也是最難說服領導的地方，我曾經和一個客戶溝透過建設智慧化運維診斷系統。但是客戶就不願意花錢去改造執行指標採集模組，他覺得他們已經用了好幾年ZABBIX了，基於ZABBIX採集的資料去做上面的分析應用不就夠了，為啥還要再花錢呢?