oracle 11g常用隱含參數

ORACLE 11GR2常用參數(含隱含參數)設置如下：
alter system set "_PX_use_large_pool" = true scope=spfile;
alter system set "_clusterwide_global_transactions" = false scope=spfile;
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;
alter system set "_gc_policy_time" = 0 scope=spfile;
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;
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;
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;


參數釋義：
一、_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)


二、_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規范的基礎是兩階段提交協議：
在第一階段，交易中間件請求所有相關數據庫準備提交(預提交)各自的事務分支，以確認是否所有相關數據庫都可以提交各自的事務分支。
當某一數據庫收到預提交后，如果可以提交屬于自己的事務分支，則將自己在該事務分支中所做的操作固定記錄下來，并給交易中間件一個同意提交的應答，
此時數據庫將不能再在該事務分支中加入任何操作，但此時數據庫并沒有真正提交該事務，數據庫對共享資源的操作還未釋放(處于鎖定狀態)。
如果由于某種原因數據庫無法提交屬于自己的事務分支，它將回滾自己的所有操作，釋放對共享資源上的鎖，并返回給交易中間件失敗應答。


在第二階段，交易中間件審查所有數據庫返回的預提交結果，如所有數據庫都可以提交，交易中間件將要求所有數據庫做正式提交，這樣該全局事務被提交。
而如果有任一數據庫預提交返回失敗，交易中間件將要求所有其它數據庫回滾其操作，這樣該全局事務被回滾。
****************************************************


三、_gc_defer_time
how long to defer pings for hot buffers in milliseconds
用于確定服務器在將頻繁使用的塊寫入磁盤之前要等待的時間長度 (以 1/1000 秒為單位)，以減少進程對熱塊的爭用，默認為0。


四、_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)


五、_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


六、_cleanup_rollback_entries
該參數指定回滾時每次回滾的ENTRIES個數，默認為100，設置成400加快回滾速度。


七、_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較多，故沒必要啟用。


八、_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，
重啟數據庫生效。


九、_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)






十、_gc_policy_time
參數默認值是10，0是關閉DRM特性,DRM在11G中不穩定，存在眾多BUG


十一、_gc_read_mostly_locking
參數默認是TRUE，即開啟read mostly locking，
FALSE即為禁用read mostly的特性，read mostly locking機制，能減少讀訪問的消息傳遞和CPU消耗，
但是寫訪問就會比傳統的cache fusion locking機制消耗更多的IO。read-mostly的特性是給那些讀很多，
寫很少的系統來啟用比較合適。


十二、_gc_undo_affinity
參數默認是TRUE，設置為FALSE用于關閉DRM。


十三、_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 <pid of mmon>


官檔：
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)


十四、_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信息。


十五、deferred_segment_creation
段延遲創建，默認是true，也就是新建一個表，并且沒有向其中插入數據，那么這個表不會立即分配extent，也就是不占數據空間，
只有當insert數據后才會分配空間，這會導致在exp時，沒有segment的對象不會導出。設置成false即禁用段延遲創建。


十六、Audit_trail
用于控制數據庫審計，默認是DB，設置成none即關閉審計。


十七、_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)




十八、event='28401 trace name context forever,level 1'
在10.2.0.5及以后版本，使用錯誤密碼登陸嘗試會導致很高的Library Cache Locks或row cache lock,
可以設置該event來避免。