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

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

既然數(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)越來(lái)越不適合了。要想實(shí)現(xiàn)自動(dòng)化的智能分析，必須擁有較為完整的數(shù)據(jù)，利用這些數(shù)據(jù)，可以在故障現(xiàn)象發(fā)生時(shí)第一時(shí)間被捕捉到，并被分析與分類，告知運(yùn)維人員的同時(shí)已經(jīng)把大體的問(wèn)題分類一并告知了。這樣的告警可以加速故障定位，縮短消缺時(shí)間。

我臨時(shí)畫了一張草圖，并不完整，如果對(duì)數(shù)據(jù)庫(kù)需要采集哪些數(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)化采集到的，不過(guò)有些是無(wú)法采集的，需要在配置的時(shí)候人工輸入。

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

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

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

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

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

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

不過(guò)從文件IO情況的匯總信息上還是能看出一些特殊的東西來(lái)。

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

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

這些問(wèn)題從AWR報(bào)告里都是沒(méi)有的。必須和運(yùn)維人員溝通才能獲得到相關(guān)的信息。對(duì)于這些問(wèn)題的不同回答，很可能問(wèn)題分析的方向也會(huì)發(fā)生變化。如果這個(gè)數(shù)據(jù)庫(kù)不是跑在Oracle一體機(jī)上的，那么很多參數(shù)設(shè)置就值得商榷了。如果說(shuō)這臺(tái)服務(wù)器只有一個(gè)實(shí)例使用，CPU_COUNT=8就是一個(gè)容易引發(fā)閂鎖問(wèn)題的設(shè)置，而且剛才我們看到的IO負(fù)載很小的結(jié)論也不存在了。因?yàn)槲覀儽仨毧凑麄€(gè)服務(wù)器上所有實(shí)例的IO負(fù)載，才能了解到IO是否存在負(fù)載過(guò)高的問(wèn)題，這就需要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è)分析過(guò)程能夠順利的自動(dòng)化完成。甚至有些數(shù)據(jù)很可能都無(wú)法實(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，那就說(shuō)明IO性能下降的很厲害了。

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