從最終權(quán)威那兒獲得關(guān)于 SQL 調(diào)整的幫助：該權(quán)威就是 Oracle 數(shù)據(jù)庫(kù)本身！使用 SQL 配置文件進(jìn)行查詢，并了解如何使用 ADDM 來快速、輕松解決常見的性能問題。 迄今為止這是平靜的一天：在數(shù)據(jù)庫(kù)中沒有重大問題發(fā)生，不需要去滅“火”。您幾乎可以放松一下了；接下來正好可以抓緊處理那些重要任務(wù)了，如對(duì) RMAN 調(diào)整參數(shù)或多個(gè)塊大小進(jìn)行調(diào)整等。 忽然，一位開發(fā)人員出現(xiàn)在您面前。他的 SQL 查詢要運(yùn)行很長(zhǎng)一段時(shí)間。他問您是否能盡快調(diào)整該查詢使其能夠“工作”。 也許您放松得太早了。您最初的日程安排是花些時(shí)間制定戰(zhàn)略決策，以使您的數(shù)據(jù)庫(kù)運(yùn)行得更好、更快、更安全。例如，確保數(shù)據(jù)庫(kù)是可恢復(fù)的，增強(qiáng)底層技術(shù)或研究安全性更新等等。相反，您將又花一天的時(shí)間集中處理 SQL 等戰(zhàn)術(shù)活動(dòng)，而很少或沒有時(shí)間來考慮戰(zhàn)略問題。 作為一名戰(zhàn)略 DBA，您想把自己從日常瑣事中解脫出來，更多地關(guān)注那些引人深思的領(lǐng)域。讓一名助理 DBA 幫助您做那些瑣事難道不好嗎？ 有了 Oracle 數(shù)據(jù)庫(kù) 10g，您就有了一位自動(dòng)數(shù)據(jù)庫(kù)診斷監(jiān)控程序 (ADDM) 形式的助理 DBA，這種機(jī)器人式的 DBA 會(huì)不知倦怠地反復(fù)搜索數(shù)據(jù)庫(kù)性能統(tǒng)計(jì)，以標(biāo)識(shí)瓶頸、分析 SQL 語句、并據(jù)此提供多種改進(jìn)性能的建議，它通常與其他“顧問”（如 SQL Tuning Advisor）一起使用。在這篇文章中，對(duì)該過程的工作方式進(jìn)行了概述。 自動(dòng)數(shù)據(jù)庫(kù)診斷監(jiān)控程序 (ADDM) 在第 6 周，您了解到被稱作快照的自動(dòng)負(fù)載信息庫(kù) (AWR)，它定期從數(shù)據(jù)庫(kù)中收集具體的與性能相關(guān)的度量標(biāo)準(zhǔn)。每次快照后，調(diào)用 ADDM 來徹底分析源自快照間差異的數(shù)據(jù)和度量標(biāo)準(zhǔn)，然后就必要的操作提出建議。正如我早先所提及的，發(fā)現(xiàn)問題后，ADDM 可能會(huì)依次調(diào)用其他顧問（如 SQL Tuning Advisor），來提出改進(jìn)建議。 我將為您完全展示（而不是用文字來解釋）這種特性是如何運(yùn)行的。假定您正設(shè)法診斷一個(gè)不可解釋的性能問題。在我們介紹的示例中，您知道了哪些 SQL 語句需要調(diào)整，或至少知道了哪些 SQL 語句存在問題。但是在現(xiàn)實(shí)生活中，您可能沒有這些有用信息。 要在 10g 中執(zhí)行診斷，您將在相關(guān)的時(shí)間間隔內(nèi)選擇快照進(jìn)行深入、透徹的分析。在 Enterprise Manager 10g 中，從 Database 主頁上，您將選擇 'Advisor Central'，然后單擊 'ADDM' 鏈接，它將出現(xiàn)一個(gè)類似于圖 1 的頁面。 圖 1：創(chuàng)建 ADDM 任務(wù)在該頁中，您可以創(chuàng)建 ADDM 要分析的任務(wù)。您知道性能問題發(fā)生在晚上 11 點(diǎn)左右，因此選擇那個(gè)時(shí)間間隔的快照，通過 'Period Start' 和 'Period End' 值進(jìn)行指示。您也可以單擊照相機(jī)圖標(biāo)，指示開始和終止快照的時(shí)間間隔，如此處的紅色橢圓形所示。選擇時(shí)間間隔后，按下 'OK' 按鈕，將出現(xiàn)一個(gè)類似于圖 2 所示的頁面。 圖 2：ADDM 查找結(jié)果這里 ADDM 在該時(shí)間間隔內(nèi)標(biāo)識(shí)了兩個(gè)要害的、相關(guān)的性能問題：某些 SQL 語句消耗著重要的 CPU 時(shí)間，從而使數(shù)據(jù)庫(kù)的速度顯著減慢。基于這些查找結(jié)果，ADDM 建議對(duì)圖中突出顯示的那些語句進(jìn)行 SQL 調(diào)整。 假如您單擊某條查找結(jié)果，ADDM 會(huì)顯示更多具體信息。例如，單擊問題查找結(jié)果，將會(huì)出現(xiàn)一個(gè)類似于圖 3 所示的頁面。 圖 3：ADDM 查找結(jié)果的具體信息在此您可以看到引發(fā)該問題的特定 SQL 語句。ADDM 建議您用 SQL Tuning Advisor 對(duì)該 SQL 語句進(jìn)行徹底的分析，正如在 'Action' 部分中所提到的那樣。您可以通過單擊它旁邊的按鈕立即運(yùn)行該任務(wù)，這將調(diào)用 SQL Tuning Advisor。在圖 2 中，您可能注重到了一個(gè)名稱為 'View Report' 的按鈕。除了在單獨(dú)的 Web 頁面中提供建議外，ADDM 還能夠創(chuàng)建純文本報(bào)表，以進(jìn)行更快速的一步到位的分析。在我們的示例純文本報(bào)表中提出的全面建議。注重報(bào)表是如何給出相關(guān)細(xì)節(jié)的，如所考慮的 SQL 語句、它的散列值等。可以在 Enterprise Manager 的 SQL Tuning Advisor 頁中或通過命令行將 SQL ID 用于獨(dú)立的分析。 在收集了每一張 AWR 快照后就會(huì)調(diào)用 ADDM，因此可以查看基于相鄰快照的建議。因此，假如分析的范圍只是兩張相鄰的快照，就不必創(chuàng)建上面所示的 ADDM 任務(wù)。假如您想在兩張不相鄰的快照之間進(jìn)行分析，就需要?jiǎng)?chuàng)建 ADDM 任務(wù)。 記住 ADDM 所能做的遠(yuǎn)不止這些；正如您在以前的文章中所看到的，它還提供內(nèi)存治理、段治理、重作/撤消以及更多的分析和建議。由于在一篇簡(jiǎn)短的文章中描述所有的 ADDM 功能是不可能的，在此我們只關(guān)注 SQL Tuning Advisor。現(xiàn)在讓我們看看它是如何工作的。 用 SQL Tuning Advisor 訪問分析 在一個(gè)典型的運(yùn)行時(shí)優(yōu)化中，優(yōu)化器生成一組可能的訪問路徑，并基于對(duì)象統(tǒng)計(jì)從中選擇出最“經(jīng)濟(jì)”的路徑。但是，那時(shí)它沒有時(shí)間考慮是否能夠調(diào)整語句、統(tǒng)計(jì)是否陳舊、是否能夠創(chuàng)建索引等問題。相反，SQL Tuning Advisor 可以執(zhí)行這種“專家系統(tǒng)”類型的思考。實(shí)質(zhì)上，優(yōu)化器能夠回答的問題是：“基于可用的資源,獲得結(jié)果的最佳方式是什么？”而 SQL Tuning Advisor 能夠回答的問題是：“基于用戶的需求，還需要做些什么來增強(qiáng)性能？” 正如您可能預(yù)期的那樣，這種“思考”消耗了資源（如 CPU）；因此 SQL Tuning Advisor 在調(diào)整模式期間處理 SQL 語句，該模式可以在非高峰時(shí)間運(yùn)行。在創(chuàng)建調(diào)整任務(wù)時(shí)，通過在函數(shù)中設(shè)置 SCOPE 和 TIME 參數(shù)來指示這種模式。在數(shù)據(jù)庫(kù)活動(dòng)少的期間運(yùn)行調(diào)整模式是一個(gè)好方法，以使常規(guī)用戶相對(duì)不受影響，稍后再進(jìn)行分析。 這個(gè)概念可以通過示例很好地解釋。就看看如下所示的開發(fā)人員引起您注重的那個(gè)查詢事例吧。 select account_no from accounts where old_account_no = 11該語句調(diào)整起來并不難，但是為了更輕易說明問題，假定它很難調(diào)整。激發(fā)顧問的方式有兩種：使用 Enterprise Manager 或簡(jiǎn)單明了的命令行。 首先，讓我們看看如何在命令行中使用它。我們通過調(diào)用提供的包 dbms_sqltune 來調(diào)用顧問。 declarel_task_id varchar2(20);l_sql varchar2(2000);beginl_sql := 'select account_no from accounts where old_account_no = 11';dbms_sqltune.drop_tuning_task ('FOLIO_COUNT');l_task_id := dbms_sqltune.create_tuning_task (sql_text　=> l_sql,user_name　=> 'ARUP',scope　=> 'COMPREHENSIVE',time_limit => 120,task_name　=> 'FOLIO_COUNT');dbms_sqltune.execute_tuning_task ('FOLIO_COUNT');end;/這個(gè)包創(chuàng)建并執(zhí)行了一個(gè)名為 FOLIO_COUNT 的調(diào)整任務(wù)。接下來，您將需要查看任務(wù)執(zhí)行的結(jié)果（也就是說，查看建議）。 set serveroutput on size 999999set long 999999select dbms_sqltune.report_tuning_task ('FOLIO_COUNT') from dual;顯示的輸出結(jié)果仔細(xì)查看這些建議；顧問說您可以通過在 OLD_ACCOUNT_NO 列上創(chuàng)建一個(gè)索引來改進(jìn)性能。更佳的是，假如創(chuàng)建索引，顧問計(jì)算了查詢成本，從而使?jié)撛诘墓?jié)省量變得更加可定義、更加具體。 當(dāng)然，考慮到本示例的簡(jiǎn)單性，通過手動(dòng)檢查也能得到這種結(jié)論。但是，可以想象出該工具對(duì)于那些更復(fù)雜的查詢十分有用，因?yàn)閷?duì)這些查詢執(zhí)行手動(dòng)檢查也許是不可能的或不實(shí)際的。 查詢重構(gòu) 假定查詢更復(fù)雜： select account_no from accounts a where account_name = 'HARRY' and sub_account_name not in ( select account_name from accounts where account_no = a.old_account_no and status is not null);顧問建議如下： 1- RestrUCture SQL finding (see plan 1 in eXPlain plans section)----------------------------------------------------------------The optimizer could not unnest the subquery at line ID 1 of the executionplan.Recommendation　--------------Consider replacing 'NOT IN' with 'NOT EXISTS' or ensure that columns used on both sides of the 'NOT IN' operator are declared 'NOT NULL' by addingeither 'NOT NULL' constraints or 'IS NOT NULL' predicates.Rationale　---------A 'FILTER' operation can be very expensive because it evaluates the subquery for each row in the parent query.The subquery, when unnested candrastically improve the execution time because the 'FILTER' operation isconverted into a join.Be aware that 'NOT IN' and 'NOT EXISTS' mightproduce different results for 'NULL' values.這一次顧問不會(huì)建議任何結(jié)構(gòu)上的更改（如索引），但會(huì)通過用 NOT EXISTS 取代 NOT IN的方式很聰明地猜測(cè)到調(diào)整查詢的正確方式。由于兩種構(gòu)造相似但不相同，顧問給出了這種改變的基本原理，并把決定權(quán)留給 DBA 或應(yīng)用程序開發(fā)人員，由他們決定該建議是否對(duì)環(huán)境有效。