作為一個數(shù)據(jù)庫治理員，您可能已經(jīng)投資購買了第三方工具或使用自己開發(fā)的工具來在數(shù)據(jù)庫運行期間采集具體的統(tǒng)計數(shù)據(jù)，并從這些統(tǒng)計數(shù)據(jù)中導(dǎo)出獲得性能量度。在緊急的情況下，您可以訪問這些量度來與當(dāng)前的情況作比較。再度查看這些過去的事件可以給當(dāng)前的問題帶來一些啟發(fā)，因此不斷采集相關(guān)的統(tǒng)計數(shù)據(jù)對于性能分析變得很重要。 一段時間以來，Oracle 在這個領(lǐng)域中的解決方案是它內(nèi)置的工具 Statspack。雖然某些情況下證實它是非常有價值的，但經(jīng)常缺少性能故障診斷實踐所需的強健性。Oracle Database 10g 提供了一個顯著改進(jìn)的工具：自動工作負(fù)載信息庫 (AWR)。AWR 和數(shù)據(jù)庫一起安裝，不但采集統(tǒng)計數(shù)據(jù)，還采集導(dǎo)出的量度。 快速測試驅(qū)動程序 通過運行 $ORACLE_HOME/rdbms/admin 目錄中的 awrrpt.sql 腳本，AWR 的功能可以立即通過它從采集的統(tǒng)計數(shù)據(jù)和量度中生成的報表得到最好的說明。這個腳本從外觀和感覺上類似于 Statspack，它顯示所有的現(xiàn)有 AWR 快照并請求兩個特定的快照作為時間間隔邊界。它產(chǎn)生兩種類型的輸出：文本格式（類似于 Statspack 報表的文本格式但來自于 AWR 信息庫）和默認(rèn)的 Html 格式（擁有到部分和子部分的所有超鏈接），從而提供了非常用戶友好的報表。現(xiàn)在運行該腳本以查看報表，從而對 AWR 的功能有一個了解。 實施 現(xiàn)在，讓我們來看看 AWR 是如何設(shè)計和構(gòu)建的。AWR 實質(zhì)上是一個 Oracle 的內(nèi)置工具，它采集與性能相關(guān)的統(tǒng)計數(shù)據(jù)，并從那些統(tǒng)計數(shù)據(jù)中導(dǎo)出性能量度，以跟蹤潛在的問題。與 Statspack 不同，快照由一個稱為 MMON 的新的后臺進(jìn)程及其從進(jìn)程自動地每小時采集一次。為了節(jié)省空間，采集的數(shù)據(jù)在 7 天后自動清除。快照頻率和保留時間都可以由用戶修改。要查看當(dāng)前的設(shè)置，您可以使用下面的語句： select snap_interval, retentionfrom dba_hist_wr_control;SNAP_INTERVAL　 RETENTION------------------- -------------------+00000 01:00:00.0　 +00007 00:00:00.0 這些 SQL 語句顯示快照每小時采集一次，采集的數(shù)據(jù)保留 7 天。要修改設(shè)置 — 例如，快照時間間隔為 20 分鐘，保留時間為兩天 — 您可以發(fā)出以下命令。參數(shù)以分鐘為單位。 begin　 dbms_workload_repository.modify_snapshot_settings (　interval => 20,　retention => 2*24*60　 );end; AWR 使用幾個表來存儲采集的統(tǒng)計數(shù)據(jù)，所有的表都存儲在新的名稱為 SYSAUX 的特定表空間中的 SYS 模式下，并且以 WRM$_* 和 WRH$_* 的格式命名。前一種類型存儲元數(shù)據(jù)信息（如檢查的數(shù)據(jù)庫和采集的快照），后一種類型保存實際采集的統(tǒng)計數(shù)據(jù)。（您可能已經(jīng)猜到，H 代表“歷史數(shù)據(jù) (historical)”而 M 代表“元數(shù)據(jù) (metadata)”。）在這些表上構(gòu)建了幾種帶前綴 DBA_HIST_ 的視圖，這些視圖可以用來編寫您自己的性能診斷工具。視圖的名稱直接與表相關(guān)；例如，視圖 DBA_HIST_SYSMETRIC_SUMMARY 是在WRH$_SYSMETRIC_SUMMARY 表上構(gòu)建的。 AWR 歷史表采集的信息比 Statspack 多許多，這些信息包括表空間使用率、文件系統(tǒng)使用率、甚至操作系統(tǒng)統(tǒng)計數(shù)據(jù)。這些表的完整的列表可以通過以下命令從數(shù)據(jù)字典中看到： select view_name from user_views where view_name like 'DBA_HIST_%' escape ''; 視圖 DBA_HIST_METRIC_NAME 定義 AWR 采集到的重要的量度、它們所屬的組和采集它們的單位。例如，下面是一個記錄（豎直格式）： DBID　: 4133493568GROUP_ID　: 2GROUP_NAME: System Metrics Long DurationMETRIC_ID : 2075METRIC_NAME　 : CPU Usage Per SecMETRIC_UNIT　 : CentiSeconds Per Second 它顯示一個量度“每秒 CPU 使用率”以“每秒的厘秒數(shù)”為單位進(jìn)行測量，并且該量度屬于一個量度組 “System Metrics Long Duration”。這條記錄可以和其它的表（如 DBA_HIST_SYSMETRIC_SUMMARY）結(jié)合，以獲得數(shù)據(jù)庫的活動信息，形式如下： select begin_time, intsize, num_interval, minval, maxval, average, standard_deviation sd from dba_hist_sysmetric_summary where metric_id = 2075;BEGININTSIZE NUM_INTERVAL　 MINVAL　MAXVAL　AVERAGE　 SD----- ---------- ------------　 ------- ------- --------　----------11:39 179916　 30 0　333　9.8155354811:09 180023　 3021　35　 28　5.91543912... and so on ... 下面我們看看 CPU 時間是如何消耗的（以厘秒為單位）。標(biāo)準(zhǔn)差加入到了我們的分析中，它有助于確定平均數(shù)字是否反映了實際的工作負(fù)載。在第一條記錄中，平均值是每秒消耗 CPU 時間 3 厘秒，但標(biāo)準(zhǔn)差是 9.81，這意味著平均值 3 不能反映工作負(fù)載。在第二個例子中，平均值為 28，標(biāo)準(zhǔn)差為 5.9，這更具有代表性。這種類型的信息趨勢有助于了解幾個環(huán)境參數(shù)對性能量度的影響。使用統(tǒng)計數(shù)據(jù) 迄今為止，我們看到了 AWR 所采集的內(nèi)容，現(xiàn)在讓我們看看它將如何處理數(shù)據(jù)。 大多數(shù)性能問題并不是孤立存在的，而留有指示性的跡象，這些跡象將通向問題最終的根源。讓我們使用一個典型的調(diào)整實踐來說明這一點：您注重到系統(tǒng)很慢，于是決定查看等待的原因。您檢查發(fā)現(xiàn)“緩沖區(qū)忙等待”非常高。問題可能出在哪里呢？有幾種可能：可能有一個單調(diào)增加的索引，可能一個表太滿了，以至于要求將單個數(shù)據(jù)塊非常快速地加載到內(nèi)存中，或其它一些因素。無論在哪種情況下，您都首先要確定存在問題的段。假如它是一個索引段，那么您可以決定重新構(gòu)建它，把它修改為一個反向鍵索引，或把它轉(zhuǎn)換成一個在 Oracle Database 10g 中引進(jìn)的散列分區(qū)索引。假如它是一個表，您可以考慮修改存儲參數(shù)來使它不那么密集，或者利用自動段空間治理把它轉(zhuǎn)移到一個表空間中。 您的處理計劃一般是有規(guī)律的，并且通常基于您對各種事件的了解和您處理它們的經(jīng)驗。現(xiàn)在設(shè)想相同的事情由一個引擎來完成，這個引擎采集量度并根據(jù)預(yù)先確定的邏輯來推出可能的計劃。您的工作不就變得更輕松了嗎？ 現(xiàn)在在 Oracle Database 10g 中推出的這個引擎稱為自動數(shù)據(jù)庫診斷監(jiān)控程序 (ADDM)。為了作出決策，ADDM 使用了由 AWR 采集的數(shù)據(jù)。在上面的討論中，ADDM 可以看到發(fā)生了緩沖區(qū)忙等待，然后取出相應(yīng)的數(shù)據(jù)來查看發(fā)生緩沖區(qū)忙等待的段，評估其特性和成分，最后為數(shù)據(jù)庫治理員提供解決方案。在 AWR 進(jìn)行的每一次快照采集之后，調(diào)用 ADDM 來檢查量度并生成建議。因此，實際上您擁有了一個一天二十四小時工作的自動數(shù)據(jù)庫治理員，它主動地分析數(shù)據(jù)并生成建議，從而把您解放出來，使您能夠關(guān)注更具有戰(zhàn)略意義的問題。 要查看 ADDM 建議和 AWR 信息庫數(shù)據(jù)，請使用在名稱為 DB Home 的頁面上的新的 Enterprise Manager 10g 控制臺。要查看 AWR 報表，您可以從治理轉(zhuǎn)至工作負(fù)載信息庫，然后轉(zhuǎn)至 Snapshots 來查看它們。在以后的部分中，我們將更具體地討論 ADDM。 您還可以指定根據(jù)特定的情況來生成警報。這些警報稱為服務(wù)器生成警報，它們被推送到高級隊列中，在其中它們可以被任意監(jiān)聽它的客戶端使用。一個這樣的客戶端是 Enterprise Manager 10g，在其中警報被突出顯示。 時間模型 當(dāng)您有性能問題時，要縮短響應(yīng)時間您最先想到的是什么？很明顯，您希望消除（或減少）增加時間的因素的根源。您如何知道時間花費在哪里 — 不是等待，而是真正在進(jìn)行工作？ Oracle Database 10g 引進(jìn)了時間模型，以確定在各個地方花費的時間。花費的總的系統(tǒng)時間記錄在視圖 V$SYS_TIME_MODEL 中。下面是查詢和輸出結(jié)果。 STAT_NAME VALUE------------------------------------- --------------DB time　 58211645DB CPU54500000background cpu time　 254490000sequence load elapsed time0parse time elapsed1867816hard parse elapsed time　 1758922sql execute elapsed time　57632352connection management call elapsed time　 288819failed parse elapsed time 50794hard parse (sharing criteria) elapsed time220345hard parse (bind mismatch) elapsed time　 5040PL/SQL execution elapsed time 197792inbound PL/SQL rpc elapsed time　 0PL/SQL compilation elapsed time