Oracle当前联机日志组损坏的处理

一Oracle 日志的特性总结 1 oracle 日志切换规律（从最大sequence#号切换到最小sequence#号） eg 如下所示：下个当前日志组会是sequence#号为27的5号日志组SQL> select group#,archived,sequence#,status from v$log; GROUP# ARC SEQUENCE# STATUS---------- --- ---------- ----------------1 NO 32 CURRENT2 YES 28 INACTIVE3 YES 29 INACTIVE4 YES 30 INACTIVE5 YES 27 INACTIVE <------众日志组中sequence#号最小6 YES 31 INACTIVE 6 rows selected. SQL> alter system switch logfile ; System altered. SQL> select group#,archived,sequence#,status from v$log; GROUP# ARC SEQUENCE# STATUS---------- --- ---------- ----------------1 YES 32 ACTIVE2 YES 28 INACTIVE3 YES 29 INACTIVE4 YES 30 INACTIVE5 NO 33 CURRENT6 YES 31 INACTIVE 6 rows selected.Oracle 重做联机日志文件 http://www.linuxidc.com/Linux/2012-02/54340.htmOracle联机日志恢复案例 http://www.linuxidc.com/Linux/2013-07/87413.htm联机日志文件过小引发的log file 相关等待 http://www.linuxidc.com/Linux/2013-03/81591.htmOracle联机日志文件丢失或损坏的处理方法 http://www.linuxidc.com/Linux/2013-01/77506.htm联机日志损坏时的恢复（正常关闭数据库） http://www.linuxidc.com/Linux/2012-07/66092.htm2 快速转换oracle日志组状态active为inactive日志组切换后，上一个当前日志组状态由current变成active，实际上是由于当前数据文件头部的scn值还位于状态为active日志组的low scn 和next scn 内，所以我们此刻如果立即发起alter sytem checkpoint 命令推进数据文件头部scn 变可使日志状态由active 变为inactive。SQL> select group#,archived,sequence#,status from v$log; GROUP# ARC SEQUENCE# STATUS---------- --- ---------- ----------------1 YES 32 INACTIVE2 YES 34 INACTIVE3 YES 35 INACTIVE4 NO 36 CURRENT5 YES 33 INACTIVE6 YES 31 INACTIVE SQL> alter system switch logfile; System altered. SQL> select group#,archived,sequence#,status from v$log; GROUP# ARC SEQUENCE# STATUS---------- --- ---------- ----------------1 YES 32 INACTIVE2 YES 34 INACTIVE3 YES 35 INACTIVE4 YES 36 ACTIVE <------sequence号为36的日志为active5 YES 33 INACTIVE6 NO 37 CURRENT 6 rows selected. 查询数据文件头部scn情况如下：SQL> select hxfil,fhscn from x$kcvfh; HXFIL FHSCN---------- ----------------1 27812392212 27812392213 27812392214 27812392215 27812392216 27812392217 27812392218 278123922111 278123922112 278123922113 2781239221 SQL> select sequence#,first_change#,next_change# from v$log_history;SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#---------- ------------- ------------32 2781218249 278121830033 2781218300 278121917434 2781219174 278121918435 2781219184 278123922036 2781239220 2781239424数据文件头部的scn：2781239221 处于sequence号为36的日志scn范围 内 2781239220 2781239424 SQL> alter system checkpoint; System altered. SQL> select hxfil,fhscn from x$kcvfh; HXFIL FHSCN---------- ----------------1 27812394562 27812394563 27812394564 27812394565 27812394566 27812394567 27812394568 278123945611 278123945612 278123945613 2781239456 11 rows selected. SQL> select group#,archived,sequence#,status from v$log; GROUP# ARC SEQUENCE# STATUS---------- --- ---------- ----------------1 YES 32 INACTIVE2 YES 34 INACTIVE3 YES 35 INACTIVE4 YES 36 INACTIVE 5 YES 33 INACTIVE6 NO 37 CURRENT3 clear 日志组的执行条件 clear的日志组状态不能是acitve 或者当前日志组eg：SQL> select group#,archived,sequence#,status from v$log; GROUP# ARC SEQUENCE# STATUS---------- --- ---------- ----------------1 NO 38 CURRENT2 YES 34 INACTIVE3 YES 35 INACTIVE4 YES 36 INACTIVE5 YES 33 INACTIVE6 YES 37 ACTIVE SQL> alter database clear logfile group 6;alter database clear logfile group 6*ERROR at line 1:ORA-01624: log 6 needed for crash recovery of instance CRM （thread 1）ORA-00312: online log 6 thread 1: "/oracle/CRM2/CRM/redo06.log"ORA-00312: online log 6 thread 1: "/oracle/CRM2/CRM/redo06b.log"

Oracle用控制文件旧备份恢复后数据库恢复总结ORA-01200错误的分析相关资讯 Oracle联机日志 Oracle日志损坏

Oracle联机日志恢复案例（07/16/2013 09:23:44）

Oracle联机日志文件丢失或损坏的处（01/09/2013 08:47:40）

本文评论查看全部评论（0）