對(duì)于SQL，我們一般都說SQL審計(jì)，SQL優(yōu)化，很少談SQL監(jiān)控。確實(shí)也是，SQL是很難監(jiān)控的，因?yàn)橐粋€(gè)復(fù)雜的系統(tǒng)中，每天SQL的執(zhí)行次數(shù)高達(dá)千萬(wàn)級(jí)別，甚至數(shù)十?dāng)?shù)百億，執(zhí)行不同SQL的數(shù)量也可能高達(dá)數(shù)萬(wàn)數(shù)十萬(wàn)。如果大量的SQL是動(dòng)態(tài)生成的或者沒有使用綁定變量，那么可能在幾分鐘內(nèi)就有數(shù)萬(wàn)條不同的SQL在執(zhí)行。

在這樣的情況下，如果我們需要開發(fā)一個(gè)通用性的產(chǎn)品用于做SQL監(jiān)控是十分困難的。當(dāng)然如果我們的業(yè)務(wù)系統(tǒng)相對(duì)比較穩(wěn)定，需要監(jiān)控的SQL數(shù)量相對(duì)穩(wěn)定，針對(duì)這些SQL做針對(duì)性的監(jiān)控也是比較容易實(shí)現(xiàn)的。而事實(shí)上，對(duì)于大多數(shù)企業(yè)來說，我們需要監(jiān)控的數(shù)據(jù)庫(kù)系統(tǒng)有上百甚至上千套，業(yè)務(wù)系統(tǒng)也在不斷發(fā)生變更，在這種環(huán)境下，要實(shí)現(xiàn)通用的SQL監(jiān)控確實(shí)還是有難度的。

對(duì)于DBA來說，也會(huì)有一定的SQL語(yǔ)句監(jiān)控的需求，也都會(huì)掌握一些SQL語(yǔ)句監(jiān)控與分析的技巧。對(duì)于Oracle數(shù)據(jù)庫(kù)的DBA來說，我們已經(jīng)十分習(xí)慣于通過AWR報(bào)告的TOP SQL相關(guān)內(nèi)容來分析SQL的運(yùn)行情況，發(fā)現(xiàn)存在問題的SQL。不過這種分析只能算SQL優(yōu)化，而無(wú)法稱之為SQL監(jiān)控。

今天我們來探討一下SQL監(jiān)控的問題，隨著硬件、云平臺(tái)、數(shù)據(jù)庫(kù)技術(shù)以及應(yīng)用架構(gòu)的不斷優(yōu)化演進(jìn)，一些完全因?yàn)橛布Y源或者數(shù)據(jù)庫(kù)配置等引發(fā)的數(shù)據(jù)庫(kù)問題的比例相對(duì)較少了，而因?yàn)镾QL引發(fā)的問題在運(yùn)維中的占比越來越高。對(duì)于SQL的監(jiān)控需求是一直存在的，而且需求的種類也五花八門。前陣子有個(gè)客戶提出需要了解隨意一條SQL在某個(gè)時(shí)間段內(nèi)的精確執(zhí)行次數(shù)，問我們的D-SMART是否支持。另外一個(gè)客戶問我D-SMART是否支持對(duì)任意一條SQL的執(zhí)行計(jì)劃變化進(jìn)行跟蹤，發(fā)現(xiàn)問題及時(shí)報(bào)警。

實(shí)際上SQL監(jiān)控的目的依然是及時(shí)發(fā)現(xiàn)系統(tǒng)可能存在的風(fēng)險(xiǎn)。我和第一個(gè)朋友聊了聊他需要做如此精確的監(jiān)控的目的是什么，他也說不出一個(gè)所以然來。實(shí)際上這個(gè)需求最好從應(yīng)用的角度去做，在應(yīng)用系統(tǒng)的模塊中通過鉤子進(jìn)行統(tǒng)計(jì)的成本是最低的，從數(shù)據(jù)庫(kù)去做可能成本太高。如果要從數(shù)據(jù)庫(kù)的角度去統(tǒng)計(jì)，其精準(zhǔn)度就要大打折扣了，因?yàn)閿?shù)據(jù)庫(kù)的內(nèi)存中保存的SQL統(tǒng)計(jì)信息并不完整，因此我們?nèi)ゲ蓸拥臅r(shí)候會(huì)有誤差。當(dāng)某條SQL有一定時(shí)間沒有執(zhí)行的時(shí)候，很可能會(huì)從內(nèi)存統(tǒng)計(jì)緩沖區(qū)中被清除，下一次再出現(xiàn)的是可能從頭統(tǒng)計(jì)了。目前我們的TOP SQL采集工作也是5分鐘進(jìn)行一次，對(duì)這段時(shí)間內(nèi)比較活躍的SQL進(jìn)行一次統(tǒng)計(jì)。因?yàn)榇笮拖到y(tǒng)中的SQL數(shù)量可能會(huì)十分龐大，為了避免給生產(chǎn)系統(tǒng)帶來太大的負(fù)載，這種采集也必然是輕量級(jí)的，只采集一些十分重要的TOP SQL的詳細(xì)信息。

至于第二個(gè)需求，如果我們要對(duì)全量的SQL進(jìn)行執(zhí)行計(jì)劃的跟蹤，那肯定是不現(xiàn)實(shí)的，如果系統(tǒng)中存在幾萬(wàn)條SQL,幾十萬(wàn)個(gè)執(zhí)行計(jì)劃，采集一次的成本開銷之大，對(duì)于一些并發(fā)量較高，并且業(yè)務(wù)對(duì)SQL執(zhí)行延時(shí)的穩(wěn)定性要求較高的系統(tǒng)來說，是無(wú)法承受的。

Oracle數(shù)據(jù)庫(kù)的SQL語(yǔ)句都是存儲(chǔ)于共享內(nèi)存的CURSOR結(jié)構(gòu)中的，而不少開源、國(guó)產(chǎn)數(shù)據(jù)庫(kù)并不使用全局共享CURSOR的方式，CURSOR僅在會(huì)話內(nèi)共享。因此采集SQL語(yǔ)句與執(zhí)行計(jì)劃的接口并不十分完善，有些數(shù)據(jù)庫(kù)甚至還要開啟一些特殊的跟蹤功能才能實(shí)現(xiàn)。針對(duì)不同的數(shù)據(jù)庫(kù)產(chǎn)品，我們需要采取不同的手段來采集TOP SQL，因此SQL監(jiān)控的實(shí)現(xiàn)方式還是需要仔細(xì)去設(shè)計(jì)的。

另外一點(diǎn)，我們做SQL監(jiān)控的目的并不是SQL監(jiān)控本身，SQL監(jiān)控的目標(biāo)是防止SQL出現(xiàn)異常，從而導(dǎo)致數(shù)據(jù)庫(kù)系統(tǒng)出現(xiàn)問題。因此我們不能把SQL監(jiān)控當(dāng)初目標(biāo)，而是把SQL監(jiān)控當(dāng)成一種手段和方法。因此在一個(gè)系統(tǒng)中，監(jiān)控某個(gè)時(shí)間段內(nèi)某條SQL的精確執(zhí)行次數(shù)在絕大多數(shù)場(chǎng)景中沒有任何意義，我們只需要知道某些可能影響系統(tǒng)的SQL語(yǔ)句的大致執(zhí)行數(shù)量、平均每次執(zhí)行的開銷以及執(zhí)行次數(shù)與開銷的歷史波動(dòng)情況，就足以支撐我們所需要的運(yùn)維分析場(chǎng)景了。

而某條SQL語(yǔ)句的執(zhí)行計(jì)劃發(fā)生了變化，如果其執(zhí)行成本并無(wú)增加，對(duì)數(shù)據(jù)庫(kù)的穩(wěn)定運(yùn)行并無(wú)太大的影響，那么這種變化我們也無(wú)需實(shí)時(shí)發(fā)現(xiàn)，只要在定期的審計(jì)中有所發(fā)現(xiàn)，并能夠分析出其存在的潛在風(fēng)險(xiǎn)就可以了。而因?yàn)閳?zhí)行計(jì)劃的變化而導(dǎo)致了系統(tǒng)負(fù)載過高，系統(tǒng)性能下降，那么我們從其他一些方面也可以觀察到。我們利用數(shù)據(jù)庫(kù)可觀測(cè)性的一些其他側(cè)面能夠發(fā)現(xiàn)此類問題就可以了。比如我們可以通過整個(gè)系統(tǒng)的邏輯讀/物理的突然增加，CPU使用率的增加，活躍會(huì)話數(shù)的增加等相對(duì)容易觀察到，并且監(jiān)控成本比較低的可觀測(cè)性指標(biāo)也能夠發(fā)現(xiàn)因?yàn)镾QL執(zhí)行計(jì)劃變壞導(dǎo)致的問題，并能夠通過分析定位，快速發(fā)現(xiàn)是因?yàn)镾QL執(zhí)行計(jì)劃變壞導(dǎo)致了該問題。那么我們也就能解決這個(gè)問題了。

比如說在D-SMART中采用了關(guān)鍵SQL平均邏輯讀突增與每秒邏輯讀數(shù)量超出正常水平等兩種方式來發(fā)現(xiàn)相關(guān)的問題。我們以關(guān)鍵SQL平均邏輯讀突然增加的告警來看看D-SMART是如何分析這個(gè)問題的。

從SQL的歷史分析上看，確實(shí)出現(xiàn)了平均每次邏輯讀突變的情況。我們?cè)賮砜纯碨QL的執(zhí)行計(jì)劃，是不是出現(xiàn)了多個(gè)執(zhí)行計(jì)劃。

從分析上看，確實(shí)出現(xiàn)了兩個(gè)不同子游標(biāo)，其中一個(gè)游標(biāo)的執(zhí)行成本明顯大于另外一個(gè)。正是因?yàn)檫@個(gè)問題，導(dǎo)致了剛才那個(gè)告警的出現(xiàn)。這種方式是針對(duì)關(guān)鍵SQL的，關(guān)鍵SQL是一個(gè)系統(tǒng)中對(duì)應(yīng)用可用性或者SLA有著關(guān)鍵影響的SQL，我們可以在每個(gè)采樣周期都對(duì)其進(jìn)行監(jiān)控。因?yàn)橐粋€(gè)系統(tǒng)中的關(guān)鍵SQL的數(shù)量不會(huì)很大，因此這種專項(xiàng)監(jiān)控的成本也不高。

而如果出問題的并不是關(guān)鍵SQL，而是隨便哪一條SQL，突然因?yàn)榻y(tǒng)計(jì)信息不準(zhǔn)確或者說表數(shù)據(jù)量的變化，亦或是系統(tǒng)變更后出現(xiàn)了應(yīng)用的BUG，從而引起了執(zhí)行計(jì)劃的變化，進(jìn)而導(dǎo)致了系統(tǒng)資源不足，引起關(guān)鍵SQL因?yàn)橄到y(tǒng)資源不足（內(nèi)存，CPU，IO等）而引發(fā)了性能問題。這種情況也是十分常見的。如果這條SQL出問題還沒有觸發(fā)系統(tǒng)資源不足，從而導(dǎo)致核心業(yè)務(wù)故障，那么這個(gè)問題并不一定需要馬上被捕捉到，并且進(jìn)行處置。

只需要在定期的SQL審計(jì)（比如每周）中發(fā)現(xiàn)這個(gè)問題，就完全可以解決。如果比較嚴(yán)重了，可能會(huì)導(dǎo)致系統(tǒng)故障，那么我們還是需要盡可能早的捕獲到此類問題。在D-SMART中我們針對(duì)邏輯讀突增、物理讀突增、R隊(duì)列突增、活躍會(huì)話數(shù)突增、同一條SQL的并發(fā)執(zhí)行量達(dá)到某個(gè)閾值（此類SQL執(zhí)行計(jì)劃異常后必然出現(xiàn)執(zhí)行時(shí)間過長(zhǎng)，如果對(duì)系統(tǒng)產(chǎn)生較大影響，則大概率會(huì)出現(xiàn)多個(gè)SQL同時(shí)執(zhí)行的情況出現(xiàn)）等，都會(huì)產(chǎn)生告警。并且在這些告警中，都可有執(zhí)行計(jì)劃發(fā)生變化的診斷路徑，可以用于根因溯源。這樣就采取了一種迂回策略，從一個(gè)側(cè)面解決了此類問題的預(yù)警問題。