?周五下午的DTCC智能運(yùn)維專場（專場19）因?yàn)榕R時(shí)原因，讓我客串主持人，幸虧是線上會(huì)議，對主持人的形象要求不高，否則因?yàn)橐咔樵騼蓚€(gè)月沒去理發(fā)店的本尊真的很難上鏡。

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

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

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

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

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

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

原本想著只要確認(rèn)了寫IO存在性能問題，就基本上可以定位問題在哪了。于是立即查看后臺進(jìn)程的寫IO相關(guān)的指標(biāo)。

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

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

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

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

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

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

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

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