oracle 体系_第四章 redo日志

第四章：redo 日志

4.1作用和特征

作用：数据recovery

特征：

1）记录数据库的变化（DML、DDL)

2）用于数据块的recover

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

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

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

 

4.2日志组及切换

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

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

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

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

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

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

 

4.3 添加日志组和成员

1）三个重要视图

SQL> select * from v$log;

SQL> select * from v$logfile;

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

2）增加一个组group4,

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

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;

STATUS是INVALID，说明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;   状态是current和active的组不能删除

2）删除成员

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

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