检查点（Checkpoint）优化及故障排除指南 (文档 ID 1526118.1).pdf

让世界为你转身

125

5页

1次

2024-12-15

25墨值下载

检查点（Checkpoint）优化及故障排除指南 (文档 ID 1526118.1)

适用于:

Oracle Database Exadata Express Cloud Service - 版本 N/A 和更高版本

Oracle Database Cloud Service - 版本 N/A 和更高版本

Oracle Database - Enterprise Edition

Oracle Database Cloud Schema Service - 版本 N/A 和更高版本

Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - 版本 N/A 和更高版本

本文档所含信息适用于所有平台

用途

本文档旨在使数据库管理员更好地了解增量检查点（

Checkpoint），并对检查点（Checkpoint）优化所用的下列四个初

始化参数进行了描述：

- FAST_START_MTTR_TARGET

- LOG_CHECKPOINT_INTERVAL

- LOG_CHECKPOINT_TIMEOUT

- LOG_CHECKPOINTS_TO_ALERT

此外，本文档还介绍了如何解释和处理检查点错误：

ALERT<sid>.LOG 文件中报告的“Checkpoint not Complete（检

查点未完成

）”和“Cannot Allocate New Log（无法分配新日志）”。

适用范围

详细信息

1. 什么是检查点？

2. 检查点和性能

3. 与增量检查点相关的参数

4. Redo（

重做）日志和检查点

5. 了解检查点错误消息（“Cannot allocate new log”和“Checkpoint not complete”）

6. Oracle 版本信息

7. 使用 Statspack 确定检查点问题

检查点优化和错误处理

1. 什么是检查点？

检查点是一种将内存中的已修改数据块与磁盘上的数据文件进行同步的数据库事件。通过Checkpoint

Oracle 确保了被 transaction 修改过数据可以被同步至磁盘。Oracle transaction 提交的时候不会将已修

改数据块同步写入磁盘上。

检查点有两个用途：(1) 确保数据一致性，和 (2) 实现更快的数据库恢复。如何更快地恢复？由于直至检查

点生成时所有的数据库更改均已记录在数据文件中，因此无需再应用先于检查点的 redo 日志条目。检查点

必须确保高速缓存中所有已修改的缓冲数据均已切实写入到相应的数据文件中，以避免在发生崩溃（实例

或磁盘故障）时可能会出现的数据丢失。

文档 1526118.1 https://support.oracle.com/epmos/faces/DocumentDisplay?...

第1页共5页

2024/12/15 19:43

Oracle 只有在特定条件下才会将脏缓存写入磁盘：

- shadow process 需要扫描的数据块个数超过 db_block_buffers 参数的四分之一。

- 每三秒钟。

- 生成一个检查点时。

检查点通过五种类型的事件来实现：

- 每次切换 redo 日志文件时。

- 达到 LOG_CHECKPOINT_TIMEOUT 的延迟时。

- 当前 redo 日志文件中已存在了大小为（LOG_CHECKPOINT_INTERVAL* OS块的大小（bytes））的

数据。

- 直接由 ALTER SYSTEM SWITCH LOGFILE 命令实现。

- 直接使用 ALTER SYSTEM CHECKPOINT 命令实现。

在检查点期间会发生以下操作：

- DBWR 将缓冲区缓存中所有已修改的数据库块写回到数据文件中，

- 检查点进程 (ckpt) 更新所有数据文件的文件头，以反映上一个检查点发生的时间 (SCN)

2. 检查点和性能

检查点的优化常常会使数据库管理员左右为难。频繁的检查点会实现更快的数据库恢复，但也会导致数据

库性能降低。那么，DBA 如何解决这一问题呢？

根据数据库中的数据文件数量，检查点将会是一种高度占用资源的操作，因为所有数据文件头在检查点期

间都会被冻结。关于检查点的频率设置，需要对性能进行权衡。检查点频率越高，就能在数据库崩溃后更

快地实现恢复。这也是为什么一些不太能忍受意外系统停机的客户现场常常会选择此选项的原因。但是，

在很多情况下，频繁的检查点可能会导致性能降低，这使得上述观点并不能完全站稳脚跟。我们假设数据

库已启动，且有 95% 的时间处于运行状态，剩下 5% 未运行时间是由于出现偶发的实例崩溃或硬件故障，

需要进行数据库恢复。对于大多数的客户现场而言，优化 95% 的性能相比于极少的 5% 停机时间要更具意

义。

本文档假设性能是您的首要考虑事项，并由此给出相应的建议。因此，您的目标是通过优化尽量减少检查

点的频率。

优化检查点涉及到下面四个关键初始化参数：

- FAST_START_MTTR_TARGET

- LOG_CHECKPOINT_INTERVAL

- LOG_CHECKPOINT_TIMEOUT

- LOG_CHECKPOINTS_TO_ALERT

下面将详细讨论这些参数。

同时，还针对alert日志中出现的“checkpoint not complete”消息给出了处理建议，这些消息说明redo

日志和检查点需要优化。

3. 与增量检查点相关的参数

注意：日志文件切换将始终覆盖由以下参数引起的检查点。

FAST_START_MTTR_TARGET

自 Oracle 9i 以来，FAST_START_MTTR_TARGET 参数已成为优化增量检查点目标的首选方法。通过

FAST_START_MTTR_TARGET，您可以指定数据库执行单实例的崩溃恢复所要花费的秒数。基于内部统计信息，增

量检查点会自动调整检查点目标，以满足 FAST_START_MTTR_TARGET 的要求。

V$INSTANCE_RECOVERY.ESTIMATED_MTTR 显示当前预计的平均恢复时间 (MTTR)（以秒为单位）。即使未指

文档 1526118.1 https://support.oracle.com/epmos/faces/DocumentDisplay?...

第2页共5页

2024/12/15 19:43

检查点（Checkpoint）优化及故障排除指南 (文档 ID 1526118.1)

适用于:

Oracle Database Exadata Express Cloud Service - 版本 N/A 和更高版本

Oracle Database Cloud Service - 版本 N/A 和更高版本

Oracle Database - Enterprise Edition

Oracle Database Cloud Schema Service - 版本 N/A 和更高版本

Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - 版本 N/A 和更高版本

本文档所含信息适用于所有平台

用途

本文档旨在使数据库管理员更好地了解增量检查点（

Checkpoint），并对检查点（Checkpoint）优化所用的下列四个初

始化参数进行了描述：

- FAST_START_MTTR_TARGET

- LOG_CHECKPOINT_INTERVAL

- LOG_CHECKPOINT_TIMEOUT

- LOG_CHECKPOINTS_TO_ALERT

此外，本文档还介绍了如何解释和处理检查点错误：

ALERT<sid>.LOG 文件中报告的“Checkpoint not Complete（检

查点未完成

）”和“Cannot Allocate New Log（无法分配新日志）”。

适用范围

详细信息

1. 什么是检查点？

2. 检查点和性能

3. 与增量检查点相关的参数

4. Redo（

重做）日志和检查点

5. 了解检查点错误消息（“Cannot allocate new log”和“Checkpoint not complete”）

6. Oracle 版本信息

7. 使用 Statspack 确定检查点问题

检查点优化和错误处理

1. 什么是检查点？

检查点是一种将内存中的已修改数据块与磁盘上的数据文件进行同步的数据库事件。通过Checkpoint

Oracle 确保了被 transaction 修改过数据可以被同步至磁盘。Oracle transaction 提交的时候不会将已修

改数据块同步写入磁盘上。

检查点有两个用途：(1) 确保数据一致性，和 (2) 实现更快的数据库恢复。如何更快地恢复？由于直至检查

点生成时所有的数据库更改均已记录在数据文件中，因此无需再应用先于检查点的 redo 日志条目。检查点

必须确保高速缓存中所有已修改的缓冲数据均已切实写入到相应的数据文件中，以避免在发生崩溃（实例

或磁盘故障）时可能会出现的数据丢失。

文档 1526118.1 https://support.oracle.com/epmos/faces/DocumentDisplay?...

第1页共5页

2024/12/15 19:43

Oracle 只有在特定条件下才会将脏缓存写入磁盘：

- shadow process 需要扫描的数据块个数超过 db_block_buffers 参数的四分之一。

- 每三秒钟。

- 生成一个检查点时。

检查点通过五种类型的事件来实现：

- 每次切换 redo 日志文件时。

- 达到 LOG_CHECKPOINT_TIMEOUT 的延迟时。

- 当前 redo 日志文件中已存在了大小为（LOG_CHECKPOINT_INTERVAL* OS块的大小（bytes））的

数据。

- 直接由 ALTER SYSTEM SWITCH LOGFILE 命令实现。

- 直接使用 ALTER SYSTEM CHECKPOINT 命令实现。

在检查点期间会发生以下操作：

- DBWR 将缓冲区缓存中所有已修改的数据库块写回到数据文件中，

- 检查点进程 (ckpt) 更新所有数据文件的文件头，以反映上一个检查点发生的时间 (SCN)

2. 检查点和性能

检查点的优化常常会使数据库管理员左右为难。频繁的检查点会实现更快的数据库恢复，但也会导致数据

库性能降低。那么，DBA 如何解决这一问题呢？

根据数据库中的数据文件数量，检查点将会是一种高度占用资源的操作，因为所有数据文件头在检查点期

间都会被冻结。关于检查点的频率设置，需要对性能进行权衡。检查点频率越高，就能在数据库崩溃后更

快地实现恢复。这也是为什么一些不太能忍受意外系统停机的客户现场常常会选择此选项的原因。但是，

在很多情况下，频繁的检查点可能会导致性能降低，这使得上述观点并不能完全站稳脚跟。我们假设数据

库已启动，且有 95% 的时间处于运行状态，剩下 5% 未运行时间是由于出现偶发的实例崩溃或硬件故障，

需要进行数据库恢复。对于大多数的客户现场而言，优化 95% 的性能相比于极少的 5% 停机时间要更具意

义。

本文档假设性能是您的首要考虑事项，并由此给出相应的建议。因此，您的目标是通过优化尽量减少检查

点的频率。

优化检查点涉及到下面四个关键初始化参数：

- FAST_START_MTTR_TARGET

- LOG_CHECKPOINT_INTERVAL

- LOG_CHECKPOINT_TIMEOUT

- LOG_CHECKPOINTS_TO_ALERT

下面将详细讨论这些参数。

同时，还针对alert日志中出现的“checkpoint not complete”消息给出了处理建议，这些消息说明redo

日志和检查点需要优化。

3. 与增量检查点相关的参数

注意：日志文件切换将始终覆盖由以下参数引起的检查点。

FAST_START_MTTR_TARGET

自 Oracle 9i 以来，FAST_START_MTTR_TARGET 参数已成为优化增量检查点目标的首选方法。通过

FAST_START_MTTR_TARGET，您可以指定数据库执行单实例的崩溃恢复所要花费的秒数。基于内部统计信息，增

量检查点会自动调整检查点目标，以满足 FAST_START_MTTR_TARGET 的要求。

V$INSTANCE_RECOVERY.ESTIMATED_MTTR 显示当前预计的平均恢复时间 (MTTR)（以秒为单位）。即使未指

文档 1526118.1 https://support.oracle.com/epmos/faces/DocumentDisplay?...

第2页共5页

2024/12/15 19:43

of 5

25墨值下载

oracle数据库

关注

评论