10g或者11g打上scn过度增长的补丁之后，或者应用了 2012 JAN 的CPU 的情况下oracle屏蔽了一系列增进SCN的手段，用以防止SCN的异常增进。
此时使用event和隐含参数不能提升SCN值，并且_minimum_giga_scn隐含参数也已经不被oracle使用

这时候必须使用bbed修改数据文件头提升SCN值，或者我们还可以尝试使用oradebug来直接递增SCN，我想这是oracle无论如何也封锁不了的。
通过oradebug来修改SCN的原理在于直接修改实例的Global Lamport SCN，在SGA中由kcsgscn变量存储，对于一个实例来说这是唯一的源SCN，
所有其他的SCN均由这个source scn所驱动。通过用oradebug 修改该Global Lamport SCN kcsgscn，来推进SCN

下面我们来实验一下，首先模拟一个ORA-600 2662环境，模拟过程略
数据库在启动过程中后台报错：
Thu Aug 01 16:11:43 CST 2013
Errors in file /oracle/app/admin/test/udump/test_ora_26592.trc:
ORA-00600: internal error code, arguments: [2662], [0], [1073748930], [0], [1073945531], [4194364], [], []
Thu Aug 01 16:11:43 CST 2013
SMON: enabling cache recovery
Thu Aug 01 16:11:47 CST 2013
Errors in file /oracle/app/admin/test/udump/test_ora_26592.trc:
ORA-00600: internal error code, arguments: [2662], [0], [1073748930], [0], [1073945531], [4194364], [], []
实例异常终止

如果此时，在无法用event或者隐含参数来提升SCN的情况下，BBED是提升SCN的一个方法，但是oradebug也不失为一种好方法
首先我们通过ORA-600的报错，来确定需要提升的SCN的值：
1）计算level
1.1) Arg {c}* 4得出一个数值，假设为V_Wrap
1.2) 如果Arg [d]=0，则V_Wrap值为需要的level
Arg [d] < 1073741824，V_Wrap+1为需要的level
Arg [d] < 2147483648，V_Wrap+2为需要的level
Arg [d] < 3221225472，V_Wrap+3为需要的level
获得level的值为2
SCN被增进了1024*1024*1024*level（level*10 billion）=2147483648

首先我们mount数据库：
SQL> startup mount
ORACLE instance started.

Total System Global Area 1610612736 bytes
Fixed Size                  2096632 bytes
Variable Size             385876488 bytes
Database Buffers         1207959552 bytes
Redo Buffers               14680064 bytes
Database mounted.

SQL> oradebug setmypid
Statement processed.
SQL> oradebug DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [060012658, 060012688) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 60012338 00000000

ORADEBUG POKE 0×060012658 4 0xfffff
poke 命令的语法

” allows you to modify a given region of memory (length of memory is limited to size of scalar C types)
而2147483648转化成16进制即为：80000000
SQL> oradebug poke 0×060012658 4 0×80000000
BEFORE: [060012658, 06001265C) = 00000000
AFTER: [060012658, 06001265C) = 80000000

此时再dump一下SCN查看：
SQL> oradebug DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [060012658, 060012688) = 80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 60012338 00000000

尝试启动数据库：
SQL> alter database open;

Database altered.

数据库正常打开

检查当前的SCN;
SQL> select current_scn from v$database;

CURRENT_SCN
———–
2147483769

可以看到已经被提升到2147483769

附录：
不同版本oradebug SCN的方法：
8.1.7
ORADEBUG DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [13A4EA8, 13A4EC8) = 00000000 00053B25 00000000 00000000 …
前6位中记录了记录了系统当前的scn
9.2.0
ORADEBUG DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [1FECFE0, 1FED000) = 00000000 000B9463 000004A7 00000000 00000000 00000000 00000000 01FECCC0

oracle 从9i开始提供了dbms_flashback来获得当前的scn
select dbms_flashback.get_system_change_number from dual;

10.1.0
ORADEBUG DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [2E2AF70, 2E2AF90) = 00000000 000AD811 000007C5 00000000 00000000 00000000 00000000 02E2AB60

select dbms_flashback.get_system_change_number from dual;

oracle之 oradebug 递增SCN