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来避免。