第四章:redo 日志

4.1作用和特征

作用:数据recovery

特征:

1)记录数据库的变化(DMLDDL)

2)用于数据块的recover

3)以组的方式管理redo file,最少两组redo,循环使用

4)和数据文件存放到不同的磁盘上,需读写速度快的磁盘(比如采用RAID10)

5)日志的block和数据文件的block不是一回事

spacer.gif

 

4.2日志组及切换

1)最少两组,最好每组有两个成员(多路复用),并存放到不同的磁盘(不同路径)上,大小形同,互相镜像

2)日志在组写满时将自动切换

①归档模式:将历史日志连续的进行保存。

②非归档:历史日志被覆盖

③切换产生checkpoint(考虑性能有延迟),通知dbwn写脏块 并且更新控制文件

3)在归档模式,日志进行归档,并把相关的信息写入controlfile

 

4.3 添加日志组和成员

1)三个重要视图

SQL> select * from v$log;

oracle 体系_第四章 redo日志_第1张图片

SQL> select * from v$logfile;

oracle 体系_第四章 redo日志_第2张图片

SQL> select name,sequence# from v$archived_log;


2)增加一个组group4,

SQL> alter database add logfile group 4 '/u01/oradata/prod/redo04.log' size 50m;

oracle 体系_第四章 redo日志_第3张图片

3)添加日志组的成员

为每个组增加一个member(一共是4个组)

先建好目录,准备放在/u01/disk2/prod/

[oracle@cuug ~]$ mkdir -p /u01/disk2/prod

SQL>alter database add logfile member

'/u01/disk2/prod/redo01b.log' to group 1,

'/u01/disk2/prod/redo02b.log' to group 2,

'/u01/disk2/prod/redo03b.log' to group 3,

'/u01/disk2/prod/redo04b.log' to group 4;

spacer.gif

STATUSINVALID,说明member还没有同步好。

SQL> alter system switch logfile;   至少做4次切换,消除invalid。这步很必要。

 

4.4 v$log视图的状态

STATUS列有四种状态:

 unused:   新添加的日志组,还没有使用

 inactive   日志组对应的脏块已经从data buffer写入到data file,可以覆盖

 active:   日志组对应的脏块还没有完全从data buffer写入到data file,含有实例恢复需要的信息,不能被覆盖

 current:   当前日志组对应的脏块还没有全部从data buffer写入到data file,含有实例恢复需要的信息,不能被覆盖

THREAD   线程在单实例的环境下,thread# 永远是1

SEQUENCE#   日志序列号。在日志切换时会递增

FIRST_CHANGE#   在每个日志组对应一个sequence号,其中首条日志条目的第一个的scn

 

4.5日志恢复(PPT-II-146-148)


4.5.1 inactive日志组损坏

假如日志组4损坏,状态inactive。解决很简单,重建日志组即可

SQL> alter database clear logfile group 4;   这里clear的意思是重建group4的文件。

4.5.2 current日志组丢失

本例日志组1状态是CURRENT状态的,现在模拟当前日志组损坏

[oracle@prod]$ rm /u01/oradata/prod/redo01.log

[oracle@prod]$ rm /u01/disk2/prod/redo01b.log

SQL> alter system switch logfile;   切换几次,触动它一下。

告警日志会记录有关信息

暂时好像没有什么问题发生,继续切换,当current 又转会到group1时,session死!

当前日志损坏的问题比较复杂,见上图可以分以下几种情况讨论

1)数据库没有崩溃

第一步,可以做一个完全检查点,将db buffer中的所有dirty buffer全部刷新到磁盘上。

SQL> alter system checkpoint;

第二步,尝试数据库在打开状态下进行不做归档的强制清除。

SQL> alter database clear unarchived logfile group n;

数据库此时为打开状态,这步若能成功,一定要做一个新的数据库全备,因为当前日志无法归档,归档日志sequence已无法保持连续性。全备的目的就是甩掉之前的归档日志。

2)数据库已经崩溃,只能做传统的基于日志的不完全恢复或使用闪回数据库。

SQL> recover database until cancel;

SQL> alter database open resetlogs;

3)如果之前没有可用的备份,或问题严重到任何方法都不能resetlogs打开数据库,为了抢救数据,考虑最后一招使用Oracle的隐含参数:_allow_resetlogs_corruption=TRUE

Oracle不推荐使用这个隐含参数

该参数的含义是:允许数据库在不致性的情况下强制打开数据库。_

在不一致状态下强行打开了数据库后,建议做一个逻辑全备。

4.5.3 active日志组损坏

做检查点切换,如成功,按照inactive损坏处理。否则,按current损坏处理。

 

4.6 使日志恢复到原来的配置

1)删除日志组

SQL> alter database drop logfile group 4;   状态是currentactive的组不能删除

2)删除成员

SQL> alter database drop logfile member '/u01/disk2/prod/redo01b.log';   状态是current组不能删除成员,需要切换一下。

3)清理物理日志文件。   删除物理文件需要rm