Oracle检查点队列与Buffer Cache原理
好的，我们将深入探讨 Oracle Buffer Cache 的另一个核心机制：检查点（Checkpoint） 及其相关的检查点队列（Checkpoint Queue）。理解这部分内容对于掌握数据库的恢复原理、性能调优（尤其是写操作密集型的系统）至关重要。
1. 检查点（Checkpoint）的核心概念
官方/专业解释
检查点是一个事件，当此事件发生时，数据库写入器进程（DBWR） 会将 Buffer Cache 中所有自上次检查点以来被修改过的数据块（称为脏块，Dirty Buffers）写入到数据文件中。同时，检查点进程（CKPT） 会更新所有数据文件的文件头和控制文件，以记录这个检查点的 SCN（System Change Number）。
通俗解释
把它想象成一个 “游戏存档点”。
- 你正在玩一个游戏（数据库在运行，数据在不断变化）。
- 游戏过程中，你可能会经历很多战斗和获得很多物品（产生脏块）。
- 系统会定期或在关键时刻自动存档（发生检查点）。
- 存档时，游戏会将当前的所有进度（脏块）真正保存到硬盘（写入数据文件），并记录“已存档至此关第5分钟”（更新SCN）。
- 如果之后游戏突然崩溃（实例故障），你不需要从第一关重新玩起，而只需要从上一个存档点继续（实例恢复），丢失的只是存档之后那一小段时间的进度（少量重做日志记录）。
检查点的主要意义在于：极大地缩短实例恢复所需的时间。
2. 检查点队列（Checkpoint Queue） - CQ
官方/专业解释
检查点队列（CQ），也称为 LRU-W（Least Recently Used - Write）列表 或 脏队列（Dirty Queue），是 Buffer Cache 中的一个重要的内部链表结构。它是一个按时间顺序链接的链表：
- 排序依据： 缓冲区首次被修改变成脏块的时间（Low RBA - Redo Byte Address）。
- 链表内容： 所有脏块对应的 Buffer Header 都被按顺序挂在这个链表上。
这意味着，链表头指向最早被修改的脏块，而链表尾指向最近被修改的脏块。
通俗解释
继续用图书馆的比喻，但这次我们关注的是被读者涂改过的书（脏块）。
- 图书管理员（DBWR）需要知道哪些书被涂改过，以便把它们抄写回原始档案库（数据文件）中。
- 他使用一个 “待抄写清单” （检查点队列）。
- 这个清单的规则是：按照书本第一次被涂改的时间先后顺序来排列。最早被涂改的书排在清单的最前面。
这个“待抄写清单”使得管理员可以非常高效地工作：
- 他知道清单最前面的书是“脏”了最久的，最需要被优先抄写归档。
- 在“存档”（检查点）时，他可以从清单开头开始，按顺序批量处理这些书。
3. 检查点、CQ 与实例恢复的关系
实例恢复（Instance Recovery）发生在数据库异常关闭（如断电）后重新启动时。它包含两个阶段：前滚（Roll Forward） 和 回滚（Roll Back）。
- 前滚 (Roll Forward)： 利用重做日志（Redo Log）中记录的信息，重演所有已提交但尚未写入数据文件的更改。这个过程将从最后一个检查点记录的SCN开始，一直应用到重做日志的末尾。
- 回滚 (Roll Back)： 前滚后，数据库可能包含了未提交的事务。回滚阶段会撤销这些未提交的更改，保证数据的一致性。
检查点队列的核心作用就在这里：
因为检查点队列按脏块首次变脏的顺序（Low RBA）排列，而Low RBA与重做日志中的位置对应，所以：
检查点队列的队首，直接指向实例恢复需要开始的起点。
通俗解释：
- 游戏崩溃了（实例故障）。
- 你决定从上一次存档点开始恢复（检查点SCN）。
- 那个“存档点”记录的信息，正好对应“待抄写清单”（CQ）上第一本书开始被涂改的时间点。
- 你只需要阅读从那个时间点之后的游戏操作日志（重做日志），就能完美重现崩溃前的所有有效操作，而无需重头开始玩。
因此，检查点队列使得数据库能够快速、精准地定位实例恢复的起始点，大大减少了恢复时间。
4. 数据库写入器进程 (DBWR) 如何写脏块
DBWRn（n从0到9，a到j）是负责将脏块写入数据文件的后台进程。它的写入并非实时进行，而是由多种机制触发。
DBWR 的触发条件：
- 检查点发生： 这是最主要的触发原因。包括：
- 增量检查点（Incremental Checkpoint）： 持续地将CQ上的脏块逐步写入磁盘，并不断更新检查点位置（RBA）。这是现代Oracle默认和推荐的方式。
- 完全检查点（Full Checkpoint）： 命令DBWR将Buffer Cache中所有脏块写入磁盘。通常发生在
ALTER SYSTEM CHECKPOINT;、正常关闭数据库（SHUTDOWN IMMEDIATE, TRANSACTIONAL, NORMAL）或日志切换时（如果FAST_START_MTTR_TARGET未设置）。
- 服务器进程需要空闲缓冲区： 当服务器进程需要读新块进Buffer Cache，但在LRU列表上找不到空闲缓冲区时，它会通知DBWR将一些脏块写入磁盘以腾出空间。
- 超时（Timeout）： DBWR会定期唤醒（大约3秒一次），检查是否有需要写入的脏块。
- RAC Ping请求： 在RAC环境中，当另一个实例需要访问当前实例缓存的数据块时。
- 表空间离线（OFFLINE） 或只读（READ ONLY）： 需要将该表空间的所有脏块写回磁盘。
DBWR 的写操作特点：
- 多块写（Multiblock Write）： DBWR一次I/O可以写入多个连续的块（由
DB_WRITER_PROCESSES和DB_FILE_MULTIBLOCK_READ_COUNT等参数影响），这比单块写效率高得多。 - 散列写（Scattered Write）： DBWR写入的块在磁盘上不一定是连续的。它写的是脏块，而这些脏块可能属于不同的数据文件、不同的表空间。
5. 如何提高 DBWR 的写效率
DBWR的写速度直接影响检查点的完成速度和整个数据库的性能。如果DBWR写入跟不上脏块产生的速度，就会导致“自由缓冲区等待（Free Buffer Waits）”等性能问题。
优化策略包括：
-
使用多个DBWR进程：
- 对于多CPU系统或写操作非常频繁的系统，单一的DBWR进程可能成为瓶颈。
- 可以配置多个写进程（
DBWR_IO_SLAVES或DB_WRITER_PROCESSES）。 - SQL命令：
ALTER SYSTEM SET db_writer_processes = 4 SCOPE=SPFILE; -- 通常设置为CPU核心数的1/8到1/4 -- 需要重启数据库生效
-
使用异步I/O（Asynchronous I/O）：
- 允许DBWR发出一个写请求后立即返回去处理下一个请求，而不必等待磁盘I/O完成。这极大地提高了吞吐量。
- 在大多数现代操作系统和存储上，AIO是默认推荐开启的。
- 查询和设置：
SELECT name, asynch_io FROM v$datafile; -- 查看数据文件是否启用AIO -- AIO通常在操作系统层面设置，并需要Oracle支持。
-
优化存储I/O性能：
- 这是最根本的优化。使用高速磁盘（如SSD）、条带化（RAID）、增加I/O通道数、确保数据文件均匀分布在不同的物理磁盘上，都能直接提升DBWR的写能力。
-
合理设置检查点相关参数：
FAST_START_MTTR_TARGET： 这是一个非常重要的参数。它指定了实例恢复的预期最大时间（秒）。Oracle会自动调整内部检查点的频率和进度，以确保恢复时间不超过这个值。- 设置较小的值会促使DBWR更频繁地写入，减少恢复时间，但可能增加平时I/O开销。
- 设置较大的值会减少平时I/O开销，但延长了恢复时间。
- SQL命令：
ALTER SYSTEM SET fast_start_mttr_target = 300; -- 目标恢复时间设为300秒（5分钟）
-
使用Buffer Cache的多池特性：
- 将不同的段（如小表、索引）放入Keep Pool，或将大表放入Recycle Pool，可以避免它们干扰默认池中的LRU算法，从而间接减轻DBWR的压力。
6. 相关查询与管理 SQL 命令
A. 监控检查点进度和状态
-- 查看当前检查点信息
SELECT checkpoint_change#, -- 当前的SCN
name
FROM v$database;
-- 查看增量检查点的状态和恢复估计时间
SELECT target_mttr,
estimated_mttr,
ckpt_block_writes -- 检查点期间写入的块数
FROM v$instance_recovery;
-- 查看数据文件头中的检查点SCN
SELECT file#, checkpoint_change#
FROM v$datafile_header;
B. 监控DBWR活动和性能
-- 查看DBWR相关的统计信息和等待事件
SELECT statistic#, name, value
FROM v$sysstat
WHERE name LIKE '%DBWR%';
-- 查看自由缓冲区等待（Free Buffer Waits），如果值很高，说明DBWR写入不够快
SELECT event, total_waits, time_waited
FROM v$system_event
WHERE event = 'free buffer waits';
-- 查看当前脏块的数量
SELECT COUNT(*) AS dirty_buffers
FROM v$bh
WHERE dirty = 'Y';
C. 手动执行检查点
-- 在维护窗口进行手动完全检查点（谨慎使用，会引发大量I/O）
ALTER SYSTEM CHECKPOINT;
-- 只对当前实例执行检查点（RAC环境）
ALTER SYSTEM CHECKPOINT LOCAL;
总结
| 组件/概念 | 官方角色 | 通俗比喻 | 关键点 |
| ：— | :— | :— | :— |
| 检查点 (CKPT) | 更新数据文件头和控制文件以记录同步点 | 游戏存档点 | 缩短恢复时间 |
| 检查点队列 (CQ) | 按首次变脏时间排序的脏块链表 | 待抄写清单 | 决定了实例恢复的起始点 |
| DBWR | 将脏块写入数据文件的进程 | 图书管理员 | 多块写、散列写，由多种条件触发 |
| 实例恢复 | 前滚 + 回滚 | 从存档点重玩 | 依赖检查点队列和重做日志 |
| 优化DBWR | 多进程、AIO、快存储、MTTR设置 | 增加管理员、提高抄写速度 | 核心是减少free buffer waits |
通过深入理解检查点队列和DBWR的工作机制，你可以更好地诊断数据库在写密集型负载下的性能瓶颈，并有效地配置数据库以确保其既高效又具备快速的恢复能力。
欢迎关注我的公众号《IT小Chen》
扫一扫
2065
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
