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

說到智能運維或者說自動化運維，實際上主要依靠的還是數(shù)據(jù)智能和知識智能。而知識智能的分析基礎還是數(shù)據(jù)，因此說數(shù)據(jù)無論對于自動化運維還是智能化運維來說，都是最為關鍵的。本周二DBAIOPS社區(qū)的培訓是由我來介紹如何利用工具來運維自己的數(shù)據(jù)庫系統(tǒng)，其中我強調了“知識自動化”的基礎就是數(shù)據(jù)，一個知識自動化系統(tǒng)從數(shù)據(jù)采集開始就已經(jīng)充滿了專家經(jīng)驗和知識了。

既然數(shù)據(jù)如此重要，那么我們需要什么樣的數(shù)據(jù)呢？傳統(tǒng)的運維自動化系統(tǒng)都僅僅采集用于告警的數(shù)據(jù)，當告警發(fā)生后，再去補充分析其他數(shù)據(jù)。這種模式在智能化運維時代已經(jīng)越來越不適合了。要想實現(xiàn)自動化的智能分析，必須擁有較為完整的數(shù)據(jù)，利用這些數(shù)據(jù)，可以在故障現(xiàn)象發(fā)生時第一時間被捕捉到，并被分析與分類，告知運維人員的同時已經(jīng)把大體的問題分類一并告知了。這樣的告警可以加速故障定位，縮短消缺時間。

我臨時畫了一張草圖，并不完整，如果對數(shù)據(jù)庫需要采集哪些數(shù)據(jù)有興趣的朋友，可以安裝一套D-SMART社區(qū)版，在監(jiān)控信息里可以看到D-SMART使用的監(jiān)控信息，在基本信息里可以看到配置相關的信息。在集群拓撲里可以看到相關的關聯(lián)信息。這些數(shù)據(jù)有些是可以自動化采集到的，不過有些是無法采集的，需要在配置的時候人工輸入。

有道是書到用時方恨少，實際上數(shù)據(jù)只有到了要分析問題的時候才會發(fā)現(xiàn)是不夠的。昨天網(wǎng)上有個朋友發(fā)了一個AWR報告，讓人幫助看看，我正好有空，就下載下來看了看。這個案例挺有意思的，初一看，系統(tǒng)的問題有好幾條線索。

從AWR上看，DB TIME確實很高，和Load Profile完全對不上，從上面的數(shù)據(jù)可以看出，系統(tǒng)的負載極小，每秒的執(zhí)行數(shù)僅為153。不過負載不高有兩種可能性，一種是從上游來的SQL并發(fā)量就很小，還有一種可能性是當時系統(tǒng)出現(xiàn)問題，形成了一定的阻塞，因此并發(fā)量下降了。

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

原本想著只要確認了寫IO存在性能問題，就基本上可以定位問題在哪了。于是立即查看后臺進程的寫IO相關的指標。

沒想到寫IO的性能指標并無大礙，文件寫平均延時3毫秒，日志寫平均延時不到1毫秒，按理說這樣的寫IO性能不會產(chǎn)生如此大的影響。不過從后臺進程等待中我們也發(fā)現(xiàn)了一些特殊的東西，比如發(fā)現(xiàn)當時存在備份相關的等待。因為無法直接得出結論，所以必須繼續(xù)查看更多的信息。

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

不過從文件IO情況的匯總信息上還是能看出一些特殊的東西來。

這套RAC系統(tǒng)居然把數(shù)據(jù)文件存放在ACFS上了，在11.2.0.4上使用ACFS還是有很多坑的。從這里我們又發(fā)現(xiàn)了一條新的線索，是不是因為ACFS的BUG導致了IO性能問題，進而引發(fā)了這個問題呢？這就需要日志和TRACE的信息了，在AWR報告里我們是找不到答案的。

從參數(shù)小節(jié)里，我們也發(fā)現(xiàn)了一些異常，很多配置是來自于Oracle ODA一體機的配置模板，難道這是一臺Oracle一體機？另外cpu_count=8也是有些異常的，因為從OS信息可以看出這是一臺兩路服務器，36核的。難道說這臺服務器上還有其他數(shù)據(jù)庫實例？

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

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

通過這個案例，我們也可以看出完整的數(shù)據(jù)對智能化運維的意義。實際上這也是最難說服領導的地方，我曾經(jīng)和一個客戶溝通過建設智能化運維診斷系統(tǒng)。但是客戶就不愿意花錢去改造運行指標采集模塊，他覺得他們已經(jīng)用了好幾年ZABBIX了，基于ZABBIX采集的數(shù)據(jù)去做上面的分析應用不就夠了，為啥還要再花錢呢？?