Awr-Oracle10g新特性—工作量自動收集-性能調(diào)優(yōu)當數(shù)據(jù)庫發(fā)生了性能問題時，如何去定位？比較常用的方法是采用一個既定的模式：解決諸如“是不是同一問題的再現(xiàn)？”、“是否在某一特殊時間段發(fā)生？”、“兩個問題之間是否存在聯(lián)系？”等問題，這樣通常能得到一個比較好的診斷結(jié)果。作為一個DBA，你可能使用一個第三方或者自己開發(fā)的工具來收集數(shù)據(jù)庫運行期間的精細統(tǒng)計數(shù)據(jù)，并從中得到性能度量數(shù)據(jù)。你需要將這些發(fā)生問題時的度量數(shù)據(jù)與當前數(shù)據(jù)進行比較。重現(xiàn)以前的時間能使現(xiàn)在的問題變得明朗。因此，持續(xù)的收集相關(guān)統(tǒng)計數(shù)據(jù)對于性能分析來說十分重要。在某些情況下，在解決收集統(tǒng)計數(shù)據(jù)這方面的問題上有自己內(nèi)置的工具——statspack。盡管在某些情況下的作用非常大，但它缺乏解決性能問題所必須的健壯性。提供了一個標志性的改進特性：自動工作量存儲（AutomaticWorkloadRepositoryAWR）。AWR是隨著數(shù)據(jù)庫一起被安裝的，它不僅能收集統(tǒng)計數(shù)據(jù)，還能從統(tǒng)計數(shù)據(jù)中分析出度量數(shù)據(jù)。通過運行$ORACLE_HOME/rdbms/admin目錄下的awrrpt.sql腳本可以生產(chǎn)AWR從統(tǒng)計和度量數(shù)據(jù)中分析報告。這個分析報告最能體現(xiàn)出AWR的性能分析能力。這個腳本看起來很像statspack，它會列出所有可用的AWR快照并要求輸入兩個特定的快照編號作為一個間隔段。它能產(chǎn)生兩種類型的輸出：文本格式（除了AWR統(tǒng)計信息外和statspack報告基本類似）和默認的格式（通過超連接等方式來提供一個友好的界面）。下面來運行以下這個腳本，對它產(chǎn)生的分析報告及AWR的性能分析能力做一個認識。AWR的使用首先來了解一下AWR是如何設(shè)計的，并了解一下它的構(gòu)造。基本上來說，AWR應(yīng)該是一個Oracle用來收集性能相關(guān)統(tǒng)計數(shù)據(jù)并從中得出性能度量數(shù)據(jù)來追蹤潛在問題的內(nèi)置工具。和statspack不一樣，AWR的快照信息是由一個新的后臺進程MMON及其線程來每隔一個小時自動收集的。為了節(jié)省空間，這些收集的數(shù)據(jù)會在7天后自動清除。快照收集的頻率和保留時間都是可以被用戶修改的。可以通過以下腳本查看當前的設(shè)置：SQL>selectsnap_interval,retentionfromdba_hist_wr_control;SNAP_INTERVALRETENTION--------------------------------------+0000001:00:00.0+0000700:00:00.0這個結(jié)果表明當前的快照是每隔一個小時收集一次，并且會被保留7天。要改變這個設(shè)置，比如需要設(shè)置成每隔半小時收集一次，并且只保留3天，可以使用以下語句（參數(shù)的單位都是分）：SQL>begin2dbms_workload_repository.modify_snapshot_settings(3interval=>30,4retention=>3*24*605);6end;SQL>selectsnap_interval,retentionfromdba_hist_wr_control;SNAP_INTERVALRETENTION--------------------------------------+0000000:30:00.0+0000300:00:00.0oracle10G性能調(diào)優(yōu)2011-01-0421:18了解使用Oracle10g新顧問程序的方法，消除調(diào)優(yōu)工作中的猜測。"自動"一詞似乎已經(jīng)毫無限制地應(yīng)用于Oracle數(shù)據(jù)庫10g的許多新特性當中了--如自動數(shù)據(jù)庫診斷監(jiān)測器（ADDM）、自動工作量信息庫（AWR）、自動空間管理和自動SQL調(diào)優(yōu)。但是，先不要認為Oracle正在設(shè)法讓我們失業(yè)，應(yīng)把"自動"理解為"自動駕駛儀"，而不是"自動開罐器"。沒有人會僅僅因為飛機上的儀器內(nèi)置了某些智能而使其能在高空飛行，就建議將機長從駕駛艙撤出。同樣，對于數(shù)據(jù)庫調(diào)優(yōu)，即使是專家也可能使用一些智能性建議。我們都已采用TKPROF、ExplainPlan和Statspack等工具來確保獲得最佳性能。我們已經(jīng)重新運行統(tǒng)計、刪除統(tǒng)計、修改init.ora參數(shù)、創(chuàng)建索引、刪除索引、重新編寫SQL，采用了各種方法，以尋求更好的性能。利用數(shù)據(jù)庫管理員的技巧包來找出問題點的解決方案固然有其優(yōu)點，但這也是重復(fù)而耗時的。Oracle數(shù)據(jù)庫10g內(nèi)置的自動調(diào)優(yōu)功能不僅提供了這些功能，還提供了更多功能，并達到了極致--性能最佳的數(shù)據(jù)庫--運行速度極快。這都基于Oracle數(shù)據(jù)庫該版本所內(nèi)置的新的智能型基礎(chǔ)架構(gòu)。智能型基礎(chǔ)架構(gòu)Oracle數(shù)據(jù)庫10g綜合的智能型基礎(chǔ)架構(gòu)可對整個數(shù)據(jù)庫進行探測，使數(shù)據(jù)庫能夠在運行過程中對其自身進行監(jiān)測和診斷，并通知數(shù)據(jù)庫管理員出現(xiàn)了問題，數(shù)據(jù)庫管理員便可采取有效的糾正措施。簡要地說，Oracle數(shù)據(jù)庫10g中這種新的智能型基礎(chǔ)架構(gòu)的幾個關(guān)鍵組件包括AWR、ADDM和一個"自動顧問程序"（automaticadvisors）數(shù)組，它們可以使數(shù)據(jù)庫管理員避免許多猜測和重復(fù)勞動。簡單地說，AWR包含了Statspack所提供的功能，還會匯總大量新的統(tǒng)計數(shù)據(jù)。AWR會收集、處理和維護性能統(tǒng)計數(shù)據(jù)（默認情況下，AWR每60分鐘進行一次數(shù)據(jù)快照），用于問題檢測和自我調(diào)優(yōu)，并將所收集的數(shù)據(jù)存儲在可由ADDM來分析的數(shù)據(jù)庫中。ADDM蘊含了Oracle公司內(nèi)外許多Oracle專家的集體智慧，可為有效管理和診斷數(shù)據(jù)庫性能提供基礎(chǔ)性的知識和分析。它進行"根本原因"（root-cause）分析，并跨幾種重要的數(shù)據(jù)庫對象類（如應(yīng)用程序、模式和內(nèi)存利用率）提出具體建議。例如，對于一個特定的模式對象，ADDM要確定"對數(shù)據(jù)庫塊的讀寫爭用耗費大量的數(shù)據(jù)庫時間，"并給出此結(jié)論的報告（在通過命令行生成的ADDM報告中或通過Oracle企業(yè)管理器［OEM］控制臺進行）。這樣一個結(jié)論的詳細信息中可能還會包括這樣一個事實：向需要空閑列表的表中插入數(shù)據(jù)存在著一種高級插入方式。同時會建議："考慮在一個本地管理的表空間中使用Oracle的自動段空間管理……"建議還可以包括：對數(shù)據(jù)庫資源消耗多于共享的SQL語句運行特定的顧問程序?qū)υ挕Ｔ谝院蟮膶谥校覍⑻接慉DDM、AWR及其他一些利用了這一新基礎(chǔ)架構(gòu)智能的新顧問程序。優(yōu)化器改進在這批新工具和智能型基礎(chǔ)架構(gòu)中，數(shù)據(jù)庫管理員能最快享受到的好處之一是快速而輕松地調(diào)優(yōu)SQL語句。SQL調(diào)優(yōu)顧問程序使你可以在不修改源代碼的情況下調(diào)優(yōu)SQL語句。這一特性很有用，尤其是對打包的應(yīng)用程序，例如，當你等待廠家的補丁程序時，但是它也可以用于任何SQL的調(diào)優(yōu)（例如，通過游標高速緩存，或指定一個SQL文本串）。在進行詳細討論之前，我們先簡要地看一看這一特殊顧問程序（明確地講是優(yōu)化器）所依賴的隱含功能的概況。一般來講，OracleSQL性能的核心是Oracle基于成本的優(yōu)化器（CBO），該組件對獲得數(shù)據(jù)的可能途徑進行評估，并從許多可能的備選方案中生成最佳執(zhí)行計劃。執(zhí)行計劃定義了Oracle數(shù)據(jù)庫執(zhí)行語句所用的步驟組合；它們包括語句所訪問的每個表的訪問方法以及這些表的排序（連接順序）。優(yōu)化器可確定執(zhí)行特定SQL語句的最有效方式。對于任一特定的SQL語句，指定其有效的可選方式的可能數(shù)目后，優(yōu)化器會對它們進行快速評估，在一秒鐘之內(nèi)生成一個執(zhí)行計劃。除了優(yōu)化器的這一所謂"正常"模式外，Oracle數(shù)據(jù)庫10g現(xiàn)在還提供一種"調(diào)優(yōu)"模式（在Oracle文獻中有時稱作"自動調(diào)優(yōu)優(yōu)化器"）。正如其名稱意義所示，優(yōu)化器的調(diào)優(yōu)模式明確地用于SQL調(diào)優(yōu)對話（使用SQL調(diào)優(yōu)顧問程序和SQL訪問顧問程序），以生成可在運行時加速性能的附加信息。調(diào)優(yōu)模式包含了正常模式的性能，同時還提供擴展功能，因此它能夠在創(chuàng)建執(zhí)行計劃的過程中進行進一步的分析。在調(diào)優(yōu)模式下，優(yōu)化器進行四個關(guān)鍵級別的分析，生成可以為優(yōu)化器返回SQL語句結(jié)果提供附加信息的統(tǒng)計數(shù)據(jù)：SQL統(tǒng)計數(shù)據(jù)分析。優(yōu)化器會檢查缺少或陳舊的統(tǒng)計數(shù)據(jù)，并給出適當?shù)慕ㄗh--例如，為指定的數(shù)據(jù)庫對象收集統(tǒng)計數(shù)據(jù)--以確保生成最佳執(zhí)行計劃。（優(yōu)化器還會生成附加信息，如果建議的措施未被采用，這些信息會存儲在一個在運行時使用的SQL附加信息集合中）。SQL附加信息集合。優(yōu)化器會進行更廣泛的分析，并匯總可以使查詢運行更為理想的必要附加信息，將其存儲在一個SQL附加信息集合中。SQL附加信息集合包含的信息可以使SQL編譯器對特定的SQL文本的執(zhí)行計劃進行優(yōu)化。SQL附加信息集合在運行時使用（當優(yōu)化器返回正常模式時），用于提高SQL的性能，但不改變源代碼。SQL訪問分析。優(yōu)化器對訪問方式進行分析，核查索引是否處于最佳使用狀態(tài)，如果不是，則建議適當?shù)貏?chuàng)建索引，以提供更快的訪問方式。（可以單獨運行不同的SQL訪問顧問程序工具來匯總所有訪問結(jié)構(gòu)的建議--特別是物化視圖、物化視圖記錄和整個SQL工作量的索引。在以后的專欄中我會介紹這一工具。）SQL結(jié)構(gòu)分析。當優(yōu)化器構(gòu)建執(zhí)行計劃、給出提高性能的建議時，它會分析SQL語句的結(jié)構(gòu)（語義、語法和設(shè)計），生成大量的注釋和診斷。例如，為了顯著提高性能，優(yōu)化器可能會建議用NOTEXISTS代替NOTIN，盡管NOTEXISTS在語義上與NOTIN不同，但它們所產(chǎn)生的結(jié)果相同。（不過，只有在該查詢的相關(guān)連接列中沒有NULL值時，你才應(yīng)該這樣更改--這就是SQL調(diào)優(yōu)顧問程序讓你來決定是否采用結(jié)構(gòu)分析所生成建議的原因。）如果在"綜合"模式下運行SQL調(diào)優(yōu)顧問程序，四個分析都會進行；但是SQL統(tǒng)計數(shù)據(jù)分析、SQL訪問分析和SQL結(jié)構(gòu)分析只在"有限"模式下進行--不生成SQL附加信息集合。如果你想調(diào)優(yōu)應(yīng)用程序代碼，如含有打包應(yīng)用程序的代碼，你應(yīng)使用綜合模式，以確保獲得SQL附加信息集合。優(yōu)化器的調(diào)優(yōu)模式在SQL調(diào)優(yōu)顧問程序和SQL訪問顧問程序?qū)υ捚陂g使用。在綜合模式下使用SQL調(diào)優(yōu)顧問程序來為一個或多個SQL語句生成SQL附加信息集合可能會花很長時間--優(yōu)化器在忙于匯總和生成附加統(tǒng)計數(shù)據(jù)和注釋。不過，通過更改默認設(shè)置值（30分鐘），可以限制優(yōu)化器花在特定調(diào)優(yōu)任務(wù)上的時間。不過，在調(diào)優(yōu)SQL語句，尤其是在處理打包應(yīng)用程序（其SQL源代碼不能直接控制）時，使用SQL附加信息集合將提供極大的好處。SQL調(diào)優(yōu)顧問程序可以在OEM基于Web的新控制臺接口內(nèi)的很多地方啟動，也可以通過DBMS_SQLTUNE包用（AQL*Plus）命令行來進行訪問。要使用SQL調(diào)優(yōu)顧問程序（或任何其他顧問程序），都需要具有ADVISOR（顧問程序）權(quán)限（Oracle數(shù)據(jù)庫10g版本最新提供；默認情況下，數(shù)據(jù)庫管理員具有ADVISOR權(quán)限）。ADDM：Oracle10g診斷功能的中樞新的自管理Oracle數(shù)據(jù)庫的一個創(chuàng)新就是診斷自身性能問題的能力。Oracle數(shù)據(jù)庫10g中包括一個內(nèi)置于數(shù)據(jù)庫核心的自診斷引擎，叫做自動數(shù)據(jù)庫診斷監(jiān)測器（ADDM）。ADDM以較短的定期間隔（默認為30分鐘）自動監(jiān)測數(shù)據(jù)庫狀態(tài)，提供持續(xù)的數(shù)據(jù)庫性能診斷。ADDM（以及顧問程序）中的很多數(shù)據(jù)都會根據(jù)相應(yīng)的數(shù)據(jù)類型顯示為圖形--如按時間繪制的線圖、條形圖、餅狀圖，因此這些信息一目了然。除了查看主動ADDM分析的結(jié)果之外，還可以使用OEM的PL/SQL接口通過OEM或命令行手動運行ADDM。ADDM對潛在的瓶頸進行自頂向下的分析，得出包括根本原因和帶有原理闡述建議的一組分析結(jié)果。除了識別問題以外，ADDM還對每個問題對系統(tǒng)總體性能有多大影響及解決該問題后會得到多少好處進行報告。這種影響－好處分析有助于數(shù)據(jù)庫管理員將精力集中在那些解決后能獲得最大性能收益的問題上。主動調(diào)優(yōu)對話期的調(diào)優(yōu)步驟無論是調(diào)優(yōu)單個語句還是調(diào)優(yōu)具有不同來源（ADDM、AWRTopSQL或二者組合）的一系列語句，所有的調(diào)優(yōu)活動都是以創(chuàng)建調(diào)優(yōu)任務(wù)為起點的。對于打包應(yīng)用程序，占用太多資源的SQL代碼很可能會顯現(xiàn)在由特定SQL_ID標識的OEMTopSQL頁中（在Oracle數(shù)據(jù)庫10g中，每個SQL語句現(xiàn)在都由一個SQL_ID來標識）。以下是從命令行使用DBMS_SQLTUNE包來調(diào)優(yōu)SQL語句的方法。步驟1創(chuàng)建調(diào)優(yōu)任務(wù)以標識SQL語句。在本例中，SQL文本是指使用綁定變量的語句。create_tuning_task(sql_text=>'select*fromempwhereemp_id=:bnd',bind_list=>sql_binds(anydata.ConvertNumber(100)),user_name=>'scott',scope=>'comprehensive',time_limit=>60,task_name=>'my_sql_tuning_task',description=>'tasktotuneaqueryonaspecifiedemployee');因為本例任務(wù)中的時限被定為60，所以我們允許優(yōu)化器用整整一分鐘時間來進行分析。還要注意作用域參數(shù)的"綜合"設(shè)置，它意味著由優(yōu)化器進行、用以提高性能的任何附加分析都可以在SQL附加信息集合中獲得。要調(diào)優(yōu)打包應(yīng)用程序中的SQL，需要找出其SQL_ID［如果它引出了問題（例如），就可以在OEM的TopSQL頁找到它，或通過查詢新框架（SQL_ADVISOR_%）的表］，并按下面代碼所示創(chuàng)建調(diào)優(yōu)任務(wù)：create_tuning_task(sql_id=>'q1rsx05369psft');根據(jù)優(yōu)化器實際所用時間（直至最高時限）的不同，create_tuning_task函數(shù)最終會返回一個可標識該任務(wù)的獨特的字符ID；此ID可與其他API一起使用［例如interrupt（中斷）、cancel（取消）、drop（刪除）］。步驟2現(xiàn)在已經(jīng)有了此任務(wù)，并具備了我們的參數(shù)設(shè)置，但若不執(zhí)行并啟動進程，它什么都不會做。要執(zhí)行此調(diào)優(yōu)任務(wù)：execute_tuning_task(task_name=>'my_sql_tuning_task');任務(wù)完成后會返回提示。該任務(wù)的執(zhí)行結(jié)果會在后臺被發(fā)送到該新框架（基礎(chǔ)架構(gòu)）所依賴的表中。你可以使用DBA_ADVISOR_%視圖（DBA_ADVISOR_FINDINGS、DBA_ADVISOR_RECOMMENDATIONS等）之類的許多新視圖來查詢這些表，其中存儲著執(zhí)行結(jié)果和建議。步驟3通過調(diào)用report_tuning_task過程來查看結(jié)果：setlong10000;selectreport_tuning_task(task_name=>'my_sql_tuning_task')fromdual;report_tuning_task過程生成任務(wù)結(jié)果的完整報告，其中包括執(zhí)行結(jié)果和建議，以及輸出到控制臺的內(nèi)容。（OEM也能達到同樣的詳細程度。）步驟4適當?shù)夭杉{建議。假定已在綜合模式下運行了該調(diào)優(yōu)任務(wù)，并生成了一個SQL附加信息集合，則可以通過執(zhí)行accept_sql_profile命令來使用SQL附加信息集合：accept_sql_profile(taskname=>'my_sql_tuning_task',name=>'my_sql_profile');上例中的name是可選項；如果未給出name，系統(tǒng)會為該附加信息集合生成一個惟一名稱。接受SQL附加信息集合會將其永久地存儲到數(shù)據(jù)字典中，在運行時會用到它：應(yīng)用程序下次運行時，優(yōu)化器（返回"正常"模式）將在后臺使用該附加信息集合來加速應(yīng)用該優(yōu)化器的SQL語句性能，而與其來源（打包應(yīng)用程序或其他）無關(guān)。什么會更容易呢？結(jié)論至少可以這樣說，Oracle數(shù)據(jù)庫10g中可管理性的新改進非常豐富，它為當今忙得不可開交的數(shù)據(jù)庫管理員提供了一個得力的"自動駕駛儀"。本專欄介紹的只是SQL調(diào)優(yōu)顧問程序新功能的皮毛。SQL調(diào)優(yōu)功能可以輕松地提高任何SQL代碼的性能，包括打包應(yīng)用程序中的SQL代碼，而無需修改源代碼，數(shù)據(jù)庫管理員也不必指出要向優(yōu)化器發(fā)送哪些提示來提高性能。這一新基礎(chǔ)架構(gòu)所提供的功能和眾多新的顧問程序都不會取代數(shù)據(jù)庫管理員，但它們將使我們能夠?qū)Ｗ⒂诠ぷ髦懈刑魬?zhàn)性和更有趣的部分。Oracle10g調(diào)優(yōu)：Oracle10gAWR使用方法及分析如何分析AWR(1)Kaya發(fā)表于如果關(guān)注數(shù)據(jù)庫的性能，那么當拿到一份AWR報告的時候，最想知道的第一件事情可能就是系統(tǒng)資源的利用情況了，而首當其沖的，就是CPU。而細分起來，CPU可能指的是OS級的User%,Sys%,Idle%DB所占OSCPU資源的Busy%DBCPU又可以分為前臺所消耗的CPU和后臺所消耗的CPU如果數(shù)據(jù)庫的版本是11g，那么很幸運的，這些信息在AWR報告中一目了然:OS級的%User為75.4，%Sys為2.8，%Idle為21.2，所以%Busy應(yīng)該是78.8。DB占了OSCPU資源的69.1，%BusyCPU則可以通過上面的數(shù)據(jù)得到：

%BusyCPU=%TotalCPU/(%Busy)*100=69.1/78.8*100=87.69，和報告的87.7相吻合。如果是10g呢，則需要手工對Report里的一些數(shù)據(jù)進行計算了。HostCPU的結(jié)果來源于DBA_HIST_OSSTAT，AWR報告里已經(jīng)幫忙整出了這段時間內(nèi)的絕對數(shù)據(jù)(這里的時間單位是centisecond,也就是1/100秒)這里，%User=USER_TIME/(BUSY_TIME+IDLE_TIME)*100=146355/(152946+41230)*100=75.37%Sys

=SYS_TIME/(BUSY_TIME+IDLE_TIME)*100%Idle=IDLE_TIME/(BUSY_TIME+IDLE_TIME)*100值得注意的，這里已經(jīng)隱含著這個AWR報告所捕捉的兩個snapshot之間的時間長短了。有下面的公式BUSY_TIME+IDLE_TIME=ELAPSED_TIME*CPU_COUNT正確的理解這個公式可以對系統(tǒng)CPU資源的使用及其度量的方式有更深一步的理解。因此ELAPSED_TIME=(152946+41230)/8/100=

242.72seconds當然，這正確無誤。至于DB對CPU的利用情況，這就涉及到10g新引入的一個關(guān)于時間統(tǒng)計的視圖了，v$sys_time_model，簡單而言，Oracle采用了一個統(tǒng)一的時間模型對一些重要的時間指標進行了記錄，具體而言，這些指標包括:1)backgroundelapsedtime2)backgroundcputime3)RMANcputime(backup/restore)1)DBtime2)DBCPU2)connectionmanagementcallelapsedtime2)sequenceloadelapsedtime2)sqlexecuteelapsedtime2)parsetimeelapsed3)hardparseelapsedtime4)hardparse(sharingcriteria)elapsedtime5)hardparse(bindmismatch)elapsedtime3)failedparseelapsedtime4)failedparse(outofsharedmemory)elapsedtime2)PL/SQLexecutionelapsedtime2)inboundPL/SQLrpcelapsedtime2)PL/SQLcompilationelapsedtime2)Javaexecutionelapsedtime2)repeatedbindelapsedtime我們這里關(guān)注的只有和CPU相關(guān)的兩個:backgroundcputime和DBCPU。這兩個值在AWR里面也有記錄:TotalDBCPU=DBCPU+backgroundcputime=1305.89+35.91=1341.8seconds再除以總的BUSY_TIME+IDLE_TIME%TotalCPU=1341.8/1941.76=69.1%，這剛好與上面Report的值相吻合。其實，在LoadProfile部分，我們也可以看出DB對系統(tǒng)CPU的資源利用情況。用DBCPUperSecond除以CPUCount就可以得到DB在前臺所消耗的CPU%了。這里5.3/8=66.25%比69.1%稍小，說明DB在后臺也消耗了大約3%的CPU，這是不是一個最簡單的方法了呢？如何分析AWR(2)Kaya發(fā)表于上一篇提到了DBCPU，這是一個用于衡量CPU的使用率的重要指標。假設(shè)系統(tǒng)有N個CPU，那么如果CPU全忙的話，一秒鐘內(nèi)的DBCPU就是N秒。如何去表征一個系統(tǒng)的繁忙程度呢？除了利用CPU進行計算外，數(shù)據(jù)庫還會利用其它計算資源，如網(wǎng)絡(luò)，硬盤，內(nèi)存等等，這些對資源的利用同樣可以利用時間進行度量。假設(shè)系統(tǒng)有M個session在運行，同一時刻，有的session可能在利用CPU，有的session可能在訪問硬盤，那么，在一秒鐘內(nèi)，所有session的時間加起來就可以表征系統(tǒng)在這一秒內(nèi)的繁忙程度，一般的，這個和的最大值應(yīng)該為M。這其實就是Oracle提供的另一個重要指標：DBtime，它用以衡量前端進程所消耗的總時間。對除CPU以后的計算資源的訪問，Oracle用等待事件進行描述。同樣地，和CPU可分為前臺消耗CPU和后臺消耗CPU一樣，等待事件也可以分為前臺等待事件和后臺等待事件。DBTime一般的應(yīng)該等于DBCPU+前臺等待事件所消耗時間的總和。等待時間通過v$system_event視圖進行統(tǒng)計，DBTime和DBCPU則是通過同一個視圖，即v$sys_time_model進行統(tǒng)計。LoadProfile一節(jié)就有了對DBTime的描述:這個系統(tǒng)的CPU個數(shù)是8，因此我們可以知道前臺進程用了系統(tǒng)CPU的7.1/8=88.75%。DBTime/s為11.7，可以看出這個系統(tǒng)是CPU非常繁忙的。里面CPU占了7.1，則其它前臺等待事件占了11.7–7.1=4.6WaitTime/s。DBTime占DBCPU的比重呢？7.1/11.7=60.68%Top5TimedEvents，或許很多人都對它有所耳聞，按照CPU/等待事件占DBTime的比例大小，這里列出了Top5。如果一個工作負載是CPU繁忙型的話，那么在這里應(yīng)該可以看到DBCPU的影子。注意到，我們剛剛已經(jīng)算出了DBCPU的%DBtime，60%。其它的externaltableread,directpathwrite,PXDeq:readcredit,PXDeq:SlaveSessionStats這些就是占比重40的等待事件里的Top4了。回過頭再再研究下這個Top5TimedForegroundEvents，如果先不看LoadProfile，你能說出這個一個CPU-Bound的工作負載嗎？答案是否定的，要知道系統(tǒng)CPU的繁忙程序，還要知道這個AWR所基于兩個snapshot的時間間隔，還要知道系統(tǒng)CPU的個數(shù)。要不，系統(tǒng)可以是一個很IDLE的系統(tǒng)呢。記住CPU利用率=DBCPU/(CPU_COUNT*ElapsedTIME)。這個Top5給我們的信息只是這個工作負載應(yīng)該是并行查詢，從外部表讀取數(shù)據(jù)，并用insertappend的方式寫入磁盤，同時，主要時間耗費在CPU的運算上。上面提到，DBTime一般的應(yīng)該等于DBCPU+前臺等待事件所消耗時間的總和。在下面有對這三個值的統(tǒng)計：DBCPU=6474.65DBTIME=10711.2FGWaitTime=1182.63明顯的，DBCPU+FGWaitTime<DBTime，只占了71.5%其它的28.5%被消耗到哪里去了呢？這里其實又隱含著一個Oracle如何計算DBCPU和DBTime的問題。當CPU很忙時，如果系統(tǒng)里存在著很多進程，就會發(fā)生進程排隊等待CPU的現(xiàn)象。在這樣，DBTIME是把進程排隊等待CPU的時間算在內(nèi)的，而DBCPU是不包括這一部分時間。這是造成DBCPU+FGWaitTime<DBTime的一個重要原因。如果一個系統(tǒng)CPU不忙，這這兩者應(yīng)該就比較接近了。不要忘了在這個例子中，這是一個CPU非常繁忙的系統(tǒng)，而71.5%就是一個信號，它提示著這個系統(tǒng)可能是一個CPU-Bound的系統(tǒng)。如何分析AWR(3)Kaya發(fā)表于除了DBCPU，DBTime，或許另一個比較常用的指標應(yīng)該是IO的利用情況。關(guān)于IO的指標就比較多了，單單在LoadProfile里面就有5個，在DBTime和DBCPU的下面：這5個指標的值都來自v$systat視圖，分別是：RedoSize:‘redosize’Logicalreads=’sessionlogicalreads’or(’dbblockgets’+‘consistentgets’)BlocksChanges=‘dbblockchanges’Physicalreads=‘physicalreads’Physicalwrites=‘physicalwrites’具體指標的解釋參考DatabaseReference.如何得到系統(tǒng)大致的MBPS呢？MBPS=(Physicalreads+Physicalwrites)*Block_Size=(196,271.4+2.0)*8*1024/1024/1024=1533MB/s更準確的MBPS可以從InstanceActivityStats部分獲得。physicalIOdiskbytes=physicalreadtotalbytes+physicalwritetotalbytes值得注意的是這里physicalwritetotalbytes大致是physicalwritebytes的兩倍。這應(yīng)該是physicalwritetotalbytes統(tǒng)計的是磁盤的IO，而這里，我們做了ASM，normalredundancy，一份數(shù)據(jù)寫了兩遍的原因。LoadProfile剩下的部分主要是關(guān)于各種執(zhí)行情況的統(tǒng)計，除了W/AMBprocessed來自v$pgastat（單位其實也是Byte，不是MB），其它數(shù)據(jù)都是來自于v$sysstat。BlocksChanges:‘dbblockchanges’Usercalls:

‘usercalls’Parses:‘parsecount(total)’Hardparses:‘parsecount(hard)’Logons:‘logonscumulative’Executes:

‘executecount’Rollbacks:‘userrollbacks’Tranasactions:‘userrollbacks’+‘usercommits’W/AMBprocessed:‘bytesprocessed’一般而言，Hardparses<Parses<Executes<UserCalls。AWR的一般性介紹我想差不多就這些了，其它部分的介紹借助于一些更具體的AWR報告進行分析可能會更加方便和清晰。如何分析AWR(4)Kaya發(fā)表于如果這個系列是按“總-分-總”組織的話，接下來的系列應(yīng)該是進行“分”這一部分了。構(gòu)建DSS系統(tǒng)的第一步離不開數(shù)據(jù)加載，通過文本文件加載是最常見的方式，Oracle提供了外部表加載的方法，即把一個文本文件當成一個正常的表來進行操作，通過類似insert/*+append*/intotableselectfromexternal_table的方式進行加載。數(shù)據(jù)加載是一個CPU-Bound的過程，不過是通過什么工具，externaltable也好，sqlldr也好，imp也好，impdp也好。換句話說，如果連數(shù)據(jù)加載都出現(xiàn)IO瓶頸，這個系統(tǒng)的配置就說不過去了。這個過程的AWR報告會是怎么樣子的呢？先做個一般的假定，從外部表加載數(shù)據(jù)到一個本地分區(qū)表。Top5TimedEvents類似下面：如果去抓取這段時間DBA_HIST_ACTIVE_SESS_HISTORY的數(shù)據(jù)，并轉(zhuǎn)換為圖表的話，我們會得到更形象的Top10WaitEvents.（如何實現(xiàn)這一步可以參考用Oracle實現(xiàn)ASH的數(shù)據(jù)透視圖）enq:HV–contention是什么東西呢？在11.2以前，對于分區(qū)表的paralleldirect-pathload，Oracle采用的是brokeredload的方式，即所有的PXSlaves共享對每個分區(qū)的highwatermark的訪問，通過輪流持有highwatermark實現(xiàn)對每個segment添加新的blocks。這種方法對于充分利用ext