在数据库遇到ora-600[2662],scn不一致(又没有日志）的时候，我们首先想到的就是去推进数据库的scn,让数据库能够open起来,抢救其中的数据,但是由于各种乱用的情况,oracle scn的pach出来后(11.2.0.4,12.0.1.0默认就屏蔽)，屏蔽了以前大部分传统的推进scn的方法(adjust_scn, _minimum_giga_scn),现在能够推进scn的有oradebug,bbed,修改控制文件.本文就列举通过ue修改控制文件scn来推进数据库scn的方法.
数据库当前scn
idle> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
271743118
idle> shutdown abort
ORACLE 例程已经关闭。
分析控制文件中scn
这里我们可以看到加粗部分为数据库scn
SQL>select to_number('10327a59','xxxxxxxxx') from dual;
TO_NUMBER('10327A59','XXXXXXXXX')
---------------------------------
271743577
这里的scn值和在数据库中查询的值有小差别,因为查询时间点和我完全关闭数据库有个时间差,而这个时间差有scn变化.细红框部分为控制文件对块的验证信息
修改控制文件scn和验证信息
验证信息修改为全部0,scn信息你可以根据你的需求去修改,这里把数据库的scn修改为57253932971026,按照数据库的原理,启动后的scn应该稍微大于该scn值.
SQL>select to_number('341278563412','xxxxxxxxxxxxxxxxx') from dual;
TO_NUMBER('341278563412','XXXXXXXXXXXXXXXXX')
---------------------------------------------
57253932971026
启动数据库
idle> startup mount
ORACLE 例程已经启动。
Total System Global Area 400846848 bytes
Fixed Size 2440024 bytes
Variable Size 289408168 bytes
Database Buffers 100663296 bytes
Redo Buffers 8335360 bytes
数据库装载完毕。
idle> recover database;
完成介质恢复。
idle> alter database open;
数据库已更改。
idle> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
57253932991028
数据库启动后查询scn为57253932991028(数据库当前scn)果然微大于57253932971026(修改控制文件scn),证明我们通过修改控制文件scn,实现数据库scn推近完全OK.不实验风险较大,请勿在生产环境上测试,负载后果自负
重庆思庄18年5月OCP认证培训周末班正在授课，欢迎联系试听！新的OCP周末班将于6月2日开课，火热报名中，名额有限，请提前预定！更多详情访问思庄网站咨询在线客服。
来源：oschina
链接：https://my.oschina.net/u/3761438/blog/1809075