第一步：新建三个新的联机日志组：
第二步：改变用户状态
第三步：查看用户状态
第二和第三步反复做，知道 活跃的用户联机日志转移到4,5,6组上；
第四步：重启数据库，使得group1，group2，group3都是inactive状态下，然后用下面指令删除，原先的redo组
第五步-重建group1，group2，group3，
第六步：重复第二步和第三步，把用户redo联机日志活动状态移动回到group1，或2，或3；
第七步：重启机器，等group4，group5，group6的状态编导inactive时，删除他们。
详细见：http://blog.csdn.net/robinson_0612/article/details/5749556
下面是参考材料。
重做日志文件是ORACLE数据库不可缺少的组成部分，Oracle服务器将对数据库所有更改按顺序记录到重做日志缓冲区中，LGWR进程把重做条目从重做日志缓冲区写入联机重做日志文件中，在发生介质故障时，会提供恢复机制，这也是ORACLE数据库保证数据安全的一种手段。
在真实的环境中，可能会因为误删除或其他原因，丢失了重做日志文件，如果数据库在启动时检测到重做日志丢失，数据库将无法启动。如果数据库在运行时切换日志文件组，检测到下一组或者全部的重做日志丢失，数据库将会崩溃。所以有必要学习下Oracle重做日志恢复的技巧。
一、丢失非活动日志文件的恢复
如果丢失的日志文件组状态为‘INACTIVE’,说明该日志组已经完成检查点，数据库不会发生数据丢失，但是千万不能够忽视，因为当日志切换到该日志组时会发生错误。恢复的方法有很多种，以下罗列了三种方法：
测试环境
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 – Production
SQL> select group#,members,status from v$log;
GROUP# MEMBERS STATUS
---------- ---------- ----------------
1 2 INACTIVE
2 1 CURRENT
3 2 INACTIVE
模拟故障
[oracle@mylinux2 ~]$ rm /u01/oradata/orcl/redo01.log
当数据库日志切换到该日志组后，发现日志文件不存在，数据库将会崩溃，除了DBA外其他用户都不能连接到数据库。
从警告日志可得到下面信息：
Sun Aug 08 15:57:51 2010
Errors in file /u01/diag/rdbms/orcl/dave/trace/dave_m000_10925.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u01/oradata/orcl/redo01.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
启动数据库，会提示丢失了日志文件。
SQL> startup
ORACLE instance started.
Total System Global Area 422678528 bytes
Fixed Size 1300324 bytes
Variable Size 251660444 bytes
Database Buffers 163577856 bytes
Redo Buffers 6139904 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u01/oradata/orcl/redo01.log'
执行恢复（三种恢复方法）
1. 直接删除丢失的重做日志文件组,但是删除后必须保证数据库的重做日志组数目不能小于2个。
a) 删除重做日志文件组：
SQL> alter database drop logfile group 1;
Database altered.
b) 增加重做日志文件组：
SQL>alter database add logfile group 1 ('/u01/oradata/orcl/redo1.log','/u01/oradata/orcl/redo01.log') size 50m;
Database altered.
2. 在丢失的重做日志组中增加同样大小的REDO文件，然后删除丢失的MEMBER。
a) 增加重做日志文件成员：
SQL> alter database add logfile member '/u01/oradata/orcl/redo01.log' to group 1;
Database altered.
b) 删除丢失的日志文件：
SQL> alter database drop logfile member '/u01/oradata/orcl/redo1.log';
Database altered.
c) 这种方法只适合丢失的文件组中至少还有一个成员是可用的，如果丢失的日志文件所属的文件组只有这一个文件，那么这种方法是不适合的。在添加日志文件时会出错：
SQL> alter database add logfile member '/u01/oradata1/redo1.log' to group 1;
alter database add logfile member '/u01/oradata1/redo01.log' to group 1
*
ERROR at line 1:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u01/oradata/orcl/redo01.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
3. 通过clear日志恢复
SQL> alter database clear logfile group 1;
Database altered.
SQL> alter database open;
Database altered.
需要说明的是，如果数据库处于归档模式下，则需要使用下面的命令来清除日志：
alter database clear unarchived logfile group 1;
二、丢失当前日志文件的恢复
丢失的日志文件的状态如果是ACTIVE或CURRENT，说明没有归档。如果没有归档的日志组中含有多个日志文件成员，那么丢失或者损坏部分日志文件时，只需要复制正常的日志文件，来替换丢失或损坏的日志文件即可解决，这样数据不会丢失，也不用做恢复操作。
如果没有归档的重做日志组中所有日志件都丢失或者损坏，将会导致数据库数据丢失，如果没有归档的日志文件组为当前组，则数据库立即DOWN机。当这个情况发生时，就意味着数据的丢失，我们只能将数据库恢复到前一次的归档日志切换时刻
下面模拟在正常和非正常关闭数据库后丢失当前日志文件的场景，来恢复日志文件。
1. 正常关闭数据库，丢失当前日志文件的恢复
因为是正常关闭，因此数据库在关闭前，做了全面检查点，日志文件对实例恢复没有意义了。
测试环境
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 – Production
SQL> select group#,members,status from v$log;
GROUP# MEMBERS STATUS
---------- ---------- ----------------
1 2 INACTIVE
2 1 CURRENT
3 2 INACTIVE
模拟丢失文件
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> !rm /u01/oradata1/redo02.log
SQL> startup
ORACLE instance started.
Total System Global Area 146472960 bytes
Fixed Size 1298472 bytes
Variable Size 92278744 bytes
Database Buffers 50331648 bytes
Redo Buffers 2564096 bytes
Database mounted.
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/u01/oradata1/redo02.log'
SQL> !ls -l /u01/oradata1
total 102528
-rw-r----- 1 oracle oinstall 52429312 Sep 26 03:49 redo010.log
进行恢复
SQL> alter database clear unarchived logfile group 2;
Database altered.
检查发现，日志文件已恢复。
SQL> !ls -l /u01/oradata1
total 102528
-rw-r----- 1 oracle oinstall 52429312 Sep 26 03:49 redo010.log
-rw-r----- 1 oracle oinstall 52429312 Sep 26 03:54 redo02.log
SQL> alter database open;
Database altered.
2. 异常关闭数据库，丢失当前日志文件的恢复
异常关闭数据库，说明在数据库启动时进行的实例恢复一定要求有当前的日志文件，否则oracle将无法保证提交的成功的数据部丢失。
测试环境
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 – Production
SQL> select group#,members,status from v$log;
GROUP# MEMBERS STATUS
---------- ---------- ----------------
1 2 INACTIVE
2 1 CURRENT
3 2 INACTIVE
模拟丢失文件
SQL> shutdown abort
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> !rm /u01/oradata1/redo02.log
SQL> startup
ORACLE instance started.
Total System Global Area 146472960 bytes
Fixed Size 1298472 bytes
Variable Size 92278744 bytes
Database Buffers 50331648 bytes
Redo Buffers 2564096 bytes
Database mounted.
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/u01/oradata1/redo02.log'
SQL> !ls -l /u01/oradata1
total 102528
-rw-r----- 1 oracle oinstall 52429312 Sep 26 03:49 redo010.log
进行恢复
该参数默认值为FALSE，为TRUE说明，在破坏唯一性的情况下强制重置日志，打开数据库。在打开的过程中，ORACLE会跳过一致性检查，使数据库处于不一致的状态下打开。
SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
System altered.
修改后，重启数据库。
SQL> shutdown immeditae
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 146472960 bytes
Fixed Size 1298472 bytes
Variable Size 92278744 bytes
Database Buffers 50331648 bytes
Redo Buffers 2564096 bytes
Database mounted.
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 3046568 generated at 09/26/2010 00:59:56 needed for thread 1
ORA-00289: suggestion :
/u01/flash_recovery_area/ORCL/archivelog/2010_09_26/o1_mf_1_2_%u_.arc
ORA-00280: change 3046568 for thread 1 is in sequence #2
Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/oradata/orcl/system01.dbf'
ORA-01112: media recovery not started
如果这里出现错误，跳过即可
SQL> alter database open resetlogs;
Database altered.
检查发现，日志文件已恢复。
SQL> !ls -l /u01/oradata1
total 102528
-rw-r----- 1 oracle oinstall 52429312 Sep 26 03:49 redo010.log
-rw-r----- 1 oracle oinstall 52429312 Sep 26 03:54 redo02.log
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 146472960 bytes
Fixed Size 1298472 bytes
Variable Size 92278744 bytes
Database Buffers 50331648 bytes
Redo Buffers 2564096 bytes
Database mounted.
Database opened.
数据库被打开后，马上执行全备，shutdown数据库,修改_all_resetlogs_corrupt参数为FALSE
254
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
