项目场景：

用户的一台测试机，因发生过断电情况，在通电恢复后通过plsql连接数据库时提示ORA-01033的问题，无法正常使用数据库

问题描述以及解决方案

接到问题反馈后，通过IP地址:端口号/SID方式登录测试，确实无法登录数据库，后台的服务、监听都在，遂先查看数据库的当前状态：

mouned的情况，我重启了下库还抱有一丝侥幸，结果提示ORA-00600，通过后台alert可以定位到相应trc文件，也能定位到问题，由于有些了解我就直接进行尝试恢复了：

像这样情况断电后产生的问题有是由当时的redo日志文件引发的，尝试恢复下看看情况:

再以上截图中，有个信息特别重要：就是ORA-00280中 change xxxxxx 和 sequence #815,这类型的故障,一般是由于缺少日志(比如数据库非归档模式,或者归档日志丢失),导致某些文件无法正常online。明白提示的问题后我们就要确定下是哪个日志导致的无法将数据文件system01.dbf进行正常online读取的。需要用到以下命令进行查询：

#在mount状态下，使用sysdba用户连接：
select v1.group#, member, sequence#, first_change#
  2   from v$log v1, v$logfile v2
  3   where v1.group# = v2.group#;

那么本次案例中#815对应的是我的redo02.log（图片没有截取全），接下来就需要进行不完全恢复了。

recover database的原理是数据库使用控制文件的scn作为恢复的终点，将数据文件block恢复到控制文件所记录的scn为止。
而使用recover database using backup controlfile;实际上是告诉数据库，我要联机日志的最大scn为终点，对数据文件在block级别进行恢复。recover database using backup controlfile until cancel,既可以完全恢复，也可以指定归档日志、联机日志不完全恢复。

在执行到红框部分输入我们所查询到日志的路径和名称回车，告诉日志的最大scn终点。
完成以上操作后，我们就可以进行open数据库，但是这里要注意的是我们在不完全恢复后，日志序列号中断，重新open数据库的话就需要重置日志序列。

到这里此次的故障就算排除掉了，但需要注意的是下次再发类似情况的话，处理起来就比较棘手了呦。