使用 ADDM 快速輕松解決常見的性能問題

　　從最終權威那兒獲得關於 SQL 調整的幫助該權威就是 Oracle 數據庫本身！使用 SQL 配置文件進行查詢並了解如何使用 ADDM 來快速輕松解決常見的性能問題
　　
　　迄今為止這是平靜的一天在數據庫中沒有重大問題發生不需要去滅火您幾乎可以放松一下了接下來正好可以抓緊處理那些重要任務了如對 RMAN 調整參數或多個塊大小進行調整等
　　
　　突然一位開發人員出現在您面前他的 SQL 查詢要運行很長一段時間他問您是否能盡快調整該查詢使其能夠工作
　　
　　也許您放松得太早了您最初的日程安排是花些時間制定戰略決策以使您的數據庫運行得更好更快更安全例如確保數據庫是可恢復的增強底層技術或研究安全性更新等等相反您將又花一天的時間集中處理 SQL 等戰術活動而很少或沒有時間來考慮戰略問題
　　
　　作為一名戰略 DBA您想把自己從日常瑣事中解脫出來更多地關注那些引人深思的領域讓一名助理 DBA 幫助您做那些瑣事難道不好嗎？
　　
　　有了 Oracle 數據庫 g您就有了一位自動數據庫診斷監控程序 (ADDM) 形式的助理 DBA這種機器人式的 DBA 會不知疲倦地反復搜索數據庫性能統計以標識瓶頸分析 SQL 語句並據此提供多種改進性能的建議它通常與其他顧問（如 SQL Tuning Advisor）一起使用在這篇文章中對該過程的工作方式進行了概述
　　
　　自動數據庫診斷監控程序 (ADDM)
　　您了解到被稱作快照的自動負載信息庫 (AWR)它定期從數據庫中收集詳細的與性能相關的度量標准每次快照後調用 ADDM 來徹底分析源自快照間差異的數據和度量標准然後就必要的操作提出建議正如我早先所提及的發現問題後ADDM 可能會依次調用其他顧問（如 SQL Tuning Advisor）來提出改進建議
　　
　　我將為您完全展示（而不是用文字來解釋）這種特性是如何運行的假定您正設法診斷一個不可解釋的性能問題在我們介紹的示例中您知道了哪些 SQL 語句需要調整或至少知道了哪些 SQL 語句存在問題但是在現實生活中您可能沒有這些有用信息
　　
　　要在 g 中執行診斷您將在相關的時間間隔內選擇快照進行深入透徹的分析在 Enterprise Manager g 中從 Database 主頁上您將選擇 Advisor Central然後單擊 ADDM 鏈接它將出現一個類似於圖 的頁面
　　　
　　圖 創建 ADDM 任務
　　
　　在該頁中您可以創建 ADDM 要分析的任務您知道性能問題發生在晚上 點左右因此選擇那個時間間隔的快照通過 Period Start 和 Period End 值進行指示您也可以單擊照相機圖標指示開始和終止快照的時間間隔如此處的紅色橢圓形所示選擇時間間隔後按下 OK 按鈕將出現一個類似於圖 所示的頁面
　　　
　　圖 ADDM 查找結果
　　
　　這裡 ADDM 在該時間間隔內標識了兩個關鍵的相關的性能問題某些 SQL 語句消耗著重要的 CPU 時間從而使數據庫的速度顯著減慢基於這些查找結果ADDM 建議對圖中突出顯示的那些語句進行 SQL 調整
　　
　　如果您單擊某條查找結果ADDM 會顯示更多詳細信息例如單擊問題查找結果將會出現一個類似於圖 所示的頁面
　　　
　　圖 ADDM 查找結果的詳細信息
　　
　　在此您可以看到引發該問題的特定 SQL 語句ADDM 建議您用 SQL Tuning Advisor 對該 SQL 語句進行徹底的分析正如在 Action 部分中所提到的那樣您可以通過單擊它旁邊的按鈕立即運行該任務這將調用 SQL Tuning Advisor
　　
　　在圖 中您可能注意到了一個名稱為 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 =
　　
　　該語句調整起來並不難但是為了更容易說明問題假定它很難調整激發顧問的方式有兩種使用 Enterprise Manager 或簡單明了的命令行
　　
　　首先讓我們看看如何在命令行中使用它我們通過調用提供的包 dbms_sqltune 來調用顧問
　　declare
　　
　　l_task_id　　 varchar();
　　l_sql　　　　 varchar();
　　begin
　　l_sql := select account_no from accounts where old_account_no = ;
　　dbms_sqltunedrop_tuning_task (FOLIO_COUNT);
　　l_task_id := dbms_sqltunecreate_tuning_task (
　　sql_text　=> l_sql
　　user_name　=> ARUP
　　scope　　　=> COMPREHENSIVE
　　time_limit =>
　　task_name　=> FOLIO_COUNT
　　);
　　dbms_sqltuneexecute_tuning_task (FOLIO_COUNT);
　　end;
　　/
　　
　　這個包創建並執行了一個名為 FOLIO_COUNT 的調整任務接下來您將需要查看任務執行的結果（也就是說查看建議）
　　set serveroutput on size
　　set long
　　select dbms_sqltunereport_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 = aold_account_no and status is not null);
　　
　　顧問建議如下
　　 Restructure SQL finding (see plan in explain plans section)
　　
　　The optimizer could not unnest the subquery at line ID of the execution
　　plan
　　
　　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 adding
　　either 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 queryThe subquery when unnested can
　　drastically improve the execution time because the FILTER operation is
　　converted into a joinBe aware that NOT IN and NOT EXISTS might
　　produce different results for NULL values
　　
　　這一次顧問不會建議任何結構上的更改（如索引）但會通過用 NOT EXISTS 取代 NOT IN的方式很聰明地猜測到調整查詢的正確方式由於兩種構造相似但不相同顧問給出了這種改變的基本原理並把決定權留給 DBA 或應用程序開發人員由他們決定該建議是否對環境有效
　　
　　高級調整SQL 配置文件

From:http://tw.wingwit.com/Article/program/Oracle/201311/16900.html