天天看点

Oracle Redo Log和CheckPoint详解

Oracle Redo Log和CheckPoint详解

    • 1.Redo Log
      • 1.1.REDO LOG 的作用
      • 1.2.update事务流程
      • 1.3.LogBuffer写入Redo Log的条件:
      • 1.4.LGWR写的具体过程:
      • 1.5.redo log的6种状态
    • 2.CheckPoint
      • 2.1.CheckPoint主要作用:
      • 2.2.CheckPoint发生的条件:
      • 2.3.CheckPoint相关参数
      • 2.4.CheckPoint相关视图

1.Redo Log

1.1.REDO LOG 的作用

1).记录Oracle数据库的变化

2).避免数据提交后直接写入数据文件

3).实例恢复和介质恢复

1.2.update事务流程

  1. 找到被修改的数据块A_block,读入内存
  2. 申请一个UNDO块U_block,读入内存
  3. 将被修改的块A_block内容拷贝到UNDO块U_block
  4. 将上述UNDO的变化内容写入REDO(旧UNDO,新UNDO)
  5. A_block块的变化写入REDO(旧A,新A)
  6. A_block块被更新

1.3.LogBuffer写入Redo Log的条件:

关于logbuffer可参考ORACLE log_buffer

1).用户提交

2).有1/3重做日志缓冲区未被写入磁盘(可以通过修改_LOG_IO_SIZE参数来控制 )

3).有大于1M的重做日志缓冲区未被写入磁盘

4).每隔3 秒钟

5). DBWR 需要写入的数据的SCN大于LGWR记录的SCN,DBWR 触发LGWR写入。

1.4.LGWR写的具体过程:

1).先尝试获取redo writing latch,确保其他process不会继续触发lgwr(这里可能会产生log file sync等待事件)

2).获取redo allocation latch(public redo allocation latch),防止有新的change vector继续写入log buffer,造成LGWR无法确定应该写多少redo.

3).LGWR确定写的范围(从上次lgwr启动所写的最后一个日志块到这个时间点时的最后一个被使用的所有写满or未写满的日志块)此时前台process仍可以向这个范围内的redo block(buffer)写内容(从PGA写)所以lgwr不阻碍其它进程获得redo copy latch(即:不阻止其它进程向log buffer 中可用块中写change vector)

4).确定redo block(buffer)后生成新SCN号

5).LGWR释放redo allocation latch与redo writing latch

6).LGWR需要等待 其它进程对要写入日志文件的block的更新操作完成(pga-log buffer的操作),通过判断日志block(buffer)上的redo copy latch是否都释放。

7).将第4步scn号copy到要写入logfile的log buffer的块头里,然后触发物理的写操作,将这些待写日志块写入redo file

1.5.redo log的6种状态

CURRENT: The online redo log is active, that is, needed for instancerecovery, and it is the log to which the database is currently writing. The redo log can be open orclosed.

ACTIVE: The online redo log is active and required for instance recovery, but is not the log to which the database is currently writing. It may be in use for blockrecovery, and may or may not be archived.Once perform “alter system checkpoint”,the log will be change inactive.

INACTIVE: The log is no longer needed for instance recovery. It may be in use for media recovery,and may or may not be archived.

UNUSED: The online redo log has never been written to.

CLEARING: The log is being re-created as an empty log after an ALTER DATABASECLEAR LOGFILE statement. After the log is cleared, then the status changes to UNUSED.

CLEARING_CURRENT: Current log is being cleared of a closed thread. The log can stay in this status if there is some failure in the switch such as an I/O error writing thenew log header. . .

2.CheckPoint

checkpoint负责:通知DBWn进程;update数据文件头;update控制文件。

2.1.CheckPoint主要作用:

1).保证数据库的一致性,这是指将脏数据写入到硬盘,保证内存和硬盘上的数据一致;

2).缩短实例恢复的时间,实例恢复要把实例异常关闭前没有写出到硬盘的脏数据通过日志进行恢复。如果脏块过多,实例恢复的时间也会很长,检查点的发生可以减少脏块的数量,从而提高实例恢复的时间。

2.2.CheckPoint发生的条件:

1).当发生日志组切换的时候。

2).当符合LOG_CHECKPOINT_TIMEOUT,LOG_CHECKPOINT_INTERVAL,fast_start_io_target,fast_start_mttr_target参数设置的时候。

3).当运行ALTER SYSTEM SWITCH LOGFILE的时候。

4).当运行ALTER SYSTEM CHECKPOINT的时候。

5).当运行alter tablespace XXX begin backup,end backup的时候。

6).当运行alter tablespace ,datafile offline的时候。

7).shutdown时

8).ckpt进程每3s起来一次记录checkpoint的进度到控制文件中

当修改redo日志组时,使用ALTER SYSTEM SWITCH LOGFILE切换当前实例的日志组,会遇到日志组从current变成active后,迟迟不变成inactive。

此时可用ALTER SYSTEM CHECKPOINT触发CheckPoint,则所有非current状态日志组状态均变为inactive,可以进行删除操作。

2.3.CheckPoint相关参数

log_checkpoint_interval

设定两次checkpoint之间重做日志块(重做日志块和系统数据块是一样的)数,当重做日志块数量达到设定值的时候将触发checkpoint。

log_checkpoint_timeout

设定两次checkpoint之间的间隔时间,当超时值达到时增量checkpoint将被触发。Oracle建议不用这个参数来控制,因为事务(transaction)大小不是按时间等量分布的。将此值设置成0时将禁用此项设置。

fast_start_io_target

因为log_checkpoint_interval主要看的时候重做日志块的数量,并不能反应buffer cache中脏数据块的修改,因此Oracle又引入了这个参数来实现当脏数据块达到一定数量的时候触发checkpoint,不过此参数实际上控制的是恢复时所需IO的数量。

fast_start_mttr_target

此参数是在9i中引入用来代替前面的三个参数的,它定义了数据块崩溃后所需要的实例恢复的时间,Oracle在实际上内在的解释成两个参数:fast_start_io_target和

2.4.CheckPoint相关视图