後9i時代怎麼樣最佳化Oracle資料庫

 作者： piner (轉載請註明本文出處： Ixdba.com)

永久連結： http://www.ixdba.com/html/y2008/m12/297-oracle-9i-after-performance.html

如果問一個Oracle DBA在學習Oracle的過程中，什麼最難，估計十之八九會回答最佳化。的確，Oracle的最佳化是一門高深的學問，不僅僅是要深刻的理解Oracle的體繫結構、運行機制，還要對硬體、OS等周邊環境了如指掌。進階的最佳化者還要有豐富的編程與應用經驗，能從應用上結合Oracle來做最佳化。

為了能更方便的最佳化Oracle資料庫，Oracle從817開始推出了Statspack，一個被DBA廣泛使用的最佳化工具。包括在我的職業生涯中，Statspack一直是我的主要幫手，它直觀的資料統計，給我帶來了很大的便捷性。但是，隨著資料庫越來越多，環境越來越複雜，Statspack也開始表現出它的不足，如在幾十個資料庫的環境中，每個資料庫都看上一遍Statspack報表的話，DBA已經累個半死了。

如果說Statspack是8i-9i時代最強大的Oracle最佳化工具，那麼在後9i時代（10g-11g），隨著系統越來越多，環境越來越複雜，我們該怎麼調優呢？新的監控工具會是什麼樣子？它們應當具備如下的特點：

◆集中的圖形化管理、監控與最佳化

◆自動化的、即時的警示與處理

◆曆史資料的對照與分析

在這種新的需求下，各種各樣圖形化的集中管理與監控的工具就出現了，如Veritas I3、quest Central等等。甚至還包括很多公司（如我們團隊）自己也開發一些集中的圖形化管理與監控介面來配合Statspack使用。當然，Oracle公司也看到了這裡潛在的問題與未來的市場，Oracle Enterprise Manager（OEM）就是這種情況下應運而生的產物。

如果說9i的OEM還是個雞肋的話，從10g起的OEM已經是好多了，在我之前的Blog：Oracle 11g EM–重返圖形介面中，也描述了現有的OEM+Grid Control強大的集中化管理功能，使得Oracle 資料庫的管理門檻與管理成本大幅度下降。

其實，從Oracle 10g起的OEM不僅僅是具備方便與集中的管理功能，其監控與最佳化功能也不可小視。通過OEM，我們方便的通過圖形介面就可以看到更多的資料庫效能指標資訊，並且能夠診斷資料庫存在的問題並提出建議，甚至可以具體到最佳化存在效能問題的SQL。所以，對於DBA來說，從10g開始，OEM將是一個非常重要的效能診斷工具，使得一個DBA 甚至不需要具備高深的技能，動動滑鼠，就可以完成一個在10g之前高難度的最佳化工作。如果再加上Grid Control，DBA甚至可以方便的管理與最佳化非常多的Oracle資料庫。

這裡我不打算介紹OEM強大的集中化管理功能，而是通過一個小小的案例來說明後9i時代怎麼樣通過OEM完成一個曆史問題的跟蹤與SQL的最佳化。在正式分析案例之前，我們先熟悉一下幾個名詞：

AWR：自動負載資訊庫 (Automatic Workload Repository)，從Oracle 10g開始也採用AWR用於取代以前的Statspack。相比Statspack，AWR報告不需要安裝配置，預設就已經整合安裝好了，並且不需要寫指令碼定期採集和刪除資訊，Oracle預設情況下每一小時採集一次AWR資訊，保留最近一個星期的AWR資訊。

ADDM：自動資料庫診斷監控程式(Autometic Database Diagnostic Monitor)，可以藉助AWR定期從資料庫中收集詳細的與效能相關的度量標準。每次快照後，調用 ADDM 來徹底分析源自快照間差異的資料和度量標準，然後就必要的操作提出建議。

ASH：活動會話曆史（Active Session History），作為ADDM的一個補充，ASH可以動態隨時收集當前的關鍵效能資料並儲存在Shared pool的ASH buffers中，被引入用以保留最近的會話活動的詳細曆史資訊。通過ASH，可以方便的分析最近的SQL與會話資訊，本次案例的分析，其實資料就是基於ASH的。

DB Time：這個也是從10g開始出現的一個新概念，表示一個請求(call)在資料庫中花費的所有時間，包括CPU time,IO time,以及非空閑等待時間。但是，DB time不等於Response time。DB Time反應了資料庫中所消耗的整體時間，不管是CPU問題，還是IO問題，還是其它等待事件，都是可能有最佳化空間的。

Average Active Sessions：平均活動會話數，這個是一個很繞口的概念，表示當前統計時間段內，活動會話的使用率的一個累計。對於單個進程而言，這個使用率是一個百分比（%Active），表示DB Time/總體時間的一個比率；對於多個進程而言，就這這些進程的累加，如果值越大，也表示了活動的Session很多，或者是活動的Session很忙。

下面，我們開始分析，假定我（DBA）接到一個報告，說Oracle 10g的一個資料庫剛才有幾分鐘時間很慢，但是，現在已經恢複正常了，需要我尋找其中的原因。當然，我可以通過Statspack或者是AWR做一個報告，但是，現在，我選擇登陸OEM，登陸進去之後，選擇Performance標籤，看到如下的畫面：

可以看到，在10：30左右的時候，對比其它時間段，有一個異常的突起，平均活動會話數到了20左右，而平常一般5都不能達到。另外，通過HOST進程的分析（圖上面）以及DB IO與Transaction都沒有大的變化，應當表示當前的會話突然變忙了。我點擊Top Activity（頁面的下面）進入頂級活動頁面。

在這個頁面中，我可以拖拉陰影框到指定的位置，也就是我要分析的時間點，下面就即時的顯示了這個時間範圍之內的所有Top Sql以及Top Session，我可以點擊任何SQL ID或者是Session ID瞭解詳細情況。在這裡，我點擊Top 1的SQL ID，看看這個最耗費效能的SQL到底是什麼SQL：

這裡也有好幾個標籤頁，不同的標籤頁就可以看到SQL不同的資訊，如統計資訊，活動資訊，執行計畫預計調優資訊。在Activity標籤中，我看到了具體的SQL活動資訊，通過Plan標籤，能看到它執行時候的具體執行計畫，判斷它是否走錯了執行計畫。甚至可以通過SQL調優顧問（SQL Tuning Advisor）給出具體的最佳化建議，如增加一個合適的索引。

通過以上的一個小案例，示範了Oracle 後9i時代，通過Oracle Web化的圖形管理工具–OEM，在最佳化方面的強大功能。實際上，上面也說過了，OEM的功能遠遠不止如此，可以說，Oracle 9i之後的OEM是眾多DBA 的一個福音。

不過，要真正的精通最佳化，不是靠一個完善的工具就能解決的。工具最終僅僅還是工具，最多是一個方便管理，節約成本，能給我們多一點休息時間的好東西，至於DBA本身的技能，並不能指望通過工具來獲得提升，還是需要各位DBA苦練內功才能獲得的。

最後，強大的監控僅僅是能及時的發現問題以及處理問題，為什麼會出現了問題，怎麼樣把問題消滅在萌芽之中，這才是每個DBA所需要思考的：

◆我們應當怎麼樣合理、有效規劃與設計我們的資料庫，避免不必要的設計失誤以及意外的Bug。

◆我們應當通過什麼樣的流程來審核開發人員的Query以及DBA的日常操作，避免各種各樣的操作失誤。

◆我們應當通過什麼樣的文檔與規範來標準化日常的DDL以及DML操作，讓每個操作都有據可循？