|
今日一个同事找到我说他的数据库无法使用了，希望我帮忙研究一下。 其实本人对数据库也没什么深入研究，只是没事的时候喜欢度看看网上高手的资料，遇到事情的时候习惯结合高手资料进行不断尝试以便总结经验。 言归正传一起来研究一下。 同事说他之前想备份数据库表空间文件tnits_BAK_2.ORA，备份了之后习惯性的删除了原有文件，然后想维护一下服务器，就重启数据库服务器了。结果服务器起来之后再启动数据库才想起来有数据库文件刚才被删除掉了，数据库就起不来了，这就是操作过程。 先让他启动了监听lsnrctl start，发现监听能启动起来
使用sqlplus /nolog进入数据库，然后执行startup，系统提示如下： cannot start already-running ORACLE - shut it down first 这说明在启动的时候有问题了。此时想到可以对数据库启动过程进行分步执行用于判断哪一步出现的问题。 启动数据库分为三个步骤，分别为nomount、mount、open，一般我们在直接使用startup的时候是自动执行这3步的。
当然我们也可以手工单独执行这3个步骤： 将这三句在sql窗口中执行，结果如下：
SQL> startup nomount
SQL> alter database mount;
SQL> alter database open; 这里第三个语句中的报错引起了我的重视，他提示“需要回复介质文件”，这说明我同事删除之后还原回去的tnits_BAK_2.ORA这个文件没能让数据库软件检测到。 看了一下同事提供出来的原来文件的截图和还原之后的文件截图发现文件大小并没有区别，只是文件的修改时间上有区别。 修改前
修改后
既然数据库系统没有识别出来文件并提示需要回复介质文件那么我就手工回复一下，执行recover datafile 9，提示如下：
SQL> recover datafile 9 然后再次打开数据库发现依然无法正常打开，还是提示找不到tnits_BAK_2.ORA这个数据文件。
SQL> alter database open ;
突然想到oracle在启动的时候会验证检查点SNC，如果检查点验证不通过，那么是不是有可能不识别还原的文件，从而导致上面提示的找不到某个文件呢 为了验证一下我决定tnits_BAK_2.ORA置为offline状态然后再启动试试。
SQL> alter database datafile '/DataExt/tnits_BAK_2.ORA' offline; 结果看来还是不成功，不使用文件名直接使用文件编号再次尝试更改文件状态：
SQL> alter database datafile 9 offline;
这次看来有点效果，但是依然不对，记得在网上看到过一个文章似乎数据库归档和非归档是有区别的，马上上网找了一个文档看了一下，果然是有区别的，归档数据库可以直接使用offline，非归档要使用offline drop才行。 使用如下命令进行操作：
SQL> alter database datafile '/DataExt/tnits_BAK_2.ORA' offline drop; 成功完成。
alter database datafile '/DataExt/tnits_BAK_2.ORA' offline; 也完成了。 再次执行打开数据库命令，发现可以成功打开了。
SQL> alter database open; 进入数据库进行了验证，发现各项数据还都在，应用程序也可以正常运行，至此修复完毕。
总结如下： 1、数据文件切记不要轻易删除，就算要删除也不要再操作系统层面进行删除，数据库本身可以进行文件的删除，有指定的命令。 2、在数据库启动和online的时候，Oracle一定会去online一个“一致”的表空间。此时，它会发现表空间内部SCN的不一致。根据提示，我们需要手工进行文件恢复。或者使用offline drop和offline让数据库在启动时跳过一致性监测。关于此点可以参考http://www.linuxidc.com/Linux/2014-05/101881p2.htm，以及http://blog.csdn.net/folio/article/details/8156805
3、回复的时候要确认数据库是否为归档模式，确认方式为使用dba权限登录sql窗口，然后执行ARCHIVE LOG LIST，结果提示Database log mode No Archive Mode则为非归档。或执行select name,log_mode from v$database;如果结果为QUERY NOARCHIVELOG则为非归档。 |
