谁有灾难恢复相关资料？500分悬赏。

Question

谁能提供灾难恢复相关资料和解决方案? 谢谢！ 结帖后统统加分。另外怎么才可以给出更多分？

Answer 1

具体是什么错误？
http://www.orafaq.net/cgi-bin/search/query?p=1&lang=en&include=&exclude=&penalty=&mode=all&q=ORA-01157

Answer 2

机器异常断电，oracle不能正常启动，可以mount，不能open。数据库未备份过。
错误码：
At startup, the database will mount, but gives the following errors at open: 
 ORA-00312: "online log %s thread %s: '%s'" 
     Cause: This message reports the filename for details of another message. 
    Action: Other messages will accompany this message. See the 
            associated messages for the appropriate action to take. 
 ORA-00322: "log %s of thread %s is not current copy" 
     Cause: Check of log file header at database open found that an online log  
            appears to be an incorrectly restored backup. 
    Action: Restore correct file or reset logs. 解决方法描述：
首先检查ORACLE_HOME 和ORACLE_SID在startup参数中是否正确，如果不正确重新startup。Recover the loss of an inactive, online redo log group. SQL>ALTER DATABASE CLEAR LOGFILE 'filename'; If there is more than one LOGFILE in the redo log group then you must 
specify all the log files. For example, the following fails: SVRMGR> alter database clear logfile '/vobs/oracle/dbs/log3.log'; 
alter database clear logfile '/vobs/oracle/dbs/log3.log' 
* 
ORA-1514: error in log specification: no such log 
ORA-1517: log member: '/vobs/oracle/dbs/log3.log But, specifying all the log files in the group works: 
SVRMGR> ALTER DATABASE CLEAR LOGFILE ('/vobs/oracle/dbs/t4.log','/vobs/oracle/; 
Statement processed. 介绍一个意外情况，如果上面的方法不成功，数据库还是不能open，采用recover，restore都不成功，说明logfile可能已经损坏，数据库打开需要做一致性检查，所以不能正常打开。因为数据库未作过备份，为了尽可能地减少损失，采用打开数据库，然后立刻导出数据的方法。
oracle有一个不推荐的方法，可以使数据库在不进行一致性检查的方式下打开数据库。
做法：
1。为保险起见，将数据库的系统表空间，数据文件，控制文件均做一次备份：copy。
2。在初始化配置文件中（init.ora）加上：
_allow_resetlogs_corruption=true
_corrupted_rollback_segments=(将所有rollback_segments=(...)的内容加到这里）
将rollback_segments=(...)前加上#
3。startup mount
recover database until cancel；
cancel
alter database open resetlogs;
此时数据库已经可以打开了，请立刻将数据export出来，然后重新安装oracle，重新建立database，再将数据import。
注意：这种方法属于数据库的不完全恢复，最后提交的sql可能会丢失，毕竟能够尽可能地减少损失，可以试试。
以上操作我均做过测试。

Answer 3

解决方案最终还是看具体的错误信息来处理，就是连ORACLE的内部工程师也不例外现在没有出现问题，先注重的数据库备份的策略，每一个策略都有自己的恢复方法。先从备份策略开始吧

Answer 4

这是Oracle技术网的 一个文章：阿木伯 著
没有备份、只有归档日志，如何恢复数据文件？
可通过重建数据文件来恢复，前提是归档日志文件保存完整先将数据库设置为归档模式SQL*Plusconn system/manager--创建实验表空间
create tablespace test datafile
'c:\test.ora' size 5M
AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED
default storage (initial 128K next 1M pctincrease 0)
/--创建实验用户
  drop user test cascade;
create user test identified by test default tablespace test;
grant connect,resource to test;
conn test/testcreate table a(a number);
insert into a values(1);
insert into a select * from a; --反复插入，达到100万条
commit;--关闭数据库
SVRMGR> connect internal
SVRMGR> alter system switch logfile; --强制归档
SVRMGR> alter system switch logfile;
SVRMGR> alter system switch logfile;
SVRMGR> shutdown--操作系统下删除test.ora文件--重新启动数据库
SVRMGR> connect internal
SVRMGR> startup这时，可以mount上，但无法打开，因为数据文件test.ora不存在，
显示错误如下：ORA-01157: ????/?????? 8 - ??? DBWR ????
ORA-01110: ???? 8: 'C:\TEST.ORA'SVRMGR> connect internal
SVRMGR> startup mount
SVRMGR> alter database create datafile 'c:\test.ora';
SVRMGR> set autorecovery on
SVRMGR> recover datafile 'c:\test.ora';
SVRMGR> alter database open;conn test/test
select count(*) from a; --数据又恢复到100万条--删除实验表空间
conn system/manager
alter tablespace test offline;
drop tablespace test INCLUDING CONTENTS;
drop user test;
--如果是非归档模式，也可以运用以上方法，
--前提是：输入记录所占空间的大小不超过所有联机日志文件的大小
--即：用联机日志文件来恢复

Answer 5

楼主有没有EMAIL，我可以给你几篇文章参考一下

Answer 6

我的email是：[email protected]
谢谢！