自動性能診斷技術

摘要:企業數據庫在大小和數量上的不斷增長使得系統管理的復雜性也隨之增加。該文介紹的Oracle 數據庫 10g新性能診斷技術和監控技術。可以在不受工作負載影響的情況下，簡化管理、提高效率以及降低與系統管理相關的成本，該技術大大簡化了 Oracle 數據庫的診斷和調整過程。

關鍵詞:自動性能診斷;自動工作負載信息庫;oracle

Approach to Flash Memory in Oracle

XIA Yue-ping

( Nanjing College of Information Technology， Nanjing 210016， China)

Abstract: The increase of enterprise database in dimensions and quantity make the management so complexity. The text talk about new diagnose technology and monitoring technology about ORACLEdatabase 10g. The technology can simplify management and raise efficient. It also can reduce the cost about management. The technology simplifies the production of diagnose and adjustment about database.

Key words: automatic performance diagnostics; automatic workload repository; oracle

Oracle 新性能診斷和監控技術技術內置于數據庫服務器中，并通過 Oracle Enterprise Manager (EM) 實現外部化。該技術大大簡化了 Oracle 數據庫的診斷和調整過程。主要組件包括自動工作負載信息庫 (AWR)、自動數據庫診斷監控程序 (ADDM) 和 Oracle Enterprise Manager (EM)。所有這些組件均建立在 Oracle 數據庫代碼中代碼規范的基礎上，該代碼規范生成大量來自 Oracle 數據庫的診斷統計信息。為了實現這一新功能，已對 Oracle 服務器(尤其是代碼方法部分)進行了許多更改。

1 數據庫性能統計

每個新數據庫版本都增加了更多的性能統計，用于診斷數據庫中的問題。10g 增加了幾個新的統計，專門用于提高性能問題自動診斷的精確性。在服務器內部生成一個工具的優點之一是，如果問題難以診斷，則我們可以添加更多的規范來簡化它!

1) 等待類

Oracle 數據庫 10g 中現在可能擁有 700 多個不同的等待事件。事件數目之所以增多，主要是由于為了確保更精確的問題診斷，許多鎖和鎖栓已經作為單獨的等待事件發生。為了實現對等待事件進行更容易的高級分析，等待事件已經劃分為基于解決方案空間的等待類，該空間通常用于解決與等待事件有關的問題。例如， TX 互斥鎖通常是一個應用程序級別的問題，而 HW 鎖定通常是一個配置問題。

2) 時間模型

嘗試調整 Oracle 系統時涉及到許多組件，每個組件都具有單獨的統計集。要從整體上檢查系統，必須使用某種通用度量來實現跨模塊比較，例如，如果將內存從緩沖區緩存移動到共享池，總體性能是否會提高?唯一可行的通用度量是時間。如果通過將 8MB 內存移動到共享池而產生的預期性能改進是 x，通過將 8MB 內存移出緩沖區緩存而產生的預期性能下降為y，則如果 x-y 的結果是正值，則表示凈收益。在 10g 中，多數顧問程序都會及時的報告它們的結果。此外，還引入了名為“時間模型統計”的新統計，這些統計顯示為新的 V$SYS_TIME_MODEL 和 V$SESS_TIME_MODEL 視圖。該規范可以幫助我們識別對數據庫操作的量化效果。

3) DB 時間

新統計最重要的部分是“數據庫時間”。這是數據庫調用花費的總時間。調整 Oracle 系統的目標可以陳述為減少用戶對數據庫執行操作所花的時間，即減少“DB 時間”。如果減少系統對給定工作負載的“DB 時間”，則可以改進性能。“DB 時間”的減少還可以用作調整投入有效性的度量。

例如，通過其它時間模型統計可以從數量方面了解登錄操作以及硬分析和軟分析的影響。由于該數據無法直接在本產品的早期版本中使用，因此無法實現對這些操作的影響進行量化分析。

4) 活動會話歷史記錄 (ASH)

從 Oracle7 開始，對 V$SESSION_WAIT 進行取樣可以有效地實時檢查系統所發生的事件。V$SESSION_WAIT 視圖包含的有關當前等待事件的詳細信息可以向下擴展到正在讀取的單個塊以及會話等待的鎖栓和等待鎖栓的會話數量。但該詳細信息無法輕松地用于歷史分析。

在 Oracle 數據庫 10g 中，V$ACTIVE_SESSION_HISTORY 視圖提供了有關數據庫中所發生的事件的取樣歷史記錄(記錄在內存中的循環緩沖區中)。由于只捕獲處于“活動”狀態的會話(即數據庫調用中的會話)，因此它可以表示一個可管理的數據集、直接與執行的工作關聯的大小，而非系統允許的會話數量。當會話等待資源(例如 取樣時等待 IO)時，等待的完成導致取樣數據被修改，這樣 V$ACTIVE SESSION_HISTORY 中的條目將包含等待事件實際完成所需的時間。

使用“活動會話歷史記錄”使我們能夠回溯時間，執行詳細的分析，并通常不必重播工作負載以收集其它性能跟蹤信息作為性能診斷的一部分。

5) 其它 SQL 統計

引入了新列 SQL_id。這是比散列值“更唯一”的值，并顯示為字符串。SQL_id 用于 Oracle 數據庫 10g 智能基礎架構中的 SQL 語句上的所有操作。 以上描述的最常用的等待類已經添加到 V$SQL 中的 SQL 統計中。PLSQL 和 Java 中花費的時間也被量化。 為了使 SQL 調整顧問程序進行更全面的分析，還捕獲了 SQL 語句的示例綁定值。

6) 操作系統統計

在數據庫中的計時數據方面遇到的問題之一是，許多 CPU 計時器的粒度比已用計時器低數個數量級。由于許多操作將報告零 CPU 使用率，因此這將導致對 CPU 時間的低估。隨著 CPU 速度的提高，這一問題變得更加嚴重。因內存壓力導致的分頁和交換活動也可以影響數據庫的性能，但這無法通過查看任何可用數據庫統計信息得到診斷。新視圖 V$OSSTAT 可以捕獲數據庫中的計算機級信息，這樣我們便可以輕松地確定是否存在硬件級資源問題。

2 AWR:性能信息庫

長期以來，人們已經認識到維護有關 Oracle 系統操作的信息庫的重要性。8i 之后的數據庫附帶的 Statspack 腳本已經得到廣泛使用。10g 中采用了自動工作負載信息庫，從而使信息庫的維護又上了一個臺階。AWR 自動運行以收集有關 Oracle 系統操作的數據并將捕獲的數據存儲到數據庫中。AWR 設計輕便，能夠對其使用的存儲空間進行自行管理，這樣您最終獲得的性能數據信息庫將不會大于捕獲數據的數據庫。在完成默認安裝后，AWR 將每 30 分鐘捕獲一次數據，并將清除超過 7 天的舊數據。可以對數據保存的頻率和時間長度進行配置。還可以執行手動快照。

AWR 捕獲先前由 Statspack 捕獲的所有數據以及以上所述的新數據。這些被捕捉到的數據允許進行系統級和用戶級分析，又一次減少了為診斷問題所進行的重復工作負載需求。最優化的執行確保了捕捉到的數據被高效執行，以實現企業運營開支的最小化。這些優化的一個示例就是對 SQL 語句的捕捉。在這些數據庫中運行時，我們維持 SQL 語句數據在快照之間的增量。這使我們能夠高效地只捕獲上個快照后對系統負載具有顯著影響的語句(通過不同的維度，如 CPU 和已用時間等)，而不必捕獲自從它們首次出現在系統中之后所有已執行一個闞值級別以上工作的語句(以前則出現這種情況)。這既提高了 SQL 捕獲的性能，另一方面又大幅降低了隨著時間不斷捕獲 SQL 語句的數量。

3 自動數據庫診斷監控程序:預防性診斷

以 AWR 中捕獲的數據為基礎，Oracle 數據庫 10g 包含自動數據庫診斷監控程序 (ADDM)，一個內置于數據庫中的整體自我診斷引擎。做一個醫學上的類比，使用 ADDM 就像到您的全科醫生那里看病一樣。它查看整個系統，進行診斷，然后提供處理方法建議，或者可能求助于專家程序，即其它 10g 顧問程序組件，如 SQL 調整顧問程序。由于 ADDM 在每次 AWR 統計值捕獲后自動運行，因此您可能將其看作是每 30 分鐘進行一次定期排定的性能檢查。就像醫生無論您屬于哪個種族都會為您提供治療一樣，ADDM 將以同等方式自如處理任何類型的數據庫，OLTP、數據倉庫或這些類型的混合。

ADDM [圖 1] 檢查 AWR 中所捕捉的數據，前瞻性地分析并確定系統面臨的主要問題，同時在多數情況下建議解決方案，并量化預期的利益。ADDM 對系統性能采取整體分析，使用時間作為組件間的通用單位。

ADDM 的目標是識別系統中那些消耗“數據庫時間”最多的一些領域。ADDM 再深入分析并查明這些問題的根源所在，而不只是提供故障現象和匯報該問題對整個系統影響。如果提出建議后，它將匯報其預期的收益，同樣也是時間方面的收益。時間吞吐量的使用允許對一些問題的影響或建議進行比較。先前的許多問題都是基于價值判斷和經驗，而不是量化影響來識別的。.擁有較高登錄量的系統就是一個很好的示例。單憑經驗法則可能會得出這樣一個結論:每秒登錄的數量超過 10 就是個應該修復的問題并需解決。但許多系統都可以大幅度地運行更高的登錄率，而不會明顯影響系統的性能。在 AWR 中使用新的時間模型數據，ADDM 能夠作出量化匯報，如登錄系統時間占耗費于數據庫全部時間的 20%。該量化值可以使任何需要修復問題或安排它進行修復的任何人更容易相信，而不只是進行“我認為您進行了次數的登錄太多了”這樣的陳述。在最高級別，ADDM 使用時間模型和等待模型數據檢查時間耗費在數據庫中的哪些方面，并下鉆自上而下樹結構規則集。ADDM 內部使用的分類樹基于 Oracle HQ 中的 Oracle 服務器技術性能組和其他性能專家的的性能調整經驗。這些分類規則的大多數已經在 Oracle 內部工具中得到使用，Oracle Support 組織成功使用這些內部工具用于處理 Statspack 文件已有一年多。

在這些問題中，某些問題先前可以通過執行 Statspack 報表分析來檢測，而其它問題(如識別在 Java 中耗費大量時間的 SQL 語句以及識別過量檢查點的原因)則必須通過執行附加診斷工作才能確定;ADDM 不僅限于執行等同于 Statspack 分析的工作。

數據庫性能頁由三個部分組成，并在單個屏幕上顯示主機信息、用戶活動和吞吐量。通過此信息，數據庫管理員先驗證計算機是否有足夠的 CPU 和內存資源可用，然后對數據庫進行分析。然后，可以通過“活動會話”圖形(顯示用戶對 CPU 的使用程度以及是否有用戶正在等待資源而非正在運行 CPU)評估數據庫的運行狀況。最后，該頁面顯示了一個吞吐量圖形，用于判斷吞吐量是否受到計算機資源、CPU 消耗或資源爭用的影響。

“活動會話”圖形包含大量數據。其中的圖表在 Y 軸上顯示了由等待類和 CPU 分解的活動會話的平均數。該數字表示數據庫上的平均負載。Oracle 實例上包含 200 已連接的并正并發工作的會話，但如果只有10 個會話在某個時間點活動，則圖形上的活動會話的數目將為 10。該數據每 15 秒鐘刷新一次，以便可以實時對問題進行分析。

4 結論

Oracle 數據庫性能診斷是數據庫管理員職責的重要部分，從以往來看，它消耗了大量的時間和投入，但在確保回報方面卻收效甚微。Oracle 數據庫 10g 中的 ADDM、AWR 和 ASH 的預防性自動診斷功能為數據庫管理員提供了結果和建議，從而可以將精力投入到將為系統吞吐量帶來最大好處的方面。用于支持這些的代碼規范還增強了企業管理器支持的實時反應式調整方法。

與傳統監控系統相比，該診斷所需的成本(無論是資金方面的成本還是已使用的系統資源方面的成本)低很多。最終，客戶(您)將從 Oracle 數據庫 10g 提供的各種自我管理創新性功能中獲得明顯的好處。

參考文獻:

[1] 趙伯山.Oracle Database 10g 實用培訓教程[M].北京:清華大學出版社，2005.

[2] 馬樹奇譯.OCP:Oracle 10g 新特性學習指南[M].北京:電子工業出版社，2005.

[3] Oracle[EB/OL].http://www.oracle.com.