從最終權威那兒獲得關于 SQL 調整的幫助：該權威就是 Oracle 數據庫本身！使用 SQL 配置文件進行查詢，并了解如何使用 ADDM 來快速、輕松解決常見的性能問題。 迄今為止這是平靜的一天：在數據庫中沒有重大問題發生，不需要去滅“火”。您幾乎可以放松一下了；接下來正好可以抓緊處理那些重要任務了，如對 RMAN 調整參數或多個塊大小進行調整等。 忽然，一位開發人員出現在您面前。他的 SQL 查詢要運行很長一段時間。他問您是否能盡快調整該查詢使其能夠“工作”。 也許您放松得太早了。您最初的日程安排是花些時間制定戰略決策，以使您的數據庫運行得更好、更快、更安全。例如，確保數據庫是可恢復的，增強底層技術或研究安全性更新等等。相反，您將又花一天的時間集中處理 SQL 等戰術活動，而很少或沒有時間來考慮戰略問題。 作為一名戰略 DBA，您想把自己從日常瑣事中解脫出來，更多地關注那些引人深思的領域。讓一名助理 DBA 幫助您做那些瑣事難道不好嗎？ 有了 Oracle 數據庫 10g，您就有了一位自動數據庫診斷監控程序 (ADDM) 形式的助理 DBA，這種機器人式的 DBA 會不知倦怠地反復搜索數據庫性能統計，以標識瓶頸、分析 SQL 語句、并據此提供多種改進性能的建議，它通常與其他“顧問”（如 SQL Tuning Advisor）一起使用。在這篇文章中，對該過程的工作方式進行了概述。 自動數據庫診斷監控程序 (ADDM) 在第 6 周，您了解到被稱作快照的自動負載信息庫 (AWR)，它定期從數據庫中收集具體的與性能相關的度量標準。每次快照后，調用 ADDM 來徹底分析源自快照間差異的數據和度量標準，然后就必要的操作提出建議。正如我早先所提及的，發現問題后，ADDM 可能會依次調用其他顧問（如 SQL Tuning Advisor），來提出改進建議。 我將為您完全展示（而不是用文字來解釋）這種特性是如何運行的。假定您正設法診斷一個不可解釋的性能問題。在我們介紹的示例中，您知道了哪些 SQL 語句需要調整，或至少知道了哪些 SQL 語句存在問題。但是在現實生活中，您可能沒有這些有用信息。 要在 10g 中執行診斷，您將在相關的時間間隔內選擇快照進行深入、透徹的分析。在 Enterprise Manager 10g 中，從 Database 主頁上，您將選擇 'Advisor Central'，然后單擊 'ADDM' 鏈接，它將出現一個類似于圖 1 的頁面。 圖 1：創建 ADDM 任務在該頁中，您可以創建 ADDM 要分析的任務。您知道性能問題發生在晚上 11 點左右，因此選擇那個時間間隔的快照，通過 'Period Start' 和 'Period End' 值進行指示。您也可以單擊照相機圖標，指示開始和終止快照的時間間隔，如此處的紅色橢圓形所示。選擇時間間隔后，按下 'OK' 按鈕，將出現一個類似于圖 2 所示的頁面。 圖 2：ADDM 查找結果這里 ADDM 在該時間間隔內標識了兩個要害的、相關的性能問題：某些 SQL 語句消耗著重要的 CPU 時間，從而使數據庫的速度顯著減慢。基于這些查找結果，ADDM 建議對圖中突出顯示的那些語句進行 SQL 調整。 假如您單擊某條查找結果，ADDM 會顯示更多具體信息。例如，單擊問題查找結果，將會出現一個類似于圖 3 所示的頁面。 圖 3：ADDM 查找結果的具體信息在此您可以看到引發該問題的特定 SQL 語句。ADDM 建議您用 SQL Tuning Advisor 對該 SQL 語句進行徹底的分析，正如在 'Action' 部分中所提到的那樣。您可以通過單擊它旁邊的按鈕立即運行該任務，這將調用 SQL Tuning Advisor。在圖 2 中，您可能注重到了一個名稱為 'View Report' 的按鈕。除了在單獨的 Web 頁面中提供建議外，ADDM 還能夠創建純文本報表，以進行更快速的一步到位的分析。在我們的示例純文本報表中提出的全面建議。注重報表是如何給出相關細節的，如所考慮的 SQL 語句、它的散列值等。可以在 Enterprise Manager 的 SQL Tuning Advisor 頁中或通過命令行將 SQL ID 用于獨立的分析。 在收集了每一張 AWR 快照后就會調用 ADDM，因此可以查看基于相鄰快照的建議。因此，假如分析的范圍只是兩張相鄰的快照，就不必創建上面所示的 ADDM 任務。假如您想在兩張不相鄰的快照之間進行分析，就需要創建 ADDM 任務。 記住 ADDM 所能做的遠不止這些；正如您在以前的文章中所看到的，它還提供內存治理、段治理、重作/撤消以及更多的分析和建議。由于在一篇簡短的文章中描述所有的 ADDM 功能是不可能的，在此我們只關注 SQL Tuning Advisor。現在讓我們看看它是如何工作的。 用 SQL Tuning Advisor 訪問分析 在一個典型的運行時優化中，優化器生成一組可能的訪問路徑，并基于對象統計從中選擇出最“經濟”的路徑。但是，那時它沒有時間考慮是否能夠調整語句、統計是否陳舊、是否能夠創建索引等問題。相反，SQL Tuning Advisor 可以執行這種“專家系統”類型的思考。實質上，優化器能夠回答的問題是：“基于可用的資源,獲得結果的最佳方式是什么？”而 SQL Tuning Advisor 能夠回答的問題是：“基于用戶的需求，還需要做些什么來增強性能？” 正如您可能預期的那樣，這種“思考”消耗了資源（如 CPU）；因此 SQL Tuning Advisor 在調整模式期間處理 SQL 語句，該模式可以在非高峰時間運行。在創建調整任務時，通過在函數中設置 SCOPE 和 TIME 參數來指示這種模式。在數據庫活動少的期間運行調整模式是一個好方法，以使常規用戶相對不受影響，稍后再進行分析。 這個概念可以通過示例很好地解釋。就看看如下所示的開發人員引起您注重的那個查詢事例吧。 select account_no from accounts where old_account_no = 11該語句調整起來并不難，但是為了更輕易說明問題，假定它很難調整。激發顧問的方式有兩種：使用 Enterprise Manager 或簡單明了的命令行。 首先，讓我們看看如何在命令行中使用它。我們通過調用提供的包 dbms_sqltune 來調用顧問。 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;/這個包創建并執行了一個名為 FOLIO_COUNT 的調整任務。接下來，您將需要查看任務執行的結果（也就是說，查看建議）。 set serveroutput on size 999999set long 999999select dbms_sqltune.report_tuning_task ('FOLIO_COUNT') from dual;顯示的輸出結果仔細查看這些建議；顧問說您可以通過在 OLD_ACCOUNT_NO 列上創建一個索引來改進性能。更佳的是，假如創建索引，顧問計算了查詢成本，從而使潛在的節省量變得更加可定義、更加具體。 當然，考慮到本示例的簡單性，通過手動檢查也能得到這種結論。但是，可以想象出該工具對于那些更復雜的查詢十分有用，因為對這些查詢執行手動檢查也許是不可能的或不實際的。 查詢重構 假定查詢更復雜： 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.這一次顧問不會建議任何結構上的更改（如索引），但會通過用 NOT EXISTS 取代 NOT IN的方式很聰明地猜測到調整查詢的正確方式。由于兩種構造相似但不相同，顧問給出了這種改變的基本原理，并把決定權留給 DBA 或應用程序開發人員，由他們決定該建議是否對環境有效。