经过修改控制文件scn推动数据库scn

时间 2019-11-17

标签经过修改控制文件 scn 推动数据库栏目 SQL 繁體版

原文原文链接

在数据库遇到ora-600[2662],scn不一致(又没有日志）的时候，咱们首先想到的就是去推动数据库的scn,让数据库可以open起来,抢救其中的数据,可是因为各类乱用的状况,oraclescn的pach出来后(11.2.0.4,12.0.1.0默认就屏蔽)，屏蔽了之前大部分传统的推动scn的方法(adjust_scn, _minimum_giga_scn),如今可以推动scn的有oradebug,bbed,修改控制文件.本文就列举经过ue修改控制文件scn来推动数据库scn的方法.数据库

数据库当前scnoracle

idle> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# 271743118 idle> shutdown abort ORACLE 例程已经关闭。测试

分析控制文件中scndebug

这里咱们能够看到加粗部分为数据库scn日志

SQL>select to_number('10327a59','xxxxxxxxx') from dual; TO_NUMBER('10327A59','XXXXXXXXX') 271743577blog

这里的scn值和在数据库中查询的值有小差异,由于查询时间点和我彻底关闭数据库有个时间差,而这个时间差有scn变化.细红框部分为控制文件对块的验证信息get

修改控制文件scn和验证信息原理

验证信息修改成所有0,scn信息你能够根据你的需求去修改,这里把数据库的scn修改成57253932971026,按照数据库的原理,启动后的scn应该稍微大于该scn值.select

SQL>select to_number('341278563412','xxxxxxxxxxxxxxxxx') from dual; TO_NUMBER('341278563412','XXXXXXXXXXXXXXXXX') 57253932971026bug

启动数据库

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.不实验风险较大,请勿在生产环境上测试,负载后果自负