检索两个SCN号：1490874094对应的时间是2016/9/21 9:49，而1490736502对应的时间是2016/9/20 9:00。显然是文件在关闭shutdown immediate之后，由于一些原因被替换为24小时之前的文件。
和朋友确认，的确是有可能备份厂商为了能够启动数据库，似乎使用过头一天的镜像来部分还原数据文件，而且是整个F盘。
了解了原有，就起码有一个基本出发点。下面就是如何进行数据处理，具体来说有三种方法可以考虑：
ü 如果需要紧急的启动数据库，在非归档模式下，可以将F盘对应的表空间和数据文件offline drop剔除数据库。但是这样，就永远不能将文件数据追回了；
ü 对应F盘上的数据都是数据表空间文件，而不是系统表空间，而且在一天中乜有对应的更新，所以可以通过bbed类型手工修改文件头SCN编号，让所有文件SCN号统一。这样就可以避免open过程错误，但是需要人为修改若干个文件头，技术风险存在；
ü 第三种是让Oracle启动open过程放弃验证SCN一致性，强行打开系统。这样的问题是，后续也可能出现其他报错问题。
经过讨论，决定使用第三种方法进行操作。
3、操作处理
Oracle放弃一致性检查的参数是_ALLOW_RESETLOGS_CORRUPTION，将其添加在pfile中，使用这个pfile启动数据库。
注意：放弃验证之后，依然会有open resetlog方式启动数据库，刷新全体SCN对象的情况。之后，open状态依然存在问题。
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 6 with name
"_SYSSMU6_1439239625$" too small
进程 ID: 2596
会话 ID: 96 序列号: 1
在alert log中，报错如下：
Thu Oct 06 10:04:19 2016
SMON: enabling cache recovery
ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0000.58dbbfec):
select ctime, mtime, stime from obj$ where obj# = :1
Errors in file d:\app\administrator\diag\rdbms\DGT\DGT\trace\DGT_ora_7856.trc:
ORA-00704: 引导程序进程失败
ORA-00704: 引导程序进程失败
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01555: 快照过旧: 回退段号 6 (名称为 "_SYSSMU6_1439239625$") 过小
Errors in file d:\app\administrator\diag\rdbms\DGT\DGT\trace\DGT_ora_7856.trc:
ORA-00704: 引导程序进程失败
ORA-00704: 引导程序进程失败
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01555: 快照过旧: 回退段号 6 (名称为 "_SYSSMU6_1439239625$") 过小
Error 704 happened during db open, shutting down database
USER (ospid: 7856): terminating the instance due to error 704
Instance terminated by USER, pid = 7856
ORA-1092 signalled during: alter database open...
opiodr aborting process unknown ospid (7856) as a result of ORA-1092
Thu Oct 06 10:04:21 2016
ORA-1092 : opitsk aborting process
Oracle启动open阶段要进行两个recovery，分别为Media Recovery和Cache Recovery。Media Recovery主要是基于online redo log进行日志的前滚操作，Cache Recovery则是依赖从bootstrap$等系列数据字典对象创建重构，将数据库启动的操作过程。
当前报错主要是在执行SQL：4krwuz0ctqxdt的时候，要求SCN为0x0000.58dbbfec的数据镜像。这个SCN时间对应为：1490796524，而检索时候希望使用MVCC特性，就出现了undo段不支持的情况了。
那么，这个时间点是什么？
SQL> select a.name,a.checkpoint_change# start_SCN,
2 b.checkpoint_change# last_SCN
3 from v$datafile_header a, v$datafile b
4 where a.file#=b.file#;
NAME START_SCN LAST_SCN
-------------------------------------------------------------------------------- ---------- ----------
D:\APP\ADMINISTRATOR\ORADATA\DGT\SYSTEM01.DBF 1490776516 1490776516
D:\APP\ADMINISTRATOR\ORADATA\DGT\SYSAUX01.DBF 1490776516 1490776516
SQL> select resetlogs_change#, CHECKPOINT_CHANGE# from v$database;
RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
----------------- ------------------
1490736503 1490776516
由于原来的SCN比较高，现在检索一个过去的SCN时间点是不存在的。解决的方法是强制的推动SCN到一个适当地时间点。
SQL> conn / as sysdba
已连接。
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
MOUNTED
SQL> alter session set events '10015 trace name adjust_scn level 10';
会话已更改。
SQL> select CHECKPOINT_CHANGE# from v$database;
CHECKPOINT_CHANGE#
------------------
1490796521
SQL>
SQL> alter session set events '10015 trace name adjust_scn level 10';
会话已更改。
SQL> select CHECKPOINT_CHANGE# from v$database;
CHECKPOINT_CHANGE#
------------------
1490796521
SQL> alter session set events '10015 trace name adjust_scn level 10';
会话已更改。
SQL> select CHECKPOINT_CHANGE# from v$database;
CHECKPOINT_CHANGE#
------------------
1490796521
SQL> alter database open;
数据库已更改。
SQL> select CHECKPOINT_CHANGE# from v$database;
CHECKPOINT_CHANGE#
------------------
1490816526