某日,生产数据库服务器异常宕机,在重启服务器开启数据库时报如下错误:
有一种解决方法是这样的
SQL> RECOVER DATAFILE '/oracle/PRD/data1/system_1/system.data1'
恢复受损的文件.
SQL> recover tablespace system;//不一定需要,提示不要求恢复的时候,可以直接打开数据库。
恢复系统表空间.
SQL> RECOVER DATABASE;
恢复数据库.
SQL> ALTER DATABASE OPEN;
Database altered.
做这类操作时,不一定能成功。所以请一定先备份当前状态下所有数据文件、控制文件和日志文件,先做到保护现场,然后再做其他尝试。
经过冷备后,尝试这种方法不行。咨询Dbsnake后,尝试异常恢复强行打开数据库。
#su - oracle
$vi /oracle/PRD/data1/init.ora 修改初始化参数
*._allow_resetlogs_corruption=FALSE
修改为*._allow_resetlogs_corruption=TRUE(#正常启库后修改为原值FALSE)
(这个参数允许在数据不一致的情况下打开)
*.undo_management='AUTO'
修改为*.undo_management='MANUAL'(#正常启库后修改为原值AUTO)
(这个参数是让UNDO表空间由自动管理变手动管理)
增加此句
*._corrupted_rollback_segments=(_SYSSMU12$)(#正常启库后去掉此句)
(屏蔽出错的事务回滚段,根据ALERT提示ORA-01555: snapshot too old: rollback segment number 12 with name "_SYSSMU12$" too small)
然后保存参数文件,重新打开库,发现还是不行。检查ALERT日志发现SCN号不一致, 下一步推进SCN值。
查看估算SCN值
SQL> select dbms_flashback.get_system_change_number()/(1024*1024*1024) from dual;
*._minimum_giga_scn=4
SQL> startup mount pfile='/oracle/PRD/data1/init.ora';
ORACLE instance started.
Database altered.
数据库成功打开。
最后
SCN原理:在安全关闭数据库的过程中,系统会执行一个检查点动作,这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值。在数据库重新启动的时候,Oracle将文件头中的那个启动scn与数据库文件检查点scn进行比较,如果这两个值相互匹配,oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn。如果这两个值也一致,就意味着所有数据块多已经提交,所有数据库的修改都没有在关闭数据库的过程中丢失,因此这次启动数据库的过程也不需要任何恢复操作,此时数据库就可以打开了。当所有的数据库都打开之后,存储在控制文件中的数据文件终止scn的值再次被更改为null,这表示数据文件已经打开并能够正常使用了。
但在异常当机的情况下,由于最后一次检查点未进行或进行中间被中止,因而在控制文件,就存在部分的数据文件stop SCN为最大值,在数据库重新启动后,会检查控制文件中对应每个数据文件的stop SCN,如果stop SCN不等于控制文件中对应每个数据文件的checkpoint SCN,就会使用日志文件redo从checkpoint SCN开头到stop SCN为止的全部数据库操作.当数据库发现SCN不一致,应该是redo log文件中的SCN>=数据文件中的SCN.在定位到底是使用哪一个redo log文件时,就用到了日志文件头中的low scn,next scn,也就是说要使用的redo log 的low scn ,next scn必须包含数据文件重做所须的change vector. 在确定了哪个数据文件须redo,oracle会比较change vector中的SCN和数据文件数据块中的SCN,如果change vector的SCN小于数据块的scn,则跳过此change vector,否则redo。