ORACLE 11GR2經常使用參數(含隱含參數)設置

ORACLE 11GR2經常使用參數(含隱含參數)設置以下：

alter system set "_PX_use_large_pool" = true scope=spfile;
alter system set "_clusterwide_global_transactions" = false scope=spfile;#RAC環境 https://www.sohu.com/a/152628320_505827
alter system set "_gc_defer_time" = 3 scope=spfile;
alter system set "_resource_manager_always_off" = true scope=spfile;
alter system set "_resource_manager_always_on" = false scope=spfile;
alter system set "_serial_direct_read" = never scope=spfile;
alter system set "_cleanup_rollback_entries" = 400 scope=spfile;
alter system set "_optimizer_use_feedback" = false scope=spfile;
alter system set "_dbms_sql_security_level" =0 scope=spfile;
alter system set "_bloom_pruning_enabled" = false scope=spfile;
修改DRM（有bug，易致使RAC 實例崩潰）
alter system set "_gc_policy_time" = 0 scope=spfile sid='*';
alter system set "_bloom_filter_enabled" = false scope=spfile;
alter system set "_gc_read_mostly_locking" = false scope=spfile;
alter system set "_gc_undo_affinity" = false scope=spfile;
#alter system set "_smu_debug_mode" = 134217728 scope=spfile;#http://www.laoxiong.net/how-to-drop-undo-segment.html
alter system set "_undo_autotune" = false scope=spfile;
alter system set deferred_segment_creation = false scope=spfile;
alter system set audit_trail = none scope=spfile;
alter system set event='28401 trace name context forever,level 1' scope=spfile;
關閉11g新特性自適應遊標共享（Adaptive Cursor Sharing）
alter system set "_optimizer_extended_cursor_sharing_rel"=none;
alter system set "_optimizer_extended_cursor_sharing"=none;
alter system set "_optimizer_adaptive_cursor_sharing"=false;
alter system set "_memory_imm_mode_without_autosga"=false sid='*';關閉 _memory_imm_mode_without_autosga http://blog.itpub.net/27243841/viewspace-1147107/ 避免ORA4031
alter system set "_b_tree_bitmap_plans"=false sid='*';修改_b_tree_bitmap_plans，https://www.cnblogs.com/archersun/p/3173141.html
alter system set "_partition_large_extents"='FALSE' sid='*';
alter system set "parallel_force_local"=TRUE scope=spfile sid='*';
alter system set "parallel_max_servers"=64 scope=spfile sid='*';
alter system set "_use_adaptive_log_file_sync"='FALSE' sid='*'; _use_adaptive_log_file_sync 下降log_file_sync等待 http://blog.itpub.net/28572479/viewspace-2130627/

參數釋義：
1、_PX_use_large_pool
並行執行從屬進程一塊兒工做時會交換數據和信息，因此咱們須要從shared pool或large pool中分配內存，
這個取決於PARALLEL_AUTOMATIC_TUNING參數值的設置，_PX_use_large_pool所起的做用跟PARALLEL_AUTOMATIC_TUNING參數差很少。
當PARALLEL_AUTOMATIC_TUNING=TRUE時從large pool中分配內存，不然從shared pool分配。
10g中,PX信息緩存在large pool中分配，若是：
a.) parallel_automatic_tuning = true (棄用) or
b.) _PX_use_large_pool = true or
c.) sga_target is set

11g中,PX信息緩存在large pool中分配，若是：
a.) parallel_automatic_tuning = true (棄用) or
b.) _PX_use_large_pool = true or
c.) SGA memory is auto tuned (sga_target or memory_target)
2、_clusterwide_global_transactions
集羣範圍全局性事務(Clusterwide global transactions)是11g的新特性，其允許XA事務(XA分佈式事務)在RAC中更透明。基本上，
一個集羣範圍全局性事務是一個在RAC中的每一個節點均有一個本地事務的分佈式事務，當_clusterwide_global_transactions=true(默認)時，
ORACLE會把這些本地事務當作一個事務對待，當_clusterwide_global_transactions=false時，ORACLE會將這些本地事務當作單獨的事務
經過多階段提交協調處理。設置該參數爲false不會有任何性能影響。

設置該參數值爲FALSE能夠解決以下等問題：
Bug 13605839 ORA-600 [ktbsdp1] ORA-600 [kghfrempty:ds] ORA-600 [kdBlkCheckError]. Corruption in Rollback with Clusterwide Global Transactions in RAC
ORA-00600: [kjuscl:!free]

****************************************************
XA釋義：
XA是X/Open DTP組織(X/Open DTP group)定義的兩階段提交協議，XA被許多數據庫(如Oracle和DB2)和中間件等工具(如CICS 和 Tuxedo).本地支持 。
X/Open DTP模型(1994)包括應用程序(AP)、事務管理器(TM)、資源管理器(RM)、通訊資源管理器(CRM)四部分。在這個模型中，
一般事務管理器(TM)是交易中間件，資源管理器(RM)是數據庫，通訊資源管理器(CRM)是消息中間件。
通常狀況下，某一數據庫沒法知道其它數據庫在作什麼，所以，在一個DTP環境中，交易中間件是必需的，由它通知和協調相關數據庫的提交或回滾。
而一個數據庫只將其本身所作的操做(可恢復)影射到全局事務中。
XA就是X/Open DTP定義的交易中間件與數據庫之間的接口規範(即接口函數)，交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。
XA接口函數由數據庫廠商提供。一般狀況下，交易中間件與數據庫經過XA接口規範，使用兩階段提交來完成一個全局事務。

XA規範的基礎是兩階段提交協議：
在第一階段，交易中間件請求全部相關數據庫準備提交(預提交)各自的事務分支，以確認是否全部相關數據庫均可以提交各自的事務分支。
當某一數據庫收到預提交後，若是能夠提交屬於本身的事務分支，則將本身在該事務分支中所作的操做固定記錄下來，並給交易中間件一個贊成提交的應答，
此時數據庫將不能再在該事務分支中加入任何操做，但此時數據庫並無真正提交該事務，數據庫對共享資源的操做還未釋放(處於鎖定狀態)。
若是因爲某種緣由數據庫沒法提交屬於本身的事務分支，它將回滾本身的全部操做，釋放對共享資源上的鎖，並返回給交易中間件失敗應答。

在第二階段，交易中間件審查全部數據庫返回的預提交結果，如全部數據庫均可以提交，交易中間件將要求全部數據庫作正式提交，這樣該全局事務被提交。
而若是有任一數據庫預提交返回失敗，交易中間件將要求全部其它數據庫回滾其操做，這樣該全局事務被回滾。
****************************************************
3、_gc_defer_time
how long to defer pings for hot buffers in milliseconds
用於肯定服務器在將頻繁使用的塊寫入磁盤以前要等待的時間長度 (以 1/1000 秒爲單位)，以減小進程對熱塊的爭用，默認爲0。
4、_resource_manager_always_off、_resource_manager_always_on
默認FALSE、TRUE，其默認是啓用資源調度。
將_resource_manager_always_off = true、_resource_manager_always_on = false即爲禁用Oracle缺省啓用的資源調度,
避免可能產生resmgr:cpu quantum等待事件狀況。因爲在11g中資源調度存在諸多BUG，故選擇關閉。
部分官檔：
'resmgr:cpu quantum' wait event in 11g when VKRM process is not present (文檔 ID 1603996.1)
Awr Reports hang, MMon slaves are waiting on resmgr:cpu quantum (文檔 ID 1530676.1)
5、_serial_direct_read
在Oracle 11g中，全表掃描可能使用direct path read方式(不管表大小)，而不是buffer cache，這樣的全表掃描就是物理讀了。
_serial_direct_read = false 禁用direct path read
_serial_direct_read = true 啓用direct path read
_serial_direct_read = never 能夠顯著地減小direct path read
6、_cleanup_rollback_entries
該參數指定回滾時每次回滾的ENTRIES個數，默認爲100，設置成400加快回滾速度。
7、_optimizer_use_feedback
11.2開始Oracle有了一種新的特性Cardinality Feedback，Cardinality Feedback是一個優化器自動優化的過程，
優化器會自動修正重複執行的查詢的執行計劃。對於一些複雜的查詢，好比多字段條件，字符串範圍比較，數據SKEW等等，
以及缺少統計信息，優化器可能不可以產生一個徹底準確的基數估計, 如丟失或統計數據不許確，或複雜的謂詞的基數估計。
cardinality feedback 就是基於這一緣由而產生的。
_optimizer_use_feedback參數默認是TRUE，即開啓Cardinality Feedback，FALSE爲關閉Cardinality feedback。
因爲在11GR2中Cardinality feedback生效存在不少限制且BUG較多，故不必啓用。
8、_dbms_sql_security_level
該參數有0,1,2共3個值(默認值爲1)，0關閉dbms_sql包的安全檢查，打開光標級別爲1的要求執行/綁定和解析用戶id是相同的。
2級是更嚴格的和須要id和角色是相同的全部操做,如綁定、描述、執行、提取等。若是出現ORA-29471的錯誤以後，只有斷開當前這個session，
而後從新鏈接數據庫才能夠正常調用DBMS_SQL包。如果想封閉security check，需要將一個隱含參數_dbms_sql_security_level設置成0，
重啓數據庫生效。
9、_bloom_pruning_enabled、_bloom_filter_enabled
布隆過濾器(Bloom Filter)算法在Oracle Database 10gR2中被引入到Oracle數據庫中,
布隆過濾可以使用極低的存儲空間，存儲海量數據的映射，從而能夠提供快速的過濾機制。
11R2會遇到一個BLOOM過濾器致使的BUG 9124206和BUG 8361126，出現ORA-00060 ORA-10387錯誤，
_bloom_pruning_enabled、_bloom_filter_enabled均設爲FALSE避免BUG
詳細錯誤以下：
ORA-00060: deadlock detected while waiting for resource
ORA-10387: parallel query server interrupt (normal)
10、_gc_policy_time
參數默認值是10，0是關閉DRM特性,DRM在11G中不穩定，存在衆多BUG
11、_gc_read_mostly_locking
參數默認是TRUE，即開啓read mostly locking，
FALSE即爲禁用read mostly的特性，read mostly locking機制，能減小讀訪問的消息傳遞和CPU消耗，
可是寫訪問就會比傳統的cache fusion locking機制消耗更多的IO。read-mostly的特性是給那些讀不少，寫不多的系統來啓用比較合適。
12、_gc_undo_affinity
參數默認是TRUE，設置爲FALSE用於關閉DRM。
十3、_smu_debug_mode
默認爲0，會有部分性能故障及BUG須要設置"_smu_debug_mode" = 134217728來避免，
另經過設置_smu_debug_mode值能夠很好的實如今undo自動管理模式下,指定事務在特定的回滾段,
在某些極限狀況下,能夠經過該操做來減小回滾段爭用。
例如：
(1)當undo自動管理分配undo時，某些狀況下有些undo段很很忙，有些則比較空閒，這個時候咱們需將事務使用的回滾段從忙的回滾段
修改爲閒的回滾段。
select segment_name,owner,tablespace_name from DBA_ROLLBACK_SEGS; <<==查詢回滾段
set transaction use rollback segment "_SYSSMU8_517538920$"; <<==執行回滾段
select XIDUSN from V$TRANSACTION; <<==查詢事務回滾段

2)在11.2.0.2及之後版本，可能會遇到BUG 9272671，現象是每隔5分鐘在alert日誌中會輸出
minact-scn: Slave 1 discarding message for out-of-order msg，該信息能夠忽略，
亦可設置"_smu_debug_mode" = 134217728來避免該信息輸出值alert日誌。

3)當一個大事務被kill後，SMON進行事務回滾時會被MMON進程堵塞
select usn, state, undoblockstotal "Total", undoblocksdone "Done", undoblockstotal-undoblocksdone "ToDo",
decode(cputime,0,'unknown',sysdate+(((undoblockstotal-undoblocksdone) / (undoblocksdone / cputime)) / 86400)) "Estimated time to complete"
from v$fast_start_transactions;
USN STATE Total Done ToDo Estimated time to complete
---------- ---------------- ---------- ---------- ---------- -----------------------------
90 RECOVERED 15669 15669 0 01-OCT-2012 05:52:35
15 RECOVERING 174954 8137 166817 17-OCT-2012 12:32:07 <<<<<<<<<<
GNTOUN35>/
USN STATE Total Done ToDo Estimated time to complete
---------- ---------------- ---------- ---------- ---------- -----------------------------
90 RECOVERED 15669 15669 0 01-OCT-2012 05:52:39
15 RECOVERING 174954 8137 166817 17-OCT-2012 12:33:33 <<<<<<<<<<<<<<<
GNTOUN35>/
USN STATE Total Done ToDo Estimated time to complete
---------- ---------------- ---------- ---------- ---------- -----------------------------
90 RECOVERED 15669 15669 0 01-OCT-2012 05:52:40
15 RECOVERING 174954 8137 166817 17-OCT-2012 12:33:54 <<<<< see no movement for this
解決方法：
設置參數
alter system set "_smu_debug_mode"=134217728;
kill MMON進程(注：kill MMOM進程不會終止實例，AWR主要的進程，kill以後一個新的MMON進程會自動使用_smu_debug_mode=134217728啓動)
kill -9
官檔：
Minact-Scn Master-Status: Grec-Scn Messages In Trace File (文檔 ID 1361567.1)
SMON Is Waiting On Latch High CPU Resource consumption MMON blocking SMON (文檔 ID 1496453.1)
十4、_undo_autotune
默認TRUE，設置FALSE即關閉undo retention自動調整。
該參數用於自動調整undo retention時間，對於自動擴展(autoextend on)的undo表空間，參數undo_retention設置成爲Oracle自動
調節undo retention的最低閥值。對於非自動擴展(autoextend off)，非guarantee的undo表空間，Oracle會根據undo表空間大小
和v$undostat的歷史信息(是否統計undo信息是由隱含參數_collect_undo_stats決定的，默認狀況爲TRUE)最大可能性保留undo信息。
十5、deferred_segment_creation
段延遲建立，默認是true，也就是新建一個表，而且沒有向其中插入數據，那麼這個表不會當即分配extent，也就是不佔數據空間，
只有當insert數據後纔會分配空間，這會致使在exp時，沒有segment的對象不會導出。設置成false即禁用段延遲建立。
十6、audit_trail
用於控制數據庫審計，默認是DB，設置成none即關閉審計。
十7、_optimizer_extended_cursor_sharing_rel、_optimizer_extended_cursor_sharing、_optimizer_adaptive_cursor_sharing
自適應遊標共享(Adaptive Cursor Sharing： ACS)
alter system set "_optimizer_extended_cursor_sharing_rel"=none;
alter system set "_optimizer_extended_cursor_sharing"=none;
alter system set "_optimizer_adaptive_cursor_sharing"=false;
即爲關閉ACS，避免衆多Bug，例如Bug 11657468，Bug 12333007等。
官檔：
Bug 11657468 - Excessive mutex waits with adaptive cursor sharing (文檔 ID 11657468.8)
Bug 12333007 - Dump on kkocscopycolstats (文檔 ID 12333007.8)
十8、event='28401 trace name context forever,level 1'
在10.2.0.5及之後版本，使用錯誤密碼登錄嘗試會致使很高的Library Cache Locks或row cache lock,
能夠設置該event來避免。