① 怎麼設置sql server 2005或2008達到C2安全等級
最簡單的回答：
1、SQL Server是資料庫叢納坦，它的分等級標准中沒有C2一說。
2、1985年美國國防部公布了《美國國防部可信計算機系統評估系統TcsEC》，裡面對電腦的安全等級的劃分有C2一說。現在主要用來指操作系統的分級。
3、EAL才是資料庫安全等級的劃分標准。
資料：
目前中國信息安全測評中心使用茄亂的標准：
GB/T 18336—2008 《信息技術 安全技術 信息技術安全性評估准則》（ISO/IEC 15408:2005）
信息安全技術安全通用評估方法：ISO/IEC 18045:2005
產品分級評估(EAL）是評估保證要求的一個基線集合。每一評估保證級定義一套一致的保證要求，合起來，評估保證級構成預定義的GB/T 18336保證級尺度。
在GB/T 18336中定義了以下7個評估保證級：
(1) 評估保證級1(EAL1)——功能測試；
(2) 評估保證級2(EAL2)——結構測試；
(3) 評估保證級3(EAL3)—滲桐—系統地測試和檢查；
(4) 評估保證級4(EAL4)——系統地設計、測試和復查；
(5) 評估保證級5(EAL5)——半形式化設計和測試；
(6) 評估保證級6(EAL6)——半形式化驗證的設計和測試；
(7) 評估保證級7(EAL7)——形式化驗證的設計和測試；
② SQL Server 補丁版本的 CU與GDR有什麼區別
常見問題
對我的 SQL Server 版本提供了 GDR 和/或 CU（累積更新）更新。我如何知道該使用哪個更新？
首先，確定 SQL Server 的版本號。有關確定 SQL Server 版本號的更多信息，請參閱 Microsoft 知識庫文章321185 - 如何確定 SQL Server 及其組件的版本、版本類別和更新級別。
其次，在下表中，找出你的版本號及其所屬的版本范圍。相應的更新指您需要安裝的更新。
GDR 更新 – 累積僅包含適用於給定基線的安全更新。
CU 更新 – 累積包含適用於給定基線的所有功能修復程序和安全更新。
如果 SQL Server 安裝了基線版本，則可以選擇 GDR 或 CU 更新。
如果 SQL Server 安裝有意只安裝了過去的 GDR 更新，則選擇安裝 GDR 更新包。
如果 SQL Server 安裝有意只安裝了以前的 CU 更新，則選擇安裝 CU 安全更新包。
注意：您僅有一次機會可以將 GDR 更新更改為 CU 更新。一旦 SQL Server CU 更新應用於 SQL Server 安裝，將無法返回到 GDR 更新路徑。
注意如果您的 SQL Server 版本號未列在下表中，則說明此 SQL Server 版本不再受支持。請升級到最新的 Service Pack 或 SQL Server 產品，以便使用本次和未來的安全更新。
什麼是 GDR 和 CU 更新名稱，兩者有何差別？
GDR（General Distribution Release，普通分發版本）和 CU（Cumulative Update，累積更新）對應於兩種不同的可用於 SQL Server 基線版本的服務選項。基線可以是 RTM 版本或 Service Pack 版本。
對於任何給定基線，GDR 或 CU 更新均為可選項（見下文）。
詳情參見：網頁鏈接
③ oracle的SQL索引使用
1，第一次查詢慢，以後就快了，主要是因為第一次要進行磁碟操作，以後數據被cache到內存中了，不在操作磁碟，所以就快了。
2，對於你說的這四種查詢，where條件中的a=a估計你是舉例子這樣寫的吧。實際上應該是a=變數A。其他的b，或游罩c，d也是這樣。那麼這種語句都是可以利用你說的復合索衫鬧引的。如果是RBO優化器，這四句都應該用索引。但是oracle現在推薦的CBO優化器不能保證你磨賀都走索引。
3，到底用沒用索引，你可以從v$sqlaera中找到你的語句對應的hash_value，然後從v$sql_plan中找到語句的執行計劃，通過執行計劃確認你的語句是不是使用了索引。
具體語句你可以類似如下寫法：
select hash_value,sql_text from v$sqlarea where upper(sql_text) like '%你需要查找的sql語句的特徵片段%'
select * from v$sql_plan where hash_value = 上一句查到的hash_value
④ 如何創建 SQL 計劃基線
創建和發展 SQL 計劃基線
Oracle ACE 總監 Bjoern Rost 在 OTN 虛擬技術峰會專題講座上做察猜鏈了這個題為「利用 SQL 計劃管理改變 SQL 調優思路」的上機操作。這個上機操作演示了如何使用自動捕獲為查詢創建 SQL 計劃基線，並演示了如何即使在添加索引之後，實際上也只使用接受的基線（使用全表掃描），直至檢查和發展新的基線。
必需元素：Oracle 開發人員虛擬機
上機操作說明
我們將通過一個非常簡單的查詢使用一個兆罩簡單的示例表。我們將先對未建立索引的列運行查詢，這將返回全表掃描結果。然後，我們將在該列上添加一個索引，看看是否仍然執行全表掃描敗孫並添加一個新的基線，其狀態為未接受。我們將生成一個發展報告，最終發展成新基線，刪除舊基線。
在開發人員 VM 中，以 pmuser/oracle 身份運行以下命令並收集統計信息。您可以從命令行或 SQLDeveloper GUI 工具使用 sqlplus。
[oracle@localhost ~]$ sqlplus pmuser/oracle
SQL*Plus: Release 12.1.0.1.0 Proction on Thu Jun 12 09:48:13 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Proction
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
PDB1@ORCL> create table t as select * from dba_objects;
Table created.
PDB1@ORCL> exec DBMS_STATS.GATHER_SCHEMA_STATS ('PMUSER');
PL/SQL procere successfully completed.
第 1 步：驗證 OPTIMIZER_USE_SQL_BLAN_BASELINES 是否設置為 true（默認值）
PDB1@ORCL> show parameter baselines
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
第 2 步：為此會話啟用自動捕獲，運行一條語句兩次，並再次禁用自動捕獲。
PDB1@ORCL> ALTER SESSION SET OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES = TRUE;
Session altered.
PDB1@ORCL> variable var42 varchar2(42);
PDB1@ORCL> exec :var42 := 'PMUSER';
PL/SQL procere successfully completed.
PDB1@ORCL> select count(*) from t where owner= :var42;
COUNT(*)
----------
5
PDB1@ORCL> select count(*) from t where owner= :var42;
COUNT(*)
----------
5
PDB1@ORCL> ALTER SESSION SET OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES = FALSE;
Session altered.
現在，我們應得到該 sql 的基線：
PDB1@ORCL> set linesize 300
PDB1@ORCL> column sql_handle format a20
PDB1@ORCL> column plan_name format a42
PDB1@ORCL> column sql_text format a42
PDB1@ORCL> select sql_handle, plan_name, sql_text, enabled, accepted, fixed from dba_sql_plan_baselines;
SQL_HANDLE PLAN_NAME SQL_TEXT ENA ACC FIX
-------------------- ------------------------------ ------------------------------------------ --- --- ---
SQL_abdfaaa7e926cf0a SQL_PLAN_arrxanznkdmsa3fdbb376 select count(*) from t where owner= :var42 YES YES NO
注意，現在該語句有了一條基線，並自動設置為 ACCEPTED。現在我們創建一個索引，啟用自動捕獲重新運行查詢，通過索引掃描收集新基線。
PDB1@ORCL> create index t_idx on t (owner);
Index created.
PDB1@ORCL> exec dbms_stats.gather_schema_stats ('PMUSER');
PL/SQL procere successfully completed.
PDB1@ORCL> alter system flush shared_pool;
System altered.
PDB1@ORCL> ALTER SESSION SET OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES = TRUE;
Session altered.
PDB1@ORCL> select count(*) from t where owner= :var42;
COUNT(*)
----------
5
PDB1@ORCL> select count(*) from t where owner= :var42;
COUNT(*)
----------
5
PDB1@ORCL> ALTER SESSION SET OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES = FALSE;
Session altered.
⑤ oracle 10g 安裝後打開oem 後顯示SQL的基線不可用，重置後顯示如下圖。求高手幫忙.
需要先建立快照。
⑥ 用共享游標提升 MSSQL 性能
Boost SQL Performance with cursor_sharing
關鍵詞：cursor_sharing
概述
本文闡述在Oracle8i Release 2和Oracle9i中增強的游標共享設施。這些增強功能被一個新的參數cursor_sharing控制。
cursor_sharing的目的就是提高沒有使用綁定變數(bind vvariable)的應用程序伺服器的性能。
需要 cursor_sharing
本段解釋為什麼應用程序不使用綁定變數(bind variables)會帶來性能問題。
應用程序反復執行相似的SQL語句
使用Oracle資料庫管理他（她）們的數據的應用程序必須使用SQL語句訪問/修改資料庫。這些SQL語句可以是由一個應用程序使用OCI, OCCI, JDBC, PL/SQL等直接產生的，也是可以是使用其他工具和庫（例如：dbms_sql）間接產生的。
根據不用的應用類型，通常一個應用程序都為最終用戶提供了一個固定的功能集合，例如，一個人力資源應用程序可能會提供一些像增加一個新雇員，修改一個雇員的個人信息等功能。最終這些功能使用SQL訪問和/或修改數據。因為應用程序重復地執行這些功能，一個應用和Oracle資料庫的交互是由相似的SQL語句的反復執行構成的。
SQL調用的步驟
為執行一個SQL語句，客戶端可以使用使用不同的介面。例如，通過OCI介面，客戶端創建一個語句句柄(statement handle)，然後perpare這個語句，綁定，定義和執行這個語句句柄，或者，SQL語句也可以通過一個PL/SQL過程被執行。
按照客戶端介面，Oracle資料庫一直都使用固定的步驟（默認）：
1. 打開一個游標 － 用戶游標是一個和SQL語句相關的全部用戶狀態的句柄，像執行內存，共享游標團橘御引用，用戶游標的當前狀態等等。
2. 解析一個SQL語句到打開的用戶游標中 －使SQL語句和用戶游標關聯；它也建立了一個共享游標，對應於SQL語句的解析格式。在一些情況下，共享游標也可以作為解析的一部分被校對和優化。解析，校對和優化SQL語句的過程通常是非常耗費CPU時間，內存和連接資源的。
3. 如有需要，綁定變數 － 給伍態Oracle提供SQL語句中綁定變數的數據類型，大小和值等必要的信息。
4. 校對優化共享游標，如果還沒有做這項工作的話。
5. 執行用戶游標 － 這一步真正完成語句執行的工作，根據語句的復雜程度消耗CPU和會話內存(session memory)。
注意，解析，校對和優化（在本文中統稱為編譯）組成了執行一個SQL語句塌岩的消耗，並且能夠限制資料庫的容量和可測量性。
共享游標
一個典型的重復執行相似語句的應用，在Oracle資料庫許多針對SQL處理目的的優化重復執行。最重要的優化是共享游標，試圖通過在相同的語句的不同執行之間共享編譯結果來消除編譯的耗費（不是並發就是在不同的時間發生）。
User Session 1
Private
execution
state
User Session 2
Private
execution
state
Shared Cursor
為了能夠使用共享游標，Oracle分割語句執行狀態到共享游標中，並且在實例中預處理。共享游標是編譯的結果並包含了執行計劃；它在緩存在共享池中。每個執行該語句的會話有一個預執行狀態的私有拷貝，如用戶游標，運行時變數值等。
在解析階段（上面提到的第2步），Oracle首先搜索一個已經存在的可以被用戶會話共享的共享游標。Oracle把搜索分為兩步：基於SQL文本的檢索，找到相同SQL文本創建的游標，根據其他標准選擇適當的游標，如優化模式，訪問的基本對象等。如果一個可以共享的游標被找到，並不需要編譯，這個處理成為軟解析（soft parse）。否則，編譯SQL語句創建新的共享游標，這個處理成為硬解析（hard parse）。
當被應用程序使用的大多數語句能夠共享同樣的游標集合時，大多數解析變成為軟解析，進而提高資料庫伺服器的能力/吞吐量（縮減了內存和CPU的使用），響應時間（減少了解析階段所使用的時間）和可測量性（減少了閉鎖連接（latch connection） ）。
為什麼游標不是共享的？
假設其他的因素是相同的，如可配置的實例/會話/事務等級參數，理論上，如果在同樣的行/對象上執行同樣的操作，使用同樣的計劃，語句S1和S2的游標可以被共享。但是要計算和找出這些游標是非常困難的，這樣做也可能抵消共享游標帶來的好處。因此，Oracle游標共享標准規定在所有的情況下默認都不共享游標，除非它們被設計得很高效。從8i Release 2開始，如果S1和S2都是文本的並且不少的其他條件都相同（對象名被轉換成為同樣的基本對象，會話中語句的優化模式相同，等等），它們可以共享同一個游標。
當應用程序在語句中使用文字標量替代綁定變數時就會導致一個游標共享的問題。如應用程序最終產生的語句只是在文字標量上有一些不同，甚至語句都是相同的。如，一個應用程序沒有使用綁定變數，可以假設在不同的時間或不同的會話中有下面兩個語句：
INSERT INTO T VALUES(1, 『foo』, 4)
INSERT INTO T VALUES(2, 『bar』, 7)
因為這兩個語句文本上並不相同，它們最終產生不同的游標。
有幾種情況下應用程序可能不會使用綁定變數：
l 用文字標量很容易就寫出一個SQL語句，特別是使用了一些工具
l 老的Oracle關系資料庫不支持綁定變數（至少是沒有共享游標的好處，從Oracle7才開始使用它們），已有的應用程序要求作一些代碼升級的工作。
l 其他所有的資料庫供應商都不支持綁定變數，即使有語法也不相同；因此，使用特定的Oracle語法/特性會使應用程序失去與其他數據的兼容性。
l 如果一個語句使用綁定變數，那麼它就一直使用相同的執行計劃。如果不同的綁定變數會有不同的優化計劃就可能產生問題，如，考慮下面的語句：
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)
根據值在欄位N中的分布，兩個語句可能有不同的優化計劃。因此使用綁定變數：
SELECT * FROM T1, T2 WHERE (T1.N = :X) AND (T1.N1=T2.N2)
將會由於一些綁定變數的值導致低效的優化。這時可以強制使用文字標量代替綁定變數。
概念
在開始解決方案之前，這里先澄清一些基本概念。
相似語句(Similar statements)
如果任何兩個語句只是文字標量不相同，可以認為它們是相似的。
這純粹是一個語義學上的標准。
例如：以下的語句是相似的
INSERT INTO T VALUES(1, 『foo』, 4)
INSERT INTO T VALUES(2, 『bar』, 7)
INSERT INTO T VALUES(5, 『alpha』, 11)
INSERT INTO T VALUES(10, 『kappa』, 17)
最優共享語句（Optimally sharable statements）
相似語句可能有也可能沒有同樣的執行計劃。例如，下面兩個語句就有相同的執行計劃：
INSERT INTO T VALUES(1, 『foo』, 4)
INSERT INTO T VALUES(2, 『bar』, 7)
在本文中，這些語句叫做最優共享語句。
因此：
最優共享語句是具有相同最優計劃的相似語句。
同樣也意味著最優共享語句可以共享相同的游標，而不會對執行成本有任何的影響。
非最優化共享語句（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)
根據（N=100）和（N=500）的行數，值在欄位N中的分布，在N, N1或N2上索引的可用性等情況，可能有不同的最優計劃。例如，第一個語句可能使用一個在T1上的索引，而第二個語句可能是在T1上做全表掃描。或者第一個語句可能是作一個哈希連接而第二個語句可能是做一個嵌套循環連接。這些語句響應地可以當作是非最優化共享語句，因此：
非最優化共享語句是可能具有不同最優計劃的相似語句。
同樣也意味著如果非最優化共享語句共享同樣的游標，那麼在執行效率上可能會存在損失。
最優共享與非最優共享語句
最優共享和非最優共享語句的區別並不純粹是在語義上的。它依賴於下面的因素：
l 文字標量在語句中的位置（例如，是在VALUES子句中還是在WHERE子句中）
l 可用的訪問路徑（例如，索引的存在）
l 如果一個文字標量出現在一個包含欄位的謂詞中（如，N=100用到了在欄位N上的統計值的可用性），則取決於數據分布（統計值）和它的可用性
l 優化器的演算法使用
非共享語句
因為使用同樣的游標會產生不正確的結果，會出現相似語句不能共享同一個游標的情況。這些相似語句意味著不同的事情，或者在執行期間做了完全不同的事。下面的語句描述了這一點：
SELECT * FROM T ORDER BY 1,4
SELECT * FROM T ORDER BY 2,3
在這個例子中，文字標量1,2,3和4指的是選擇表項中的項目。這些語句叫做非共享語句。因此有：
非共享語句是不能共享同樣的執行計劃的相似語句。
這里最重要的一點就是：如果兩個非共享語句共享同樣的游標，它們其中一個就會得到錯誤的結果。
解決方案
這一節描述通過cursor_sharing參數所提供的解決方案
概述
新參數cursor_sharing只要有可能就允許相似語句共享游標。根據參數的值，相似語句可以被強制共享相同的游標（有可能會使用非最優計劃），或者共享相同游標而不危及底層執行計劃的安全。
不管設置cursor_sharing為SIMILAR還是FORCE，Oracle都首先搜索完全相同的語句文本的游標。如果沒有發現，Oracle搜索相似語句文本的游標。
用法
參數：cursor_sharing
從Oracle 8i Release 2開始，一個新的動態參數cursor_sharing被引入。在8i中，參數可以有兩個不同的值FORCE和EXACT。從9i開始，一個新的值SIMILAR被加入。
默認值是EXACT。它只允許完全相同文本的語句共享一個游標。這是早期版本的行為。
SIMILAR參數值使相似語句共享同樣的游標，而不危機執行計劃的安全。例如：只有最優共享語句共享游標。
將參數值設為FORCE會強迫Oracle對相似語句共享游標，但存在非最優執行計劃的風險，如，最優共享和非最優共享語句會共享同一個游標。只有在非最優執行計劃的風險被共享游標的性能提高超過的時候，該參數才可以被設置為FORCE，例如：如果太多的非最優共享語句的硬解析導致了嚴重的性能問題。
SQL語句
一個新的標記CURSOR_SHARING_EXACT在被SQL語句中被用於在語句級別控制游標共享。這個標記類似於初始化參數cursor_sharing被設置為EXACT，並屏蔽了已經設定的初始化參數的值，也就是：它導致語句共享採用精確匹配構建的游標。
ALTER SYSTEM 和 ALTER SESSION 命令允許新參數cursor_sharing的設置和改變。語法如下面的形式：
ALTER SYSTEM SET cursor_sharing = {FORCE | SIMILAR | EXACT}
ALTER SYSTEM SET cursor_sharing = {FORCE | SIMILAR | EXACT}
動態視圖
下面的四個動態視圖顯示了綁定變數的信息：
l GV$SQL_BIND_METADATA
l V$SQL_BIND_METADATA
l GV$SQL_BIND_DATA
l V$SQL_BIND_DATA
這些視圖也包括了內部綁定變數的信息。內部綁定變數可以根據視圖[G]V$SQL_BIND_DATA中的欄位SHARED_FLAG2與用戶綁定變數區分，內部綁定變數的標記值為256。
只參看內部綁定變數的行，用戶可以考慮下面的語句：
SELECT * FROM V$SQL_BIND_DATA WHERE BITAND (SHARED_FLAG2, 256) =256
主要利益與折衷
考慮一個沒有使用綁定變數的應用，該應用重復地使用相似語句，大多數的執行都將導致硬解析。
一個不使用綁定變數的典型應用可能會有各種類型的語句：最優共享，非最優共享安和非共享。對於最優共享語句，共享游標明顯是有好處；非共享語句不能共享同樣的游標。
對於非最優共享語句沒有一個簡單的答案：共享游標與獲取最優計劃的比較是硬解析的系統耗費與強制使用相同執行計劃後的性能退化之間的折衷。因此，根據系統負載，應用特徵，資源限制等，正確的答案是不同的。這也是Oracle 提供為cursor_sharing提供兩個不同的值SIMILAR和FORCE，並把決定權留給用戶的原因。SIMILAR是更保守的選擇，它僅僅使最優可共享語句共享游標。採用FORCE，最優共享和非最優共享語句都被強制共享游標，結果便不可預測，因為游標可能被共享但執行計劃的性能也降低了。因此，因為硬解析造成性能有非常大的影響並且非最優共享語句占非常大的百分比的情況下，使用FORCE是有意義的。另外一個考慮的方式是：在採用FORCE 之前先嘗試SIMILAR。
當cursor_sharing採用相似語句共享游標的時候，硬解析轉換為軟解析。注意，由於判斷語句相似性的附加成本，軟解析比已使用綁定變數的應用的軟解析（用綁定變數在內部替換文字標量）花費要昂貴一些。但是，完全保存在CPU內部，內存和鎖競爭任然需要考慮。
對於cursor_sharing，Oracle任然首先搜索一個精確匹配。只有當一個完全相同文本語句的游標沒有找到時，Oracle搜索一個相似語句的游標。這樣做是為了確保當遇到相同的沒有硬編碼文字標量的SQL文本的時候，不會對性能有所影響。
因為在尋找游標之前置換文字標量，其他的Oracle優化，像session_cached_cursors和cursor_space_for_time 可以方便地和cursor_sharing整合。例如，將cursor_sharing和session_cached_cursors設置為一個合理的值，在文字標量被內部綁定變數置換之後，相似語句就可以使用緩沖打開游標。
主要好處的概要如下：
l 應用程序不需要做改變
l 對已經使用綁定變數的語句沒有副作用
l 使用SIMILAR，經常共享的游標不會影響執行計劃
l 作為最後的辦法，所有的相似語句都可以用FORCE強制共享游標
忠告
混合語句(Mixed statements)
混合語句是既有綁定變數也有硬編碼文字標量的語句。如：
INSERT INTO T VALUES(5, 『alpha』, :X)
如果是使用Oracle7 OCI的客戶端，混合的相似語句不會通過cursor_sharing共享游標；在更新的版本中可以共享游標（從Oracle8 OCI開始）。實際上，這也同樣適用於在伺服器上的PL/SQL存儲過程的SQL語句，因為在伺服器上的PL/SQL使用了較老的客戶端介面。
通過PL/SQL的靜態SQL
Cursor_sharing對於在PL/SQL中的靜態（嵌入）SQL沒有任何影響。
存儲概要（Stored outlines）
任何存儲概要建立都沒有將cursor_sharing設置為FORCE或SIMILAR，當cursor_sharing被設置時（FORCE或 SIMILAR）速度並不會有提升。那是因為存儲概要被SQL文本索引，當前的cursor_sharing實現修改語句文本。為了使用帶有游標共享的存儲概要，它們必須使用create_stored_outlines參數重建（並且不要使用創建概要語句）。
耗費（Overhead）
使用FORCE或SIMILAR參數，搜索為相似語句創建的游標存在一個耗費。像前面提及的，這包括：
l 用原始語句文本搜索游標
l 用內部綁定變數替換文字標量，並且基於新文本的搜索
當共享游標工作的時候，這個耗費並不重要，因為大量的硬解析會被花費很小的軟解析替換。但是，當游標共享沒有明顯的增加的時候，這些耗費會對性能產生負面的影響。在三種情況下它會發生時：
1. 應用程序沒有使用綁定變數，發布相同的語句，並且沒有相似語句
如果應用程序一直用同樣的文字標量硬編碼執行同樣的語句，它會發生。這樣的應用程序默認使用軟解析，並且設置游標共享為FORCE或SIMILAR，會使軟解析更昂貴。
針對這樣一個應用的情況，有一個竅門可以使用：在共享池暖啟動以後，也就是，在所有有相同文字標量的語句都被編譯了以後，cursor_sharing可以被設置為FORCE或SIMILAR。這種情況下，Oralce會立刻發現哪些語句的游標，避免額外的消耗。
如果在一個應用中，有一些語句使用同樣的文字標量而有一些語句改變文字標量，這非常的有用。
2. 應用程序發布不同結構的語句，因而沒有任何相似語句
這樣的應用默認使用硬解析，設置cursor_sharing為FORCE或SIMILAR會使硬解析更昂貴一些。
3. 沒有使用綁定變數的應用，設置cursor_sharing為SIMILAR，大部分相似語句被次最優化共享
這樣的應用默認採用硬解析，將cursor_sharing設為FORCE，大量使用軟解析。設置cursor_sharing為SIMILAR，將使硬解析更昂貴一些。
使用FORCE
使用FORCE可能會導致一個非常壞的執行計劃被使用。在有些情況下，壞的執行計劃和好的執行計劃之間的差異是非常重要的，如，DSS環境。因此，Oralce不推薦在這種情況下使用FORCE。
何時使用游標共享？
這一段作一些關於使用游標共享的建議。
使用cursor_sharing=SIMILAR
像早先提及的，cursor_sharing並不會損害使用綁定變數編寫的應用程序的性能。設置cursor_sharing為SIMILAR，在大多數情況下，提高沒使用綁定變數的應用程序的性能（在前一段提及的兩個情況例外）。因此，假如沒有使用綁定變數的應用程序的性能問題，將 cursor_sharing設置為SIMILAR風險最小。應用中使用了綁定變數的部分繼續共享游標，那些使用硬編碼文字標量的部分從一些游標共享中獲益。
cursor_sharing=SIMILAR是否會提高應用程序性能依賴於下面問題的答案：
l 性能低下是由於非常大量的硬解析造成的嗎？
這可以通過監控幾個指標來判斷，如硬解析的平均數，解析數/執行數，平均響應時間，會話的等待事件等等。
l 在共享池中的使用硬編碼文字標量的相似語句是否很多？
可以通過動態視圖v$sql或v$sqlarea查看。
如果上面兩個問題的答案都是肯定的，那麼cursor_sharing很可能會提高性能。
使用cursor_sharing=FORCE
在下面的情況下可以考慮使用cursor_sharing=FORCE：
l 次最優化共享語句的比率非常高，使SIMILAR的作用不大
沒有很輕松的方法找出次最優化語句的比率，除了測試所有的語句。另外一種方式是設置cursor_sharing=SIMILAR；如果硬解析是由於沒有相似語句沒有持續的共享游標，然後有許多次最優化語句，FORCE是唯一的解決方案。
l 應用有硬編碼文字標量，並且在執行時間上有一些退化，強迫相似語句使用相同游標
當使用SIMIlAR沒有幫助的時候，考慮FORCE作為最後的手段是有用處的。
何時應該不使用cursor_sharing?
早先提及的（在「忠告」一節中），有三種情況，使用cursor_sharing會有壞處。那些情況下，沒有任何可以使用某些cursor_sharing的值共享游標的相似語句，並且使用它只會增加解析的耗費。
另一個要記住的事情是：cursor_sharing為面對一個使用了文字標量的應用程序的DBA提供了一個解決方案。但是，它並不是替代使用綁定變數編寫應用程序，也可以採用Oracle提供的其他優化。例如，應用程序可以保持頻繁執行的解析語句在打開的游標中，並且在需要的時候，只是執行它們。這樣的優化是基於深度的應用程序知識，並且不能被cursor_sharing匹配。
結論
cursor_sharing的使用可以解決有硬解析引發的性能問題，假如應用程序沒有使用綁定變數。基於應用和資料庫特性以及系統資源，參數應該被明智地設置。
附錄：一些性能測量
這一段描述了用Oracle 8i Release 2做的一個試驗，驗證cursor_sharing。
描述
這個試驗的目的是做一個基本的驗證。伺服器的最大吞吐量被一些客戶端重復地發布一個單一語句測量。試驗做了三次，採用下面的特性：
1. 只使用綁定變數
有兩個目的：建立一個基線；確保每個語句不會因為使用cursor_sharing影響性能。
2. 只使用文字標量，每個文字標量都有不同的文字
發布相似語句，期望從cursor_sharing獲取最大的收益。
3. 每個文字標量都使用相同的文字
並不期望從cursor_sharing獲取收益，相反，期望性能惡化。理由是測試cursor_sharing軟解析的耗費。
在每種情況下只測量解析吞吐量（每秒鍾的解析量）。
結果
下面是測試結果：
Typecursor_sharing=EXACTcursor_sharing=FORCEBinds only26502650Similar statements86025001 statement with literalsg33002600
Oracle 8.1.7 採用cursor_sharing的解析吞吐量(解析數/秒)
⑦ sql最高幾條相同的
兩尺核余條。sql官方設定為最高兩條相同。sql是具有數據操陵滾縱和數據定義等多種功能的資料庫語言，這種語言具有交互性特點，能為用氏悔戶提供極大的便利。
⑧ 6.mybatis裡面的動態sql是怎麼設定的，常用標簽有那些以及其
1、動態SQL片段
通過SQL片段達到代碼復用
<!-- 動態條件分頁查詢 -->
<sql id="sql_count">
select count(*)
</sql>
<sql id="sql_select">
select *
</sql>
<sql id="sql_where">
from icp
<dynamic prepend="where">
<isNotEmpty prepend="and" property="name">
name like '%$name$%'
</isNotEmpty>
<isNotEmpty prepend="and" property="path">
path like '%path$%'
</isNotEmpty>
<isNotEmpty prepend="and" property="area_id">
area_id = #area_id#
</isNotEmpty>
<isNotEmpty prepend="and" property="hided">
hided = #hided#
</isNotEmpty>
</dynamic>
<dynamic prepend="">
<isNotNull property="_start">
<isNotNull property="_size">
limit #_start#, #_size#
</isNotNull>
</isNotNull>
</dynamic>
</sql>
<select id="findByParamsForCount" parameterClass="map" resultClass="int">
<include refid="sql_count"/>
<include refid="sql_where"/>
</select>
<select id="findByParams" parameterClass="map" resultMap="icp.result_base">
<include refid="sql_select"/>
<include refid="sql_where"/>
</select>
2、數字范圍查詢
所傳參數名稱是捏造所得，非資料庫欄位，比如_img_size_ge、_img_size_lt欄位
<isNotEmpty prepend="and" property="_img_size_ge">
<![CDATA[
img_size >= #_img_size_ge#
]]>
</isNotEmpty>
<isNotEmpty prepend="and" property="_img_size_lt">
<![CDATA[
img_size < #_img_size_lt#
]]>
</isNotEmpty>
多次使用一個參數也是允許的
<isNotEmpty prepend="and" property="_now">
<![CDATA[
execplantime >= #_now#
]]>
</isNotEmpty>
<isNotEmpty prepend="and" property="_now">
<![CDATA[
closeplantime <= #_now#
]]>
</isNotEmpty>
3、時間范圍查詢
<isNotEmpty prepend="" property="_starttime">
<isNotEmpty prepend="and" property="_endtime">
<![CDATA[
createtime >= #_starttime#
and createtime < #_endtime#
]]>
</isNotEmpty>
</isNotEmpty>