The Self-Managing Database: Automatic Performance Diagnosis（一）原文翻譯

自管理資料庫：自動效能診斷

An Oracle White Paper Nov. 2003

今天開始翻譯這個文件，暫時還比較粗糙，有些東東覺得沒有用就沒翻，有些不知道怎麼翻的，慚愧。

原文：http://www.oracle.com/technology/products/manageability/database/pdf/twp03/TWP_manage_automatic_performance_diagnosis.pdf

INTRODUCTION
企業資料庫在大小和數量上持續增長，其結果就是系統管理和維護的複雜性增加。ORACLE 10g資料庫整合了一系列自我管理的功能以簡化管理，提高效率，降低和系統管理相關的消耗，且無論對哪種工作流都適用。
這個白皮書討論了oracle新的效能怎段和監控技術的結構和元件，這些新的功能將整合到資料庫伺服器，並可以通過OEM實現。這個技術極大的簡化了oracle資料庫的診斷和調整。這個白皮書中主要討論的元件包括Automatic Workload Repository (AWR), Automatic Database Diagnostic Monitor (ADDM), and Oracle Enterprise Manager (EM).這些元件的最根本的功能是檢測oracle資料庫，產生診斷統計。

PROBLEM OVERVIEW
資料庫的效能優化是一個自然科學、藝術和巫術都一直在探討的問題，通常認為是個非常複雜的工作，耗時且需要豐富的經驗和解決問題的技巧。。。。。
調整資料庫是否真的是非常困難的？是不是需要非常熟悉oracle資料庫的將近200個引數和很多的函式？更多的調整經驗是不是比更少的好？答案是 NO。
你是不是經常調整這些不可思議的引數以提高資料庫的效能？現在有了一個好的訊息，在oracle 10g，我們可以使你夢想成真，所有你需要做的就是設定：
_MAKE_SQL_RUN_FASTER = TRUE
在你的初始化檔案中，這個引數設定將會你企業中的每個資料庫執行的更快而不會出現下降趨勢。真的，我們有沒有告訴你，我們有一手好牌是你可以興奮得工作而且拿到加薪。。。。。

ISSUES WITH ACCURATE PROBLEM DIAGNOSIS
在執行對系統的任何改變之前，一個至關重要的步驟是執行準確和及時地問題診斷。一些DBA經常發現一些徵兆，然後立即修改系統設定以消除這些徵兆。任何作過真正效能優化的人都會建議你正確的診斷問題可以更好的提高成功解決問題的可能性。
雖然如此，我們仍然發現很多DBA花費了大量的時間用來解決災難系統的效能問題而不是努力去解決效能可能出現的問題。很多時候，隱患的派出結果可能就是效能的提高。通常情況下，隱患消除是因為DBA知道如何去消除隱患，他曾經遇到過類似的問題，並且認為這可能是問題的反覆，但是很不幸的是，並不是每次都是這樣。
這些相關的調整可能是冗餘的，可能修復了一個問題，但是導致了系統另一個部分的瓶頸。通常情況下，為了診斷出問題所在，需要首先診斷出問題是工作流的哪個部分導致的，並且在開啟更多的細節診斷後重複該工作流的工作。稱為：workload replay.工作流的充做並不是每次都是可能的，基於以下的原因：
1、標示出的工作流其實只是導致問題的一個微不足道的部分。
2、大量的資料庫不能在生產資料庫上被重做。
這兩個因素將會導致問題在數週甚至數月時間內都不能診斷出問題所在。

OVERVIEW OF ORACLE DATABASE 10G DIAGNOSTIC BENEFITS
自動資料庫診斷監控（ADDM）提供以下好處：
1、每小時自動效能診斷報告
2、基於近十年的經驗進行問題診斷
3、基於時間的量化問題的影響和推薦的好處
4、標示根本原因，而不是徵兆
5、因為在自動工作流資料庫（AWR）中已經完整記錄了資料的變化，因此減少了重複工作流以細節分析需要

REACTING TO AN ORACLE PERFORMANCE PROBLEM
為了證明新的oracle 10g的效能校正的作用，我們現在需要估計在10g之前解決一個效能問題需要的步驟，並且對比在10g中的方法。相同的問題將出現非常不同的診斷結論。你可能猜到了，在10g的版本中，這個工作將比以前簡單很多。
降低了診斷工作將使DBA有更多的時間用來解決問題，這也是我們主張的DBA真正應該做的工作。

Pre-Oracle Database 10g – The Before Image
1、在這一節中，我們將看一個在10g之前的版本中診斷出存在效能問題例子：
2、一個DBA收到一個使用者（或者報警日誌）的有關係統很慢的抱怨
3、這個DBA檢查伺服器看到還有大量的資源可以使用，所以很明顯，速度變慢的原因不是因為機器馬力不夠。
4、然後，他檢查資料庫，看到大量的程式在等待‘latch free’
5、鑽取到latches中，他看到大部分的latch free在等待on ‘library cache’ 和 ‘shared pool’ latches.
6、從以往的經驗和他曾經看到過的資料資料上，DBA知道這些latches經常和硬解析（hard parsing）相關。再次檢查有關‘parse time elapsed’ 和 ‘parse time cpu’的統計，發現增長。It is also observed that the elapsed time is accumulating much faster than CPU time so the suspicion is confirmed.（最後一句沒看懂，怎麼就確定的之前的猜測呢）
7、到了這一步，DBA有很多的辦法可以確定不均勻的資料分配。一個辦法就是檢查所有程式的‘parse count(hard)’統計察看是不是有一個或者多個程式是造成硬解析的主要原因。另一個可選的辦法是檢查shared pool判斷是不是有很多統計是針對相同的SQL執行計劃但是對應不同的sql指令碼的。在我們的例子裡，DBA將採用後一種方法發現只有少量的執行計劃，每個對應很多不同的sql指令碼。
8、重新察看這些SQL語句中的一部分發現這些SQL中包含字串在where語句中所以每個語句必須被單獨解析。
9、在看到這些情況之後DBA可以說導致問題的最根本的原因就是沒有繫結變數導致的重新解析，下一步就可以解決這些問題了。
10、在執行了這些步驟之後DBA可以用他的經驗診斷出問題所在，如果其中某一步出現錯誤的決定都將導致時間和精力的浪費。

Oracle Database 10g - The After Image
對於相同的例子，我們在oracle 10g中可以看到顯而易見的不同：
1、一個DBA收到一個使用者（或者報警日誌）的有關係統很慢的抱怨
2、這個DBA檢查了最後一次的ADDM報告（下面的附件中給出了完全的例子），首先推薦看這裡：
=======================================================================
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%的時間用來解析，推薦如何做以解決這個問題。注意這裡還包含了一個猜想的計劃雜湊值以快速的檢查一些例子語法。另外DBA沒有增加額外的管理費用。
這個例子很好的體現了10g自動診斷校正的作用。

INTELLIGENT INFRASTRUCTURE
oracle的效能診斷的能力不是偶然出現的。調整專家需要理解資料庫的工作方式和他們可以做什麼以影響資料庫的方法。為了提供這個新的功能，oracle伺服器的編碼方式發生了顯著的修改。

Database Statistics
資料庫的每個新的版本都增加了新的效能統計以提供給我們在資料庫中的診斷方式。10g中我們特別提供了用以提高自動診斷效能的功能。當問題不好診斷的時候我們就可以依賴於工具使問題簡化。

 

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