救急！！！日志文件全部破坏？如何恢复？？？

显示全部楼层 · 2009-3-2 15:42:53

日志文件全部破坏？没有冷备份的,重建控制文件以后，设置
_allow_read_only_corruption=true
_allow_resetlogs_corruption = true
然后
bash-2.05$ sqlplus
SQL*Plus: Release 9.2.0.1.0 - Production on 星期三 3月 23 16:02:51 2005
Copyright (c) 1982, 2002, Oracle Corporation.All rights reserved.
请输入用户名:/ as sysdba
已连接到空闲例程。
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area 5254389768 bytes
Fixed Size
737288 bytes
Variable Size
3137339392 bytes
Database Buffers 2113929216 bytes
Redo Buffers
2383872 bytes
数据库装载完毕。
SQL> recover database until cancel;
ORA-00279: 更改 59807975 (在 03/23/2005 15:53:59 生成) 对于线程 1 是必需的
ORA-00289: 建议: /u01/opt/oracle/product/9.2.0/dbs/arch1_1.dbf
ORA-00280: 更改 59807975 对于线程 1 是按序列 # 1 进行的

指定日志: {=suggested | filename | AUTO | CANCEL}
ORA-00308: 无法打开存档日志 '/u01/opt/oracle/product/9.2.0/dbs/arch1_1.dbf'
ORA-27037: 无法获得文件状态
SVR4 Error: 2: No such file or directory
Additional information: 3

ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件1需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: '/u01/opt/oracle/product/9.2.0/oradata/jw/system01.dbf'

SQL> alter database open resetlogs ;
alter database open resetlogs
*
ERROR 位于第 1 行:
ORA-03113: 通信通道的文件结束

千问 · 2009-3-2 15:42:53

Noarchivelog 下，不要recover database until cancel;

千问 · 2009-3-2 15:42:53

请问chensq，那我应该怎么作啊？

千问 · 2009-3-2 15:42:53

把上面步骤重新进行一次看看
应该可以达开
不过这样可能会导致数据字典有些问题

千问 · 2009-3-2 15:42:53

我试了n遍，但是老是提示
SQL> alter database open resetlogs ;
alter database open resetlogs
*
ERROR 位于第 1 行:
ORA-03113: 通信通道的文件结束

千问 · 2009-3-2 15:42:53

REDO的磁盘可以用吗？
是不是还是坏的？
如果是坏的
那在打开以前重新建几组REDO

千问 · 2009-3-2 15:42:53

如果你实在全部日志文件丢失后再把数据库shutdown immediate正常关闭的话,可以重建控制文件;并且在重建语法中选用resetlogs,就可以起来了,只不过redo log里面的一些还没有来得及写到数据文件里面的数据会丢失,没有必要用_allow_resetlogs_corruption参数的;
如果shutdown immediate 后再删除的日志文件,也可以用这种方法!(不管数据库是不是在归档日志模式);
如果是shutdown abort的话,一般只能用_allow_resetlogs_corruption参数了.
不管如何日志文件丢掉了,还是好恢复的..

千问 · 2009-3-2 15:42:53

alert里面你最后一次关闭数据库是正常关闭的，这样事实上不需要这么麻烦，只要重新创建控制文件后resetlogs打开就会重新生成了。如果不是正常关闭的话回滚段里面还有一些数据，这时候启动的时候就需要把回滚表空间脱机再打开，如果不脱机的话需要加入_corrupted_rollback_segments来指定UNDO表空间里面的回滚段再试着resetlogs打开。

千问 · 2009-3-2 15:42:53

首先不知道你为什么要重建控制文件？似乎没这个必要
加参数以后，recover database until cancel的时候一定要选cancel，然后再resetlogs打开，可能一次不行，多试几次，打开后立刻exp数据库

千问 · 2009-3-2 15:42:53

to coolyl:首先是current log 被删掉, 在mount模式下执行 alter database clear unarchived logfile group X 是不生效的...普通做法只有在初始化参数中 _allow_RESETLOGS_CORRUPTION=true ,但这样会导致数据库逻辑不一致,从而需要exp ,重建数据库;
但是如果重建控制文件,并resetlogs ;就不需要设置参数_allow_resetlogs_corruption了,这儿提供的是另外一种解决方法.但这种方法,只有在删除current log,再shutdown immediate后,或shutdown immediate 再删除current log 两种场景时候都能恢复数据库;但我不知道这种方法是否会产生倒是数据库逻辑不一致的后果;
按理来说,无论是更改初始化参数,重建控制文件,能打开数据库后,再shutdown immediate,再open,这个时候数据库应该逻辑一致的,还有必要再exp重建库吗? 当然数据是不可避免会丢失一些的..