联机日志文件损坏问题

联机日志文件分2种： 当前联机日志 和 非当前联机日志
非当前联机日志的丢失并不会产生太大的影响，但当前联机日志的丢失，非常有可能会造成数据的丢失。
以下操作均在归档模式下操作

在启动数据库时，发现只是启动到mount状态下，报ORA-00312或ORA-00313错误。
select * from v$log;
查看丢失或损坏日志是不是当前日志。

如果丢失的是非当前联机日志，它的恢复是比较简单的。
1.如果损坏的日志文件已经归档。
alter database clear logfile group n;
--用上述命令对这个日志文件进行重建
2.如果损坏的日志文件还没有归档
alter database clear unarchived logfile group n;
-------------------------------------------------------------------------------------
最后就可以正常打开数据库了
alter database open;
由于是非当前日志丢失，此恢复过程并不会造成数据丢失。

如果丢失的书当前联机日志，它非常有可能造成数据丢失
首先如果有数据库全备份的话，使用rman先修复一下
restore database;
recover database until cancel;--能恢复到什么程度就恢复到什么程度
选择auto进行恢复，出错不管它
alter database open resetlogs;
以上做的一致性的不完全恢复，会跑日志到现在可以用到的日志，并回滚未提交的事务数据，丢失的是当前联机重做日志中的数据。
如果没有备份的话，就只能进行不一致性恢复。
修改一致性校验参数
alter system set "_allow_resetlogs_corruption" =true scope=spfile;
重新启动数据库到mount。
recover database until cancel;
alter database open resetlogs;
alter system set "_allow_resetlogs_corruption" =false scope=spfile;--将参数修改回来
利用现有数据，重新建库

     _allow_resetlogs_corruption参数设置为true时，只要数据库启动需要的各个物理文件都在的话，就算数据文件头部和控制文件中的那些scn值不相等，它也可以强行打开数据库。
这种方法是万不得已才用的，这种做法会导致数据库不一致，就是有可能出现已提交的数据没被写到数据文件中，而未提及的事务的数据写到了数据文件中。

 

 

实验1：

丢失当前联机重做日志文件，用备份进行一致性的不完全恢复。

 

 

手动删除当前日志

 

强制重新启动数据库，出错

 

用rman恢复数据文件

 

 

打开数据库后，查看数据是否还在，已经不存在

 

实验2：

丢失当前日志文件，假设没有备份，进行不一致性不完全恢复

 

 

 

删除当前日志文件

 

 

 

打开数据库后，重置一致性参数

 

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

转载于:http://blog.itpub.net/29227735/viewspace-1066330/