概述

大家都知道硬解析，軟解析對數據庫sql的執行效率影響是很大的。在Oracle中，用戶輸入的SQL語句要進行所謂的Parse解析過程，用于生成執行計劃，這也就是Query Optimizer的主要工作。在Parse中，有兩種具體類型，被稱為“hard parse”(硬解析)和“Soft parse”(軟解析)。

“實現執行計劃shared cursor共享，減少硬解析”是我們OLTP系統優化一個重要方向。但是，讓Oracle真正實現SQL共享不是一件容易的事情，受到很多其他因素的影響。最常用的方式是使用綁定變量，讓SQL字面值保持一致。如果應用端沒有使用綁定變量，其中一種做法是設置系統參數cursor_sharing，將SQL語句中的條件進行綁定變量替換。

---

一、Cursor_sharing簡介：

這個參數是用來告訴Oracle在什么情況下可以共享游標，即SQL重用。

Cursor_sharing參數有3個值可以設置：

1)、EXACT：通常來說，exact值是Oracle推薦的，也是默認的，它要求SQL語句在完全相同時才會重用，否則會被重新執行硬解析操作。

2)、SIMILAR：similar是在Oracle認為某條SQL語句的謂詞條件可能會影響到它的執行計劃時，才會被重新分析，否則將重用SQL。

3)、FORCE：force是在任何情況下，無條件重用SQL。

備注：上面所說的SQL重用，僅僅是指謂詞條件不同的SQL語句，實際上這樣的SQL基本上都在執行同樣的業務操作。

---

二、在Cursor_sharing參數值不同時對SQL的影響：

1、創建實驗環境：

----首先創建一張hwb表---- SQL> create table hwb (id int,name varchar2(10)); ----產生一些數據---- SQL> insert into hwb values(1,'aa'); SQL> insert into hwb values(2,'bb'); SQL> insert into hwb values(3,'cc'); SQL> insert into hwb values(4,'dd'); SQL> commit; SQL> select * from hwb; ----創建下面實驗將要用到的三張表---- SQL> create table hwb_exact as select * from hwb; SQL> create table hwb_similar as select * from hwb; SQL> create table hwb_force as select * from hwb; ----查看該session的trace文件的路徑---- SQL> oradebug setmypid SQL> oradebug tracefile_name/u01/app/oracle/diag/rdbms/nwppdb/nwppdb/trace/nwppdb_ora_3553.trc

---

2、 cursor_sharing=exact的情況：

----將cursor_sharing設置為exact---- SQL> alter session set cursor_sharing=exact; SQL> alter session set sql_trace=true; SQL> select * from hwb_exact where id=1; SQL> select * from hwb_exact where id=3; SQL> select * from hwb_exact where id=1; SQL> alter session set sql_trace=false; ----從下面的查詢可以看出執行了兩次硬解析---- SQL> select sql_text from v$sql where sql_text like 'select * from hwb_exact where%';----查看trace文件，通過tkprof工具[oracle@nwppdb:/u01/app/oracle/diag/rdbms/nwppdb/nwppdb/trace]$tkprof nwppdb_ora_3553.trc nwppdb_ora_3553.txt aggregate內容比較多，就不介紹了，這里可以通過輸出文件看到有兩次硬解析一次軟解析

總結：當cursor_sharing=exact時，只有當SQL語句是完全一樣的情況下才能被重用。

---

3、 cursor_sharing=similar的情況：

----將curor_sharing設置為similar----SQL> oradebug setmypidStatement processed.SQL> oradebug tracefile_name/u01/app/oracle/diag/rdbms/nwppdb/nwppdb/trace/nwppdb_ora_3671.trcSQL> alter session set cursor_sharing=similar;SQL> alter session set sql_trace=true;SQL> select * from hwb_similar where id=1;SQL> select * from hwb_similar where id=4;SQL> select * from hwb_similar where id=8;---下面查詢中可以看到Oracle將SQL中的謂詞條件用同一個名詞的一個變量替代，盡管看起來是一樣的，但是Oracle依然把它們作為兩條SQL來處理---- SQL> select sql_text from v$sql where sql_text like 'select * from hwb_similar where%'; SQL> alter session set sql_trace=false;[oracle@nwppdb:/]$tkprof /u01/app/oracle/diag/rdbms/nwppdb/nwppdb/trace/nwppdb_ora_3671.trc /home/oracle/nwppdb_ora_3671.txt sys=no

從trace文件中可以清楚看到上面的結論----

對于SIMILAR的情況，如果CBO發現被綁定變量的謂詞還有其他的執行計劃可以選擇時，如果謂詞條件的值有變化，就將會產生一個新的子游標，而不是重用之前的SQL；如果謂詞沒有其他的執行計劃可選擇，則忽略謂詞的值，重用之前的SQL。

---

4、 cursor_sharing=force的情況

----設置cursor_sharing=force---- SQL> alter session set cursor_sharing=force; SQL> alter session set sql_trace=true; SQL> select * from hwb_force where id=1; SQL> select * from hwb_force where id=4; SQL> select * from hwb_force where id=1; SQL> alter session set sql_trace=false; ----從下面的查詢中可以看出只進行了一次硬解析，而且使用了綁定變量---- SQL> select sql_text from v$sql where sql_text like 'select * from hwb_force where%'; ----查看trace文件內容----[oracle@nwppdb:/home/oracle]$tkprof /u01/app/oracle/diag/rdbms/nwppdb/nwppdb/trace/nwppdb_ora_3697.trc /home/oracle/nwppdb_ora_3697.txt aggregate=no sys=no

總結：force是在任何情況下，無條件重用SQL。

---

總結：

FORCE和SIMIALR最大的區別在于，FORCE會把所有的謂詞用變量代替，并且不管變量的值如何，一律重用第一條SQL語句，而SIMILAR會根據謂詞的不同，來重新選擇SQL的執行計劃。

如果一個系統，它存在變量綁定的問題，并且這種問題已經影響到了系統的性能，這時候可以考慮將參數cursor_sharing的值設置為SIMILAR或FORCE來改善這種局面，不過在改成SIMILAR或FORCE都可能帶來一些Bug以及很多未知的東西，所以需要慎用。

最后，對于OLTP系統，如果綁定變量情況不好的話，也許可以考慮通過設置這個參數來緩解一下問題；對于是在OLAP系統上，這個參數應該設置成EXACT，并且不應該使用綁定變量，因為在OLAP系統中，SQL的解析對于SQL的執行來看，花費的代價幾乎可以忽略，而正確的SQL執行計劃才是OLAP數據庫最需要關注的。

總結

以上是生活随笔為你收集整理的isight参数优化理论与实例详解_详解oracle数据库优化参数--cursor_sharing的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。