慎用sys_context,可能導致無法正確的bind_peeking,而選擇錯誤的執行計劃
http://www.itpub.net/thread-1350771-1-1.html
在上面的帖子裡,樓主提出使用dbms_session來處理繫結變數。但是,這個方法必須進行有效的測試,防止出現錯誤的執行計劃。
由於sys_context導致bind_peeking無法正確執行,在某些情況下,會生成錯誤的執行計劃,見下例:
[@more@]SQL*Plus: Release 11.2.0.1.0 Production on 星期三 9月 29 08:43:56 2010
Copyright (c) 1982, 2010, Oracle. All rights reserved.
SUNDOG315>conn test/test
已連線。
SUNDOG315>create table t (id number,text varchar2(4000));
表已建立。
SUNDOG315>insert into t select 1,object_name from dba_objects;
已建立55085行。
SUNDOG315>insert into t select 2,'aaa' from dual;
已建立 1 行。
SUNDOG315>commit;
提交完成。
SUNDOG315>create index t_idx on t(id);
索引已建立。
SUNDOG315>exec dbms_stats.gather_table_stats(user,'T',null,null,method_opt=>'for
all columns',cascade=>true);
PL/SQL 過程已成功完成。
SUNDOG315>select id,count(*) from t group by id;
ID COUNT(*)
---------- ----------
1 55085
2 1
SUNDOG315>select count(*) from t where id=2;
COUNT(*)
----------
1
SUNDOG315>select * from table(dbms_xplan.display_cursor());
SQL_ID 8tfp2xac71yd6, child number 0
-------------------------------------
select count(*) from t where id=2
Plan hash value: 293504097
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 1 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | INDEX RANGE SCAN| T_IDX | 1 | 3 | 1 (0)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"=2)
已選擇19行。
--選擇了正確的索引範圍掃描
SUNDOG315>var fid number;
SUNDOG315>exec :fid := 2;
PL/SQL 過程已成功完成。
SUNDOG315>select count(*) from t where id=:fid;
COUNT(*)
----------
1
SUNDOG315>select * from table(dbms_xplan.display_cursor());
SQL_ID 3u1847dua6k75, child number 0
-------------------------------------
select count(*) from t where id=:fid
Plan hash value: 293504097
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 1 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | INDEX RANGE SCAN| T_IDX | 1 | 3 | 1 (0)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"=:FID)
已選擇19行。
--由於bind_peeking的存在,依然選擇了正確的索引範圍掃描
SUNDOG315>create context test using test_p;
上下文已建立。
SUNDOG315>create or replace procedure test_p is
2 begin
3 dbms_session.set_context('test','id',2);
4 end;
5 /
過程已建立。
SUNDOG315>exec test_p;
PL/SQL 過程已成功完成。
SUNDOG315>select sys_context('TEST','ID') from dual;
SYS_CONTEXT('TEST','ID')
--------------------------------------------------------------------------------
2
SUNDOG315>select count(*) from t where id=sys_context('test','id');
COUNT(*)
----------
1
SUNDOG315>select * from table(dbms_xplan.display_cursor());
SQL_ID 69x691fhtckm0, child number 0
-------------------------------------
select count(*) from t where id=sys_context('test','id')
Plan hash value: 1058879072
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 32 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | INDEX FAST FULL SCAN| T_IDX | 27543 | 82629 | 32 (4)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("ID"=TO_NUMBER(SYS_CONTEXT('test','id')))
已選擇19行。
--TO_NUMBER(SYS_CONTEXT('test','id'))無法peeking到正確的值,因此,選擇了錯誤的執行計劃
SUNDOG315>set autot trace stat
SUNDOG315>select count(*) from t where id=2;
統計資訊
----------------------------------------------------------
0 recursive calls
0 db block gets
2 consistent gets
0 physical reads
0 redo size
423 bytes sent via SQL*Net to client
415 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SUNDOG315>select count(*) from t where id=:fid;
統計資訊
----------------------------------------------------------
0 recursive calls
0 db block gets
2 consistent gets
0 physical reads
0 redo size
423 bytes sent via SQL*Net to client
415 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SUNDOG315>select count(*) from t where id=sys_context('test','id');
統計資訊
----------------------------------------------------------
0 recursive calls
0 db block gets
116 consistent gets --邏輯讀增大
0 physical reads
0 redo size
423 bytes sent via SQL*Net to client
415 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
目前,估計用dbms_session的人還是比較少,像這種問題,Oracle其實完全可以處理掉的。估計如果使用的人多,就會進行處理了。呵呵
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/19423/viewspace-1039108/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 統計資訊不正確導致執行計劃的錯誤選擇
- autotrace 和explain plan for可能導致執行計劃錯誤AI
- 11G的SORT GROUP BY NOSORT導致錯誤執行計劃
- 執行計劃錯誤導致系統負載高負載
- 看執行計劃是否正確
- ORACLE analyse table方式收集表統計資訊導致SQL執行計劃不準確而效能下降OracleSQL
- date列統計資訊陳舊導致sql沒有選擇最優執行計劃SQL
- 執行計劃的偏差導致的效能問題
- 統計資訊不準確導致執行計劃走了笛卡爾積
- 完美的執行計劃導致的效能問題
- 由於無法分配ip而導致的FailedCreatePodSandBoxAI
- 執行無法解決的編譯錯誤編譯
- 資料庫恢復狀態可能導致JOB無法自動執行資料庫
- 動態建立 @ViewChild 導致執行時錯誤的原因分析View
- 統計資訊過舊導致SQL無法執行出來SQL
- 錯誤初始化引數導致無法啟動的解決辦法
- Grant許可權導致執行計劃失效
- 決定一個SQL執行效率的是執行計劃, 而不是SQL的寫法SQL
- 為什麼說選擇正確的程式語言很重要,以及如何正確的選擇
- 為什麼說選擇正確的程式語言很重要 以及如何正確的選擇
- 交流(1)-- 執行計劃錯誤問題
- 選擇正確的 WebSphere 診斷工具Web
- 詳細分析 Java 中啟動執行緒的正確和錯誤方式Java執行緒
- 【UX設計】如何為你的遊戲選擇正確的字型?UX遊戲
- 怎樣得到準確的執行計劃
- 執行計劃中的COLLECTION ITERATOR PICKLER FETCH導致的效能問題
- [譯] RxJS: 避免因濫用 switchMap 而導致錯誤JS
- sql中使用函式導致explain plan for和set autotrace得到執行計劃不準確SQL函式AI
- MySQL5.6執行計劃錯誤案例分析MySql
- 執行計劃變化導致CPU負載高的問題分析負載
- MongoDB是不是正確的選擇? - simplethreadMongoDBthread
- 在RAC 中解決 vipca 和 srvctl 無法執行的錯誤PCA
- 設計表時,如何選擇正確的資料型別資料型別
- tornado template預設壓縮空白字元導致coffee無法正確縮排字元
- DDL觸發器設定導致DDL無法執行(二)觸發器
- DDL觸發器設定導致DDL無法執行(一)觸發器
- Oracle當number型別超過一定長度直方圖限制導致SQL執行計劃錯誤Oracle型別直方圖SQL
- 執行計劃-4:謂詞的選擇時機與使用細節