Oracle redo log recovery

Redolog状态分为unused,inactive,active和current几种状态.其中前2种状态的文件坏掉,不会影响数据库已经提交的数据.

当active和current的redo log出现损坏,意味着已经commit的事务无法完成check point(磁盘同步);

或者需要rollback的事务,也无法完成回滚.Active和current的redo log坏掉,意味着此时数据库文件可能出现不一致.

1, 什么时候checkpoint?

a,alter system switch logfile;

b,alter system checkpoint;

c,热备表空间ALTER TABLESPACE TS_NAME BEGIN BACKUP/END BACKUP

d,alter database/tablespace read only;

e,shutdown数据库

2, check point会做什么?

a,同步SCN到数据文件头,控制文件;

b,通知dbwr对data buffer的脏数据进行同步到磁盘.

3, redo log损坏的几种情况?

3.1 数据库正常关闭状态下redo损坏.

a,数据进行正常关闭,inactive状态的redo
log文件都已经完成归档.

例如:redo01.log丢失

ｓｅleｃｔ　＊　ｆｒｏｍ　ｖ＄ｌｏｇ　ｏｒｄｅｒ　ｂｙ　ｆｉｒｓｔ_ｔｉｍｅ；

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME

------ -------- ---------- ---------- ---------- --- ---------------- ------------- -------------------

1 1 2 52428800 1 YES INACTIVE 7295637 2012-06-16 10:01:07

2 1 3 52428800 1 YES INACTIVE 7303922 2012-06-16 10:50:41

4 1 4 52428800 1 YES INACTIVE 7304107 2012-06-16 10:55:10

3 1 5 52428800 1 NO CURRENT 7305791 2012-06-16 11:20:32


ａｌｔｅｒ　ｄａｔｂａｓｅ　ｃｌｅａｒ　ｌｏｇｆｉｌｅ　ｇｒｏｕｐ　１；

b,数据进行正常关闭,current状态的redo log文件完成checkpoint,但没有归档.

Sat Jun 16 16:04:54 2012
Thread 1 opened at log sequence 7
Current log# 2 seq# 7 mem# 0: /u01/app/oracle/oradata/hdb/redo02.log
Sat Jun 16 16:04:59 2012
Completed: ALTER DATABASE OPEN
开启数据库,确认redo02.log是current状态的redo log.

2012-06-16 16:07:52 HR @ hdb>insert into T_20120616_001 values(3,'sequnce#7','b3','c3');
1 row created.
2012-06-16 16:07:53 HR @ hdb>commit;
插入数据,此时current状态的redo log为redo02.log,sequence# 7

Sat Jun 16 16:09:18 2012
Shutting down instance: further logons disabled
EMN0 started with pid=25, OS id=27230
此时删除redo02.log

Sat Jun 16 16:14:01 2012
Errors in file /u01/app/oracle/admin/hdb/bdump/hdb_lgwr_27381.trc:
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/hdb/redo02.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
此时无法启动数据库

解决方法:

ｓｔａｒｔｕｐ　ｍｏｕｎｔ；

ｒｅｃｏｖｅｒ　ｄａｔａｂａｓｅ ｕｎｔｉｌ　ｃａｎｃｅｌ；

ａｌｔｅｒ　ｄａｔａｂａｓｅ　ｏｐｅｎ　ｒｅｓｅｔｌｏｇｓ；　　

分析:由于该current状态的日志是正常关闭之后丢掉的,内存中的data buffer已经被同步；此时问题就是打开数据库时，

没有办法进行一致性确认，只需要对redo log进行resetlogs即可，但在resetlogs之前，需要进行不完全恢复．恢复之后

数据库数据没有丢失，最后插入的一行数据，虽然redo log文件为current，但数据已经同步到磁盘，未丢失．

c,正常关闭的数据库没有active的状态,因为checkpoint执行后,active redo变成inactive.

3.2 数据库运行状态时redo损坏.

a,inactive状态的redo丢失;

(1),inactive且已经完成归档,恢复时只需执行

ａｌｔｅｒ　ｄａｔａｂａｓｅ　ｃｌｅａｒ　ｌｏｇｆｉｌｅ ｇｒｏｕｐ　２；

2012-06-16 20:09:33 SYS @ hdb>select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME

------ ---------- ---------- ---------- ---------- --- ---------------- ------------- -------------------

1 1 2 52428800 1 NO CURRENT 7324031 2012-06-16 20:00:11

4 1 0 52428800 1 YES UNUSED 0

3 1 0 52428800 1 YES UNUSED 0

2 1 1 52428800 1 YES INACTIVE 7309824 2012-06-16 16:44:02

(2),inactive但没有完成归档,恢复时只需执行如下命令。因为归档缺失，建议对数据库进行一次全备份。

ａｌｔｅｒ　ｄａｔａｂａｓｅ　ｃｌｅａｒ
ｕｎａｒｃｈｉｖｅｄ　ｌｏｇｆｉｌｅ　ｇｒｏｕｐ　２；

b,active/current状态的redo丢失.

(1),active且已经完成归档,恢复时只需执行

ａｌｔｅｒ　ｄａｔａｂａｓｅ　ｃｌｅａｒ　ｌｏｇｆｉｌｅ ｇｒｏｕｐ　２；

此时关闭数据库,则active状态会变成inactive,由于其已归档,所以可以清除掉redo logfile,否则需要不完全恢复.

2012-06-16 20:01:13 SYS @ hdb>/

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME

------ ---------- ---------- ---------- ---------- --- ---------------- ------------- -------------------

1 1 2 52428800 1 NO CURRENT 7324031 2012-06-16 20:00:11

2 1 1 52428800 1 YES ACTIVE 7309824 2012-06-16 16:44:02

3 1 0 52428800 1 YES UNUSED 0

4 1 0 52428800 1 YES UNUSED 0

(2),active但没有完成归档,恢复时需要执行

ｓｔａｒｔｕｐ　ｍｏｕｎｔ；

ｒｅｃｏｖｅｒ　ｄａｔａｂａｓｅ ｕｎｔｉｌ　ｃａｎｃｅｌ；

ａｌｔｅｒ　ｄａｔａｂａｓｅ　ｏｐｅｎ　ｒｅｓｅｔｌｏｇｓ；　　

此时,如果能够正常关闭,则会进行checkpoint,并完成磁盘数据同步,不会有数据丢失;否则会出现数据丢失.

(3),current恢复时需要执行

ｓｔａｒｔｕｐ　ｍｏｕｎｔ；

ｒｅｃｏｖｅｒ　ｄａｔａｂａｓｅ ｕｎｔｉｌ　ｃａｎｃｅｌ；

ａｌｔｅｒ　ｄａｔａｂａｓｅ　ｏｐｅｎ　ｒｅｓｅｔｌｏｇｓ；　

如果此时删除了current redo log之后能够插入数据,并且完成了checkpoint磁盘同步,不完全恢复后数据不会丢失;

否则该不完全恢复后会有数据丢失.

4, 关于Linux下rm删除current redo文件之后,数据库能够继续正常读写的测试,可以看网友测试.
http://chinapkw.iteye.com/blog/524475
rm并不能真正模拟文件的损坏,请注意这一点.