RedoLog和Checkpointnotcomplete

2024-05-29 22:18
文章标签 redolog checkpointnotcomplete

本文主要是介绍RedoLog和Checkpointnotcomplete，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

原 Redo Log 和Checkpoint not completehttps://blog.csdn.net/tianlesoftware/article/details/4908066版权声明： https://blog.csdn.net/tianlesoftware/article/details/4908066
    首先我们来看下 alertSID.log 日志：
  Mon Nov 30 17:31:54 2009
Thread 1 advanced to log sequence 14214 (LGWR switch)
  Current log# 3 seq# 14214 mem# 0: /u03/oradata/newccs/redo03.log
Mon Nov 30 17:34:29 2009
Thread 1 advanced to log sequence 14215 (LGWR switch)
  Current log# 1 seq# 14215 mem# 0: /u03/oradata/newccs/redo01.log
Mon Nov 30 17:35:54 2009
Thread 1 cannot allocate new log, sequence 14216
Checkpoint not complete
  Current log# 1 seq# 14215 mem# 0: /u03/oradata/newccs/redo01.log
Mon Nov 30 17:35:55 2009
Thread 1 advanced to log sequence 14216 (LGWR switch)
  Current log# 2 seq# 14216 mem# 0: /u03/oradata/newccs/redo02.log
Mon Nov 30 17:40:25 2009
Thread 1 advanced to log sequence 14217 (LGWR switch)
  Current log# 3 seq# 14217 mem# 0: /u03/oradata/newccs/redo03.log
Mon Nov 30 17:44:22 2009
Thread 1 advanced to log sequence 14218 (LGWR switch)
  Current log# 1 seq# 14218 mem# 0: /u03/oradata/newccs/redo01.log
    我们先来分析下它的原因和后果：
当我们进行redo 切换的时候，会触发checkpoint 事件。 触发该事件有5个条件。 下文有说明。 Checkpoint做的事情之一是触发DBWn把buffer cache中的Dirty cache磁盘。另外就是把最近的系统的SCN更新到datafile header和control file（每一个事务都有一个SCN），做第一件事的目的是为了减少由于系统突然宕机而需要的恢复时间，做第二件事实为了保证数据库的一致性。
              Checkpoint will flush dirty block to datafile, 从而触发DBWn书写dirty buffer，等到redo log覆盖的dirty block全部被写入datafile后才能使用redo log（循环使用），如果DBWn写入过慢，LGWR必须等待DBWn完成，则这时会出现“checkpoint not completed！”。 所以当出现checkpoint  not competed的时候，还会伴随cannot allocate new log的错误。
              如果遇到这个问题，可以增加日志组和增大日志文件，当然也可以修改 checkpoint参数使得检查点变频繁一些。
       在出现这个错误的时候，数据库是短暂hang住的，等待checkpoint的完成。 在hang住的时候，没有日志产生。
    Tom 同学对这个问题的解释如下：
  the infamous "checkpoint not complete, cannot allocate new log" message.
  this occurrs when Oracle attempts to reuse a log file but the checkpoint that would flush
the blocks that may have redo in this log file has not yet completed -- we must wait
until that checkpoint completes before we can reuse that file -- thats when this message is printed.  during this time (when we cannot allocate a new log) processing is suspended in the database while the checkpoint is made to complete ASAP.
-- 我们必须等待checkpoint 的完成， 在这个过程中， 数据库是短暂的hang住的。
  The major way to relieve this is to have sufficient log to carry you through peak times.  that way, we can complete the  checkpoint while you are not busy.  also make sure your checkpoints happen as fast as they can (eg: enable ASYNC IO or configure >1 DBWR if ansyc IO cannot be used, make sure disks are not contending with other apps and so on)
  Another way is to make the log files smaller, hence increasing the frequency with which we checkpoint (log checkpoint interval and other init.ora parameters achieve the same effect btw).
      这个主题使DBA能对checkpoint和checkpoint优化的参数有一个较好的理解：
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT
  它也解释了怎样解释和处理出现在ALERT<sid>.LOG file中的checkpoint的错误"'Checkpoint not Complete' and 'Cannot Allocate New Log"。
  什么是checkpoint
Checkpoint是为了内存中已经被修改的数据块与磁盘数据文件同步的一种数据库事件。它提供了一种保持事务提交以后数据一致的手段。往Oracle磁盘写脏数据的机制与事务提交不是同步的。
  checkpoint有两个目的：
1、确保数据一致性。
2、使数据库能快速地恢复。
  怎样快速恢复

因为数据库会把所有的改变都在数据文件上设置checkpoint并一直增加，它不需要请求checkpoint之前的重做日志，Checkpoint能保证所有在缓存区的数据写到相应的数据文件，防止因为意外的实例失败导致的数据丢失。
  Oracle写这个脏数据只在一定的条件下：
1、DBWR 超时，大约3秒时间
2、系统中没有多的空缓冲区来存放数据
3、CKPT进程(产生新的checkpoint） 触发DBWR。
  一个checkpoint有5中事件类型：
1、每次重做日志的切换；
2、LOG_CHECKPOINT_TIMEOUT 这个延迟参数的到达；
3、相应字节(LOG_CHECKPOINT_INTERVAL* size of IO OS blocks)被写到当前的重做日志；
4、ALTER SYSTEM SWITCH LOGFILE 这个命令会直接导致checkpoint发生
5、ALTER SYSTEM CHECKPOINT
  Checkpoint期间会有下面进程发生：
1. DBWR写所有脏数据到数据文件；
2. LGWR更新控制文件和数据文件的SCN。
  Checkpoints和优化：
Checkpoints是一个数据库优化的难点。频繁的Checkpoints可以实现快速的恢复，但也会使性能下降。怎样处理这个问题呢？
依赖于数据库数据文件的数量，一个Checkpoint可能是高速的运行。因为所有的数据文件在Checkpoint期间都会被冻结。更频繁的Checkpoints可以快速恢复数据库。这也客户对不按规定系统宕机的容忍的原因。然而，在一些特殊情况下，频繁的Checkpoints也不能保证可以快速恢复。我们假设数据库在95%的时间内是正常运行，5%由于实例失败导致不可用，要求恢复。对大多数客户而言，他们更希望调整95%的性能而不是5%的宕机时间。这个假设表明，性能是摆在第一位的，所以我门的目标就是在优化期间减少Checkpoints的频繁度。
  优化Checkpoints包括4个关键的初始化参数：

- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
 - LOG_CHECKPOINTS_TO_ALERT
  详细介绍每个参数：

FAST_START_MTTR_TARGET：
Oracle9i以来FAST_START_MTTR_TARGET 参数是调整checkpoint的首选的方法。FAST_START_MTTR_TARGET 可以指定单实例恢复需要的秒数。基于内部的统计，增长的checkpoint会自动调整的checkpint的目标以满足FAST_START_MTTR_TARGET 的需求。
V$INSTANCE_RECOVERY.ESTIMATED_MTTR 显示当前估计需要恢复的秒数。这个值会被显示即使FAST_START_MTTR_TARGET 没有被指定。
V$INSTANCE_RECOVERY.TARGET_MTTR 表明在短时间内MTTR的目标。
V$MTTR_TARGET_ADVICE 显示这个当前MTTR设置的工作量产生的I/O数量和其他I/O。这个视图帮助用户评定这个在优化和恢复之前的平衡。
  LOG_CHECKPOINT_INTERVAL：
LOG_CHECKPOINT_INTERVAL 参数指定这个最大的重做块的间隔数目。如果FAST_START_MTTR_TARGET被指定，LOG_CHECKPOINT_INTERVAL不能被设置为0。
在大多数Unix系统的OS块大小是512字节。设置LOG_CHECKPOINT_INTERVAL=10000意味着这个增长的checkpoint不能追加到当前日志，因为多于5M。如果你的重做日志是20M，你将发出4个checkpoint对每个重做日志。

LOG_CHECKPOINT_INTERVAL 会发生影响当一个checkpoint发生时，小心设置这个参数，保持它随着重做日志文件大小变化而变化。checkpoint频繁是这个影响数据库恢复的原因之一。短的checkpoint间隔意味数据库将快速恢复，也增加了资源的利用。这个参数也影响数据库向前回滚的时间。实际的恢复时间是基于这个时间，当然还有失败的类型和需要归档日志的数量。
    LOG_CHECKPOINT_TIMEOUT：
这个参数指定checkpoint发出的时间间隔。换句话说，它指定一次脏数据多少时间写出一次。checkpoint频率会影响这个数据库恢复的时间。长时间的间隔会要求数据库恢复要求更久。Oracle建议用LOG_CHECKPOINT_interval去控制checkpoint而不用LOG_CHECKPOINT_TIMEOUT，LOG_CHECKPOINT_TIMEOUT每n秒发一次checkpoint，不顾事务提交的频率。这可能会导致一些没有必要的checkpoint在事务已经变化的情况下。不必要的checkpoint必须被避免。还有一个容易误解的地方：LOG_CHECKPOINT_TIMEOUT 会间隔性地发出log switch。而Log switch会触发一个checkpoint，但checkpoint不会导致一个log switch。唯一手工方式alter system switch logfile或者重新设置redo logs大小可以导致频繁switch。
SQL> alter system set log_checkpoint_timeout=300;[单位是秒] 
  log_checkpoint_to_alert：
设置为真,可以在告警日志中观察到增量检查点的触发。
SQL> alter system set log_checkpoints_to_alert=true; 
  对于优化和恢复, 在线重做日志的大小是关键的。
  修改Redo log 大小的操作方法：
查看当前日志组状态：
SQL> select group#,sequence#,bytes,members,status from v$log;
      GROUP#  SEQUENCE#  BYTES    MEMBERS STATUS
    ---------- ----------    ----------    ---------- ----------------
         1      14230   52428800          1    ACTIVE
         2      14231   52428800          1    CURRENT
         3      14229   52428800          1    INACTIVE
  CURRENT: 表示是当前的日志。
INACTIVE：脏数据已经写入数据块。该状态可以drop。
ACTIVE： 脏数据还没有写入数据块。
  查看当前日志组成员：
SQL> select member from v$logfile;
  MEMBER
--------------------------------------------------------------------------------
/u03/oradata/newccs/redo03.log
/u03/oradata/newccs/redo02.log
/u03/oradata/newccs/redo01.log
    添加online redo log组：
SQL> alter database add logfile group 4 ('/u03/oradata/newccs/redo04.log') size 100m reuse;
SQL> alter database add logfile group 5 ('/u03/oradata/newccs/redo05.log') size 100m reuse;
SQL> alter database add logfile group 6 ('/u03/oradata/newccs/redo06.log') size 100m reuse;
    切换归档日志：
SQL> alter system switch logfile;
    查看归档文件的状态，因为只有Inactive的我们才可以drop，它的数据块已经写入了数据块。如果是Active状态，表示这里的脏数据还没有写入写入数据库，手工加个全局检查点，督促CKPT马上唤醒DBWR写入脏数据

SQL>alter system checkpoint;
SQL> select group#,sequence#,bytes,members,status from v$log;
    GROUP#  SEQUENCE#  BYTES    MEMBERS STATUS
    ---------- ----------    ----------    ---------- ----------------
         1      14230   52428800          1    ACTIVE
         2      14231   52428800          1    ACTIVE
         3      14229   52428800          1    INACTIVE
   4      14229   52428800          1    CURRENT
 5      14229   52428800          1    UNUSED
   6      14229   52428800          1    UNUSED
  因为5，6 我们还没有用，所以显示为UNUSED
  删除redo log组：
SQL> alter database drop logfile group 1;
Database altered.
或者：
SQL> alter database drop logfile '/u03/oradata/newccs/redo01.log';
  在添加redo log group 1. 
SQL> alter database add logfile group 1 ('/u03/oradata/newccs/redo01.log') size 100m reuse;
  通过删除在添加，达到对redo log group 的resize. 
  注意两点
1. 单纯加redo log group单个文件的大小没有作用，同一个group里，文件大小都是一致的。

2. 如果是归档模式的话，确保已经自动归档，如果手动归档的话，需要在alter system switch logfile锁死的时候，用alter system log current 来手动归档。或者通过alter system archive log start打开自动归档。否则的话，当redo log group切换完整个groups的时候，会一直等待状态(******). 
  3. 《Oracle DBA必备技能详解》（Robert G.Freeman）,上面建议redo log 最好是15分钟切换一次
 https://img-blog.csdnimg.cn/20190217105710569.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEwNzgxNDE=,size_16,color_FFFFFF,t_70《算法导论 第三版英文版》_高清中文版.pdf
https://pan.baidu.com/s/17D1kXU6dLdU0YwHM2cvNMw
《深度学习入门：基于Python的理论与实现》_高清中文版.pdf
https://pan.baidu.com/s/1IeVs35f3gX5r6eAdiRQw4A
《深入浅出数据分析》_高清中文版.pdf
https://pan.baidu.com/s/1GV-QNbtmjZqumDkk8s7z5w
《Python编程：从入门到实践》_高清中文版.pdf
https://pan.baidu.com/s/1GUNSg4mdpeOf1LC_MjXunQ
《Python科学计算》_高清中文版.pdf
https://pan.baidu.com/s/1-hDKhK-7rDDFll_UFpKmpw

这篇关于RedoLog和Checkpointnotcomplete的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1014783。

相关文章

MySQL日志——redolog

MySQL日志——redolog

redo log（重做日志） 为什么需要redo log？ 在mysql提交一个事务后，这个事务所作的数据修改并不会直接保存到磁盘文件中，而是先保存在buffer pool缓冲区中，在需要读取数据时，先从缓冲区中找，没找到再去磁盘找，加之每次提交事务都将数据写入磁盘的效率低下，所以引入了buffer pool缓冲区 也正是因为一个事务的提交并不会立即由磁盘进行持久化，此时mysql故障就会有
阅读更多...
binlog和redolog有什么区别

binlog和redolog有什么区别

在数据库管理系统中，binlog（binary log）和 redolog（redo log）是两种重要的日志机制，它们在数据持久性和故障恢复方面扮演着关键角色。虽然它们都用于记录数据库的变化，但它们的目的和使用方式有所不同。下面详细解释它们之间的区别： Binlog（Binary Log） 1. 主要功能： 数据复制和同步：binlog 主要用于主从复制（replication），使得从库
阅读更多...
MySQL事务中的BinLog与redolog与undolog

MySQL事务中的BinLog与redolog与undolog

文章目录 1.redo log2.undo log3.binlog和事务日志的先后顺序及group commit4.总结 1.redo log redo log和二进制日志的区别 redo log不是二进制日志。 虽然二进制日志中也记录了innodb表的很多操作，也能实现重做的功能，但是它们之间有很大区别。二进制日志是在存储引擎的上层产生的，不管是什么存储引擎，对数据库进行的
阅读更多...
如何解析MySQL中的redolog日志？

如何解析MySQL中的redolog日志？

解析MySQL中的redolog日志比解析binlog更为复杂，因为redolog是InnoDB存储引擎特有的，以物理格式记录数据库的更改，主要用于恢复未提交的事务和加速数据恢复。由于其物理和二进制的特性，redolog没有直接可读的SQL语句或简单的解析工具如mysqlbinlog。 然而，有一些高级的方法和工具可以间接地帮助你理解redolog的内容： 1. InnoDB的Crash Re
阅读更多...
使用logminer做redolog的分析（做在线日志分析）

使用logminer做redolog的分析（做在线日志分析）

1、 数据库的参数文件中做以下设置参数添加 添加参数： log_archive_start=true log_archive_format=%S.arc log_archive_dest=/home/oracle/arch UTL_FILE_DIR=/u02/oralog 写入到spfile中： SQL> create spfile from pfile='/home/
阅读更多...
数据库中的binlog、redolog、undolog的区别

数据库中的binlog、redolog、undolog的区别

binlog二进制日志是mysql-server层的，主要是做主从复制，时间点恢复使用 redo log重做日志是InnoDB存储引擎层的，用来保证事务安全 undo log回滚日志保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。select如果没有特定加锁的话就是快照读，用到了undolog，而insert delete和updat
阅读更多...
MySQL：三大日志（binlog、redolog、undolog）

MySQL：三大日志（binlog、redolog、undolog）

再了解三个日志前我们先了解一下MySQL的两层架构： Server 层负责建立连接、分析和执行 SQL。MySQL 大多数的核心功能模块都在这实现，主要包括连接器，查询缓存、解析器、预处理器、优化器、执行器等。另外，所有的内置函数和所有跨存储引擎的功能都在 Server 层实现。存储引擎层负责数据的存储和提取。支持 InnoDB、MyISAM、Memory 等多个存储引擎，不同的存储引擎共用一个
阅读更多...
binlog、redolog、undolog的区别

binlog、redolog、undolog的区别

前言： 在MYSQL数据库中，binlog、redolog、undolog都是数据库日志类型文件。 binlog：主要用于数据库的数据备份，崩溃恢复和数据复制等操作。mysql主从复制 redolog：用来做恢复，事务持久性 undolog：用来做回滚 Mysql中 redolog和undolog只能适用于InnoDB，因为要支持事务。而binlog可以支持所有存储引擎。 binlog
阅读更多...
Mysql日志binlog、redolog、undolog

Mysql日志binlog、redolog、undolog

Mysql有多种日志，承担着不同的功能。 BinLog高可用的基石 Binlog是Mysql的server层记录的日志，包含表结构和数据的变更。Binlog有两个常用的作用，一个是用作数据库恢复，通过数据库快照和binlog，我们可以把数据库恢复到任意时刻。另一个是用于数据库复制，通过将binlog传给其他数据库副本，然后再执行binlog中的sql实现数据的同步，构建出一套高可用的数据库服务
阅读更多...
mysql-binlog，redolog 和 undolog区别

mysql-binlog，redolog 和 undolog区别

binlog MySQL的binlog（二进制日志 或 归档日志）是一种记录数据库的更改操作的日志。它包含了对数据库进行的插入、更新和删除操作的详细信息。binlog是以二进制格式存储，可以用于恢复数据库、数据复制和数据同步等操作。具体来说，binlog记录了每个更改操作的SQL语句或数据修改内容，也被称为归档日志。 binlog 用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2