问题描述
接到项目组电话，说一台测试数据库起不来了，发现是redolog丢失了，因为是测试环境所以没有开启归档模式也没有备份。
解决过程
一、打算直接通过resetlogs方式启动数据库，发现resetlog报错 ORA-01194: file 1 needs more recovery to be consistent
SQL> alter database open resetlogs
*
ERROR at line 1
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1 ：'/u01/datafile/misdb/system01.dbf'
复制二、修改隐藏参数，跳过不一致性检查，以及推进scn，以及忽略undo异常不一致的，
#生成pfile参数文件
create pfile from spile;
#打开pfile默认在$ORACLE_HOME/dbs目录下：init_${SID}.ora,加入一下内容
_allow_resetlogs_corruption = true
#推进scn，是scn激增，12.2可以使用event 21307096 来实现scn激增，level1为增加100万，level 3增加300万
event="21307096 trace name context forever, level 3"
#数据库启动的时候设置10513 event，可以避免数据库异常关闭时的异常事物的回滚，但是当需要查到异常关闭的数据块时，还是会通过块上的uba信息去找块被修改前的前镜像，但是找到之后并不会修改表的数据块，每次访问都会访问undo信息。取消10513 event之后，再次查询数据块时就会把数据块的内容改成被修改之前的数据。 还有一点，如果真正是undo块有问题，10513 event是不会解决的
event="10513 trace name context forever, level 2"
复制注:这里两个event解决的报错是不一样的:：
trace 21307096解决的是推进scn ：
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], [],[], [], [], [], [], [], []
或
ORA-01194: file 1 needs more recovery to be consistent
trace 10513解决的是undo回滚段与redo不一致，需要重建undo：
ORA-00600: internal error code, arguments: [4194], [7], [6], [], [], [], [], [], [], [], [], []
重建undo
同样在pfile中修改undo的模式为手动
undo_management=manual
#注释掉undo_tablesace
复制启动数据库，重新创建undo表空间
create undo tablespace undotbs2 datafile '/u01/datafile/misdb/undotbs2.dbf' size 100m;
alter system set undo_tablespace=undotbs2 scope=spfile;#或者在pfile中修改
alter system set undo_management=auto;#或者在pfile中修改
复制删除掉原来的undo
drop tablespace UNDOTBS1 including contents and datafiles;
复制可能会报错
ORA-01548: active rollback segment ‘_SYSSMU6_3592786768$’ found, terminate dropping tablespace,查询出状态不正常的undo段，通过配置隐藏参数忽略这些undo段
select segment_name, status, tablespace_name from dba_rollback_segs where status not in ('ONLINE', 'OFFLINE');
复制把查询出来segment_name值添加到隐藏参数中，修改/oracle/pfile.ora，添加
*._offline_rollback_segments=(_SYSSMU6_3592786768$,_SYSSMU7_3592786769$)复制
总结
通过这几个方式就可以对数据库进行操作了，剩下的就是把这些隐藏参数复原注释掉就可以了。
