Boost SQL Performance with cursor_sharing
 
關(guān)鍵詞：cursor_sharing
 
概述
本文闡述在Oracle8i Release 2和Oracle9i中增強(qiáng)的游標(biāo)共享設(shè)施。這些增強(qiáng)功能被一個新的參數(shù)cursor_sharing控制。
cursor_sharing的目的就是提高沒有使用綁定變量(bind vvariable)的應(yīng)用程序服務(wù)器的性能。
 
需要 cursor_sharing
本段解釋為什么應(yīng)用程序不使用綁定變量(bind variables)會帶來性能問題。
 
應(yīng)用程序反復(fù)執(zhí)行相似的SQL語句
使用Oracle數(shù)據(jù)庫管理他（她）們的數(shù)據(jù)的應(yīng)用程序必須使用SQL語句訪問/修改數(shù)據(jù)庫。這些SQL語句可以是由一個應(yīng)用程序使用OCI, OCCI, JDBC, PL/SQL等直接產(chǎn)生的，也是可以是使用其他工具和庫（例如：dbms_sql）間接產(chǎn)生的。
根據(jù)不用的應(yīng)用類型，通常一個應(yīng)用程序都為最終用戶提供了一個固定的功能集合，例如，一個人力資源應(yīng)用程序可能會提供一些像增加一個新雇員，修改一個雇員的個人信息等功能。最終這些功能使用SQL訪問和/或修改數(shù)據(jù)。因為應(yīng)用程序重復(fù)地執(zhí)行這些功能，一個應(yīng)用和Oracle數(shù)據(jù)庫的交互是由相似的SQL語句的反復(fù)執(zhí)行構(gòu)成的。
 
SQL調(diào)用的步驟
為執(zhí)行一個SQL語句，客戶端可以使用使用不同的接口。例如，通過OCI接口，客戶端創(chuàng)建一個語句句柄(statement handle)，然后perpare這個語句，綁定，定義和執(zhí)行這個語句句柄，或者，SQL語句也可以通過一個PL/SQL過程被執(zhí)行。
按照客戶端接口，Oracle數(shù)據(jù)庫一直都使用固定的步驟（默認(rèn)）：
1.         打開一個游標(biāo) － 用戶游標(biāo)是一個和SQL語句相關(guān)的全部用戶狀態(tài)的句柄，像執(zhí)行內(nèi)存，共享游標(biāo)引用，用戶游標(biāo)的當(dāng)前狀態(tài)等等。
2.         解析一個SQL語句到打開的用戶游標(biāo)中 － 使SQL語句和用戶游標(biāo)關(guān)聯(lián)；它也建立了一個共享游標(biāo)，對應(yīng)于SQL語句的解析格式。在一些情況下，共享游標(biāo)也可以作為解析的一部分被校對和優(yōu)化。解析，校對和優(yōu)化SQL語句的過程通常是非常耗費CPU時間，內(nèi)存和連接資源的。
3.         如有需要，綁定變量 － 給Oracle提供SQL語句中綁定變量的數(shù)據(jù)類型，大小和值等必要的信息。
4.         校對優(yōu)化共享游標(biāo)，如果還沒有做這項工作的話。
5.         執(zhí)行用戶游標(biāo) － 這一步真正完成語句執(zhí)行的工作，根據(jù)語句的復(fù)雜程度消耗CPU和會話內(nèi)存(session memory)。
注意，解析，校對和優(yōu)化（在本文中統(tǒng)稱為編譯）組成了執(zhí)行一個SQL語句的消耗，并且能夠限制數(shù)據(jù)庫的容量和可測量性。
 
共享游標(biāo)
一個典型的重復(fù)執(zhí)行相似語句的應(yīng)用，在Oracle數(shù)據(jù)庫許多針對SQL處理目的的優(yōu)化重復(fù)執(zhí)行。最重要的優(yōu)化是共享游標(biāo)，試圖通過在相同的語句的不同執(zhí)行之間共享編譯結(jié)果來消除編譯的耗費（不是并發(fā)就是在不同的時間發(fā)生）。如下圖：
User Session 1
 
PRivate
execution
state
User Session 2
 
Private
execution
state
Shared Cursor

為了能夠使用共享游標(biāo)，Oracle分割語句執(zhí)行狀態(tài)到共享游標(biāo)中，并且在實例中預(yù)處理。共享游標(biāo)是編譯的結(jié)果并包含了執(zhí)行計劃；它在緩存在共享池中。每個執(zhí)行該語句的會話有一個預(yù)執(zhí)行狀態(tài)的私有拷貝，如用戶游標(biāo)，運行時變量值等。
在解析階段（上面提到的第2步），Oracle首先搜索一個已經(jīng)存在的可以被用戶會話共享的共享游標(biāo)。Oracle把搜索分為兩步：基于SQL文本的檢索，找到相同SQL文本創(chuàng)建的游標(biāo)，根據(jù)其他標(biāo)準(zhǔn)選擇適當(dāng)?shù)挠螛?biāo)，如優(yōu)化模式，訪問的基本對象等。如果一個可以共享的游標(biāo)被找到，并不需要編譯，這個處理成為軟解析（soft parse）。否則，編譯SQL語句創(chuàng)建新的共享游標(biāo)，這個處理成為硬解析（hard parse）。
當(dāng)被應(yīng)用程序使用的大多數(shù)語句能夠共享同樣的游標(biāo)集合時，大多數(shù)解析變成為軟解析，進(jìn)而提高數(shù)據(jù)庫服務(wù)器的能力/吞吐量（縮減了內(nèi)存和CPU的使用），響應(yīng)時間（減少了解析階段所使用的時間）和可測量性（減少了閉鎖連接（latch connection） ）。
 
為什么游標(biāo)不是共享的？
假設(shè)其他的因素是相同的，如可配置的實例/會話/事務(wù)等級參數(shù)，理論上，如果在同樣的行/對象上執(zhí)行同樣的操作，使用同樣的計劃，語句S1和S2的游標(biāo)可以被共享。但是要計算和找出這些游標(biāo)是非常困難的，這樣做也可能抵消共享游標(biāo)帶來的好處。因此，Oracle游標(biāo)共享標(biāo)準(zhǔn)規(guī)定在所有的情況下默認(rèn)都不共享游標(biāo)，除非它們被設(shè)計得很高效。從8i Release 2開始，如果S1和S2都是文本的并且不少的其他條件都相同（對象名被轉(zhuǎn)換成為同樣的基本對象，會話中語句的優(yōu)化模式相同，等等），它們可以共享同一個游標(biāo)。
當(dāng)應(yīng)用程序在語句中使用文字標(biāo)量替代綁定變量時就會導(dǎo)致一個游標(biāo)共享的問題。如應(yīng)用程序最終產(chǎn)生的語句只是在文字標(biāo)量上有一些不同，甚至語句都是相同的。如，一個應(yīng)用程序沒有使用綁定變量，可以假設(shè)在不同的時間或不同的會話中有下面兩個語句：
INSERT INTO T VALUES(1, ‘foo’, 4)
INSERT INTO T VALUES(2, ‘bar’, 7)
因為這兩個語句文本上并不相同，它們最終產(chǎn)生不同的游標(biāo)。
有幾種情況下應(yīng)用程序可能不會使用綁定變量：
l         用文字標(biāo)量很容易就寫出一個SQL語句，特別是使用了一些工具
l         老的Oracle關(guān)系數(shù)據(jù)庫不支持綁定變量（至少是沒有共享游標(biāo)的好處，從Oracle7才開始使用它們），已有的應(yīng)用程序要求作一些代碼升級的工作。
l         其他所有的數(shù)據(jù)庫供應(yīng)商都不支持綁定變量，即使有語法也不相同；因此，使用特定的Oracle語法/特性會使應(yīng)用程序失去與其他數(shù)據(jù)的兼容性。
l         如果一個語句使用綁定變量，那么它就一直使用相同的執(zhí)行計劃。如果不同的綁定變量會有不同的優(yōu)化計劃就可能產(chǎn)生問題，如，考慮下面的語句：
SELECT * FROM T1, T2 WHERE (T1.N <= 100) AND (T1.N1=T2.N2)
SELECT * FROM T1, T2 WHERE (T1.N <= 500) AND (T1.N1=T2.N2)
根據(jù)值在字段N中的分布，兩個語句可能有不同的優(yōu)化計劃。因此使用綁定變量：
SELECT * FROM T1, T2 WHERE (T1.N <= :X) AND (T1.N1=T2.N2)
將會由于一些綁定變量的值導(dǎo)致低效的優(yōu)化。這時可以強(qiáng)制使用文字標(biāo)量代替綁定變量。
 
概念
在開始解決方案之前，這里先澄清一些基本概念。
相似語句(Similar statements)
如果任何兩個語句只是文字標(biāo)量不相同，可以認(rèn)為它們是相似的。
這純粹是一個語義學(xué)上的標(biāo)準(zhǔn)。
例如：以下的語句是相似的
INSERT INTO T VALUES(1, ‘foo’, 4)
INSERT INTO T VALUES(2, ‘bar’, 7)
INSERT INTO T VALUES(5, ‘a(chǎn)lpha’, 11)
INSERT INTO T VALUES(10, ‘kappa’, 17)
最優(yōu)共享語句（Optimally sharable statements）
相似語句可能有也可能沒有同樣的執(zhí)行計劃。例如，下面兩個語句就有相同的執(zhí)行計劃：
INSERT INTO T VALUES(1, ‘foo’, 4)
INSERT INTO T VALUES(2, ‘bar’, 7)
在本文中，這些語句叫做最優(yōu)共享語句。
因此：
最優(yōu)共享語句是具有相同最優(yōu)計劃的相似語句。
同樣也意味著最優(yōu)共享語句可以共享相同的游標(biāo)，而不會對執(zhí)行成本有任何的影響。
非最優(yōu)化共享語句（Sub-optimally sharable statements）
另一面，如下面兩個語句：
SELECT * FROM T1, T2 WHERE (T1.N <= 100) AND (T1.N1 = T2.N2)
SELECT * FROM T1, T2 WHERE (T1.N <= 500) AND (T1.N1 = T2.N2)
根據(jù)（N<=100）和（N<=500）的行數(shù)，值在字段N中的分布，在N, N1或N2上索引的可用性等情況，可能有不同的最優(yōu)計劃。例如，第一個語句可能使用一個在T1上的索引，而第二個語句可能是在T1上做全表掃描。或者第一個語句可能是作一個哈希連接而第二個語句可能是做一個嵌套循環(huán)連接。這些語句響應(yīng)地可以當(dāng)作是非最優(yōu)化共享語句，因此：
非最優(yōu)化共享語句是可能具有不同最優(yōu)計劃的相似語句。
同樣也意味著如果非最優(yōu)化共享語句共享同樣的游標(biāo)，那么在執(zhí)行效率上可能會存在損失。
最優(yōu)共享與非最優(yōu)共享語句
最優(yōu)共享和非最優(yōu)共享語句的區(qū)別并不純粹是在語義上的。它依賴于下面的因素：
l         文字標(biāo)量在語句中的位置（例如，是在VALUES子句中還是在WHERE子句中）
l         可用的訪問路徑（例如，索引的存在）
l         如果一個文字標(biāo)量出現(xiàn)在一個包含字段的謂詞中（如，N<=100用到了在字段N上的統(tǒng)計值的可用性），則取決于數(shù)據(jù)分布（統(tǒng)計值）和它的可用性
l         優(yōu)化器的算法使用
非共享語句
因為使用同樣的游標(biāo)會產(chǎn)生不正確的結(jié)果，會出現(xiàn)相似語句不能共享同一個游標(biāo)的情況。這些相似語句意味著不同的事情，或者在執(zhí)行期間做了完全不同的事。下面的語句描述了這一點：
SELECT * FROM T ORDER BY 1,4
SELECT * FROM T ORDER BY 2,3
在這個例子中，文字標(biāo)量1,2,3和4指的是選擇表項中的項目。這些語句叫做非共享語句。因此有：
非共享語句是不能共享同樣的執(zhí)行計劃的相似語句。
這里最重要的一點就是：如果兩個非共享語句共享同樣的游標(biāo)，它們其中一個就會得到錯誤的結(jié)果。
 
解決方案
這一節(jié)描述通過cursor_sharing參數(shù)所提供的解決方案
概述
新參數(shù)cursor_sharing只要有可能就允許相似語句共享游標(biāo)。根據(jù)參數(shù)的值，相似語句可以被強(qiáng)制共享相同的游標(biāo)（有可能會使用非最優(yōu)計劃），或者共享相同游標(biāo)而不危及底層執(zhí)行計劃的安全。
不管設(shè)置cursor_sharing為SIMILAR還是FORCE，Oracle都首先搜索完全相同的語句文本的游標(biāo)。如果沒有發(fā)現(xiàn)，Oracle搜索相似語句文本的游標(biāo)。
用法
參數(shù)：cursor_sharing
從Oracle 8i Release 2開始，一個新的動態(tài)參數(shù)cursor_sharing被引入。在8i中，參數(shù)可以有兩個不同的值FORCE和EXACT。從9i開始，一個新的值SIMILAR被加入。
默認(rèn)值是EXACT。它只允許完全相同文本的語句共享一個游標(biāo)。這是早期版本的行為。
SIMILAR參數(shù)值使相似語句共享同樣的游標(biāo)，而不危機(jī)執(zhí)行計劃的安全。例如：只有最優(yōu)共享語句共享游標(biāo)。
將參數(shù)值設(shè)為FORCE會強(qiáng)迫Oracle對相似語句共享游標(biāo)，但存在非最優(yōu)執(zhí)行計劃的風(fēng)險，如，最優(yōu)共享和非最優(yōu)共享語句會共享同一個游標(biāo)。只有在非最優(yōu)執(zhí)行計劃的風(fēng)險被共享游標(biāo)的性能提高超過的時候，該參數(shù)才可以被設(shè)置為FORCE，例如：如果太多的非最優(yōu)共享語句的硬解析導(dǎo)致了嚴(yán)重的性能問題。
SQL語句
一個新的標(biāo)記CURSOR_SHARING_EXACT在被SQL語句中被用于在語句級別控制游標(biāo)共享。這個標(biāo)記類似于初始化參數(shù)cursor_sharing被設(shè)置為EXACT，并屏蔽了已經(jīng)設(shè)定的初始化參數(shù)的值，也就是：它導(dǎo)致語句共享采用精確匹配構(gòu)建的游標(biāo)。
ALTER SYSTEM 和 ALTER SESSION 命令允許新參數(shù)cursor_sharing的設(shè)置和改變。語法如下面的形式：
ALTER SYSTEM SET cursor_sharing = {FORCE | SIMILAR | EXACT}
ALTER SYSTEM SET cursor_sharing = {FORCE | SIMILAR | EXACT}
動態(tài)視圖
下面的四個動態(tài)視圖顯示了綁定變量的信息：
l         GV$SQL_BIND_METADATA
l         V$SQL_BIND_METADATA
l         GV$SQL_BIND_DATA
l         V$SQL_BIND_DATA
這些視圖也包括了內(nèi)部綁定變量的信息。內(nèi)部綁定變量可以根據(jù)視圖[G]V$SQL_BIND_DATA中的字段SHARED_FLAG2與用戶綁定變量區(qū)分，內(nèi)部綁定變量的標(biāo)記值為256。
只參看內(nèi)部綁定變量的行，用戶可以考慮下面的語句：
SELECT * FROM V$SQL_BIND_DATA WHERE BITAND (SHARED_FLAG2, 256) =256
主要利益與折衷
考慮一個沒有使用綁定變量的應(yīng)用，該應(yīng)用重復(fù)地使用相似語句，大多數(shù)的執(zhí)行都將導(dǎo)致硬解析。
一個不使用綁定變量的典型應(yīng)用可能會有各種類型的語句：最優(yōu)共享，非最優(yōu)共享安和非共享。對于最優(yōu)共享語句，共享游標(biāo)明顯是有好處；非共享語句不能共享同樣的游標(biāo)。
對于非最優(yōu)共享語句沒有一個簡單的答案：共享游標(biāo)與獲取最優(yōu)計劃的比較是硬解析的系統(tǒng)耗費與強(qiáng)制使用相同執(zhí)行計劃后的性能退化之間的折衷。因此，根據(jù)系統(tǒng)負(fù)載，應(yīng)用特征，資源限制等，正確的答案是不同的。這也是Oracle 提供為cursor_sharing提供兩個不同的值SIMILAR和FORCE，并把決定權(quán)留給用戶的原因。SIMILAR是更保守的選擇，它僅僅使最優(yōu)可共享語句共享游標(biāo)。采用FORCE，最優(yōu)共享和非最優(yōu)共享語句都被強(qiáng)制共享游標(biāo)，結(jié)果便不可預(yù)測，因為游標(biāo)可能被共享但執(zhí)行計劃的性能也降低了。因此，因為硬解析造成性能有非常大的影響并且非最優(yōu)共享語句占非常大的百分比的情況下，使用FORCE是有意義的。另外一個考慮的方式是：在采用FORCE之前先嘗試SIMILAR。
當(dāng)cursor_sharing采用相似語句共享游標(biāo)的時候，硬解析轉(zhuǎn)換為軟解析。注意，由于判斷語句相似性的附加成本，軟解析比已使用綁定變量的應(yīng)用的軟解析（用綁定變量在內(nèi)部替換文字標(biāo)量）花費要昂貴一些。但是，完全保存在CPU內(nèi)部，內(nèi)存和鎖競爭任然需要考慮。
對于cursor_sharing，Oracle任然首先搜索一個精確匹配。只有當(dāng)一個完全相同文本語句的游標(biāo)沒有找到時，Oracle搜索一個相似語句的游標(biāo)。這樣做是為了確保當(dāng)遇到相同的沒有硬編碼文字標(biāo)量的SQL文本的時候，不會對性能有所影響。
因為在尋找游標(biāo)之前置換文字標(biāo)量，其他的Oracle優(yōu)化，像session_cached_cursors和cursor_space_for_time可以方便地和cursor_sharing整合。例如，將cursor_sharing和session_cached_cursors設(shè)置為一個合理的值，在文字標(biāo)量被內(nèi)部綁定變量置換之后，相似語句就可以使用緩沖打開游標(biāo)。
主要好處的概要如下：
l         應(yīng)用程序不需要做改變
l         對已經(jīng)使用綁定變量的語句沒有副作用
l         使用SIMILAR，經(jīng)常共享的游標(biāo)不會影響執(zhí)行計劃
l         作為最后的辦法，所有的相似語句都可以用FORCE強(qiáng)制共享游標(biāo)
忠告
混合語句(Mixed statements)
混合語句是既有綁定變量也有硬編碼文字標(biāo)量的語句。如：
INSERT INTO T VALUES(5, ‘a(chǎn)lpha’, :X)
如果是使用Oracle7 OCI的客戶端，混合的相似語句不會通過cursor_sharing共享游標(biāo)；在更新的版本中可以共享游標(biāo)（從Oracle8 OCI開始）。實際上，這也同樣適用于在服務(wù)器上的PL/SQL存儲過程的SQL語句，因為在服務(wù)器上的PL/SQL使用了較老的客戶端接口。
通過PL/SQL的靜態(tài)SQL
Cursor_sharing對于在PL/SQL中的靜態(tài)（嵌入）SQL沒有任何影響。
存儲概要（Stored outlines）
任何存儲概要建立都沒有將cursor_sharing設(shè)置為FORCE或SIMILAR，當(dāng)cursor_sharing被設(shè)置時（FORCE或SIMILAR）速度并不會有提升。那是因為存儲概要被SQL文本索引，當(dāng)前的cursor_sharing實現(xiàn)修改語句文本。為了使用帶有游標(biāo)共享的存儲概要，它們必須使用create_stored_outlines參數(shù)重建（并且不要使用創(chuàng)建概要語句）。
 
耗費（Overhead）
使用FORCE或SIMILAR參數(shù)，搜索為相似語句創(chuàng)建的游標(biāo)存在一個耗費。像前面提及的，這包括：
l         用原始語句文本搜索游標(biāo)
l         用內(nèi)部綁定變量替換文字標(biāo)量，并且基于新文本的搜索
當(dāng)共享游標(biāo)工作的時候，這個耗費并不重要，因為大量的硬解析會被花費很小的軟解析替換。但是，當(dāng)游標(biāo)共享沒有明顯的增加的時候，這些耗費會對性能產(chǎn)生負(fù)面的影響。在三種情況下它會發(fā)生時：
1.       應(yīng)用程序沒有使用綁定變量，發(fā)布相同的語句，并且沒有相似語句
如果應(yīng)用程序一直用同樣的文字標(biāo)量硬編碼執(zhí)行同樣的語句，它會發(fā)生。這樣的應(yīng)用程序默認(rèn)使用軟解析，并且設(shè)置游標(biāo)共享為FORCE或SIMILAR，會使軟解析更昂貴。
 
針對這樣一個應(yīng)用的情況，有一個竅門可以使用：在共享池暖啟動以后，也就是，在所有有相同文字標(biāo)量的語句都被編譯了以后，cursor_sharing可以被設(shè)置為FORCE或SIMILAR。這種情況下，Oralce會立刻發(fā)現(xiàn)哪些語句的游標(biāo)，避免額外的消耗。
 
如果在一個應(yīng)用中，有一些語句使用同樣的文字標(biāo)量而有一些語句改變文字標(biāo)量，這非常的有用。
 
2.       應(yīng)用程序發(fā)布不同結(jié)構(gòu)的語句，因而沒有任何相似語句
這樣的應(yīng)用默認(rèn)使用硬解析，設(shè)置cursor_sharing為FORCE或SIMILAR會使硬解析更昂貴一些。
 
3.       沒有使用綁定變量的應(yīng)用，設(shè)置cursor_sharing為SIMILAR，大部分相似語句被次最優(yōu)化共享
這樣的應(yīng)用默認(rèn)采用硬解析，將cursor_sharing設(shè)為FORCE，大量使用軟解析。設(shè)置cursor_sharing為SIMILAR，將使硬解析更昂貴一些。
 
使用FORCE
使用FORCE可能會導(dǎo)致一個非常壞的執(zhí)行計劃被使用。在有些情況下，壞的執(zhí)行計劃和好的執(zhí)行計劃之間的差異是非常重要的，如，DSS環(huán)境。因此，Oralce不推薦在這種情況下使用FORCE。
 
何時使用游標(biāo)共享？
這一段作一些關(guān)于使用游標(biāo)共享的建議。
使用cursor_sharing=SIMILAR
像早先提及的，cursor_sharing并不會損害使用綁定變量編寫的應(yīng)用程序的性能。設(shè)置cursor_sharing為SIMILAR，在大多數(shù)情況下，提高沒使用綁定變量的應(yīng)用程序的性能（在前一段提及的兩個情況例外）。因此，假如沒有使用綁定變量的應(yīng)用程序的性能問題，將cursor_sharing設(shè)置為SIMILAR風(fēng)險最小。應(yīng)用中使用了綁定變量的部分繼續(xù)共享游標(biāo)，那些使用硬編碼文字標(biāo)量的部分從一些游標(biāo)共享中獲益。
 
cursor_sharing=SIMILAR是否會提高應(yīng)用程序性能依賴于下面問題的答案：
l         性能低下是由于非常大量的硬解析造成的嗎？
這可以通過監(jiān)控幾個指標(biāo)來判斷，如硬解析的平均數(shù)，解析數(shù)/執(zhí)行數(shù)，平均響應(yīng)時間，會話的等待事件等等。
 
l         在共享池中的使用硬編碼文字標(biāo)量的相似語句是否很多？
可以通過動態(tài)視圖v$sql或v$sqlarea查看。
如果上面兩個問題的答案都是肯定的，那么cursor_sharing很可能會提高性能。
 
使用cursor_sharing=FORCE
在下面的情況下可以考慮使用cursor_sharing=FORCE：
l         次最優(yōu)化共享語句的比率非常高，使SIMILAR的作用不大
沒有很輕松的方法找出次最優(yōu)化語句的比率，除了測試所有的語句。另外一種方式是設(shè)置cursor_sharing=SIMILAR；如果硬解析是由于沒有相似語句沒有持續(xù)的共享游標(biāo)，然后有許多次最優(yōu)化語句，F(xiàn)ORCE是唯一的解決方案。
 
l         應(yīng)用有硬編碼文字標(biāo)量，并且在執(zhí)行時間上有一些退化，強(qiáng)迫相似語句使用相同游標(biāo)
 
當(dāng)使用SIMIlAR沒有幫助的時候，考慮FORCE作為最后的手段是有用處的。
 
何時應(yīng)該不使用cursor_sharing?
早先提及的（在“忠告”一節(jié)中），有三種情況，使用cursor_sharing會有壞處。那些情況下，沒有任何可以使用某些cursor_sharing的值共享游標(biāo)的相似語句，并且使用它只會增加解析的耗費。
另一個要記住的事情是：cursor_sharing為面對一個使用了文字標(biāo)量的應(yīng)用程序的DBA提供了一個解決方案。但是，它并不是替代使用綁定變量編寫應(yīng)用程序，也可以采用Oracle提供的其他優(yōu)化。例如，應(yīng)用程序可以保持頻繁執(zhí)行的解析語句在打開的游標(biāo)中，并且在需要的時候，只是執(zhí)行它們。這樣的優(yōu)化是基于深度的應(yīng)用程序知識，并且不能被cursor_sharing匹配。
 
結(jié)論
cursor_sharing的使用可以解決有硬解析引發(fā)的性能問題，假如應(yīng)用程序沒有使用綁定變量。基于應(yīng)用和數(shù)據(jù)庫特性以及系統(tǒng)資源，參數(shù)應(yīng)該被明智地設(shè)置。
 
附錄：一些性能測量
這一段描述了用Oracle 8i Release 2做的一個試驗，驗證cursor_sharing。
描述
這個試驗的目的是做一個基本的驗證。服務(wù)器的最大吞吐量被一些客戶端重復(fù)地發(fā)布一個單一語句測量。試驗做了三次，采用下面的特性：
1.           只使用綁定變量
有兩個目的：建立一個基線；確保每個語句不會因為使用cursor_sharing影響性能。
 
2.           只使用文字標(biāo)量，每個文字標(biāo)量都有不同的文字
發(fā)布相似語句，期望從cursor_sharing獲取最大的收益。
 
3.           每個文字標(biāo)量都使用相同的文字
并不期望從cursor_sharing獲取收益，相反，期望性能惡化。理由是測試cursor_sharing軟解析的耗費。
 
在每種情況下只測量解析吞吐量（每秒鐘的解析量）。
 
結(jié)果
下面是測試結(jié)果：