透過這篇簡短的文章，我想消除一個與分析 Oracle Exadata 上執行的 AWR 資料庫相關的誤解。 近10年來，我一直面臨這樣一個問題：Exadata軟體對生產力的貢獻是什麼？ 或用新造的字：特定資料庫的工作有多「專家」？
在我看來，這個正確的問題常常根據 AWR 統計數據得到錯誤的答案。 它提出了系統等待方法，該方法將回應時間視為處理器（DB CPU）的操作時間和各個類別的等待時間的總和。
隨著 Exadata 的出現，與 Exadata 軟體運作相關的特定係統期望出現在 AWR 統計資料中。 通常，此類等待的名稱以“單元”一詞開頭（Exadata 儲存伺服器稱為單元），其中最常見的是具有不言自明名稱的等待“單元智慧表掃描”、“單元多塊”物理讀取”和“單元單塊物理讀」。
在大多數情況下，此類Exadata 等待在總回應時間中所佔的份額很小，因此它們甚至不屬於按總等待時間排列的Top10 前台事件部分（在這種情況下，您需要在前台等待中查找它們）活動部分）。 我們好不容易從客戶那裡找到了一個每日AWR的例子，其中Exadata的預期被列入Top10部分，總計約為5%：
活動
等待
總等待時間（秒）
平均等待時間
%資料庫時間
等待班
資料庫CPU
115.2K
70.4
來自 dblink 的 SQL*Net 更多數據
670,196
5471.5
8.16ms
3.3
網絡
Cell單塊物理讀
5,661,452
3827.6
676.07us
2.3
使用者輸入/輸出
同步 ASM 重新平衡
4,350,012
3481.3
800.30us
2.1
其他
單元多塊物理讀取
759,885
2252
2.96ms
1.4
使用者輸入/輸出
直接路徑讀取
374,368
1811.3
4.84ms
1.1
使用者輸入/輸出
來自 dblink 的 SQL*Net 訊息
7,983
1725
216.08ms
1.1
網絡
單元格智慧表掃描
1,007,520
1260.7
1.25ms
0.8
使用者輸入/輸出
直接路徑讀取溫度
520,211
808.4
1.55ms
0.5
使用者輸入/輸出
enq: TM - 爭用
652
795.8
1220.55ms
0.5
應用
從此類 AWR 統計數據中通常可以得出以下結論：
1. Exadata magic對資料庫效能的貢獻不高－不超過5%，資料庫「exadataizes」較差。
2.這樣的資料庫如果從Exadata轉移到經典的「伺服器+陣列」架構，那麼效能不會有太大變化。 因為即使該陣列比 Exadata 儲存系統慢三倍（這對於現代全快閃陣列來說幾乎是不可能的），然後將 5% 乘以 15，我們就會將 I/O 等待份額增加到 XNUMX% - 資料庫肯定會倖存！
這兩個結論都是不準確的，而且它們扭曲了對 Exadata 軟體背後理念的理解。 Exadata 不僅提供快速 I/O，其運作方式與經典伺服器 + 陣列架構有根本不同。 如果資料庫操作真正「適配」了，那麼SQL邏輯就會轉移到儲存系統上。 儲存伺服器借助許多特殊機制（主要是 Exadata 儲存索引，但不僅限於此），可以自行尋找必要的資料並將資料庫傳送到伺服器。 它們的執行效率非常高，因此典型的 Exadata 等待時間在總回應時間中所佔的比例很小。
在 Exadata 之外，這一份額將如何變化？ 這將如何影響整個資料庫的效能？ 測試將最好地回答這些問題。 例如，等待 Exadata 外部的「單元智慧表掃描」可能會變成繁重的表全掃描，導致 I/O 佔用整個回應時間，且效能急劇下降。 這就是為什麼在分析 AWR 時，將 Exadata 預期的總百分比視為其對效能的魔力貢獻是錯誤的，使用該百分比來預測 Exadata 以外的效能更是如此。 要了解資料庫的工作有多“精確”，您需要研究“Instance Activity Stats”部分的 AWR 統計數據（有很多具有不言自明的名稱的統計數據）並將它們相互比較。
要了解 Exadata 以外的資料庫的感受，最好從目標架構上的備份進行資料庫克隆，並分析該克隆在負載下的效能。 一般來說，Exadata 所有者有這個機會。
作者： Alexey Struchenko，Jet Infosystems 資料庫部門負責人
來源： www.habr.com