Oracle-AWR- Checkpoint Activity

在 Oracle AWR 报告中，“Checkpoint Activity” 部分用于展示数据库检查点（Checkpoint）相关的物理写操作统计，反映脏数据块（内存中被修改但未写入磁盘的数据块）被写入磁盘的触发原因和规模。以下是各指标的含义及综合性能分析：

1. 整体含义

“Checkpoint Activity” 记录了数据库中因检查点机制触发的总物理写次数及具体触发来源。检查点的核心目的是将内存中的脏数据块写入磁盘，确保数据一致性，并减少实例崩溃后的恢复时间。总物理写（Total Physical Writes）是所有检查点触发的物理写操作总和，此处为 174,587,567 次，说明检查点相关的磁盘 I/O 量较大。

2. 各指标含义

2.1 Total Physical Writes

  所有检查点触发的物理写操作总次数，即 174,587,567 次，是以下各分项的总和。

2.2 MTTR Writes

  由 MTTR（Mean Time To Recovery，平均恢复时间）目标触发的检查点写次数。MTTR 是 Oracle 为控制实例崩溃后恢复时间设置的目标，系统会定期触发检查点以确保脏块在 MTTR 内写入磁盘。此处为 0，说明未因 MTTR 目标触发检查点写（可能 MTTR 设置宽松，或系统未达到触发条件）。

2.3 Log Size Writes

  因重做日志文件（Redo Log）大小限制触发的检查点写次数。当重做日志写满需要切换时，Oracle 需触发检查点将对应脏块写入磁盘，以释放日志空间供新日志使用。此处为 58,928,141 次，占比约 33.7%，是主要来源之一。

2.4 Log Ckpt Writes

  由手动日志检查点（如alter system switch logfile或alter system checkpoint）触发的写次数。此处为 0，说明无手动触发的日志检查点。

2.5 Other Settings Writes

  由其他特殊参数设置（如FAST_START_MTTR_TARGET以外的检查点相关参数）触发的写次数。此处为 0，说明无此类触发。

2.6 Autotune Ckpt Writes

  由 Oracle 自动调优机制（自适应检查点）触发的写次数。Oracle 会根据系统负载、I/O 能力等动态调整检查点频率，避免脏块积累过多导致恢复时间过长。此处为 52,302,677 次，占比约 30%，是另一主要来源。

2.7 Thread Ckpt Writes

  在 RAC 环境中，单个线程（实例）触发的检查点写次数（单实例中可理解为线程级检查点）。此处为 2,353,434 次，占比约 1.3%，规模较小。

3. 性能问题综合分析

从数据来看，检查点写的主要来源是Log Size Writes（约 5892 万次）和Autotune Ckpt Writes（约 5230 万次），两者合计占总物理写的 63.7%，需重点关注：

1. Log Size Writes 过高：可能因重做日志文件过小重做日志文件大小不足会导致频繁的日志切换（Log Switch），每次切换需触发检查点释放日志空间。频繁的检查点会产生大量物理 I/O，占用磁盘带宽，可能导致：
   • 事务等待：检查点写（如db file parallel write等待事件）会与用户事务的 I/O 竞争资源，导致事务响应变慢；
   • 日志切换等待：若检查点未完成而日志已写满，会触发log file switch (checkpoint incomplete)等待，直接阻塞新事务的日志写入。
2. Autotune Ckpt Writes 过高：说明系统脏块积累过快或 I/O 压力大自动调优检查点频繁触发，通常意味着：
   • 内存中脏块增长速度超过了 I/O 系统的处理能力（如并发事务多、写操作频繁），Oracle 需主动触发检查点避免脏块过多；
   • 可能存在 I/O 瓶颈（如磁盘读写速度慢），导致脏块无法及时写入，迫使自动调优机制介入。
3. 总物理写规模大：需警惕 I/O 子系统过载总物理写达 1.74 亿次，说明检查点相关的磁盘 I/O 负载较高。若磁盘 I/O 能力不足（如机械硬盘、RAID 配置不合理），可能导致持续的 I/O 等待，整体降低数据库性能。

4. 建议优化方向

1. 增大重做日志文件大小：减少日志切换频率，降低Log Size Writes（建议单个日志文件大小使切换频率控制在 10-30 分钟 / 次）；
2. 检查 I/O 子系统性能：通过v$iostat_file或 OS 工具（如iostat）确认磁盘读写延迟，必要时升级存储（如改用 SSD）或调整 RAID 策略；
3. 优化检查点相关参数：如调整DB_WRITER_PROCESSES（增加写进程）、DB_BLOCK_CHECKPOINT_BATCH（控制每次检查点写的块数），避免单次检查点 I/O 压力过大；
4. 分析业务负载：若写操作频繁（如大量 DML），可考虑错峰执行或优化事务设计（如批量提交），减少脏块产生速度。