Oracle優化器輔助手段的發展

• Oracle 8：hint
• Oracle 8i&9: stored outline
• Oracle 10: sql profile
• Oracle 11: sql plan manangement

優化器可能選擇到很差的Plan。

RBO->CBO 由規則序列生成執行計劃，向著智慧靈活化發展，根據資料物件的統計資訊進行執行計劃生成，根據cost選擇最優。

但是CBO依賴統計資訊，統計量又不能和資料表資料完全同步，當統計資訊與實際資料差距大就會導致錯誤執行計劃生成。

(1)沒有定期收集統計量的方案，使得統計量過舊；

(2)當系統升級移植，版本不一致使得匯入的對應統計量錯誤；

(3)在夜間剛剛收集完統計量之後呼叫大作業，匯入海量資料直接改變了原有的資料分佈情況。第二天直接生成錯誤的執行計劃。

Oracle SPM 主要元件

• Plan Capture 捕獲

儲存SQL對應Plan的相關資訊。這些資訊可以唯一確定一個plan。

• Plan selection 選擇

在系統的執行時，Oracle要保證每次執行SQL的執行計劃都是使用SQL Baseline中的確定執行計劃。同時，跟蹤所有該statement執行中生成的新執行計劃，作為Plan Histroy資訊儲存下來。

• Plan evolution 進化

新增新的plan到SQL baselines中，自動或手動。

通過使用baseline，減少效能回退。可以為新應用生成baselines，逐步演化更好的plan。

Plan Capture

自動捕捉 Automatic Initial Plan Capture

1. 首先把OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES設定成TRUE

2. 從這個時刻開始，所有執行兩次以上的SQL語句會被觀測，執行計劃會進入Plan History。

3. 生成的第一個執行計劃被標記為ENABLED並且是ACCEPTED，後續的執行計劃會被標記為ENABLED但不是ACCEPTED。

4. 這時把OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES設定會FALSE，新的語句將不會建立Baseline。

5. 需要注意的是，即使關閉了自動捕捉，針對存在baseline的SQL，仍舊會有新的PLAN生成，新的Plan仍會進入Plan History，標記為ENABLED但不是ACCEPTED。

手動匯入 Manual Plan Capture

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

(這些匯入的baseline都會被自動標記為ACCEPTED)

Plan Selection

OPTIMIZER_USE_SQL_PLAN_BASELINES被設定成預設值TRUE，SQl Plan Baseline就會起作用。

過程：

• 首先，無論是否存在baseline，oracle都會正常進行硬解析或者軟解析，為SQL生成一個執行計劃。 由於ACS和bind peeking的作用，存在baseline的SQL有可能在這時生成一個不同於baseline的執行計劃。

• 如果baseline不存在，就按生成的計劃執行。如果baseline存在，那麼要檢視history裡是否有這個計劃，如果沒有，就將這個計劃插入，並標記為ENABLED,NON-ACCEPTED。

• 在baseline中檢視是否有FIXED的計劃存在，如果存在，執行FIXED的計劃，如果存在多個FIXED的計劃，根據統計資訊重新計算cost，選擇cost小的那個。

• 如果FIXED的計劃不存在，就選擇ACCEPTED的計劃執行。 如果存在多個ACCEPTED的計劃，根據統計資訊重新計算cost，選擇cost小的那個。

注意這裡每次重新計算cost的代價不大，因為執行計劃是已知的，優化器不必遍歷所有的可能，只需根據演算法計算出已知計劃的cost便可。

Plan Evolution

執行計劃的演化指Plan History裡的執行計劃從NON-ACCEPTED，變成ACCEPTED的過程。 如果上所述，由於ACS和Bind Peeking的作用，存在baseline的SQL有可能生成新的執行計劃，被儲存到Plan History中。 Oracle提供了API，通過自動或手工的方式，將一個計劃標記為ACCEPTED，這個計劃就會被後續的執行所選擇。有自動和手動兩種方式，見後面的演示。

演示

Table Prepare

create table yz as select rownum as c1, trunc(dbms_random.value(0, 1000)) as c2 from dual connect by level <= 5000;

Automatic Initial Plan Capture

show parameter capture_sql_plan;

1、alter session set optimizer_capture_sql_plan_baselines=TRUE;  （or alter system set optimizer_capture_sql_plan_baselines=TRUE;）
開啟自動capture sql plan
2、select * from yz where c1= ？; (改一下值) select * from yz where c1 = 1;
執行SQL語句
3、select signature, sql_handle, sql_text,PLAN_NAME,ORIGIN,version, ACCEPTED from dba_sql_plan_baselines where sql_text like ‘select * from yz where c1 = ?’;
檢視dba_sql_plan_baselines
 4、select * from table(dbms_xplan.display_sql_plan_baseline(sql_handle => 'SYS_SQL_c748bdb0d9540dcb', plan_name => 'SQL_PLAN_cfk5xq3cp83fb97bbe3d0'));
檢視baseline中的plan。

Manual Plan Capture

從library cache拿
1、alter session set optimizer_capture_sql_plan_baselines=false;
先關掉自動捕獲。
2、select * from yz where c2 = ?;
執行一條語句
3、select sql_handle, sql_text,PLAN_NAME,ORIGIN,version, ACCEPTED from dba_sql_plan_baselines where sql_text like 'select * from yz%';
可以看到dba_sql_plan_baselines中不存在
4、  select sql_text, sql_id, plan_hash_value from v$sql where sql_text like 'select * from yz where c2 = ?';

找到sql_id和plan_hash_value

5、SQL>  var i number;
SQL> exec :i := dbms_spm.load_plans_from_cursor_cache (sql_id=>'bg9cppxy2a7fx', plan_hash_value=>'1357081020');
將cursor cache中的plan加入到spm中

6、select sql_handle, sql_text,PLAN_NAME,ORIGIN,version, ACCEPTED from dba_sql_plan_baselines where sql_text like 'select * from yz%';
新的plan 加入baselines中

Plan Selection
1、select name,ISSES_MODIFIABLE, ISSYS_MODIFIABLE, ISINSTANCE_MODIFIABLE  from v$parameter where name like 'optimizer_use_sql_plan%';
檢視是否使用baseline
2、select * from yz where c1 = ?;
執行已經加入baseline的sql.

3、select * from table(dbms_xplan.DISPLAY_CURSOR(null, null, 'advanced'));
或者
 select sql_id, sql_text, PLAN_HASH_VALUE, executions, child_number from v$sql where sql_text like '';
select * from table(dbms_xplan.display_cursor('sql_id',null,'ADVANCED ALLSTATS LAST PEEKED_BINDS'));

4、select sql_handle, sql_text,PLAN_NAME, ACCEPTED, enabled, executions from dba_sql_plan_baselines where sql_text like 'select * from yz%';
檢視executions是不是顯示被執行過

Plan Evolution
create index yz_c1 on yz(c1);
select * from yz where c1 = ?;
select * from table(dbms_xplan.DISPLAY_CURSOR(null, null, 'advanced'));
自動
select DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE(sql_handle => NULL,  plan_name  => NULL, verify => 'YES',  commit => 'YES' ) from dual;
這裡由兩個標記控制：
o Verify 
  + YES (只有效能更好的計劃才會被演化)
  + NO (演化所有的計劃)
o Commit
  + YES (直接演化)
  + NO (只生成報告)
select sql_handle, sql_text,PLAN_NAME, ACCEPTED, enabled, executions from dba_sql_plan_baselines where sql_text like 'select * from yz%';

手動
DECLARE

 v_text  PLS_INTEGER;

BEGIN

 v_text  := DBMS_SPM.alter_sql_plan_baseline(sql_handle  => 'SYS_SQL_648e097c2d8e05a6',plan_name => 'SQL_PLAN_693h9ghqsw1d63158d001',

  attribute_name  => 'enabled',attribute_value => 'yes');

END;
/