ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 由于掉电导致数据库online redo log损坏

由于掉电导致数据库online redo log损坏

原创 Linux操作系统 作者:abp0109 时间:2011-03-31 23:57:59 0 删除 编辑

今天一网友用QQ向我请求帮助,说数据库由于意外断电导致数据库无法启动,具体来说是有一组日志文件损坏了,由于服务器和他的办公网不在一块,所以操作起来确实很麻烦,也费了点时间,不过最后还是解决了,呵呵!

简单介绍下:

在启动数据库时,alert中报如下错误:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 266281 change 79537981 time 03/26/2011 14:51:04
ORA-00312: online log 7 thread 1: '/opt/app/oracle/oradata/test1/redo0701.log'
ORA-354 signalled during: ALTER DATABASE OPEN...

显然是redo log损坏了。在后来的处理过程中,还碰到了如下一些错误:

Errors in file /opt/app/oracle/admin/test1/bdump/test1_smon_32600.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4194], [44], [44], [], [], [], [], []

Errors in file /opt/app/oracle/admin/test1/udump/test1_ora_32618.trc:
ORA-00600: internal error code, arguments: [4193], [60883], [60888], [], [], [], [], []
ORA-00600: internal error code, arguments: [4193], [60883], [60888], [], [], [], [], []

期间通过启动数据库到MOUNT状态,然后依据SPFILE创建了PFILE文本参数文件,编辑PFILE参数文件,加入隐含参数:*._allow_resetlogs_corruption=TRUE
*._allow_error_simulation=TRUE

再shutdown immediate数据库,使用PFILE启动数据库至MOUNT状态。再次尝试通过:

SQL> recover database until cancel;
SQL> alter database open resetlogs;

这种方式虽然把数据库open了,但是后台alert报了很多ORA-600 [4194] 或 ORA-600 [4193]等错误,且很快便又会自动down掉。(当时,很无奈,呵呵)

ORA-00600的4194和4193错误原因基本是类似的,查询metalink ID 9283.1和ID 39282.1了解到是由于Redo records和Undo records不一致。我就想要不重建一下UNDO表空间吧,结果却报错,见下:

SQL> create undo tablespace undotbs3
2 datafile '/opt/app/oracle/oradata/test1/undotbs3.dbf' size 100m;
create undo tablespace undotbs3
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4194], [55], [3], [], [], [], [],[]

可见,重建UNDO表空间行不通。接着想到之前在PUB上看到一种方式是通过隐含参数尝试打开数据库,因此,我让他提供了数据库系统所有的回滚段:

SQL> select owner, segment_name, tablespace_name, status
2 from dba_rollback_segs
3 where status <> 'OFFLINE'
4 order by 3;

结果是有14个回滚段_SYSSMU1$--->_SYSSMU14$。

又让他再编辑PFILE文件,添加如下内容:

undo_management='MANUAL'
*._corrupted_rollback_segments='_SYSSMU1$','_SYSSMU2$','_SYSSMU3$','_SYSSMU4$','_SYSSMU5$','_SYSSMU6$','_SYSSMU7$','_SYSSMU8$','_SYSSMU9$','_SYSSMU10$','_SYSSMU11$','_SYSSMU12$','_SYSSMU13$','_SYSSMU14$'

在依次执行:

SQL> STARTUP MOUNT PFILE='XXX/XX.ora';
SQL> recover database until cancel;
SQL> alter database open resetlogs;

过了一会,他说数据库成功打开了;我说,再等一会,看它还会不会自己down掉,过了一会,也没down掉,那就说明基本是可以了。

最后提示他说:如果数据库目前不会自动down掉的话,就重新启动数据库(spfile),然后将数据库中的数据exp导出,最后重建数据库,在imp进去。


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

请登录后发表评论 登录
全部评论

注册时间:2010-01-21

  • 博文量
    17
  • 访问量
    32047