ITPub博客

首页 > 数据库 > Oracle > 【体系结构】与Checkpoint相关的问题解决思路

【体系结构】与Checkpoint相关的问题解决思路

原创 Oracle 作者:恩强Boy 时间:2021-02-02 17:18:16 0 删除 编辑

思路清晰

1.  什么是checkpoint (检查点)

2.  checkpoint 与性能影响

3.  checkpoint 相关的参数

4.  redolog checkpoint 的关系

5.  问题解决思路:cannot allocate new log ”和“ checkpoint not complete

1.  什么是checkpoint (检查点)

checkpoint 是一个数据库事件,它将内存中被修改的数据块写进磁盘中。它保证了 Oracle 事务修改的数据一致性。在 Oracle 中,将修改后的块写入磁盘的机制与事务提交的机制是不同步的。

checkpoint 有两个目的: 1 是保证数据的一致性; 2 是为了启用更快的数据库实例恢复。如何才能更快的恢复,因为检查点之前的所有数据库更改都已经写进了数据文件中,因此不需要再对这部分进行应用 redolog 。检查点必须确保缓存中所有更改的数据块都真正写入了相应的数据文件,以避免由于实例崩溃而导致的数据丢失。

Oracle 只在某些特定的条件下才会将脏数据写进磁盘中 :

- 进程必须扫描超过 db_block_buffer 参数的 1/4

- 每三秒一次

- 当发生 checkpoint

checkpoint 会在五种情况下发生:

- 日志切换时

- 当达到 LOG_CHECKPOINT_TIMEOUT 延迟时

- 当产生日志大小 = LOG_CHECKPOINT_INTERVAL*OS 块大小 )时

- 当执行 alter system switch logfile

- 当执行 alter system checkpoint

checkpoint 会发生以下事情:

- DBWR 进程会把所有在 buffer cache 中修改的数据块写进磁盘数据文件中

- checkpoint 进程会更新所有数据文件和控制文件的头,以指示最后一个 checkpoint 发生的时间戳 SCN

2.  checkpoint 与性能

检查点会给DBA 带来一个调优难题。频繁的 checkpoint 会使恢复更快,但是会导致数据库系统的性能下降。 DBA 应该如何解决这个问题?

根据数据库中数据文件的数量,checkpoint 可能是一个高度资源密集型的操作。因为在检查点期间所有的数据文件头都会被冻结,直到检查点结束。在检查点的频率方面有一个性能的权衡:更频繁的检查点可以在实例崩溃后更快地恢复数据库,这也是一些对计划外系统停机的容忍度非常低的客户会经常选择这个选项。然而,在许多情况下,频繁的检查点会导致性能的下降。

调优checkpoint 涉及到以下几个参数

- FAST_START_MTTR_TARGET

- LOG_CHECKPOINT_INTERVAL

- LOG_CHECKPOINT_TIMEOUT

- LOG_CHECKPOINTS_TO_ALERT

3.  checkpoint 相关的参数

1)  FAST_START_MTTR_TARGET

FAST_START_MTTR_TARGET 参数指定数据库执行单个实例崩溃恢复所需的秒数。增量检查点会根据内部统计自动调整检查点目标,以满足 FAST_START_MTTR_TARGET 的要求。

V$INSTANCE_RECOVERY 视图的 ESTIMATED_MTTR 选项显示了当前评估的平均恢复时间(MTTR ),即使 FAST_START_MTTR_TARGET 没有指定,也会显示该值。

V$INSTANCE_RECOVERY 视图的TARGET_MTTR 选项显示系统执行的有效的 MTTR 目标。

V$MTTR_TARGET_ADVICE 显示了当前工作负载在当前 MTTR 设置下的 I/O 数,以及在其他 MTTR 设置下当前工作负载可能导致的 I/O 数。这个视图会有助于我们评估运行时性能和设置 FAST_START_MTTR_TARGET 之间的平衡,以获得更好的恢复时间。

2)  LOG_CHECKPOINT_INTERVAL

LOG_CHECKPOINT_INTERVAL 参数指定增量检查点应该滞后于当前redolog 末尾的重做块的最大数量。如果指定了 FAST_START_MTTR_TARGET ,就不应该设置 LOG_CHECKPOINT_INTERVAL ,或者将其设置为0

LOG_CHECKPOINT_INTERVAL 会影响检查点发生的时间,这就意味着应该仔细注意该参数的设置。检查点频率是影响数据库从意外故障中恢复所需时间的因素之一。如果检查点时间间隔更长,意味着如果系统崩溃,数据库需要更多的时间来恢复。检查点时间间隔如果更短,意味着数据库将更快的恢复,但要以检查点操作期间增加的资源利用率作为代价。

3)  LOG_CHECKPOINT_TIMEOUT

LOG_CHECKPOINT_TIMEOUT 参数指定增量检查点目标应该滞后于当前日志末尾的最大秒数。换句话说,它指定了buffer cache 中的脏缓冲区可以保持多长时间。

Oracle 建议使用 LOG_CHECKPOINT_INTERVAL 来控制检查点间隔,而不是 LOG_CHECKPOINT_TIMEOUT LOG_CHECKPOINT_TIMEOUT 将在每 n 秒启动一个检查点,而不管事务是否繁忙。在事务量不同的情况下,这可能会导致不必要的检查点。

4)  LOG_CHECKPOINTS_TO_ALERT

LOG_CHECKPOINTS_TO_ALERT 允许我们将检查点记录在alert 文件中。这样做对于确定检查点是否按照预期的频率执行是很有用的。 Oracle 建议将此值设置为 TRUE ,因为消耗是可以忽略不计的,但是会产生很有用的 alert 信息。

4.  redolog 与检查点

每次redolog 切换都会发生一个检查点。如果一个检查点正在进行中,此时又发生 redolog 切换,那么就会覆盖当前的检查点。为了避免这种情况,就需要我们设置适当大小的 redolog ,以避免由于频繁的切换日志而导致不必要的检查点。因此, redolog 的大小应该配置得足够大。 Oracle 建议每 10-20 分钟切换一次日志,日志文件过小会增加检查点活动并降低性能。 Oracle 建议将所有 redolog 设置为相同的大小,并且每个线程至少设置两个日志组。我们可以通过告警日志来监视日志切换频率,和随后发生的检查点。

5.  cannot allocate new log checkpoint not complete

有时候我们可以在alert 日志中发现以下信息

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

这个信息表明Oracle 希望重用 redolog ,但当前的检查点位置仍然在该日志中。在这种情况下, Oracle 必须等待检查点位置通过该日志。这种情况下很可能遇到了 DBWR 写太慢,或者 redolog 写满之前发生了日志切换,或者日志文件太小,就会遇到这种情况。

 

 

---- end ----


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

请登录后发表评论 登录
全部评论
勤奋,专注和练习

注册时间:2018-04-03

  • 博文量
    77
  • 访问量
    143633