ORA-600 [18062]

在以前的一篇文章中，我提到千万不能将Oracle数据库的global_name更新为空。这不，事儿来了。我的一个同事，提到了一个解决办法，不过那个办法实际上是一种不完全恢复的办法，如果没有备份，就行不通。如果没有备份，可以使用BBED来修改块来解决这个问题，不过使用bbed仍然比较麻烦。

下面是我一时心血来潮进行的一次测试。测试环境，10.2.0.4 for Linux AS 5.5。注意，不要在生产库上模仿。

首先UPDATE GLOBAL_NAME为空，COMMIT后以abort方式关闭数据库，以abort方式只是为了增加点难度。之后再启动数据库。

SQL> update global_name set global_name='';  
  
1 row updated.  
  
SQL> commit;  
  
Commit complete.  
  
SQL> shutdown abort  
ORACLE instance shut down.  
SQL> startup  
ORACLE instance started.  
  
Total System Global Area  209715200 bytes  
Fixed Size                  1266632 bytes  
Variable Size              75500600 bytes  
Database Buffers          130023424 bytes  
Redo Buffers                2924544 bytes  
Database mounted.  
ORA-01092: ORACLE instance terminated. Disconnection forced

启动失败，不出意料出现ORA-600 [18062]错误：

Mon Sep  6 15:43:31 2010  
Errors in file /oracle/app/oracle/admin/xty/udump/xty_ora_3149.trc:  
ORA-00600: internal error code, arguments: [18062], [], [], [], [], [], [], []  
QMNC started with pid=16, OS id=3151  
Mon Sep  6 15:43:33 2010  
Errors in file /oracle/app/oracle/admin/xty/udump/xty_ora_3149.trc:  
ORA-00600: internal error code, arguments: [18062], [], [], [], [], [], [], []  
Mon Sep  6 15:43:33 2010  
Errors in file /oracle/app/oracle/admin/xty/udump/xty_ora_3149.trc:  
ORA-00600: internal error code, arguments: [18062], [], [], [], [], [], [], []

第1步，重启数据库到MOUNT状态：

[oracle@xty ~]$ sqlplus / as sysdba  
  
SQL*Plus: Release 10.2.0.4.0 - Production on Mon Sep 6 15:43:47 2010  
  
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.  
  
Connected to an idle instance.  
  
SQL> startup mount  
ORACLE instance started.  
  
Total System Global Area  209715200 bytes  
Fixed Size                  1266632 bytes  
Variable Size              75500600 bytes  
Database Buffers          130023424 bytes  
Redo Buffers                2924544 bytes  
Database mounted.

第2步，在另一个窗口中，使用gdb

[oracle@xty ~]$ ps -ef | grep LOCAL  
oracle    3186  3156  0 15:43 ?        00:00:00 oraclexty (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))  
oracle    3188  2978  0 15:44 pts/3    00:00:00 grep LOCAL  
[oracle@xty ~]$ gdb $ORACLE_HOME/bin/oracle 3186  
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5)  
...（省略）...  
Reading symbols from /oracle/app/oracle/product/10.2.0/bin/oracle...(no debugging symbols found)...done.  
Attaching to program: /oracle/app/oracle/product/10.2.0/bin/oracle, process 3186  
Reading symbols from /etc/libcwait.so...(no debugging symbols found)...done.  
Loaded symbols for /etc/libcwait.so  
Reading symbols from /oracle/app/oracle/product/10.2.0/lib/libskgxp10.so...(no debugging symbols found)...done.  
Loaded symbols for /oracle/app/oracle/product/10.2.0/lib/libskgxp10.so  
Reading symbols from /oracle/app/oracle/product/10.2.0/lib/libhasgen10.so...(no debugging symbols found)...done.  
...（省略）...  
Reading symbols from /oracle/app/oracle/product/10.2.0/lib/libnnz10.so...(no debugging symbols found)...done.  
Loaded symbols for /oracle/app/oracle/product/10.2.0/lib/libnnz10.so  
Reading symbols from /usr/lib/libaio.so.1...(no debugging symbols found)...done.  
Loaded symbols for /usr/lib/libaio.so.1  
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.  
Loaded symbols for /lib/libdl.so.2  
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.  
Loaded symbols for /lib/libm.so.6  
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.  
[Thread debugging using libthread_db enabled]  
Loaded symbols for /lib/libpthread.so.0  
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.  
Loaded symbols for /lib/libnsl.so.1  
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.  
Loaded symbols for /lib/libc.so.6  
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.  
Loaded symbols for /lib/ld-linux.so.2  
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.  
Loaded symbols for /lib/libnss_files.so.2  
0x0025d402 in __kernel_vsyscall ()  
(gdb)  break kokiasg  
Breakpoint 1 at 0xa3d404d  
(gdb) continue  
Continuing.

第3步，OPEN数据库：

SQL> alter database open;

约等一会儿，在alert日志里面可以看到：

Mon Sep  6 15:44:41 2010  
SMON: enabling cache recovery  
SMON: enabling tx recovery  
Mon Sep  6 15:44:41 2010  
Database Characterset is ZHS16GBK

在gdb的输出可以看到：

Breakpoint 1, 0x0a3d404d in kokiasg ()

第4步，在gdb那里中止OPEN：

(gdb) kill  
Kill the program being debugged? (y or n) y       
(gdb) quit

sqlplus会提示：

alter database open  
*  
ERROR at line 1:  
ORA-03113: end-of-file on communication channel

这一次，Instance并没有terminated。只是Server process被KILL了。

第5步，还原GLOBAL_NAME：

[oracle@xty ~]$ sqlplus / as sysdba  
  
SQL*Plus: Release 10.2.0.4.0 - Production on Mon Sep 6 15:45:09 2010  
  
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.  
  
  
Connected to:  
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production  
With the Partitioning, OLAP, Data Mining and Real Application Testing options  
  
SQL> select status from v$instance;  
  
STATUS  
------------  
OPEN  
  
SQL> update global_name set global_name='XTY';  
  
1 row updated.  
  
SQL> commit  
  2  ;  
commit  
*  
ERROR at line 1:  
ORA-01109: database not open

虽然可以执行UPDATE，但是不能COMMIT。再试试能不能做DDL：

SQL> create table t1 ( a int);  
  
Table created.

成功了。

在另会一个会话中查看GLOBAL_NAME：

SQL> select * from global_name;  
  
GLOBAL_NAME  
--------------------------------------------------------------------------------  
XTY

GLOBAL_NAME回来了。

这里通过DDL的隐式提交特性来UPDATE GLOBAL_NAME。其实还有更简单的办法：OCI主动断开连接时的自动提交。如果UPDATE之后，直接退出sqlplus，UPDATE GLOBAL_NAME的事务实际也提交了。看起来ORACLE这时只是不能执行显式的COMMIT语句。

第6步，重启数据库：

SQL> shutdown immediate  
ORA-00604: error occurred at recursive SQL level 1  
ORA-01109: database not open  
  
  
SQL> shutdown abort  
ORACLE instance shut down.  
SQL> startup  
ORACLE instance started.  
  
Total System Global Area  209715200 bytes  
Fixed Size                  1266632 bytes  
Variable Size              75500600 bytes  
Database Buffers          130023424 bytes  
Redo Buffers                2924544 bytes  
Database mounted.  
Database opened.

看起来只能以abort方式关闭数据库：
成功了，数据库起来了。没有数据丢失，没有使用备份。不需要基于时间点的恢复，不需要BBED，不需要Resetlog。