簡(jiǎn)介一份面向 Oracle 數(shù)據(jù)庫(kù)管理員與性能優(yōu)化人員的 AWR 報(bào)告分析指南由黃偉波撰寫(xiě)系統(tǒng)講解 AWR自動(dòng)工作負(fù)載庫(kù)從導(dǎo)出到分析的全流程。內(nèi)容涵蓋 AWR 概念、統(tǒng)計(jì)信息分類(lèi)、STATISTICS_LEVEL 參數(shù)調(diào)優(yōu)、報(bào)告核心元素負(fù)載概況、SQL 報(bào)告、等待事件、活動(dòng)會(huì)話歷史、AWR 維護(hù)與快照管理并演示通過(guò)企業(yè)管理器 EM 與命令行生成多種形式的報(bào)告基線對(duì)比、時(shí)段對(duì)比同時(shí)重點(diǎn)解讀緩沖區(qū)緩存命中率、硬解析次數(shù)、邏輯讀取次數(shù)等關(guān)鍵性能指標(biāo)幫助讀者定位瓶頸并優(yōu)化數(shù)據(jù)庫(kù)配置。整份資源為 1 個(gè) PDF 文件大小 7.13MB內(nèi)容結(jié)構(gòu)按“導(dǎo)出 AWR 報(bào)告—分析 AWR 報(bào)告”組織目錄清晰既有基礎(chǔ)概念也包含操作性示例適合從初級(jí)到中高級(jí)的 DBA 閱讀與查閱。目前已有 225 人學(xué)習(xí)下載是一份偏理論但足夠完整的性能診斷參考手冊(cè)。 做DBA這些年我見(jiàn)過(guò)太多人拿到了Oracle數(shù)據(jù)庫(kù)的AWR報(bào)告翻了幾頁(yè)就擱到一邊嘴里念叨看不懂信息量太大不知道從哪里下手。尤其當(dāng)系統(tǒng)半夜出現(xiàn)性能問(wèn)題第二天早上領(lǐng)導(dǎo)把一份幾百頁(yè)的HTML報(bào)告甩過(guò)來(lái)讓你給出結(jié)論時(shí)那種壓力我太熟悉了。AWRAutomatic Workload Repository自動(dòng)工作負(fù)載信息庫(kù)報(bào)告說(shuō)白了就是Oracle數(shù)據(jù)庫(kù)的行車(chē)記錄儀體檢報(bào)告。它每隔一段時(shí)間自動(dòng)給數(shù)據(jù)庫(kù)拍一張快照記錄當(dāng)時(shí)的負(fù)載、等待事件、SQL執(zhí)行情況、資源消耗等關(guān)鍵指標(biāo)然后通過(guò)awrrpt.sql等腳本生成一份可讀的分析報(bào)告。這份報(bào)告的價(jià)值在于當(dāng)數(shù)據(jù)庫(kù)性能出現(xiàn)問(wèn)題時(shí)它能告訴你過(guò)去這段時(shí)間數(shù)據(jù)庫(kù)到底在忙什么瓶頸卡在哪個(gè)環(huán)節(jié)哪些SQL是罪魁禍?zhǔn)住１疚木蛧@AWR報(bào)告分析這件事從一個(gè)一線DBA的實(shí)際視角把報(bào)告的生成、核心指標(biāo)解讀、根因反推方法以及我踩過(guò)的坑一次性講透。不管你是剛?cè)腴T(mén)的新手還是被性能問(wèn)題折磨的老手這篇文章都能讓你拿到報(bào)告后不再發(fā)怵。1. 報(bào)告生成前必須搞清楚的事快照機(jī)制與生成方法1.1 AWR快照的工作機(jī)制AWR的核心機(jī)制是周期性采樣。默認(rèn)情況下Oracle每60分鐘自動(dòng)采集一次快照Snapshot將數(shù)據(jù)庫(kù)的運(yùn)行狀態(tài)寫(xiě)入SYSAUX表空間中的WRM$_和WRH$_系列表里。這些快照數(shù)據(jù)默認(rèn)保留8天之后會(huì)被自動(dòng)清理。所以你要分析某段時(shí)間的性能問(wèn)題必須確?？煺崭采w了問(wèn)題發(fā)生的時(shí)間窗口。這里有一個(gè)常見(jiàn)誤區(qū)很多人直接把AWR等同于報(bào)告其實(shí)AWR是數(shù)據(jù)倉(cāng)庫(kù)報(bào)告只是基于這些數(shù)據(jù)生成的分析視圖?？煺詹杉臄?shù)據(jù)包括等待事件統(tǒng)計(jì)、時(shí)間模型統(tǒng)計(jì)、SQL執(zhí)行統(tǒng)計(jì)、會(huì)話活動(dòng)統(tǒng)計(jì)、文件I/O統(tǒng)計(jì)、段Segment統(tǒng)計(jì)、系統(tǒng)參數(shù)快照等。知識(shí)點(diǎn)要記牢AWR報(bào)告對(duì)比的是兩個(gè)快照之間的增量數(shù)據(jù)而不是瞬時(shí)狀態(tài)。這意味著快照起點(diǎn)和終點(diǎn)的選擇直接決定了報(bào)告呈現(xiàn)的內(nèi)容。1.2 手動(dòng)生成報(bào)告的完整步驟雖然默認(rèn)每60分鐘自動(dòng)采集一次快照但實(shí)際生產(chǎn)中問(wèn)題往往出現(xiàn)在兩次自動(dòng)快照之間。所以手動(dòng)創(chuàng)建快照、手動(dòng)生成報(bào)告是DBA的基本功。生成單實(shí)例AWR報(bào)告的基本流程# 以sysdba身份登錄數(shù)據(jù)庫(kù) sqlplus / as sysdba # 手動(dòng)創(chuàng)建兩個(gè)快照可選一般建議分析已有快照 exec dbms_workload_repository.create_snapshot(); -- 等待一段時(shí)間讓負(fù)載數(shù)據(jù)被采集 exec dbms_workload_repository.create_snapshot(); # 調(diào)用報(bào)告生成腳本 ?/rdbms/admin/awrrpt.sql腳本執(zhí)行后會(huì)依次提示你輸入報(bào)告類(lèi)型輸入html或text。我強(qiáng)烈建議選html因?yàn)镠TML格式支持顏色標(biāo)注、排序點(diǎn)擊、圖表展示信息密度高且容易定位重點(diǎn)。除非你要做命令行環(huán)境下的快速分析才選text?？煺仗鞌?shù)范圍輸入你要查看的時(shí)間跨度比如1表示查看最近1天的快照。起始快照ID和結(jié)束快照ID這里要注意起始ID必須小于結(jié)束ID且兩個(gè)ID之間的時(shí)間窗口要覆蓋問(wèn)題時(shí)間段。輸出文件名默認(rèn)會(huì)生成awrrpt_1_100_101.html這樣的文件建議改成有意義的名字比如awrrpt_prod_20250117_2200_2300.html方便歸檔和追溯。如果是RAC集群環(huán)境每個(gè)實(shí)例有獨(dú)立的AWR數(shù)據(jù)你需要使用awrrpti.sql腳本并額外指定實(shí)例ID?/rdbms/admin/awrrpti.sql -- 按照提示輸入實(shí)例號(hào)比如 1 或 2這里分享一個(gè)我在實(shí)際運(yùn)維中經(jīng)常用的小技巧分析跨實(shí)例的性能問(wèn)題時(shí)最好分別生成每個(gè)實(shí)例的報(bào)告再做橫向?qū)Ρ?。RAC環(huán)境下負(fù)載不均衡的情況非常常見(jiàn)單看匯總報(bào)告容易掩蓋某個(gè)實(shí)例的異常。1.3 快照權(quán)限與歷史數(shù)據(jù)查詢不是所有數(shù)據(jù)庫(kù)用戶都有權(quán)限生成AWR報(bào)告。手動(dòng)生成報(bào)告需要DBA角色或者被授予ADVISOR權(quán)限。如果使用的是云數(shù)據(jù)庫(kù)如阿里云RDS、AWS RDS權(quán)限往往受限你需要通過(guò)云平臺(tái)自帶的管理控制臺(tái)生成報(bào)告命令行的方式不一定可行。如果需要查看歷史快照信息可以查詢數(shù)據(jù)字典視圖-- 查詢數(shù)據(jù)庫(kù)現(xiàn)有的快照列表 select snap_id, instance_number, to_char(begin_interval_time, yyyy-mm-dd hh24:mi) as begin_time, to_char(end_interval_time, yyyy-mm-dd hh24:mi) as end_time from dba_hist_snapshot order by snap_id desc;通過(guò)這個(gè)視圖你可以快速定位哪個(gè)快照覆蓋了問(wèn)題時(shí)間段避免盲目生成報(bào)告。我傾向于在生產(chǎn)系統(tǒng)出問(wèn)題后第一時(shí)間先查快照列表確認(rèn)快照沒(méi)有缺失再?zèng)Q定是否需要手動(dòng)補(bǔ)快照?？煺杖笔У膯?wèn)題我在后面專門(mén)講。2. 報(bào)告開(kāi)篇三巨頭DB Time、Elapsed與負(fù)載畫(huà)像拿到AWR報(bào)告大多數(shù)人會(huì)從Report Summary開(kāi)始看。這確實(shí)是正確入口但很多新手只是掃一眼就劃走了。實(shí)際上報(bào)告開(kāi)頭這幾個(gè)指標(biāo)包含了大量信息值得逐項(xiàng)拆解。2.1 DB Time與Elapsed Time的關(guān)系這是AWR報(bào)告中最核心、最先要看的兩個(gè)數(shù)值Elapsed Time快照間隔的墻鐘時(shí)間即這段分析窗口實(shí)際過(guò)去了多久。DB Time數(shù)據(jù)庫(kù)實(shí)例在所有會(huì)話上花費(fèi)的累計(jì)數(shù)據(jù)庫(kù)時(shí)間用戶調(diào)用消耗的CPU時(shí)間等待時(shí)間總和。注意它是累計(jì)值與并發(fā)會(huì)話數(shù)量直接相關(guān)。判斷邏輯很簡(jiǎn)單如果DB Time遠(yuǎn)小于Elapsed Time說(shuō)明數(shù)據(jù)庫(kù)大部分時(shí)間在休息負(fù)載較輕瓶頸大概率不在數(shù)據(jù)庫(kù)內(nèi)部。如果DB Time是Elapsed Time的幾倍甚至幾十倍說(shuō)明數(shù)據(jù)庫(kù)內(nèi)部存在嚴(yán)重的爭(zhēng)用或等待CPU、I/O、鎖競(jìng)爭(zhēng)必居其一。舉個(gè)例子某系統(tǒng)Elapsed Time為60分鐘DB Time為480分鐘說(shuō)明平均有8個(gè)會(huì)話在同時(shí)干活。這時(shí)候你再看DB CPU與Total DB Time的占比如果CPU時(shí)間占比很低而等待時(shí)間占比很高就要重點(diǎn)看等待事件了。2.2 時(shí)間模型里的關(guān)鍵指標(biāo)AWR報(bào)告的Time Model Statistics部分按累計(jì)時(shí)間排序展示了數(shù)據(jù)庫(kù)各項(xiàng)操作的耗時(shí)占比。我通常關(guān)注這幾個(gè)指標(biāo)DB CPU所有會(huì)話消耗的CPU時(shí)間總和。CPU占比高說(shuō)明數(shù)據(jù)庫(kù)在實(shí)打?qū)嵉赜?jì)算SQL執(zhí)行效率可能是關(guān)鍵。sql execute elapsed timeSQL執(zhí)行階段消耗的總時(shí)間。這個(gè)數(shù)值高說(shuō)明SQL層是性能熱點(diǎn)。parse time elapsedSQL解析時(shí)間。如果這個(gè)占比異常高要考慮硬解析過(guò)多的問(wèn)題往往與綁定變量使用不當(dāng)有關(guān)。connection management call elapsed time連接管理耗時(shí)。對(duì)高并發(fā)短連接應(yīng)用系統(tǒng)這個(gè)指標(biāo)會(huì)非常刺眼。時(shí)間模型看的是時(shí)間花到哪里去了它不像等待事件那樣能立刻指向資源瓶頸但能幫你確認(rèn)SQL執(zhí)行層在整個(gè)數(shù)據(jù)庫(kù)運(yùn)行中的權(quán)重?？赐暾麖垐?bào)告后我通常會(huì)回到時(shí)間模型校驗(yàn)一次自己的判斷。2.3 Load Profile系統(tǒng)負(fù)載的速寫(xiě)畫(huà)像Load Profile部分展示的是每秒和每事務(wù)的平均指標(biāo)相當(dāng)于數(shù)據(jù)庫(kù)負(fù)載的速寫(xiě)。這里不需要所有指標(biāo)都看但以下幾項(xiàng)要留意Redo size每秒產(chǎn)生的重做日志量。突然增大說(shuō)明有大量DML操作或批量數(shù)據(jù)寫(xiě)入。Logical reads與Physical reads邏輯讀反映SQL訪問(wèn)的數(shù)據(jù)塊總量物理讀反映實(shí)際磁盤(pán)I/O量。物理讀占比過(guò)高通常意味著B(niǎo)uffer Cache命中率下降或全表掃描過(guò)多。Executes與Transactions每秒鐘執(zhí)行SQL次數(shù)與事務(wù)數(shù)。事務(wù)數(shù)是TPS的直接體現(xiàn)如果TPS暴跌結(jié)合其他指標(biāo)才能判斷是應(yīng)用問(wèn)題還是數(shù)據(jù)庫(kù)問(wèn)題。Hard parse每秒硬解析次數(shù)。數(shù)值長(zhǎng)期偏高說(shuō)明共享池使用效率差大量SQL沒(méi)有復(fù)用執(zhí)行計(jì)劃。Load Profile的意義在于建立基線。比如某系統(tǒng)平時(shí)每秒邏輯讀在300萬(wàn)左右某天突然漲到900萬(wàn)哪怕其他指標(biāo)還沒(méi)異常你也能嗅到SQL執(zhí)行計(jì)劃發(fā)生變化或數(shù)據(jù)量突增的味道。沒(méi)有基線所有數(shù)值都是孤立的有了基線變化本身就會(huì)說(shuō)話。3. 等待事件分析定位瓶頸的核心抓手3.1 Top 10 Foreground Events的正確讀法AWR報(bào)告中最具診斷價(jià)值的部分我認(rèn)為是Top 10 Foreground Events by Total Wait Time。這部分按等待時(shí)間降序列出了前臺(tái)會(huì)話最關(guān)心的等待事件。解讀時(shí)要看三列Wait Time(s)、% DB Time、Wait Class。常見(jiàn)的等待事件分門(mén)別類(lèi)說(shuō)CPU時(shí)間類(lèi)DB CPU被列在等待事件表格中它雖然不是等待但Oracle會(huì)把它排在前面。如果DB CPU排第一且占比超過(guò)30%說(shuō)明數(shù)據(jù)庫(kù)瓶頸在CPU計(jì)算能力通常與低效SQL、全表掃描或排序操作過(guò)多有關(guān)。I/O類(lèi)db file sequential read單塊讀常見(jiàn)于索引掃描、db file scattered read多塊讀常見(jiàn)于全表掃描或索引快速全掃描、direct path read直接路徑讀常見(jiàn)于并行查詢或排序。I/O等待占比高說(shuō)明存儲(chǔ)性能或SQL訪問(wèn)路徑出問(wèn)題。并發(fā)類(lèi)enq: TX - row lock contention行鎖爭(zhēng)用多會(huì)話更新同一行、enq: TM - contention表級(jí)鎖常見(jiàn)于DDL阻塞DML。日志類(lèi)log file sync與log file parallel write。前者反映提交操作等待日志寫(xiě)入磁盤(pán)的耗時(shí)對(duì)OLTP系統(tǒng)中提交頻繁的應(yīng)用影響極大。網(wǎng)絡(luò)類(lèi)SQL*Net message from client這類(lèi)等待說(shuō)明數(shù)據(jù)庫(kù)在等客戶端發(fā)SQL過(guò)來(lái)通常不是數(shù)據(jù)庫(kù)瓶頸。不過(guò)如果在RAC環(huán)境中出現(xiàn)gc cr block busy這類(lèi)集群互連等待就要考慮集群內(nèi)節(jié)點(diǎn)間通信效率問(wèn)題。3.2 通過(guò)等待事件比例反推瓶頸只看等待事件名稱還不夠要結(jié)合% DB Time判斷嚴(yán)重程度。比如log file sync等待占總DB Time的25%意味著數(shù)據(jù)庫(kù)每4秒里就有1秒在等日志寫(xiě)盤(pán)。此時(shí)回看Load Profile中的Redo size如果事務(wù)量并不大那問(wèn)題可能在日志文件所在的存儲(chǔ)設(shè)備上如果事務(wù)量巨大則要考慮批量提交改批量、減少commit頻率等應(yīng)用層面的優(yōu)化。等待事件是并列關(guān)系而非因果關(guān)系這句話請(qǐng)劃重點(diǎn)。比如db file sequential read漲上來(lái)本質(zhì)可能是因?yàn)槟硞€(gè)SQL走了低效的執(zhí)行計(jì)劃做了大量索引范圍掃描。等待事件是結(jié)果SQL才是原因。這也是為什么看等待事件之后永遠(yuǎn)要結(jié)合Top SQL去定位根因而不是停在資源層面。3.3 Instance Activity Stats補(bǔ)充閱讀Instance Activity Stats部分按統(tǒng)計(jì)項(xiàng)名稱展示快照期間的累計(jì)值。對(duì)于等待事件指向I/O時(shí)我建議順手查這幾個(gè)統(tǒng)計(jì)項(xiàng)physical reads和physical writes確認(rèn)I/O壓力是否真實(shí)存在。table scans (long tables)長(zhǎng)表全表掃描次數(shù)這個(gè)數(shù)值如果大通常能和Top SQL中的全表掃描操作對(duì)得上。user commits與user rollbacks確認(rèn)提交頻率用于驗(yàn)證日志類(lèi)等待的推斷。session logical reads邏輯讀總次數(shù)是CPU消耗的重要影響因素。這些統(tǒng)計(jì)項(xiàng)未必每次都看但它們是驗(yàn)證等待事件判斷的有力證據(jù)。分析AWR報(bào)告就像破案等待事件是現(xiàn)場(chǎng)線索實(shí)例統(tǒng)計(jì)是物證SQL是嫌疑人三者能彼此印證結(jié)論才站得住腳。4. SQL統(tǒng)計(jì)與段統(tǒng)計(jì)把根因釘死在SQL層面4.1 SQL ordered by Elapsed Time的結(jié)果解讀AWR報(bào)告的SQL Statistics部分按Elapsed Time、CPU Time、Physical Reads、Executions等多個(gè)維度展示Top SQL。我最常看的是SQL ordered by Elapsed Time和SQL ordered by CPU Time。這里有一個(gè)新手很容易踩的坑只看Elapsed Time排序容易忽略執(zhí)行次數(shù)極少的單次慢SQL也會(huì)把執(zhí)行次數(shù)多但單次很快的SQL當(dāng)作罪魁禍?zhǔn)?。比如某條SQL執(zhí)行了100萬(wàn)次每次0.01秒累計(jì)Elapsed Time是10000秒排第一另一條SQL執(zhí)行了1次耗時(shí)3000秒排第二。從累計(jì)時(shí)間看第一條SQL更貴但從業(yè)務(wù)影響看第二條SQL直接堵住了前臺(tái)頁(yè)面用戶體感是系統(tǒng)卡死了。如果你只優(yōu)化第一條第二條的問(wèn)題依然存在。我的習(xí)慣是優(yōu)先看Executions列區(qū)分高頻小SQL和低頻大SQL。對(duì)高頻SQL重點(diǎn)看單次執(zhí)行的邏輯讀和物理讀確認(rèn)是否有執(zhí)行計(jì)劃劣化。對(duì)低頻大SQL重點(diǎn)看是否做了不必要的全表掃描、排序或嵌套循環(huán)。SQL ordered by Physical Reads也需要盯住。物理讀高意味著大量磁盤(pán)I/O尤其是Physical Reads per Execution這個(gè)比值大時(shí)基本可以斷定SQL訪問(wèn)路徑出了問(wèn)題。這時(shí)候點(diǎn)開(kāi)對(duì)應(yīng)的SQL文本和執(zhí)行計(jì)劃?rùn)z查索引情況多半能發(fā)現(xiàn)缺少索引或索引失效的問(wèn)題。4.2 執(zhí)行計(jì)劃變化不只是看SQL文本拿到Top SQL后務(wù)必將本次AWR報(bào)告中的執(zhí)行計(jì)劃與SQL歷史執(zhí)行計(jì)劃做對(duì)比。AWR本身不直接保存執(zhí)行計(jì)劃歷史但可以借助dba_hist_sql_plan視圖查看-- 查看某條SQL語(yǔ)句在特定快照間的執(zhí)行計(jì)劃變化 select * from table(dbms_xplan.display_awr(sql_id, plan_hash_value));如果發(fā)現(xiàn)同一SQL_id在不同快照中Plan Hash Value不同說(shuō)明執(zhí)行計(jì)劃變了。常見(jiàn)的導(dǎo)致執(zhí)行計(jì)劃變化的因素有表數(shù)據(jù)量增長(zhǎng)、統(tǒng)計(jì)信息過(guò)期、綁定變量窺探Bind Peeking、參數(shù)變化。這時(shí)候要重點(diǎn)分析新執(zhí)行計(jì)劃到底差在哪個(gè)環(huán)節(jié)——是全表掃描替代了索引掃描還是Join順序改變導(dǎo)致中間結(jié)果集膨脹。4.3 Segment Statistics定位熱點(diǎn)對(duì)象Segment Statistics部分按邏輯讀、物理讀、緩沖區(qū)忙等待等維度列出熱點(diǎn)數(shù)據(jù)庫(kù)對(duì)象表、索引、分區(qū)。這部分能幫你快速建立SQL?對(duì)象的對(duì)應(yīng)關(guān)系。例如Segments by Logical Reads排名第一的表恰好是Top SQL中某條SQL訪問(wèn)的表基本可以確定問(wèn)題SQL和這個(gè)表的訪問(wèn)方式有關(guān)。如果這個(gè)表邏輯讀極高但物理讀不高說(shuō)明數(shù)據(jù)已經(jīng)被緩存在Buffer Cache中CPU壓力來(lái)自大量buffer cache的遍歷如果物理讀和邏輯讀雙高說(shuō)明內(nèi)存放不下或者訪問(wèn)路徑根本沒(méi)用上索引。Segments by Buffer Busy Waits也值得關(guān)注。如果某段頻繁出現(xiàn)buffer busy wait可能涉及熱點(diǎn)塊競(jìng)爭(zhēng)——多個(gè)會(huì)話同時(shí)訪問(wèn)同一個(gè)數(shù)據(jù)塊。這在某些全局唯一索引、序列或頻繁更新的小表上很常見(jiàn)。遇到這種情況有時(shí)候要改應(yīng)用邏輯比如減少對(duì)同一行的頻繁更新有時(shí)候要調(diào)整PCTFREE或分區(qū)設(shè)計(jì)單純調(diào)SQL未必有效。5. 從報(bào)告到結(jié)論一次完整的根因推演案例理論講了這么多我拿一個(gè)實(shí)際遇到的案例來(lái)串一遍這樣整個(gè)分析鏈路會(huì)更清晰。某業(yè)務(wù)系統(tǒng)反饋每天晚上8點(diǎn)到9點(diǎn)之間特別慢業(yè)務(wù)人員操作一個(gè)查詢頁(yè)面要等十幾秒。生成這段時(shí)間的AWR報(bào)告后我按如下順序做了分析第一步看DB Time vs Elapsed Time。Elapsed Time約60分鐘DB Time約350分鐘負(fù)載確實(shí)集中在這個(gè)時(shí)段。第二步看Top 10 Foreground Events排第一的是db file sequential read占比約45%其次是DB CPU占比約25%?？吹竭@個(gè)組合我的第一判斷是大量單塊讀——極可能有人在通過(guò)索引做大量逐行訪問(wèn)I/O等待拖慢了整體響應(yīng)。第三步回到Load Profile看Physical reads per second數(shù)值為平時(shí)基線的6倍進(jìn)一步確認(rèn)I/O壓力激增。第四步翻開(kāi)SQL ordered by Physical Reads果然有一條SQL的物理讀次數(shù)遠(yuǎn)超其他SQL。點(diǎn)開(kāi)SQL文本是一張大寬表的主鍵范圍查詢而執(zhí)行計(jì)劃顯示它走了索引全掃描Index Full Scan該索引的葉子塊數(shù)量超過(guò)3萬(wàn)個(gè)。為什么走索引全掃描進(jìn)一步查執(zhí)行計(jì)劃發(fā)現(xiàn)查詢條件里用到了函數(shù)包裹索引列導(dǎo)致索引失效Oracle選擇了掃描整個(gè)索引然后做過(guò)濾。第五步驗(yàn)證將該SQL改為在應(yīng)用層先計(jì)算函數(shù)結(jié)果、再以原始列值查詢或者建立函數(shù)索引物理讀從每分鐘2萬(wàn)次直接降到幾百次頁(yè)面響應(yīng)恢復(fù)正常。這個(gè)案例說(shuō)明AWR報(bào)告分析的真正價(jià)值在于層層遞進(jìn)交叉驗(yàn)證。等待事件給方向Load Profile給量級(jí)Top SQL給抓手執(zhí)行計(jì)劃給根因。任何一步單獨(dú)看都可能誤判但串聯(lián)起來(lái)就是一個(gè)完整的故事。6. 實(shí)戰(zhàn)中的高頻坑快照缺失、RAC誤讀與報(bào)表陷阱6.1 快照缺失和采樣窗口問(wèn)題分析AWR報(bào)告最容易翻車(chē)的情況恰恰是報(bào)告生成本身。我之前遇到過(guò)一個(gè)問(wèn)題數(shù)據(jù)庫(kù)每天早上8點(diǎn)出現(xiàn)CPU飆高但生成的AWR報(bào)告里負(fù)載卻平平無(wú)奇。后來(lái)查了dba_hist_snapshot才發(fā)現(xiàn)8點(diǎn)前后恰好處于兩個(gè)自動(dòng)快照之間的盲區(qū)——問(wèn)題只持續(xù)了10分鐘而快照間隔是60分鐘峰值被平均掉了。解決辦法有兩個(gè)在問(wèn)題高發(fā)時(shí)段提前部署手動(dòng)快照縮小采樣窗口-- 每10分鐘生成一次手動(dòng)快照連續(xù)生成6次覆蓋1小時(shí) begin for i in 1..6 loop dbms_workload_repository.create_snapshot(); dbms_lock.sleep(600); end loop; end; /如果問(wèn)題已經(jīng)發(fā)生且沒(méi)有留存高頻快照退而求其次分析ASHActive Session History報(bào)告。ASH按秒級(jí)采樣會(huì)話活動(dòng)彌補(bǔ)AWR分鐘級(jí)粒度的不足。生成方式類(lèi)似?/rdbms/admin/ashrpt.sql分析方法與AWR一脈相承重點(diǎn)看Top活動(dòng)會(huì)話的等待事件和SQL_ID。6.2 RAC環(huán)境下單實(shí)例報(bào)告的局限RAC環(huán)境中最容易犯的錯(cuò)是只生成某一個(gè)實(shí)例的AWR報(bào)告然后對(duì)整體性能下結(jié)論。例如兩個(gè)節(jié)點(diǎn)的負(fù)載嚴(yán)重不均衡節(jié)點(diǎn)1的DB Time是節(jié)點(diǎn)2的8倍你只看節(jié)點(diǎn)1的報(bào)告會(huì)認(rèn)為系統(tǒng)繁忙到崩潰只看節(jié)點(diǎn)2的報(bào)告會(huì)認(rèn)為系統(tǒng)閑得很。必須分別生成每個(gè)實(shí)例的報(bào)告同時(shí)對(duì)比Global Cache Statistics里的gc cr block receive time、ges messages sent等集群互連指標(biāo)才能判斷是否存在節(jié)點(diǎn)間通信瓶頸。RAC還有一個(gè)隱蔽問(wèn)題同一個(gè)SQL在不同節(jié)點(diǎn)上的執(zhí)行計(jì)劃和性能可能完全不同。分析時(shí)需要按con_id和instance_number分開(kāi)查看SQL在各自節(jié)點(diǎn)的表現(xiàn)。如果只拉匯總報(bào)告這些差異會(huì)被掩蓋。6.3 容易誤判的指標(biāo)陷阱最后列幾個(gè)我在實(shí)際工作中反復(fù)踩過(guò)的指標(biāo)陷阱Buffer Cache命中率陷阱命中率高不代表性能好。如果一個(gè)系統(tǒng)命中率99%但邏輯讀總量高達(dá)每秒500萬(wàn)依然會(huì)消耗巨額CPU。高命中率掩蓋了低效SQL的大量邏輯訪問(wèn)。所以命中率要結(jié)合邏輯讀總量看。Average Active SessionsAAS陷阱AWR首頁(yè)有一個(gè)Avg DB Time per Call指標(biāo)但它是平均數(shù)不能反映峰值。一次大批量報(bào)表跑批可能平均數(shù)字看起來(lái)不高實(shí)際運(yùn)行過(guò)程中瞬間并發(fā)會(huì)話數(shù)已經(jīng)觸頂。SQL ordered by Gets vs Reads邏輯讀Gets和物理讀Reads排序的SQL往往不是同一批。前者影響CPU后者影響磁盤(pán)I/O。優(yōu)化時(shí)要明確目標(biāo)是降CPU還是降I/O不然優(yōu)化方向會(huì)打架。報(bào)告期間重啟數(shù)據(jù)庫(kù)的陷阱如果快照窗口內(nèi)發(fā)生過(guò)數(shù)據(jù)庫(kù)重啟快照數(shù)據(jù)會(huì)中斷部分指標(biāo)比如實(shí)例啟動(dòng)以來(lái)的累計(jì)值會(huì)出現(xiàn)跳變。這種報(bào)告直接放棄重新生成別硬分析。這些坑不是從文檔里看來(lái)的都是我在生產(chǎn)環(huán)境里一個(gè)個(gè)踩出來(lái)的。AWR報(bào)告分析能力的提升本質(zhì)上就是看報(bào)告→被坑→驗(yàn)證判斷→再被坑→再驗(yàn)證的循環(huán)。多分析歷史報(bào)告多和實(shí)際故障現(xiàn)象對(duì)照慢慢就會(huì)形成自己的判斷直覺(jué)。下一次再有人甩一份報(bào)告讓你給結(jié)論你至少知道該從哪里下刀了。本文還有配套的精品資源點(diǎn)擊獲取