1 查询隐含参数

SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ

FROM SYS.x$ksppi x, SYS.x$ksppcv y

WHERE x.inst_id = USERENV ('Instance')

AND y.inst_id = USERENV ('Instance')

AND x.indx = y.indx

AND x.ksppinm LIKE '%&par%'

2 _datafile_write_errors_crash_instance

11.2.0.2新增，默认为true，如果出现写错误，直接实例宕掉，以前为offline;

3 _use_adaptive_log_file_sync

11.2.0.1和11.2.0.2两个版本该参数默认是false。

从11.2.0.3开始，这个参数默认值是true，也就是开始启用“自适应日志同步机制”。

开启改参数后，日志同步机制会在2种方式中切换。

该参数决定了，foreground/user session 和LGWR进程通过什么方式获知commit操作已完成（也就是redo写log file完成）。

Post/wait, traditional method for posting completion of writes to redo log

传统方式，在11.2.0.3之前，user session等待LGWR通知redo写入到log file完毕，被动方式。

优点：post/wait方式，user session几乎能立即发现redo已刷到磁盘。

Polling, a new method where the foreground process checks if the LGWR has completed the write.

新方式，主动监测LGWR是否完成写入，主动方式。这种方式比Post/wait方式响应速度慢，但是可以节约CPU资源。

优点：当commit完成后，LGWR会把commit完成的消息通知给很多user session，这个过程消耗大量CPU。

 Polling方式采用朱勇监测LGWR释放写入redo完成，所以释放了LGWR占用的CPU资源。

4 _external_scn_rejection_threshold_hours

11.2.0.2及以上版本的这个参数默认值是24，其他版本默认值是744。这样使11.2.0.2以下版本的数据库其Headroom的阈值增得较大。

5 _minimum_giga_scn

11.2.0.2打上相关补丁后无效了；另alter session set events ’10015 trace name adjust_scn level XXX’也推不动SCN了，查看SCN

推荐推进SCN的方法1：

1、当数据块为8k的时候，控制文件大小为16k

2、找到Controlfile Checkpointed at scn，偏移量为第一个块的60，比如0×4060，然后具体位置在0×4060的第9至第14个byte

3、找到第一个块的第一行，如0×4000，将offset为15的flag由0×04改为0×00，并同时将checksum值（offset为16、17）全部清零。

推荐推进SCN的方法2：

“oradebug poke

SQL> col current_scn for 99999999999;
SQL> select current_scn from v$database; 
 CURRENT_SCN
------------
 12414232664
SQL> select to_char(CHECKPOINT_CHANGE#,'XXXXXXXXXXXX') from v$database; 
TO_CHAR(CHECK
-------------
    2E3F154CE
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [5000C974, 5000C994) = 00000002 E3F243A0 05AC1DA5 00000000 00000000 00000000 00000000 5000C58C
SQL>oradebug poke 0x5000C974 4 0X300000000
SQL>select to_number('300000000','XXXXXXXXXXXXXX')  current_scn from dual;