ORA-01157与ORA-00376的处理过程

测试机的数据库被无故重启，当时这个数据库放在盘阵上的三个数据文件被切换到HA的另一个节点。应用人员发现数据库无监听，向DBA报告了问题。DBA检查时，发现该数据库的监听和实例都已经停掉了。于是重启了监听和实例。但是重启实例的时候报错：
idle> startup
ORACLE instance started.

Total System Global Area 3674210304 bytes
Fixed Size                  2044904 bytes
Variable Size            1962937368 bytes
Database Buffers         1694498816 bytes
Redo Buffers               14729216 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/test/app2/oracle/oradata/users02.dbf'

当时在网上找了一个解决办法：对这部分有问题的数据文件进行OFFLINE DROP；
1. 数据库如果是归档模式：
   SQL> alter database datafile '/test/app2/oracle/oradata/users02.dbf' offline;
2. 数据库如果是非归档模式：
   SQL> alter database datafile '/test/app2/oracle/oradata/users02.dbf' offline drop;
3. 然后再启动数据库
   SQL> alter database open;

于是，先检查了归档模式
idle> archive log list;
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     213
Current log sequence           215

然后执行了相关命令。
idle> alter database datafile '/test/app2/oracle/oradata/users02.dbf' offline drop;

Database altered.

idle> alter database open;
alter database open
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/test/app2/oracle/oradata/users03.dbf'

报错，另外一个数据文件也有问题，继续执行offline drop;

idle> alter database datafile '/test/app2/oracle/oradata/users03.dbf' offline drop;

Database altered.

idle> alter database open;
alter database open
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 7 - see DBWR trace file
ORA-01110: data file 7: '/test/app2/oracle/oradata/indx01.dbf'

idle> alter database datafile '/test/app2/oracle/oradata/indx01.dbf' offline drop;

Database altered.

idle> alter database open;

Database altered.

idle> select * from dual;

D
-
X

最后，一共有三个数据文件有问题，使用OFFLINE DROP以后，解决了问题，数据库已经成功起来。

然后业务人员对一些表执行SELECT操作的时候，又出现了错误。

ORA-00376: file 5 cannot be read at this time
ORA-01110: data file 5: '/test/app2/oracle/oradata/users02.dbf'

这时候，才想起这台服务器是与另外一台测试机做HA的，盘阵已经被切到另外一台机器，于是把那边的三个数据文件切换回来。

重启数据库，但是还是有错。

于是检查了这三个数据文件的状态
SQL> select name,status from v$datafile;
/test/app2/oracle/oradata/users02.dbf                                                RECOVER
/test/app2/oracle/oradata/users03.dbf                                                RECOVER
/test/app2/oracle/oradata/indx01.dbf                                                RECOVER

发现他们的状态都是RECOVER，但是这个数据库无备份，无归档。但是REDO文件保存尚好。

于是停止数据库，将数据库启动到mount,对该部分数据文件做ONLINE。
idle> startup mount;

idle> alter database datafile '/test/app2/oracle/oradata/users02.dbf' online;          
idle> alter database datafile '/test/app2/oracle/oradata/users03.dbf' online;
idle> alter database datafile '/test/app2/oracle/oradata/indx01.dbf' online;
然后再recover数据库
idle> recover

Media recovery complete.

然后再检查数据文件状态时，发现他们已经ONLINE了。
sql> select name,status from v$datafile;

/test/app2/oracle/oradata/users02.dbf                                                ONLINE
/test/app2/oracle/oradata/users03.dbf                                                ONLINE
/test/app2/oracle/oradata/indx01.dbf                                                 ONLINE

然后再打开数据库
idle> alter database open;

Database altered.

然后再检查受影响的表，发现问题已经解决了。并且数据也没有丢失。

原因分析：由于使用offline drop后，数据库并没有做其他多余的操作，REDO日志还保留完好。虽然没有备份和归档，但是可以使用RECOVER从REDO中进行恢复。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10356975/viewspace-680352/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10356975/viewspace-680352/