[转]oracle9 startup时 报错ORA-00600: 参数: [kcratr1_lostwrt]

今天一个用户和我们联系，数据库出现问题，于是远程指导对方，发现错误为ora-00600。解决方法如下帖子所示。

 

http://space.itpub.net/8102208/viewspace-442899

 

 

原因可能是非法关机或掉电造成,以下是出现的问题及解决方法:

C:\Documents and Settings\Administrator>sqlplus

SQL*Plus: Release 9.2.0.1.0 - Production on 星期日 5月 13 09:23:23 2007

Copyright (c) 1982, 2002,OracleCorporation.  All rights reserved.

    请输入用户名:  /as sysdba

    连接到:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production

SQL> startup
ORA-01081: 无法启动已在运行的 ORACLE --- 请首先关闭
SQL> shutdown abort
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。

Total System Global Area  135338868 bytes
Fixed Size                   453492 bytes
Variable Size             109051904 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
ORA-00600: 内部错误代码，参数: [kcratr1_lostwrt], [], [], [], [], [], [], []

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

 

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

Total System Global Area  135338868 bytes
Fixed Size                   453492 bytes
Variable Size             109051904 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
SQL> recover database;
完成介质恢复。
SQL> alter database open;

数据库已更改。

SQL>exit; 

 ---------------------------------------------------------

对于问题成因，有大侠描述如下：

转帖地址：http://www.eygle.com/archives/2010/05/ora-00600_kcratr1_lostwrt.html

 

客户的一个数据库因为断电遇到了ORA-600 kcratr1_lostwrt错误，数据库无法启动。
错误信息类似：

ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kcratr1_lostwrt], [], [], [], [], [], [], []
Current SQL statement for this session:
alter database open

这个错误不难解决，但是其具体成因有点意思。
Metalink对这个错误的解释只有一句关键：

When an instance is restarted following an instance crash, Oracle carries out some checks against the last block that was written to disk prior to the instance crash.
If Oracle finds an old block, then this suggests a lost write and the  error is raised.

这句话是说，当实例崩溃之后启动，Oracle会去检查崩溃前最后一个写出的数据块，通过控制文件校验其是否一致，如果这个块是Old的，则说明最后的写操作丢失了。

这是一个非常快捷巧妙地判断，如果有写丢失，自然必须引入恢复。

在跟踪文件中记录了详细的信息：

Last BWR afn: 6 rdba: 0x18f9590(blk 1021328) ver: 0x0001. 5c21fd6e.01 flg: 0x04
Disk version: 0x0001. 5c1ec4f0.04 flag: 0x04

提示说，控制文件记录的最后一次写的数据块是file6 block 1021328，SCN版本为：5c21fd6e，而数据文件上记录的SCN则是5c1ec4f0，后者Old，小于前者，这说明丢失了写操作。

那能否恢复呢？跟踪文件里还会记录这样的信息：

Thread checkpoint rba:0x00dfeb.00000002.0010 scn:0x0001. 5c1ee5b7
On-disk rba:0x00dfeb.0001161f.0000 scn:0x0001. 5c2266d6

线程检查点的SCN为5c1ee5b7，而On-Disk Rba的SCN为5c2266d6，完全可以推演超过5c21fd6e，可以恢复。

所以这样的问题：

SQL>startup mount;
SQL>recover database;
SQL>alter database open;

一般就可以完成恢复了，如果不幸的，你的On-Disk Rba不足以恢复丢失的写操作，则问题将严重了。

转载于:https://www.cnblogs.com/xinyuxin912/archive/2010/06/09/1754779.html