数据库自动关闭：后来参考yangtingkun 解决掉电导致的ORA-600(4194) 处理ok

第一件事情是了解情况，Windows环境下的32位10201数据库，非归档模式，没有备份。

检查alert文件，发现导致问题的原因是由于掉电导致日志文件损坏，在进行CRASH恢复时无法将数据库恢复到一致性的状态。

对大致情况有了一定的了解后，准备开始着手恢复工作：首先是备份现场，这样如果恢复失败，至少保留了出错是的环境。

然后尝试利用隐含参数_allow_resetlogs_corruption来打开数据库，这个步骤在很多篇文章中都描述过了，这里就不重复了，可以参考：http://yangtingkun.itpub.net/post/468/464701

数据库顺利打开，ALTER DATABASE OPEN RESETLOGS操作并没有报错，但是由于使用了隐含参数，因此数据库肯定会丢失数据，而且会处于不一致的状态，为了避免数据库的不一致对数据造成进一步的损害，准备将业务用户执行逻辑导出：

D:>exp hc/hc file=hc_20100303.dmp buffer=2048000 compress=n log=hc_20100303.log

Export: Release 10.2.0.1.0 - Production on 星期三 3月 3 17:38:01 2010

EXP-00056: 遇到 ORACLE 错误 1034
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
EXP-00005: 所有允许的登录尝试均失败
EXP-00000: 导出终止失败

看错误信息似乎数据库没有启动，检查发现果然数据库自动关闭了，查询alert文件发现了大量的ORA-600(4194)错误。

再次尝试启动数据库报错：

C:Documents and SettingsAdministrator>sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on 星期三 3月 3 17:35:43 2010

已连接到空闲例程。

SQL> STARTUP
ORACLE 例程已经启动。

Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 121637764 bytes
Database Buffers 482344960 bytes
Redo Buffers 7135232 bytes数据库装载完毕。
ORA-00607: 当更改数据块时出现内部错误
ORA-00600: 内部错误代码, 参数: [4194], [38], [22], [], [], [], [], []

虽然STARTUP命令报错，但是数据库已经打开可以访问了，但是没过几分钟的时间，数据库就又自动关闭了，导致数据库自动关闭的原因仍然是ORA-600(4194)错误。

查询metalink发现，导致这个错误是由于UNDO信息出现了不一致，虽然metalink上没有给出解决方法，不过根据经验，利用隐含参数_corrupted_rollback_segments尝试打开数据库。

好在数据库可以短暂的打开，这样可以方便的查询到系统启动的回滚段名称：

SQL> CONN / AS SYSDBA已连接。
SQL> SELECT SEGMENT_NAME FROM DBA_ROLLBACK_SEGS;

SEGMENT_NAME
------------------------------
SYSTEM
_SYSSMU1$
_SYSSMU2$
_SYSSMU3$
_SYSSMU4$
_SYSSMU5$
_SYSSMU6$
_SYSSMU7$
_SYSSMU8$
_SYSSMU9$
_SYSSMU10$

已选择11行。

SQL> CREATE PFILE='D:ORACLEADMINORCLPFILEINITORCL.ORA' FROM SPFILE;

文件已创建。

在初始化参数文件中添加下面的参数：

undo_management='MANUAL'
_corrupted_rollback_segments=(_SYSSMU1&,_SYSSMU2&,_SYSSMU3&,_SYSSMU4&,_SYSSMU5&,_SYSSMU6&,_SYSSMU7&,_SYSSMU8&,_SYSSMU9&,_SYSSMU10&)

下面尝试打开数据库：

SQL> conn / as sysdba已连接到空闲例程。
SQL> STARTUP PFILE=D:ORACLEADMINORCLPFILEINITORCL.ORA MOUNT
ORACLE 例程已经启动。

Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 121637764 bytes
Database Buffers 482344960 bytes
Redo Buffers 7135232 bytes数据库装载完毕。
SQL> RECOVER DATABASE;完成介质恢复。
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
ORA-00279: 更改 19786562 (在 03/03/2010 18:20:31 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:ORACLEFLASH_RECOVERY_AREAORCLARCHIVELOG2010_03_03O1_MF_
1_3_%U_.ARC
ORA-00280: 更改 19786562 (用于线程 1) 在序列 #3 中

指定日志: {=suggested | filename | AUTO | CANCEL}
CANCEL介质恢复已取消。
SQL> ALTER DATABASE OPEN RESETLOGS;

数据库已更改。

数据库成功打开，下面再次利用EXP将数据库的业务用户进行导出：

D:>exp hc/hc file=hc_20100303.dmp buffer=2048000 direct=y recordlength=65534 compress=n log=hc_20100303.log

Export: Release 10.2.0.1.0 - Production on 星期三 3月 3 18:26:57 2010

连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options已导出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集
. 正在导出 pre-schema 过程对象和操作
. 正在导出用户 HC 的外部函数库名
. 导出 PUBLIC 类型同义词
. 正在导出专用类型同义词
. 正在导出用户 HC 的对象类型定义即将导出 HC 的对象...
. 正在导出数据库链接
. 正在导出序号
. 正在导出簇定义
. 即将导出 HC 的表通过直接路径...
. . 正在导出表 CAT_ORG导出了 6116 行
. . 正在导出表 CESHI_USER_FUNC导出了 0 行表 HC_AGENT_ANN 将以常规路径导出。
. . 正在导出表 HC_AGENT_ANN导出了 295 行
. . 正在导出表 HC_AGENT_ANN_ITEM导出了 0 行
. . 正在导出表 HC_AGENT_LINK导出了 5 行表 HC_AGENT_NEWS 将以常规路径导出。
. . 正在导出表 HC_AGENT_NEWS导出了 2054 行
. . 正在导出表 HC_AGENT_NEWS_ITEM导出了 0 行
.
.
.
. . 正在导出表 HC_USER_MSN_SEND导出了 122 行
. . 正在导出表 HC_VIP_PUBLISH_PRODUCT导出了 1858 行
. . 正在导出表 HC_VISIT_COUNT导出了 1 行
. . 正在导出表 PLAN_TABLE导出了 0 行
. . 正在导出表 T_INVITE导出了 0 行
. 正在导出同义词
. 正在导出视图
. 正在导出存储过程
. 正在导出运算符
. 正在导出引用完整性约束条件
. 正在导出触发器
. 正在导出索引类型
. 正在导出位图, 功能性索引和可扩展索引
. 正在导出后期表活动
. 正在导出实体化视图
. 正在导出快照日志
. 正在导出作业队列
. 正在导出刷新组和子组
. 正在导出维
. 正在导出 post-schema 过程对象和操作
. 正在导出统计信息成功终止导出, 没有出现警告。

至此，数据库的恢复工作完成。虽然数据库可以打开，但是丢失数据在所难免，所以关键数据一定要做好备份工作。

ITPub博客

遭遇数据库自动关闭（ora 600 4194）

最新文章