自管理的資料庫:自動效能診斷

Oracle 白皮書
2003 年 11月
引言
企業資料庫在大小和數量上的不斷增長使得系統管理的複雜性也隨之增加.Oracle 資料庫 10g(以下稱 Oracle 資料庫 10g)提供了一組整合的自我管理功能,可以在不受工作負載影響的情況下,簡化管理,提高效率以及降低與系統管理相關的成本. 本白皮書論述了 Oracle 新效能診斷和監控技術的基礎架構和部件,該技術內建於資料庫伺服器中,並通過 Oracle Enterprise Manager (EM) 實現外部化.該技術大大簡化了 Oracle 資料庫的診斷和調整過程.本白皮書介紹的主要元件包括自動工作負載資訊庫 (AWR),自動資料庫診斷監控程式 (ADDM) 和 Oracle Enterprise Manager (EM).所有這些元件均建立在Oracle 資料庫程式碼中程式碼規範的基礎上,該程式碼規範生成大量來自 Oracle資料庫的診斷統計資訊.

問題概述
資料庫效能優化已被人看作是一種集半科學,半藝術和半巫術於一身的技術.人們普遍認為,它是一項複雜而耗時的任務,並需要高額的專家諮詢技術.它需要相關人員進行不斷的摸索和實踐,並且只有少數人才有資格執行它.您必須成為該"核心集團"中的一分子才能在效能優化上取得成功.
調整資料庫真的那麼難嗎 它需要深入瞭解如何使用 Oracle 中的 200 個引數以及幾十個特性嗎 是否調整地頻率越大越好 對於這些問題,答案肯定是"否".
您每隔多久搜尋一次那個神奇的下劃線引數,來提高每個 Oracle 資料庫的效能 我們有好訊息要告訴您.在 Oracle 資料庫 10g中,我們將使您夢想成真.您只需在 Oracle 初始化檔案中設定 _MAKE_SQL_RUN_FASTER = TRUE,這樣便會提高企業中每個資料庫的執行速度,並且絕對不會有任何不良影響.這是肯定的.還有,我們是否告訴過您我們可以為您架起一座橋樑,並積極工作來幫助您提高薪水 好吧,還是讓我們進入正題吧!效能診斷和調整主要是指遵循一種邏輯方法.幸運的是,這正好是計算機的看家本領!

與精確的問題診斷相關的問題
在更改系統之前,重要的是對所遇到的問題進行精確,及時的診斷.許多資料庫管理員 (DBA) 通常會研究故障現象,並立即著手更改系統以修復這些故障現象.凡是曾親身執行過效能優化工作的人都會建議您:對實際問題進行精確診斷將大大提高成功解決問題的可能性. 但我們發現,DBA 通常將大量的時間和精力花費在修復效能故障現象上,而不是確定煩擾系統的效能問題上.許多情況下,故障現象修復在效能改進方面見效甚少.之所以經常處理故障現象,是因為 DBA 知道如何解決故障現象.他或她曾經修復過該故障現象,並參與這新一輪的故障現象修復.管理員在進行新一輪故障現象修復時相信:上一輪應用的效能修復方法肯定同樣適用於此次故障現象修復.這一切使他們認為該故障現象至少已經在首次出現時得到了正確地診斷,不幸的是,情況並非始終這樣!
儘管顯得多餘,但不得不說的是,調整是一個迭代過程,解決一個問題可能導致瓶頸移動(或轉移)到系統的另一部分.通常情況下,要診斷效能問題,必須先識別導致問題的工作負載部分,然後在進行更詳細診斷後重複此工作負載.我們將此稱作工作負載重放.由於以下原因可能無法實現工作負載重播:
1. 識別引起問題的工作負載是項重要的工作.
2. 大量應用程式在不設定生產資料庫副本的情況下無法重新執行.
單單這兩個問題通常就會使診斷過程增加幾周甚至幾個月的時間.

Oracle 資料庫 10g 診斷優點概述
內建於 Oracle 資料庫 10g 中的自動資料庫診斷監控程式 (ADDM) 具有以下優點:
1. 每 60 分鐘生成一份自動效能診斷報告
2. 問題診斷基於幾十年的調整經驗
3. 對問題影響進行基於時間的量化並提出建議
4. 識別根本原因,而非故障現象
5. 由於全部資料儲存在自動工作負載資訊庫 (AWR) 中,因此顯著降低了重放工作負載進行詳細分析的需要.

對 Oracle 效能問題的反應
為了演示 Oracle 資料庫 10g 中的新效能功能的有效性,我們將對 Oracle資料庫 10g 釋出之前解決效能問題所需的步驟進行評估,並將其與 Oracle 資料庫 10g 中的方法進行對比.相同的問題方案將產生完全不同的診斷投入.此時您可能已經猜到,10g 中的診斷方法要比先前版本中的診斷方法簡單很多.
降低診斷投入將使 DBA 將時間花在如何解決問題上,在我們看來這正是DBA 的用武之地.

Oracle 資料庫 10g 之前的版本
1. 在本部分中,我們將研究一個示例,該示例演示了在 Oracle 資料庫 10g 之前的版本中診斷效能所涉及的操作:
2. DBA 收到使用者(或警報)抱怨系統速度慢的電話.
3. DBA 檢查伺服器計算機並檢查是否有大量資源可用,很顯然,速度慢並非因計算機資源耗盡而引起.
4. 然後,(他或她)檢視資料庫並看到許多會話正在等待"鎖栓釋放".
5. 通過下鑽鎖栓,他了解到大多數鎖栓釋放等待都在"庫快取"和"共享池"鎖栓上.
6. 根據以往的經驗並參考大量相關書籍,資料庫管理員瞭解到這些鎖栓通常與硬分析問題相關.為了進一步核實,他將檢視統計"已用分析時間"和"分析時間 cpu"的增長率.還將發現已用時間的增長速度遠遠超過 CPU 時間的增長速度,因此懷疑得到證實.
7. 此時,資料庫管理員採用多種方法識別出現偏差的資料分佈.方法之一是檢視所有會話的"分析計數(硬)"統計資訊,以便了解是否有一個或多個會話負責硬分析的主要部分.另一個方法是檢查共享池以確定是否有許多具有 SQL 計劃相同,但 SQL 文字不同的語句.在我們的示例中,DBA 將採用第二種方法,並發現有很少數量的計劃,其中的每個計劃都有許多不同的與之關聯的 SQL 文字.
8. 檢查其中的幾個 SQL 語句後發現,SQL 語句的 WHERE 子句中包含文字字串,因此必須對每個語句單獨進行分析.
9. 由於以往曾遇到過此類情況,因此 DBA 現在可以斷定,此問題的根本原因是由於未使用繫結變數而導致的硬分析,可以繼續修復此問題.
10. 在執行這些步驟時,DBA 必須憑藉他的經驗診斷問題的原因,並可能會很有可能在其中的任何步驟中做出錯誤的決定,從而浪費時間和精力.

Oracle 資料庫 10g
採用相同的示例,我們可以會看到在 Oracle 資料庫 10g 中存在明顯的差異:
1. DBA 收到使用者抱怨速度太慢的電話.
2. DBA 檢查最新的 ADDM 報告(下面的附錄A 提供了完整示例),第一個建議顯示:
FINDING 3: 31% impact (7798 seconds)

------------------------------------

SQL statements were not shared due to the usage of

literals. This resulted in additional hard parses which

were consuming significant database time.

RECOMMENDATION 1: Application Analysis, 31% benefit (7798 seconds)

ACTION: Investigate application logic for possible use of

bind variables instead of literals. Alternatively, you may

set the parameter "cursor_sharing" to "force".

RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033

were found to be using literals. Look in V$SQL for examples

of such SQL statements.

DBA 隨即瞭解到資料庫中 30% 以上的時間用於分析,並獲得如何解決這種情況的建議.注意,該報告還包含一個可疑計劃雜湊值,使資料庫管理員能夠快速檢查幾個示例語句.此外,資料庫管理員未使用該診斷過程增加系統開銷.
該示例著重說明了使用 Oracle 資料庫 10g 的自動診斷功能能夠節省大量的時間和投入.

智慧化的基礎架構
診斷 Oracle 系統中問題的能力不是偶然發生的.調整專家需要了解資料庫的工作方式以及影響資料庫的方法. Oracle 資料庫 10g 的自動診斷功能也不是偶然發生的.為了實現這一新功能,已對 Oracle 伺服器(尤其是程式碼方法部分)進行了許多更改.

資料庫統計
每個新資料庫版本都增加了更多的效能統計,用於診斷資料庫中的問題.10g 增加了幾個新統計,專門用於提高效能問題自動診斷的精確性.在伺服器內部生成一個工具的優點之一是,如果問題難以診斷,則我們可以新增更多的規範來簡化它!

等待類
Oracle 資料庫 10g 中現在可能擁有 700 多個不同的等待事件.事件數目之所以增多,主要是由於為了確保更精確的問題診斷,許多鎖和鎖栓已經作為單獨的等待事件發生.為了實現對等待事件進行更容易的高階分析,等待事件已經劃分為基於解決方案空間的等待類,該空間通常用於解決與等待事件有關的問題.例如, TX 互斥鎖通常是一個應用程式級別的問題,而 HW 鎖定通常是一個配置問題.下面列出了最經常發生的等待類和一些示例:
1. 應用程式 - 由行級別鎖定或顯式鎖定命令導致的鎖定等待

2. 管理 - 導致其他使用者等待類似索引重建的資料庫管理員命令
3. 提交 - 在提交後等待重做日誌寫入確認
4. 併發性 - 並行分析和緩衝區快取鎖栓和鎖爭用
5. 配置 - 過小的日誌緩衝區空間,日誌檔案大小,緩衝區快取大小,共享池大小,ITL 分配,HW 入隊爭用,ST 入隊爭用
6. 使用者 I/O - 等待從磁碟讀取塊
7. 網路通訊 - 等待資料通過網路傳送
8. 空閒 - 表示會話處於非活動狀態(如 'SQL*Net message from client')的等待事件

時間模型

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/51862/viewspace-180614/，如需轉載，請註明出處，否則將追究法律責任。