重做日志（redo log）相关总结

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE 检查点（checkpoint）

检查点是一个数据库事件，它存在的意义在于减少崩溃恢复时间（crash recovery time）。检查点事件由后台进程CKPT触发，当检查点发生时，CKPT进程会负责通知 DBWR进程将脏数据（dirty buffer）写出到数据文件上。CKPT进程的另一个职责是负责更新数据文件头部及控制文件上的检查点信息。

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

Crash and instance recovery involve two distinct operations: rolling forward the current, online datafiles by applying both committed and uncommitted transactions contained in online redo records, and then rolling back changes made in uncommitted transactions to their original state.

Undo blocks (whether in rollback segments or automatic undo tablespaces) record database actions that should be undone during certain database operations. In database recovery, the undo blocks roll back the effects of uncommitted transactions previously applied by the rolling forward phase..

这句话意思是 ：在之前的前滚阶段，产生了未提交的事务，在数据库恢复过程（回滚阶段）中，undo块回滚了这种效果 Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

 After the roll forward, any changes that were not committed must be undone. Oracle applies undo blocks to roll back uncommitted changes in data blocks that were either written before the failure or introduced by redo application during cache recovery. This process is called rolling back or transaction recovery.

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

 最常见的情况，数据库可能因为断电而crash，那么内存中修改过的、尚未写入数据文件的数据将会丢失。在下一次启动数据库，oracle可以通过重做（redo）日志进行事务前滚（roll forward），将数据库恢复到崩溃之前的状态，然后数据库可以打开提供使用，之后oracle可以将未提交的事务进行回滚（roll back）。

  而检查点（checkpoint）的存在就是为了缩短前滚（roll forawrd）的时间。当检查点发生时（此时的scn被称为checkpoint scn），oracle会通知dbwr进程把修改过的数据，也就是此checkpoint scn之前的脏数据（dirty data） 从buffer cache写入磁盘，当写入完成之后，ckpt进程则会相应更数据文件头部和控制文件，记录检查点信息，标识更改。

而tom大师在他的大作中这样描述

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

Many things can cause a checkpoint to occur, the most common event being a redo log switch. As we filled up log file 1 and switched to log file 2, Oracle initiated a checkpoint. At this point in time, DBWn started flushing to disk all of the dirty blocks that are protected by log file 1. Until DBWn flushes all of these blocks protected by that log file, Oracle cannot reuse it.So, at this point in time, processing was suspended in the database while DBWn hurriedly finished its checkpoint. Oracle gave all the processing power it could, to DBWn at that point in the hope it would finish faster.

redo 介绍

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

1：redo的功能主要通过3个组件来实现：redo log buffer、lgwr进程、redo log  file。同redo log buffer类似，redo log file也是循环使用的，oracle允许使用最少两个日志组。当一个日志文件写满以后，会切换到另外一个日志文件，这个过程称为 log switch 。 log switch会触发一个检查点（checkpoint），促使dbwr进程将buffer cache中的脏数据写出到数据文件中。在检查点完成之前，日志文件是不能够被重用的。

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

3：系统产生了多少redo日志

有两种方法

a：通过 v$mystat 和 v$statname 视图

 

SQL> create table t2 as select * from dba_tables;

Table created.

SQL> select a.value ,b.name from v$mystat a , v$statname b where a.statistic#=b.statistic# and b.name='redo size';

     VALUE NAME

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

    940832 redo size

SQL> insert into t2 select * from t2;

2781 rows created.

SQL>  select a.value ,b.name from v$mystat a , v$statname b where a.statistic#=b.statistic# and b.name='redo size';

     VALUE NAME

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

   1717252 redo size

SQL> select 1717252-940832 from dual;

1717252-940832

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

        776420

 

b：通过autotrace 功能

SQL> rollback;

 Rollback complete.

 SQL> set autotrace exp;

Usage: SET AUTOT[RACE] {OFF | ON | TRACE[ONLY]} [EXP[LAIN]] [STAT[ISTICS]]

SQL> set autotrace exp stat;

Usage: SET AUTOT[RACE] {OFF | ON | TRACE[ONLY]} [EXP[LAIN]] [STAT[ISTICS]]

SQL> set autotrace trace stat;

SQL> insert into t2 select * from t2;

2781 rows created.

 

Statistics

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

          1  recursive calls

        723  db block gets

        714  consistent gets

          0  physical reads

     759652  redo size

        680  bytes sent via SQL*Net to client

        603  bytes received via SQL*Net from client

          3  SQL*Net roundtrips to/from client

          1  sorts (memory)

          0  sorts (disk)

       2781  rows processed

 

如果数据库运行在归档模式下，归档日志的生成量从视图 v$archived_log 可以得到

以下是每天产生的日志量

 select trunc(completion_time),sum(M) from

 (select name,COMPLETION_TIME,blocks*block_size/1024/1024 M from  v$archived_log ) group by trunc(completion_time)   order by trunc(completion_time)

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

4：redo写的触发条件

a：每3秒超时（timeout）

b：阀值达到：redo log buffer 1/3满 、redo log buffer 具有1MB脏数据 

              换句话说，也就是lgwr将在 min(1M,1/3 log buffer size) 时触发

 

c：用户提交(commit)   ---用户提交过于频繁，会出现等待事件 log file sync

++++++++++++++++++++++++++++++++++++++++++++++++

log file sync 描述如下

When a user session commits, the session's redo information needs to be flushed to the redo logfile. The user session will post the LGWR to write the log buffer to the redo log file. When the LGWR has finished writing, it will post the user session.

++++++++++++++++++++++++++++++++++++

 

d：在dbwr写进程之前

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

5：redo log buffer大小的设置

 因为redo log buffer的写出操作非常频繁，所以过大的log buffer 设置通常没有必要，一般 3M 较为合理。当等待事件 log buffer space 比较明显时，可以增大 log buffer

当用户执行commit的时候，这个意味着oracle已经将此时间点之前的redo写入了重做日志文件中，这个日志写完之后，oracle可以释放用户去执行其他任务。comit的原则是，确保提交成功的数据不丢失。

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

6：日志的状态

 

可以从v$log中查看log的状态

 SQL> select group#,status,first_change#  from v$log;

     GROUP# STATUS           FIRST_CHANGE#

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

         1 INACTIVE               2283561

         2 INACTIVE               2310032

         3 CURRENT                2329537

 

最常见的四种状态

 

a) current：指当前的日志文件，它是活动的，正在被使用，在进行实crash恢复时current的日志文件是必须的。

b）active： 是活动的非当前日志，该日志可能已经完成归档也有可能没有归档，活动的日志文件文件在crash恢复时会被用到。active状态意味着检查点尚未完成，如果日志文件循环使用再次到达该文件，数据库将处于等待的停顿状态，此时在alert文件中，可以看到 checkpoint not complete的记录 。 该记录在 v$session_wait 中表现出等待事件为 log file switch (checkpoint incomplete)

checkpoint incomplete有多种可能原因

1) 日志文件过小，切换频繁

2) 日志组太少， 不能满足正常事务量的需要

3) 日志文件所在的磁盘I/O存在瓶颈，导致写出缓慢，阻塞数据库正常运行

4) 由于数据文件磁盘I/O瓶颈，DBWR写出过于缓慢

5) 由于事务量巨大，DBWR负荷过高

 

针对不同的原因，又可以从以下角度着手分析

 

1) 适当增加日志文件大小

2) 适当增加日志组

3) 使用更快速磁盘存储日志文件（如采用更高速磁盘；使用raid10而不是raid5等方式）

4) 改善磁盘I/O性能

5) 使用多个DBWR进程或使用异步I/O等

 

需要强调的是，这是一类严重的等待，它意味着数据库不能再产生日志，所有数据库修改操作将全部挂起。

 

c) inactive 是非活动日志组，该日志在实例恢复时候不再需要，但是在介质恢复时可能会用到。inactive状态的日志也可能没有被归档。如果数据库启动在归档模式，在未完成归档之前，日志文件也不允许被覆盖，这时活动进程会处于 log file switch (archiving needed)等待之中。

 

 

SQL> select GROUP#, SEQUENCE#,BYTES,ARCHIVED,STATUS,FIRST_CHANGE#  from v$log;

 GROUP#     SEQUENCE#   BYTES    MEMBERS ARCHIVED  STATUS      FIRST_CHANGE#

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

         1       127       52428800     1       NO     INACTIVE      2283561

         2       128       52428800     1       NO      INACTIVE      2310032

         3      129       52428800     1       NO       CURRENT       2329537

 

注意到此时所有日志组都没有完成归档（ARCHIVED字段为NO），所有的 DML事务都将挂起，用户处于log file switch (archiving needed)等待

出现这种情况一般是由于数据库异常造成的，可能是因为I/O缓慢，也可能是因为事务量过大，在特殊情况下，有可能是因为日志损坏。

 

d) unused 表示日志从未被写入，这类日志可能是刚被添加到数据库或者在resetlogs之后被重置。被使用后，状态会被改变。

=============================================================

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

有关checkpoint not complete的问题，在如下文档中有解释

NOTE:147468.1 Title: Checkpoint Tuning and Troubleshooting Guide

Sometimes, you can see in your alert.log file, the following corresponding

messages:

 

Thread 1 advanced to log sequence 248

Current log# 2 seq# 248 mem# 0: /prod1/oradata/logs/redologs02.log

Thread 1 cannot allocate new log, sequence 249

Checkpoint not complete

 

 

This message indicates that Oracle wants to reuse a redo log file, but the current checkpoint position is still in that log. In this case, Oracle must wait until the checkpoint position passes that log. Because the incremental checkpoint target never lags the current log tail by more than 90%

of the smallest log file size, this situation may be encountered if DBWR writes too slowly, or if a log switch happens before the log is completely full, or if log file sizes are too small.

When the database waits on checkpoints,redo generation is stopped until thelog switch is done.

 

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24862808/viewspace-735406/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24862808/viewspace-735406/