簡介

在Oracle 11g之前，執行計劃一直是作為“執行時”生成的物件存在。雖然oracle提供了一些方法去指導它的生成，但Oracle一直沒有試圖去儲存完整的執行計劃。 從11g開始，執行計劃就可以作為一類資源被儲存下來，允許特定SQL語句只能選擇“已知”的執行計劃。 

同其他方法相比，SPM更加的靈活。如我們所熟知的，一條帶有繫結變數的SQL語句，最好的執行計劃會根據繫結變數的值而不同，11g以前的方法都無法解決這個問題。在11g中，與adaptive cursor sharing配合，SPM允許你同時接受多個執行計劃。執行時，根據不同的變數值，SPM會花費很少的運算從中選擇一條最合適的。 

概念

SQL Plan Management SPM：oracle 11g 中提供的新特性，用來更好地控制執行計劃。 
Plan History： 優化器生成的所有執行計劃的總稱
SQL Plan Baseline： Plan History裡那些被標記為“ACCEPTED”的執行計劃的總稱
Plan Evolution： 把一條執行計劃從Plan History裡標記為“ACCEPTED”的過程
SQL Management Base SMB： 字典表裡儲存的執行計劃的總稱，包括Plan History，SQL Plan Baseline和SQL profile。

SPM的特點

o 與profile和outline相比，更加靈活的控制手段

o SPM使計劃真正的穩定。 outline的缺點是太過死板，當資料量大幅度變化時無法做出相應的改變。 SQL proifle的缺點是，當資料量變化時，STA(SQL Tuning Advisor)會不可預知地去更改執行計劃。 而SPM則會提供幾個完整的plan供選擇。 

SPM的控制方式

SPM通過幾個標記來實現對執行計劃的控制：

o Enabled (控制活動)
  + YES (活動的，但不一定會被使用)
  + NO (可以理解為被標記刪除)
o Accepted (控制使用)
  + YES (只有 “Enabled” 並且 “Accepted” 的計劃才會被選擇使用)
  + NO (如果是“Enabled” 那麼只有被evolve成“Accepted”才有可能被執行)
o Fixed (控制優先順序)
  + YES (如果是“Enabled”並且“Accepted”，會優先選擇這個計劃，這個計劃會被視為不需要改變的)
  + NO (普通的計劃，無需優先)

另有一個被動的標記：
o Reproduced (有效性)
  + YES (優化器可以使用這個計劃)
  + NO (計劃無效，比如索引被刪除)

SPM如何捕捉執行計劃

o 自動捕捉
  1. 首先把OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES設定成TRUE
  2. 從這個時刻開始，所有執行兩次以上的SQL語句會被觀測，執行計劃會進入Plan History。有個別例外的，參見note 788853.1
  3. 生成的第一個執行計劃被標記為ENABLED並且是ACCEPTED，後續的執行計劃會被標記為ENABLED但不是ACCEPTED。
  4. 這時把OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES設定會FALSE，新的語句將不會建立Baseline。
  5. 需要注意的是，即使關閉了自動捕捉，針對存在baseline的SQL，由於ACS的作用，仍舊會有新的PLAN生成，新的Plan仍會進入Plan History，標記為ENABLED但不是ACCEPTED。參見“執行計劃的選擇”。 

o 批量匯入 (這些匯入的baseline都會被自動標記為ACCEPTED) 
   Oralce提供四種方式把計劃匯入到sql plan baseline中。 
   + 從 SQL Tuning Set STS 匯入
      DBMS_SPM.LOAD_PLANS_FROM_SQLSET
   + 從Stored Outlines 中匯入 
      DBMS_SPM.MIGRATE_STORED_OUTLINE
   + 從記憶體中存在的計劃中匯入
      DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE;
   + 通過staging table從另外一個系統中移植
      DBMS_SPM.CREATE_STGTAB_BASELINE
      DBMS_SPM.PACK_STGTAB_BASELINE
      DBMS_SPM.UNPACK_STGTAB_BASELINE