?昨天有朋友看了我的文章提問CHATGPT能不能解讀AWR報(bào)告。怎么說呢，我們先來看一個(gè)例子。

我輸入了一個(gè)AWR報(bào)告的TOP 10 EVENT，看看CHATGPT如何解讀吧。

如果說解讀AWR的TOP EVENTS數(shù)據(jù)，我想CHATGPT不會(huì)比一些人類DBA差了，實(shí)際上最初的時(shí)候我也是如此解讀AWR報(bào)告的，只不過AWR報(bào)告不僅僅需要能解讀，還需要能分析，能夠把AWR中各種相關(guān)的數(shù)據(jù)綜合起來分析，才能從AWR報(bào)告中分析出深層次的問題。對(duì)于一些十分明顯的問題，僅僅從TOP EVENT就可以看出來了，而絕大多數(shù)復(fù)雜的問題，是無法從這些地方找出答案的。這一點(diǎn)CHATGPT肯定做不到，甚至大多數(shù)人類DBA也做不到。不過如果經(jīng)過足夠的訓(xùn)練，CHATGPT也可能能做到。

實(shí)際上，臨時(shí)表空間的直接路徑讀寫肯定是與非優(yōu)化的大排序有關(guān)，如果我來解讀AWR的時(shí)候，遇到這個(gè)情況，肯定要去翻PGA相關(guān)的數(shù)據(jù)。從而發(fā)現(xiàn)存在一些大SQL的硬盤排序過多。

要想讓CHATGPT做到這一點(diǎn)，不僅僅需要更多的訓(xùn)練，更需要高水平的DBA采用正確的方法與它對(duì)話，引導(dǎo)它向正確的方向上計(jì)算，從而完成深度的解讀。

我們還是回到昨天提到的那個(gè)案例，對(duì)于DBA來說，ORA-4030可能是一個(gè)十分明確的問題，我也一直是如此認(rèn)為的。ORA-4030不外乎物理內(nèi)存耗盡，操作系統(tǒng)ULIMIT限制，操作系統(tǒng)根目錄空間等因素。直到上星期一個(gè)客戶的一個(gè)具有1.5TB的超大內(nèi)存系統(tǒng)報(bào)ORA-4030錯(cuò)誤我才認(rèn)識(shí)到以前知識(shí)的局限性。

客戶的一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)出現(xiàn)了一些ORA-4030報(bào)警，都集中在采集TOP SQL的監(jiān)控系統(tǒng)中，普通業(yè)務(wù)模塊并未報(bào)警。         

當(dāng)時(shí)的報(bào)錯(cuò)場(chǎng)景是有些奇怪的，從SWAP INFORMATION上看，這個(gè)報(bào)錯(cuò)十分沒有道理。物理內(nèi)存還有近400GB的FREE，SWAP基本沒用。但是在執(zhí)行一條訪問v$sql的語句的時(shí)候，出現(xiàn)了無法映射內(nèi)存的錯(cuò)誤。

當(dāng)時(shí)的報(bào)錯(cuò)信息是這樣的，報(bào)錯(cuò)位置是：kxs-heap-w,kqlfto,kqlfo:kqlfoobj。Kxs-heap-w的含義是執(zhí)行SQL的時(shí)候分配一個(gè)內(nèi)存用于寫入，kqlfto是數(shù)據(jù)庫(kù)內(nèi)核與OS BUFFER之間的緩沖。Kqlfoobj是從SGA向PGA/UGA寫入數(shù)據(jù)時(shí)產(chǎn)生的。串聯(lián)起來是當(dāng)會(huì)話在執(zhí)行SQL語句的時(shí)候，從SGA向會(huì)話私有內(nèi)存輸出數(shù)據(jù)的時(shí)候，無法分配內(nèi)存。從下面的TOP 10內(nèi)存使用情況看,kqlfto:kqlfoobj占了72%，達(dá)到2935MB。反推一下，總的進(jìn)程內(nèi)存大約是4076MB。

經(jīng)過分析后，當(dāng)時(shí)我們認(rèn)為通過調(diào)整vm.max_map_count可以解決這個(gè)問題，不過用戶暫時(shí)不同意調(diào)整。于是我們只能從另外一個(gè)角度去做調(diào)整。當(dāng)時(shí)發(fā)現(xiàn)報(bào)錯(cuò)的實(shí)例的SQLAREA特別大，于是在業(yè)務(wù)不忙的時(shí)候刷新了一下共享池，讓130多GB的SQLAREA變得正常了，訪問V$SQL采集SQL的功能才恢復(fù)了正常。采用這種處置方式的原理是SQLAREA中數(shù)據(jù)少了，向PGA輸出數(shù)據(jù)時(shí)，PGA就不會(huì)達(dá)到4G的限制了。實(shí)際上這個(gè)案例最終還是要通過調(diào)整OS或者數(shù)據(jù)庫(kù)參數(shù)來解決。

事后分析的時(shí)候，我們?cè)贛OS上也查到了大量的NOTES。這個(gè)問題是和Oracle的實(shí)內(nèi)存分配（非共享內(nèi)存分配）有關(guān)的。

_realfree_heap_pagesize_hint（12c之后，這個(gè)參數(shù)改名為_realfree_heap_pagesize）是 Oracle 數(shù)據(jù)庫(kù)中的一個(gè)參數(shù)，用于設(shè)置非共享內(nèi)存管理器的頁(yè)面大小。真正的空閑內(nèi)存管理器用于管理數(shù)據(jù)庫(kù)用于PL / SQL內(nèi)存和其他非共享內(nèi)存的真實(shí)內(nèi)存（非SGA）。其默認(rèn)大小是64KB。因?yàn)镽HEL操作系統(tǒng)的vm_max_map_count是65530，能夠影射的內(nèi)存大小是有限的，Oracle的_realfree_heap_pages參數(shù)定義了每個(gè)影射的塊大小，Oracle 11g默認(rèn)是64K，所以PGA中最多可以影射4GB的物理內(nèi)存。如果超出這個(gè)限制，就會(huì)因?yàn)閙ax_map_count的限制而無法分配內(nèi)存。

Oracle官方的解決方案是加大_realfree_heap_pagesize_hint或者修改max_map_count。調(diào)整任何一個(gè)參數(shù)都可以讓Oracle PGA能夠MAP更多的物理內(nèi)存。

根據(jù)這個(gè)情況，我們需要更新ORA-4030的知識(shí)庫(kù)，增加故障模型中的診斷路徑，把相關(guān)的Oracle參數(shù)，OS參數(shù)等因素加入進(jìn)去，同時(shí)在數(shù)據(jù)庫(kù)巡檢時(shí)增加對(duì)這方面的分析與診斷。知識(shí)就是這樣通過不斷地迭代，日益完善的。運(yùn)維知識(shí)完善的基礎(chǔ)是來自于生產(chǎn)一線的運(yùn)維案例。?