昨天有朋友看了我的文章提問CHATGPT能不能解讀AWR報告。怎麼說呢，我們先來看一個例子。

聊聊昨天說的那個ORA-4030

我輸入了一個AWR報告的TOP 10 EVENT，看看CHATGPT如何解讀吧。

聊聊昨天說的那個ORA-4030

如果說解讀AWR的TOP EVENTS資料，我想CHATGPT不會比一些人類DBA差了，實際上最初的時候我也是如此解讀AWR報告的，只不過AWR報告不僅僅需要能解讀，還需要能分析，能夠把AWR中各種相關的資料綜合起來分析，才能從AWR報告中分析出深層次的問題。對於一些十分明顯的問題，僅僅從TOP EVENT就可以看出來了，而絕大多數複雜的問題，是無法從這些地方找出答案的。這一點CHATGPT肯定做不到，甚至大多數人類DBA也做不到。不過如果經過足夠的訓練，CHATGPT也可能能做到。

聊聊昨天說的那個ORA-4030

實際上，臨時表空間的直接路徑讀寫肯定是與非最佳化的大排序有關，如果我來解讀AWR的時候，遇到這個情況，肯定要去翻PGA相關的資料。從而發現存在一些大SQL的硬碟排序過多。

要想讓CHATGPT做到這一點，不僅僅需要更多的訓練，更需要高水平的DBA採用正確的方法與它對話，引導它向正確的方向上計算，從而完成深度的解讀。

我們還是回到昨天提到的那個案例，對於DBA來說，ORA-4030可能是一個十分明確的問題，我也一直是如此認為的。ORA-4030不外乎實體記憶體耗盡，作業系統ULIMIT限制，作業系統根目錄空間等因素。直到上星期一個客戶的一個具有1.5TB的超大記憶體系統報ORA-4030錯誤我才認識到以前知識的侷限性。

客戶的一個資料庫系統出現了一些ORA-4030報警，都集中在採集TOP SQL的監控系統中，普通業務模組並未報警。聊聊昨天說的那個ORA-4030

當時的報錯場景是有些奇怪的，從SWAP INFORMATION上看，這個報錯十分沒有道理。實體記憶體還有近400GB的FREE，SWAP基本沒用。但是在執行一條訪問v$sql的語句的時候，出現了無法對映記憶體的錯誤。

當時的報錯資訊是這樣的，報錯位置是：kxs-heap-w,kqlfto,kqlfo:kqlfoobj。Kxs-heap-w的含義是執行SQL的時候分配一個記憶體用於寫入，kqlfto是資料庫核心與OS BUFFER之間的緩衝。Kqlfoobj是從SGA向PGA/UGA寫入資料時產生的。串聯起來是當會話在執行SQL語句的時候，從SGA向會話私有記憶體輸出資料的時候，無法分配記憶體。從下面的TOP 10記憶體使用情況看,kqlfto:kqlfoobj佔了72%，達到2935MB。反推一下，總的程式記憶體大約是4076MB。

經過分析後，當時我們認為透過調整vm.max_map_count可以解決這個問題，不過使用者暫時不同意調整。於是我們只能從另外一個角度去做調整。當時發現報錯的例項的SQLAREA特別大，於是在業務不忙的時候重新整理了一下共享池，讓130多GB的SQLAREA變得正常了，訪問V$SQL採集SQL的功能才恢復了正常。採用這種處置方式的原理是SQLAREA中資料少了，向PGA輸出資料時，PGA就不會達到4G的限制了。實際上這個案例最終還是要透過調整OS或者資料庫引數來解決。

事後分析的時候，我們在MOS上也查到了大量的NOTES。這個問題是和Oracle的實記憶體分配（非共享記憶體分配）有關的。

_realfree_heap_pagesize_hint（12c之後，這個引數改名為_realfree_heap_pagesize）是 Oracle 資料庫中的一個引數，用於設定非共享記憶體管理器的頁面大小。真正的空閒記憶體管理器用於管理資料庫用於PL / SQL記憶體和其他非共享記憶體的真實記憶體（非SGA）。其預設大小是64KB。因為RHEL作業系統的vm_max_map_count是65530，能夠影射的記憶體大小是有限的，Oracle的_realfree_heap_pages引數定義了每個影射的塊大小，Oracle 11g預設是64K，所以PGA中最多可以影射4GB的實體記憶體。如果超出這個限制，就會因為max_map_count的限制而無法分配記憶體。

Oracle官方的解決方案是加大_realfree_heap_pagesize_hint或者修改max_map_count。調整任何一個引數都可以讓Oracle PGA能夠MAP更多的實體記憶體。

根據這個情況，我們需要更新ORA-4030的知識庫，增加故障模型中的診斷路徑，把相關的Oracle引數，OS引數等因素加入進去，同時在資料庫巡檢時增加對這方面的分析與診斷。知識就是這樣透過不斷地迭代，日益完善的。運維知識完善的基礎是來自於生產一線的運維案例。

聊聊昨天說的那個ORA-4030

相關文章