某日，生产数据库服务器异常宕机，在重启服务器开启数据库时报如下错误：

SQL> startup                                                         
ORACLE instance started.                                  
Total System Global Area 1.6911E+10 bytes                           
Fixed Size                   2113696 bytes                          
Variable Size             8472498016 bytes                          
Database Buffers          8422162432 bytes                          
Redo Buffers                14659584 bytes                          
Database mounted.                                                    
ORA-01113: file 1 needs media recovery                              
ORA-01110: data file 1: '/oracle/PRD/data1/system_1/system.data1'


有一种解决方法是这样的
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; 

     DBMS_FLASHBACK.GET_SYSTEM_CHAN
           ——————————
              3.185796233
估值为3.18NG,推进的SCN值要比这个值大，所以设置值为4
$vi  /oracle/PRD/data1/init.ora 增加此句
*._minimum_giga_scn=4
再然后尝试打开库
SQL> startup mount pfile='/oracle/PRD/data1/init.ora';
ORACLE instance started.
SQL> recover database until cancel;
SQL> alter database open resetlogs;
Database altered.
数据库成功打开。
去掉隐含参数，恢复初始参数。
最后
SQL> create spfile from pfile='/oracle/PRD/data1/init.ora';
 
File created.
 
SQL> startup
ORACLE instance started.
然后及时用EXP全库导出以保护数据,做DBV的数据校验看是否有物理坏块.
 
以上方法仅限特殊情况下的应用，请慎重参考。
 
附SCN知识点:
1、Oracle的SCN在每秒16384次commit的情况下可以维持534年，每秒16384次commit是Oracle早先认为的任何系统的极限commit强度；
2、Oracle里SCN的起点是1988年1月1日；
3、_minimum_giga_scn=n的含义是把SCN往前推进到nG，但请注意，只有在SCN小于nG的时候才会用到这个隐含参数，反之则Oracle会置这个隐含参数于不顾。
 

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。