創建一個測試表用於演示基線生成對SQL語句的影響：
我第一採用的範圍查找：
通過V$SQL找到SQL的sql_id，並將其載入基線：
查看基線的執行計劃，可以看到基線的執行計劃走的是全表掃：
添加索引後，再次嘗試執行同樣的語句，發現執行計劃走的是索引掃：
嘗試用匹配查找的方式看看會有什麼不同呢？刪掉索引，重新執行發現執行計劃與範圍查找一樣走了全表掃
獲取SQL的ID號，並且生成基線
SCOTT> col sql_text for a60
SCOTT> select sql_id,sql_text from v$sql where sql_text like 'select object_id from test where object_id like%';
通過DBMS_SPM包將SQL載入基線，並查看基線名稱：
SCOTT> declare
xplan pls_integer;
begin
xplan:=dbms_spm.load_plans_from_cursor_cache(sql_id=>'7g2ycppbr43tu');
end;
/
SCOTT> col plan_name for a30
SCOTT> col sql_handle for a30
SCOTT> select sql_handle,sql_text,plan_name from dba_sql_plan_baselines;
查看基線的執行計劃可以看到走的同樣是全表掃：
SCOTT> select * from table(dbms_xplan.display_sql_plan_baseline(plan_name=>'SQL_PLAN_dw5mnstphcg0597bbe3d0',format=>'basic'));
創建索引，繼續觀察SQL語句，這是可以看到SQL選擇的是基線生成的執行計劃，而不走索引。
SCOTT> create index idx_id on test(object_id);
查看基線字典可以發現同一條語句存在兩個執行計劃的基線：
查看新基線的執行計劃：
SCOTT> set serveroutpu on
SCOTT> set long 1000
SCOTT> declare
report varchar2(1000);
begin
report:=dbms_spm.evolve_sql_plan_baseline(sql_handle=>'SYS_SQL_de1674c66b063c05',time_limit=>dbms_spm.no_limit,verify=>'NO');
dbms_output.put_line(report);
end;
/
上面的報告內容顯示，SQL處理'SYS_SQL_de1674c66b063c05'中有一個可選的（更優的）執行計劃'SQL_PLAN_dw5mnstphcg0560e1006c'，因爲更優，因此該執行計劃被轉變成了可接受的狀態。再次查看該基線的執行計劃：
可以看到該最優的基線計劃Accepted已經變爲YES。說明執行計劃已經接受了這個基線計劃。查看語句執行計劃，已經選擇走新的執行計劃：
刪除執行基線計劃：
SCOTT> declare
dplan pls_integer;
begin
dplan:=dbms_spm.drop_sql_plan_baseline(plan_name=>'SQL_PLAN_dw5mnstphcg0560e1006c');
end;
/
刪除最優的基線計劃後，再次查詢時Oracle會選擇使用原來的基線（SQL_PLAN_dw5mnstphcg0597bbe3d0）作爲執行計劃使用。
DBMS_SPM包的使用需要用戶有ADMINISTER SQL MANAGEMENT OBJECT 權限
alter_sql_plan_baseline 通過屬性名、屬性值來修改某個或所有計劃的屬性
configure 以參數/值的格式設置sql management base的選項
create_stgtab_baseline 創建stage表用來將SPM傳輸到另一個系統
drop_sql_plan_baseline 刪除與某個sql相關的某個計劃或所有計劃
evolve_sql_plan_baseline 更改一個或多個語句的SPM
load_plans_from_cursor_cache 將緩存中的一個或多個計劃加載進來
load_plans_from_sqlset 從sql tuning set加載計劃到基線中
migrate_stored_outline 從sql management base導出sql基線到stage表
unpack_stgtab_baseline 將sql基線從stage表導入到sql management base