一．概述

SQL 語句的SQL 執行計劃發生更改時，可能存在效能風險。

SQL 計劃發生更改的原因有很多，如優化程式版本、優化程式統計資訊、優化程式引數、方案定義、系統設計和SQL 概要檔案建立等。

在以前版本的Oracle DB 中引入了各種計劃控制技術（如儲存的大綱(storedoutline(9i))和SQL 概要檔案等(SQLprofile(10g))），用於解決計劃更改導致的效能迴歸。但是，這些技術都是需要手動干預的被動式程序。

SQL 計劃管理是一種隨Oracle Database 11g 引入的新功能，通過維護所謂的“SQL 計劃基線(SQL plan baseline(11g))”來使系統能夠自動控制SQL 計劃演變。啟用此功能後，只要證明新生成的SQL 計劃與SQL 計劃基線相整合不會導致效能迴歸，就可以進行此項整合。因此，在執行某個SQL 語句時，只能使用對應的SQL 計劃基線中包括的計劃。可以使用SQL 優化集自動載入或植入SQL 計劃基線。

SQL 計劃管理功能的主要優點是系統性能穩定，不會出現計劃迴歸。此外，該功能還可以節省DBA 的許多時間，這些時間通常花費在確定和分析SQL 效能迴歸以及尋找可用的解決方案上。

二．SQL 計劃基線(Plan BaseLine)：體系結構

SQL 計劃管理(SPM) 功能引入了支援新計劃的計劃維護和效能驗證所必需的基礎結構和服務。

對於多次執行的SQL 語句，優化程式會為單個SQL 語句維護一個計劃歷史記錄。優化程式通過維護語句日誌來標識可重複的SQL 語句。如果對某個已記錄的SQL 語句再次進行語法分析或再次執行該語句，則將該SQL 語句標識為可重複的語句。將某個SQL 語句標識為可重複之後，由優化程式生成的各種計劃將作為包含相關資訊（如SQL 文字、大綱、繫結變數和編譯環境等）的計劃歷史記錄得以維護；優化程式將使用這些資訊來複制執行計劃。

作為自動識別可重複SQL 語句及建立其計劃歷史記錄的一種替代或補充，系統也支援為一系列SQL 語句手動植入計劃。

計劃歷史記錄包含優化程式在某段時間內為SQL 語句生成的不同計劃。但是，只有計劃歷史記錄中的部分計劃可能被接受並得以使用。例如，正常情況下不會使用優化程式生成的新計劃，除非該計劃得到驗證不會導致效能迴歸。在維護視窗中作為自動化任務執行自動SQL 優化時，就會自動完成計劃驗證。

自動SQL 優化任務的唯一目標是獲得高負載的SQL 語句。為此，該任務會自動執行一些操作，例如，使成功的已驗證計劃成為已接受的計劃。一系列可接受的計劃組成了一個SQL 計劃基線(plan baseline)。為一個SQL 語句生成的第一個計劃很顯然是可接受的計劃，因此，該計劃形成了原始的計劃基線。優化程式後來發現的任何新計劃都包含在計劃歷史記錄中，但最初都不包含在計劃基線中。

語句日誌、計劃歷史記錄和計劃基線都儲存在SQL 管理庫(SMB) 中；該庫還包含SQL概要檔案。SMB 是資料庫字典的一部分，儲存在SYSAUX 表空間中。SMB 使用自動空間管理（例如，定期清除未使用的計劃）。可以對SMB 進行配置，以更改計劃保留策略和設定空間大小限制。

注：使用OracleDatabase 11g 時，如果資料庫例項已啟動，但SYSAUX 表空間為OFFLINE，則優化程式將無法訪問SQL 管理物件。這可能會影響某些SQL 工作量的效能。

三. 載入SQL 計劃基線

載入SQL 計劃基線的方式有兩種:

（1）  即時捕獲：

使用自動計劃捕獲，方法是：將初始化引數OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES 設定為TRUE。預設情況下，該引數設定為FALSE。將該引數設定為TRUE 將開啟自動標識可重複SQL 語句，以及自動為此類語句建立計劃歷史記錄的功能。

（2）  成批載入：

使用DBMS_SPM 程式包；該程式包支援手動管理SQL 計劃基線。使用此程式包，可以將SQL 計劃從遊標快取記憶體或現有的SQL 優化集(STS) 直接載入到SQL計劃基線中。對於要從STS 載入到SQL 計劃基線的SQL 語句，需要將其SQL計劃儲存在STS中。使用DBMS_SPM 可以將基線計劃的狀態從已接受更改為未接受（以及從未接受更改為已接受），還可以從登臺表匯出基線計劃，然後使用匯出的基線計劃將SQL 計劃基線載入到其它資料庫中。

四．演化SQL 計劃基線

在SQL 計劃基線演化階段，Oracle DB 會按常規方式評估新計劃的效能，並將效能較好的計劃整合到SQL 計劃基線中。

優化程式為SQL 語句找到新的計劃時，會將該計劃作為未接受的計劃新增到計劃歷史記錄中。然後，相對於SQL 計劃基線的效能，驗證該計劃的效能。如果經驗證某個未接受的計劃不會導致效能迴歸（手動或自動），則該計劃會被更改為已接受計劃，並整合到SQL 計劃基線中。成功驗證未接受計劃的過程包括：對此計劃的效能和從SQL計劃基線中選擇的一個計劃的效能進行比較，確保其效能更佳。

演化SQL 計劃基線的方式有兩種：

（1）使用DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE 函式。該函式將返回一個報表，顯示是否已將一些現有的歷史記錄計劃移到了計劃基線中。也可以在歷史記錄中指定要測試的特定計劃。

（2）執行SQL 優化指導：通過使用SQL 優化指導手動或自動優化SQL 語句，演化SQL計劃基線。SQL優化指導發現已優化的計劃，並確認其效能優於從相應的SQL 計劃基線中選擇的計劃的效能時，就會生成一個建議案以接受SQL 概要檔案。接受了該SQL 概要檔案後，會將已優化的計劃新增到相應的SQL 計劃基線中。

五. 重要的基線SQL 計劃屬性

如果將計劃新增到計劃歷史記錄中，則該計劃將與一些重要的屬性關聯：

（1）SIGNATURE、SQL_HANDLE、SQL_TEXT 和PLAN_NAME 是搜尋操作的重要識別符號。

（2）使用ORIGIN 可以確定計劃是自動捕獲的(AUTO-CAPTURE)、手動演化的(MANUALLOAD)、通過SQL 優化指導自動演化的(MANUAL-SQLTUNE) 還是通過自動SQL 優化自動演化的(AUTO-SQLTUNE)。

（3）  ENABLED 和ACCEPTED：ENABLED屬性表示計劃已啟用，可供優化程式使用。如果未設定ENABLED，則系統將不考慮此計劃。ACCEPTED 屬性表示使用者在將計劃更改為ACCEPTED 時計劃已經過驗證為有效計劃（系統自動進行的或使用者手動進行的）。如果將某個計劃更改為ACCEPTED，則僅當使用DBMS_SPM.ALTER_SQL_PLAN_BASELINE()更改其狀態時，該計劃才是非ACCEPTED 的。可以通過刪除ENABLED設定暫時禁用ACCEPTED 計劃。計劃必須為ENABLED 和ACCEPTED，優化程式才會考慮使用它。

（4）  FIXED 表示優化程式僅考慮標記為FIXED 的計劃，而不考慮其它計劃。例如，如果有10 個基線計劃，其中的三個計劃被標記為FIXED，則優化程式將僅使用這三個計劃中的最佳計劃，而忽略其它所有計劃。如果某個SQL 計劃基線至少包含一個已啟用的已修復計劃，則該SQL 計劃基線就是FIXED 的。如果在修復的SQL 計劃基線中添加了新計劃，則在手動將這些新計劃宣告為FIXED 之前，無法使用這些新計劃。

可以使用DBA_SQL_PLAN_BASELINES檢視檢視每個計劃的屬性。然後，可以使用DBMS_SPM.ALTER_SQL_PLAN_BASELINE 函式更改其中的某些屬性。也可以使用DBMS_SPM.DROP_SQL_PLAN_BASELINE 函式刪除計劃或整個計劃歷史記錄。

注：DBA_SQL_PLAN_BASELINES 檢視包含了一些附加屬性；使用這些屬性可以確定各個計劃的上次使用時間，以及是否應自動清除某個計劃。

六．SQL 計劃選擇

如果使用的是自動計劃捕獲，則第一次將某個SQL 語句標識為可重複時，其最佳成本計劃將被新增到對應的SQL 計劃基線中。然後，該計劃將用於執行相應的語句。

如果某個SQL 語句存在計劃基線，並且初始化引數OPTIMIZER_USE_SQL_PLAN_BASELINES 被設定為TRUE（預設值），則優化程式將使用比較計劃選擇策略。每次編譯SQL 語句時，優化程式都會先使用傳統的基於成本的搜尋方法建立一個最佳成本計劃，然後嘗試在SQL 計劃基線中找到一個匹配的計劃。如果找到了匹配的計劃，則優化程式將照常繼續執行。如果未找到匹配的計劃，則優化程式會先將新計劃新增到計劃歷史記錄中，然後計算SQL計劃基線中各個已接受的計劃的成本，並選擇成本最低的那個計劃。使用隨各個已接受的計劃儲存的大綱複製這些已接受的計劃。因此，對於SQL 語句來說，擁有一個SQL 計劃基線的好處就是：優化程式始終選擇該SQL 計劃基線中的一個已接受的計劃。

通過SQL 計劃管理，優化程式可以生成最佳成本計劃，也可以生成基線計劃。此資訊將被轉儲在有關解釋計劃的plan_table 的other_xml 列中。

此外，還可以使用新的dbms_xplain.display_sql_plan_baseline 函式，顯示某個計劃基線中給定sql_handle 的一個或多個執行計劃。如果還指定了plan_name，則將顯示相應的執行計劃。

注：為了保留向後相容性，如果使用者會話的某個SQL 語句的儲存大綱對是活動的，則將使用此儲存大綱編譯該語句。此外，即使為會話啟用了自動計劃捕獲，也不將優化程式使用儲存大綱生成的計劃儲存在SMB 中。

雖然儲存大綱沒有任何顯式遷移過程，但可使用DBMS_SPM 程式包中的LOAD_PLAN_FROM_CURSOR_CACHE 過程或LOAD_PLAN_FROM_SQLSET 過程將其遷移到SQL 計劃基線。遷移完成時，應禁用或刪除原始的儲存大綱。

七. 可能的SQL 計劃可管理性方案

（1）      資料庫升級：

將系統從較早的版本升級到Oracle Database 11g 時，成批載入SQL 計劃特別有用。為此，可以在升級前將某個SQL 工作量的計劃捕獲到SQL 優化集(STS)中，然後在升級後立即將這些計劃從STS 載入到SQL 計劃基線中。此策略可以最大程度地減少使用新的優化程式版本所導致的計劃迴歸。

（2）      新應用程式部署：

部署新的應用程式模組意味著在系統中引入新的SQL 語句。軟體供應商可以將應用程式軟體與新引入的SQL 語句的相應SQL 計劃基線一起提供。由於存在計劃基線，新的SQL 語句最初將與已知在標準測試配置下具有良好效能的計劃一起執行。但是，如果客戶系統配置與測試配置有很大的差異，則計劃基線可隨時間演化以產生更好的效能。

在上述兩種情況下，都可以在手動載入後使用自動SQL 計劃捕獲，以確保僅將較好的計劃用於將來的應用程式。

八．SQL 效能分析器和SQL 計劃基準方案

第一種方法的一個變體是通過使用SQL效能分析器。可以捕獲STS 中Oracle Database11g 之前的計劃，並將這些計劃匯入到Oracle Database 11g。然後，將初始化引數optimizer_features_enable 設定為10g，使優化程式將此資料庫當成10g Oracle DB 進行操作。接下來，為STS 執行SQL 效能分析器。執行完成後，將初始化引數optimizer_features_enable設定回11g，併為STS 重新執行SQL 效能分析器。

SQL 效能分析器將生成一個報表，列出了從10g 到11g 其計劃已發生迴歸的SQL語句。

對於那些SQL 效能分析器顯示的由於新優化程式版本而發生效能迴歸的SQL 語句，可以使用STS 捕獲其計劃，然後將這些計劃載入到SMB 中。

此方法提供了計劃植入程序的最佳形式，因為它有助於在保留資料庫升級所帶來的效能改進的同時，防止效能迴歸。

九．自動載入SQL 計劃基線：方案

另一種升級方案涉及使用自動SQL計劃捕獲機制。在此方案中，在最初一段時間（如一個季度）內將初始化引數OPTIMIZER_FEATURES_ENABLE(OFE) 設定為OracleDatabase 11g 之前的版本值，再在升級後使用自動SQl 計劃捕獲來執行您的工作量。

在這個初始時段中，由於OFE 的引數設定，優化程式可以為大部分SQL 語句複製OracleDatabase 11g 之前的計劃。因為在此期間內還啟動了自動SQL 計劃捕獲，所以優化程式生成的Oracle Database 11g 之前的計劃將被捕獲為SQL 計劃基線。

初始時段結束時，可以刪除OFE 的設定，以便在因計劃基線而出現最小計劃迴歸時或無計劃迴歸時，利用新的優化程式版本。迴歸的計劃將使用以前的優化程式版本；未迴歸的語句將受益於新的優化程式版本。

十．清除SQL 管理庫策略

系統將參照定義的限制，按周檢查SQL管理庫(SMB) 佔用的空間。限制是根據SYSAUX表空間的百分比大小定義的。預設情況下，SMB 的空間預算限制被設定為SYSAUX 大小的10%。但是，可以使用DBMS_SPM.CONFIGURE 過程配置SMB，將空間預算更改為介於1% 和50% 之間的一個值。

如果SMB 空間超過了定義的百分比限制，則會向預警日誌中寫入警告。通過清除一些SQL管理物件（如SQL 計劃基線或SQL 概要檔案）來增加SMB 空間限制、增加SYSAUX 大小或者減小SMB 大小之前，將按周生成警報。

SQL 計劃基線的空間管理將使用每週清除任務提前完成。該任務在維護視窗中作為自動化任務執行。超過53 周未使用的任何計劃都將被清除。但是，可以配置SMB，將未使用計劃保留期設定為介於5 周和523 周（比10 年稍長一些）之間的一個值。為此，可使用DBMS_SPM.CONFIGURE 過程。

可以通過檢查DBA_SQL_MANAGEMENT_CONFIG檢視來檢視SMB 的當前配置設定。此外，還可以使用DBMS_SPM.DROP_SQL_PLAN_BASELINE函式手動清除SMB。

更多內容參考：

Using SQL Plan Management

QQ:492913789

Email:[email protected]