導讀

AWR報告是DBA最常用的性能診斷工具，但它展示的其實是一種“彙總後的視角”。很多時候，我們從報告中看到的是現象，而不是問題的根源。如果想更深入地理解數據庫的運行狀態，就需要回到AWR的底層，去分析它的“裸數據”——也就是最原始的統計表信息。這樣我們才能獲得更細粒度的性能數據，更精準地定位問題，甚至構建出自己的分析與監控體系。

本次我們邀請到雲和恩墨性能優化專家、研發架構師羅海雄，帶大家深入瞭解 Oracle AWR的底層結構，看看如何通過裸數據分析，讓性能診斷更直觀、更精準、更智能。

Oracle AWR 的作用與侷限性

大家都知道，在做 Oracle 性能分析的時候，我們最常用的工具之一就是AWR（Automatic Workload Repository）報告，它能幫助我們清晰地看到一個時間區間內數據庫的整體運行情況，是 Oracle 體系中一個非常核心的性能診斷工具。

圖1：常規使用–AWR/ASH報告

不過，相信大家在使用的時候也會發現——AWR報告雖然內容非常豐富，但也存在一些侷限性。

比如：

• 報告太長、章節太多，信息量非常大；
• Oracle 裏與AWR相關的基表超過100張，數據結構複雜；
• 更重要的是，報告本身是一種“點對點”的結果，只能展示你選定的兩個時間點之間的表現。

也就是説，我們每次只能看到一個時間段內的情況。如果想看趨勢怎麼辦？那就得自己手動去生成多份報告，再人工比對。這一點，對我們分析性能問題來説，其實是挺不方便的。

另外，AWR報告的各個章節之間也缺乏關聯性：比如“等待事件”“SQL統計”“I/O情況”等章節，彼此都是獨立的，很難直接做交叉分析。

還有一個問題——報告裏的內容其實存在一定的冗餘。對於有經驗的DBA來説，可能只需要關注其中幾個關鍵部分，但系統每次都會把所有章節都生成出來，既耗時，也佔空間。

當然，AWR報告也有它的優點。最大的好處是方便離線查看，比如我們可以把報告導出，發給同事或廠商的支持團隊進行分析。但總體來看，AWR報告提供的仍然是一種靜態的、彙總式的分析方式。對於我們這些希望進行更靈活、更深入性能分析的場景來説，它可能就不夠用了。

從 AWR 報告到裸數據分析

1、直接訪問AWR的底層裸數據的優勢

那有沒有更靈活的方式呢？其實可以——我們可以直接訪問AWR的底層裸數據表。

這樣做的好處是：

• 我們能自己定義分析維度；
• 可以做趨勢分析、跨章節對比；
• 還能自定義可視化圖表，比報告自由度高得多。

AWR的底層數據大概分為以下幾類：

圖2：AWR底層數據的類別

這些表加起來上百張，但核心思想其實不復雜，我們只要掌握它的數據類型特徵，就能靈活分析。

2、AWR裸數據的類型

我們可以把這些裸數據分為兩類：累計值（Cumulative Values）和變化值（Delta Values）。

舉個例子：

• 累計值：比如邏輯讀的總次數，是從數據庫啓動以來一直往上加的。
• 所以，如果我們要看一段時間的增量，就得做一個“當前值-上次值”的計算。
• 變化值：Oracle 有些表會直接記錄兩次採樣之間的變化，比如每分鐘邏輯讀增量、平均值、最大值等。
• 還有一些是當前狀態值，比如當前會話數，這類數據不會累計。

大多數時候，我們想要的其實是“累計值的變化量”，因為那反映的才是性能趨勢。

圖3：AWR裸數據的類別

分析函數篇：用 LAG 與 LEAD 探索時間序列變化

在分析AWR的裸數據時，我們首先要解決的問題是：如何觀察數據庫性能指標隨時間的變化趨勢。這些數據本質上是一組時間序列快照，若能比較相鄰快照之間的變化，就能直觀看出系統的波動情況。在這裏，分析函數LAG()和LEAD()就非常有用。它們可以幫助我們取到“上一條”或“下一條”快照的值，再與當前值相減，計算出增長或下降幅度。

例如，我們希望瞭解CPU時間的變化趨勢，就可以用LAG(DB_TIME)取上一快照的值，再減去當前值，即可得到每個時間段的性能變化。

圖4：多個指標並列

此外，還可以結合SUM()、AVG()等聚合函數，計算移動平均值或滑動區間的統計，從而更全面地觀察性能波動。相比標準的AWR報告，這種基於裸數據的方式更動態化，可以實現實時趨勢分析，而不侷限於兩個固定時間點之間的靜態比較。

行列轉換篇：用 PIVOT 實現多指標對比

在完成時間趨勢分析之後，我們往往希望進一步進行多指標的橫向對比。比如同時觀察CPU使用率、I/O吞吐量、Redo大小、邏輯讀次數等關鍵指標。但由於這些數據在底層表中往往是“按行存放”的，若用傳統SQL分析，就需要寫很多SUM(CASE WHEN …)語句，不僅繁瑣，還不易維護。

這時，PIVOT函數就能大大簡化我們的工作。通過PIVOT，我們可以將行數據轉為列展示，只需在IN()子句中定義需要的指標，例如：

CPU_TIME, DB_TIME, Redo Size, Logical Reads …

一次性即可生成所有指標列，查詢結構清晰、擴展性也很強。此外，我們還可以自定義指標的別名，讓結果更易讀。在查詢結果中加入時間戳字段後，便能輕鬆查看各項指標在不同時間點的變化情況。通過這種方式，我們可以快速構建出一張“多維性能監控表”，讓不同指標的趨勢對比一目瞭然。

圖5：利用PIVOT函數進行行列轉換

用 RATIO_TO_REPORT 做統一尺度分析

當我們將這些分析結果導出至Excel或BI工具時，就能繪製出類似AWR報告中的趨勢圖或Load Profile圖表。不過，這時常常會遇到一個問題：不同指標的數量級差異太大。

例如，Redo Size可能是數億，而Write I/O僅有幾千。如果直接畫在同一張圖上，小指標往往會被“壓扁”，幾乎看不出趨勢變化。

為了解決這個問題，我們可以利用分析函數RATIO_TO_REPORT()。它的作用是將每個值轉換為當前結果集中的佔比，也就是把絕對值變成百分比。這樣，不同數量級的指標就能在同一尺度上進行對比。

圖6：迴歸本來含義的RATIO_TO_REPORT()

通常我們會將結果乘以100或1000，並結合ROUND()函數做取整處理，使數據更加直觀。

最終得到的趨勢圖既清晰又有可比性——無論是巨大的Redo Size，還是較小的I/O操作，都能在同一張圖上準確反映其變化趨勢。

通過這種比例化分析方法，我們可以將AWR的原始統計信息轉化為更具洞察力的趨勢視圖，讓性能分析從“靜態彙報”走向“動態理解”。

圖7：保護好你的裸數據

通過直接訪問AWR的裸數據，我們可以突破傳統報告的限制，帶來更靈活、更深入的性能分析。這種方法能幫助我們：

• 實現時間序列的趨勢分析，追蹤性能變化；
• 進行多指標的對比與可視化，便於從不同角度分析系統狀況；
• 進行跨章節的性能關聯，打破報告章節之間的隔閡，深入發現根本原因；
• 更精準地定位問題，快速找到瓶頸，提供針對性的解決方案。

相比於單純依賴AWR報告，這種基於裸數據的分析方式更加貼近我們DBA的思維方式，也能幫助我們更高效地解決性能問題。