oracle日志文件相关问题汇总。
此种情况下，由于是正常关闭数据库，数据文件，redo文件以及控制文件SCN是一直的，redo文件中的所有操作记录都已经归档，所以如果在这种情况下丢失所有redo的话，恢复是很简单的，一般思路是：
Startup mount
Recover database until cancel;
Alter database open resetlogs;(执行此命令后，oracle会重新建立redo文件)
执行完以上操作后，马上全备数据库。
试验一：
用命令清空日志组方法
1、查看原来表中数据
SQL>; conn test/test
Connected.
SQL>; select * from test;
TEL
----------
1
2
3
2、插入新数据
SQL>; insert into test values(4);
1 row created.
SQL> commit;
Commit complete.
3、 正常关闭数据库
4、 利用os command删除所有redo文件。
5、 启动数据库
SQL>startup
ORACLE instance started.
Total System Global Area 353862792 bytes
Fixed Size 730248 bytes
Variable Size 285212672 bytes
Database Buffers 67108864 bytes
Redo Buffers 811008 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/T3/ORACLE/oradata/ORA9/redo01.log'
6、 查看当前日志状态
SQL>; select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ----------
1 1 2 104857600 1 YES INACTIVE
487837 01-9月 -05
2 1 4 104857600 1 NO CURRENT
487955 01-9月 -05
3 1 3 104857600 1 YES INACTIVE
487839 01-9月 -05
看来redo01.log不是当前日志，对于这类非当前日志可以直接clear,系统会重新自动生成一个redo文件。
7、SQL> alter database clear logfile group 1;
Database altered.
7、 继续启动db
SQL>; alter database open;
alter database open
*
ERROR at line 1:
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/T3/ORACLE/oradata/ORA9/redo02.log'
8、 看来redo也得恢复，但是redo02是当前redo,直接clear是不行的
SQL>; alter database clear logfile group 2;
alter database clear logfile group 2
ORA-00350: log 2 of thread 1 needs to be archived
尝试clear unarchived logfile group ,报错：
SQL> alter database clear unarchived logfile group 2;
alter database clear unarchived logfile group 2
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
看来他是因为找不到这个文件，从有效的备份中cp一个过来看看
SQL>！ cp /T3/ORACLE/oradatabak/redo02* /T3/ORACLE/oradata/ORA9
SQL>alter database clear unarchived logfile group 2;
搞定……….
9、 按照oracle的某些做法也是可以的
SQL>alter database clear unarchived logfile group 1 unrecoverable datafile;
10、但是对于非当前日志就都可以，下面看看redo03
SQL>; alter database clear logfile group 3;
结论：
如果数据库是正常shutdown,非当前日志都可以直接clear来重新生成，而且不丢失数据，因为正常关闭db,数据已经写入dbf文件了。唯独当前日志不可以，当前日志必须首先从有效的备份中拷贝一个日志文件过来，然后用
alter database clear unarchived logfile group n 或alter database clear unarchived logfile group n,除此之外，还可以用下面的方法来做
试验方法二：
用cancel模式恢复数据库
前面的出错提示，步骤都一样，唯独恢复的方法不一样
看看丢失了哪些redo
SQL> host ls /T3/ORACLE/oradarta/ORA9/redo*
/T3/ORACLE/oradarta/ORA9/redo*: No such file or directory
看来redo都丢了
直接recover
SQL>recover database until cancel;
Media recovery complete.
这个时候redo还没有生成
SQL>; host ls /T3/ORACLE/oradata/ORA9/redo*
/T3/ORACLE/oradata/ORA9/redo*: No such file or directory
启动数据库
SQL>; alter database open ;
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL>alter database open resetlogs;
（注意，这里必须用resetlogs,否则会错误的
SQL>alter database open noresetlogs;
alter database open noresetlogs
SQL>
Resetlogs其实就是根据控制文件让系统自动重新生成redo,如果noresetlog的话，就不会重新生成redo,缺少了文件，db自然无法启动）
SQL>host ls /T3/ORACLE/oradata/ORA9/redo*
/T3/ORACLE/oradata/ORA9/redo01.log /T3/ORACLE/oradata/ORA9/redo02.log /T3/ORACLE/oradata/ORA9/redo03.log
检验
SQL>select * from test.test;
4
数据一点儿都没有丢失。
如果数据库是正常关闭的，用recover database until cancel可以轻松恢复或者说重新建立所有的redo，不再区分是否是当前日志，而且由于正常关闭，不会丢失任何数据，唯一可能丢失的情况就是如果日志还没有归档。
这种恢复方法 由于要resetlogs,所以在恢复完成后，日志清零，以前的备份不再起作用，所以建议立即备份。
SQL>archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /T3/ORACLE/arch
Oldest online log sequence 0
Next log sequence to archive 1
Current log sequence 1
SQL>;
实验三：
通过重新生成控制文件来恢复redo
前面的都一样，只是处理方法不一样
SQL>; startup
SQL>alter database backup controlfile to trace;
SQL>; shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
2、 修改一下刚才生成的那个文件
CREATE CONTROLFILE REUSE DATABASE "ORA9" RESETLOGS ARCHIVELOG
-- SET STANDBY TO MAXIMIZE PERFORMANCE
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 '/T3/ORACLE/oradata/ORA9/redo01.log' SIZE 100M,
GROUP 2 '/T3/ORACLE/oradata/ORA9/redo02.log' SIZE 100M,
GROUP 3 '/T3/ORACLE/oradata/ORA9/redo03.log' SIZE 100M
-- STANDBY LOGFILE
DATAFILE
'/T3/ORACLE/oradata/ORA9/system01.dbf',
'/T3/ORACLE/oradata/ORA9/undotbs01.dbf',
'/T3/ORACLE/oradata/ORA9/cwmlite01.dbf',
'/T3/ORACLE/oradata/ORA9/drsys01.dbf',
'/T3/ORACLE/oradata/ORA9/example01.dbf',
'/T3/ORACLE/oradata/ORA9/indx01.dbf',
'/T3/ORACLE/oradata/ORA9/odm01.dbf',
'/T3/ORACLE/oradata/ORA9/tools01.dbf',
'/T3/ORACLE/oradata/ORA9/users01.dbf',
'/T3/ORACLE/oradata/ORA9/xdb01.dbf',
'/T3/ORACLE/oradata/ORA9/test01.dbf'
CHARACTER SET ZHS16GBK
;
另存为一个脚本，运行
SQL>@clone.sql
Control file created.
搞定……………
结论：这种方法的关键是重新创建控制文件，后面的步骤和前面的道理一样的。
前面的三种方法都是假设db是正常关闭的，数据已经写入数据库文件中，所以不会有数据存在于redo中，所以clear的话也不会有数据丢失。
试验五：丢失当前日志组的成员
1、SQL>; select * from v$logfile;
GROUP# STATUS TYPE MEMBER
---------- ------- ---------- ----------
3 ONLINE
/T3/ORACLE/oradata/ORA9/redo03.log
2 ONLINE
/T3/ORACLE/oradata/ORA9/redo02.log
1 ONLINE
/T3/ORACLE/oradata/ORA9/redo01.log
---------- ------- ------- -----------
/T3/ORACLE/oradata/ORA9/redo01a.log
/T3/ORACLE/oradata/ORA9/redo02a.log
/T3/ORACLE/oradata/ORA9/redo03a.log
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
1 1 2 104857600 2 YES INACTIVE
554599 02-9月 -05
2 1 3 104857600 2 YES INACTIVE
554601 02-9月 -05
3 1 4 104857600 2 NO CURRENT
554603 02-9月 -05
3、 模拟插入数据
SQL>; insert into test values(5);
SQL>; commit
2 ;
4、 shutdown db,模拟删除一个当前日志成员
$ cd oradata/ORA9
$ ls redo03*
redo03.log redo03a.log
$ rm redo03a.log
5、 启动db,表面没有错误
SQL> startup
Database opened.
6、 查看日至成员
SQL>; select * from v$logfile;
GROUP# STATUS TYPE
---------- ------- -------
MEMBER
--------------------------------------------
3 ONLINE
2 ONLINE
1 ONLINE
---------- ------- ------- ----------
1 ONLINE
2 ONLINE
3 INVALID ONLINE
7、 删除出问题的联机日志文件
SQL> alter database drop logfile member '/T3/ORACLE/oradata/ORA9/redo03a.log';
alter database drop logfile member '/T3/ORACLE/oradata/ORA9/redo03a.log'
ORA-01609: log 3 is the current log for thread 1 - cannot drop members
ORA-00312: online log 3 thread 1: '/T3/ORACLE/oradata/ORA9/redo03.log'
ORA-00312: online log 3 thread 1: '/T3/ORACLE/oradata/ORA9/redo03a.log'
看来当前日志成员是不允许删除的。
SQL>alter system switch logfile;
System altered.
1 1 5 104857600 2 NO CURRENT
557687 02-9月 -05
554601 02-9月 -05
3 1 4 104857600 2 YES ACTIVE
SQL> alter database add logfile member '/T3/ORACLE/oradata/ORA9/redo03a.log' to group 3;
GROUP# STATUS TYPE
---------- ------- ------
-----------------------------------------
--------------------------------------------------
3 INVALID ONLINE
看来还得切换一下日至
SQL>select * from v$logfile;
-----------------------------------------------
至此，大功告成…………….
只要日志组的member不是一个，出现前面的4种可能性是非常小的，即使出现了也有相应的恢复方法，所以不必惊慌；
如果memer多于1个，即使坏了其中的几个，也不会 影响数据库的正常启动，启动后，再进行相应的操作即可， 所以这个时候每天察看alert.log就显得非常重要了。
（1）：数据库非法关闭后丢失全部redo
（2）：丢失的redo文件是非当前的，或者说是不活动的。
（3）：丢失或者损坏的redo文件是当前的。
下面分别说明如下：
修改系统参数方法：
1、 插入数据
SQL>; commit;
2、 强行关闭
SQL>; shutdown abort
3、 手工模拟删除全部redo
4、 启动db
ORA-00313: open failed for members of log group 3 of thread 1
5、 尝试使用前3中方法中最简单的
SQL>; recover database until cancel;
ORA-00279: change 550174 generated at 09/02/2005 16:00:19 needed for thread 1
ORA-00289: suggestion : /T3/ORACLE/arch/1_1.dbf
ORA-00280: change 550174 for thread 1 is in sequence #1
Specify log: {<RET>;=suggested | filename | AUTO | CANCEL}
看来不行
6、 修改initsid.ora，加入一行
_allow_resetlogs_corruption=true
7、 启动with pfile
Total System Global Area 320308312 bytes
Fixed Size 730200 bytes
Database Buffers 33554432 bytes
SQL>; alter database open resetlogs;
8、 检验数据
SQL>; select * from test.test;
看到了吧，我们前面由于执行了SHUTDOWN ABORT,这时候对数据的修改还没有保存到数据文件中，虽然执行了COMMIT,这个时候还在联机日志中，等待CKPT触发DBWR写入DATAFILE,但是这个时候执行了SHUTDOWN ABORT,redo被删除后，里面的信息也就丢了，造成数据丢失。
9、 备份，去掉那个隐含参数。
大家都清楚，联机日志分为当前联机日志和非当前联机日志，非当前联机日志的损坏是比较简单的，一般通过clear命令就可以解决问题。
1、启动数据库，遇到ORA-00312 or ORA-00313错误，如
ORA-00312:online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
从这里我们知道日志组1的数据文件损坏了
从报警文件可以看到更详细的信息
2、查看V$log视图
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ---------- ------
1 1 YES INACTIVE
2 2 YES INACTIVE
3 3 NO CURRENT
可以知道，该组是非当前状态，而且已经归档。
3、用CLEAR命令重建该日志文件
SQL>alter database clear logfile group 1;
如果是该日志组还没有归档，则需要用
SQL>alter database clear unarchived logfile group 1;
4、打开数据库，重新备份数据库
SQL>alter database open;
说明：
1、如果损坏的是非当前的联机日志文件，一般只需要clear就可以重建该日志文件，但是如果该数据库处于归档状态但该日志还没有归档，就需要强行clear。
2、建议clear，特别是强行clear后作一次数据库的全备份。
3、此方法适用于归档与非归档数据库。
归档模式下当前日志的损坏有两种情况，
一、是数据库是正常关闭，日志文件中没有未决的事务需要实例恢复，当前日志组的损坏其实就是上文的实验1案例，首先从备份中恢复一个当前的redo文件，这也是冷备份时建议同时备份redo的原因。然后可以直接用alter database clear unarchived logfile group n来重建。最后open。
二、是日志组中有活动的事务，数据库需要媒体恢复，日志组需要用来同步，有两种补救办法：
A. 最好的办法就是通过不完全恢复，可以保证数据库的一致性，但是这种办法要求在归档方式下，并且有可用的备份。
B. 通过强制性恢复，但是可能导致数据库不一致。（如果数据库没有备份，又不在归档模式下，之能采取这种方法）
下面分别用来说明这两种恢复方法
1．1 通过备份来恢复
1、打开数据库，会遇到一个类似的错误
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件
2、查看V$log，发现是当前日志
---------- ---------- -------- ----------------
1 1 NO CURRENT
3 3 YES INACTIVE
3、发现clear不成功
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
ORA-01624: log 1 needed for crash recovery of thread 1
4、拷贝有效的数据库的全备份，并不完全恢复数据库
可以采用获取最近的SCN的办法用until scn恢复或用until cnacel恢复
recover database until cancel
先选择auto，尽量恢复可以利用的归档日志，然后重新
这次输入cancel，完成不完全恢复，也就是说恢复两次。
如：
SQL> recover database until cancel;
Auto
……
Cancel;
5、利用alter database open resetlogs打开数据库
1、这种办法恢复的数据库是一致的不完全恢复，会丢失当前联机日志中的事务数据
2、这种方法适合于归档数据库并且有可用的数据库全备份。
3、恢复成功之后，记得再做一次数据库的全备份。
4、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。
1.2 如果没有备份，进行强制性恢复
4、把数据库down掉
SQL>shutdown immediate
5、在init<sid>.ora中加入如下参数
_allow_resetlogs_corruption=TRUE
6、重新启动数据库,利用until cancel恢复
Cancel
如果出错，不再理会，发出
7、如果幸运，数据库可以open，数据库被打开后，马上执行一个full export
8、shutdown数据库,去掉_all_resetlogs_corrupt参数
9、重建库
10、import并完成恢复
11、建议执行一下ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;
1、该恢复方法是没有办法之后的恢复方法，一般情况下建议不要采用，因为该方法可能导致数据库的不一致
2、该方法也丢失数据，但是丢失的数据没有上一种方法的数据多，主要是未写入数据文件的已提交或未提交数据。
3、建议成功后严格执行以上的7到11步，完成数据库的检查与分析
4、全部完成后做一次数据库的全备份
5、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。
问题：
上面的第7步，如果不能打开数据库，oracle此时可能会报ORA-00600: 内部错误代码，参数: [2662],之类的错误，针对这个问题说明如下：
1：ORA-600 [2662] "Block SCN is ahead of Current SCN"，说明当前数据库的数据块的SCN早于当前的SCN，主要是和存储在UGA变量中的dependent SCN进行比较，如果当前的SCN小于它，数据库就会产生这个ORA-600 [2662]的错误了.
2：于是想到使用ADJUST_SCN事件来调整当前的SCN，使其大于dependent SCN.
3：此时我们可以通过Oracle的内部事件来调整SCN:
出现ORA-00600: 内部错误代码，参数: [2662],之类的错误可能会出现在打开数据库之前，也可能出现在通过用_allow_resetlogs_corruption=TRUE隐含参数打开数据库之后。
调整SCN有两种常用方法:
1.通过immediate trace name方式(在数据库Open状态下，即通过用_allow_resetlogs_corruption=TRUE隐含参数打开数据库之后报错600)
alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';
2.通过10015事件(在数据库无法打开，mount状态下)
alter session set events '10015 trace name adjust_scn level x';
注:level 1为增进SCN 10亿 (1 billion) (1024*1024*1024),通常Level 1已经足够。也可以根据实际情况适当调整。
打赏
<b></b>赞
<b></b>收藏
<b></b>评论
分享
微博
微信
举报
上一篇：ORACLE 11G DATA GUARD配置全过程
下一篇：ORACLE中表死锁的处理
![oracle中的start with connect by用法[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)