一次意外导致的ORA-600[3004]错误的解决过程

今天在对测试库修改完毕后，打算恢复到测试库修改之前的状态，随手就将操作之前的全库冷备份拷贝了回去。

然后以SYSDBA登陆，打开数据库，却发现了错误：

$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on 星期五 9月 29 15:09:10 2006

已连接到空闲例程。

SQL> startup
ORACLE 例程已经启动。

Total System Global Area 1042254360 bytes
Fixed Size 743960 bytes
Variable Size 503316480 bytes
Database Buffers 536870912 bytes
Redo Buffers 1323008 bytes数据库装载完毕。
ORA-00600: 内部错误代码，参数: [3004], [1], [0], [0], [], [], [], []

开始的时候我吓了一跳，怎么用备份恢复的数据库仍然有问题呢。仔细一想才发现，刚才忙中出错，在拷贝数据文件的时候没有首先将正在运行的数据库关闭。

看来是某些数据文件或控制文件在被拷贝到目的地后，被当时仍然启动着的INSTANCE做了修改。

由于有备份，问题很容易解决，只要将数据库关闭，并重新拷贝冷备份，就可以了。

但是难得出现这种没有任何后果的测试机会，于是想尝试一下，能否在不用备份的情况下进行恢复。

查询metalink，发现没有已经发布的错误说明。

从metalink上的一些说明看，似乎是控制文件出错的可能性大一些，于是尝试重建控制文件：

SQL> alter database open;
alter database open
*
ERROR 位于第 1 行:
ORA-00600: 内部错误代码，参数: [3004], [1], [0], [0], [], [], [], []

SQL> alter database backup controlfile to trace;

数据库已更改。

SQL> shutdown
ORA-01109: 数据库未打开

已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup nomount
ORACLE 例程已经启动。

Total System Global Area 1042254360 bytes
Fixed Size 743960 bytes

www.ixdba.net

Variable Size 503316480 bytes
Database Buffers 536870912 bytes
Redo Buffers 1323008 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "TESTMV" NORESETLOGS NOARCHIVELOG
2 -- SET STANDBY TO MAXIMIZE PERFORMANCE
3 MAXLOGFILES 5
4 MAXLOGMEMBERS 3
5 MAXDATAFILES 100
6 MAXINSTANCES 1
7 MAXLOGHISTORY 454
8 LOGFILE
9 GROUP 1 '/u1/oracle/oradata/testmv/redo01.log' SIZE 100M,
10 GROUP 2 '/u1/oracle/oradata/testmv/redo02.log' SIZE 100M,
11 GROUP 3 '/u1/oracle/oradata/testmv/redo03.log' SIZE 100M
12 -- STANDBY LOGFILE
13 DATAFILE
14 '/u1/oracle/oradata/testmv/system01.dbf',
15 '/u1/oracle/oradata/testmv/undotbs01.dbf',
16 '/u1/oracle/oradata/testmv/cwmlite01.dbf',
17 '/u1/oracle/oradata/testmv/drsys01.dbf',
18 '/u1/oracle/oradata/testmv/example01.dbf',
19 '/u1/oracle/oradata/testmv/indx01.dbf',
20 '/u1/oracle/oradata/testmv/odm01.dbf',
21 '/u1/oracle/oradata/testmv/tools01.dbf',
22 '/u1/oracle/oradata/testmv/users01.dbf',
23 '/u1/oracle/oradata/testmv/xdb01.dbf'
24 CHARACTER SET ZHS16GBK
25 ;

控制文件已创建

SQL> RECOVER DATABASE完成介质恢复。
SQL> ALTER DATABASE OPEN;

数据库已更改。

居然问题解决了，不过这个测试并不能说明什么问题，如果真的在正式环境中碰到这个问题，在尝试本文介绍的方法之前，应该先备份目前的数据库，保持现场。而且，即使使用了这个办法恢复，也不保证数据库以后不会出现其他的问题。

最稳妥的方法是在数据库打开后，全库导入，创建新库，然后全库导入。

写这篇文章的主要目的是提醒自己，在操作之前一定要先想好，任何盲目的操作都可能造成严重的后果。如果当时不是cp而是mv的话，或者操作发生在产品库上的话，恐怕在随后研究这个错误时，心情就不会这么轻松了。