Oracle SCN 内部原理、机制介绍和常用SQL

原创已于 2025-09-09 12:12:04 修改 · 648 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#oracle #数据库

于 2025-09-09 12:09:52 首次发布

AI辅助_面试宝典专栏收录该内容

584 篇文章

订阅专栏

在这里插入图片描述
我将为您深入解析Oracle数据库中两个最根本、相互关联的核心机制：系统改变号（SCN） 和检查点（Checkpoint）。理解它们是掌握Oracle数据一致性、恢复和内部运作的关键。

第一部分：官方定义与核心作用

一、系统改变号 (System Change Number - SCN)

官方定义：SCN是一个由Oracle数据库内部维护的、单调递增的逻辑时间戳。它用于对数据库中的所有更改（事务提交、数据块变更、检查点发生等）进行唯一的、顺序的排序。SCN是Oracle实现数据一致性和恢复机制的基石。
核心作用：
1. 定义数据库的一致性状态：在任何一个给定的SCN点，数据库都有唯一一致的数据视图。
2. 排序事件：精确确定所有数据库操作发生的先后顺序。
3. 实现恢复：在实例恢复和介质恢复中，通过比较数据文件头、控制文件和重做日志中的SCN，来确定需要从哪个点开始应用重做日志，以及需要应用到哪个点结束。
4. 支持读一致性：当一个查询开始，它会获取一个查询SCN。在查询执行过程中，它只会看到SCN值小于或等于此查询SCN的已提交数据，从而保证读到的是一致的数据快照。

二、检查点 (Checkpoint)

官方定义：检查点是一个数据库事件，其核心作用是通知数据库写进程（DBWn）将Buffer Cache中的脏缓冲区（Dirty Buffers）写入磁盘数据文件。此事件完成后，会更新数据文件头和控制文件中的SCN信息，以同步内存与磁盘的状态。
核心作用：
1. 缩短实例恢复时间：确保在实例崩溃后，只需要应用最后一次检查点之后生成的重做日志即可完成恢复。检查点越频繁，需要恢复的时间就越短。
2. 保证数据一致性：协调内存（Buffer Cache）、磁盘（数据文件）和日志（重做日志）之间的状态，确保在任何一个SCN点，磁盘上的数据文件都包含所有在该SCN之前提交的更改。
3. 触发数据文件更新：促使DBWn进行批量写操作，将脏数据持久化到存储系统。

第二部分：深入底层原理与管理机制

一、SCN的深入解析

1. SCN的本质与获取：
SCN不是一个简单的计数器，而是一个复杂的同步机制。在高并发环境中，获取一个唯一且递增的SCN必须高效且无冲突。

获取方式：
- Lamport SCN生成算法：Oracle使用了一种分布式系统中常用的逻辑时钟算法，它结合了本地计数器和消息传递（在RAC环境中尤其关键）来保证SCN的全局唯一性和递增性。
- SCN的来源：
  - 本地生成：单实例环境中，主要从内存中的SCN计数器获取。
  - 从重做日志中获取：LGWR在将重做记录写入日志文件时，会为其标记SCN。
  - 在RAC中通过私有网络同步：一个实例的LMS进程会广播其SCN的增长，确保所有实例看到的SCN视图是同步的。
_SMALL_TABLE_THRESHOLD参数：虽然与SCN不直接相关，但此参数决定了全表扫描时是直接读磁盘还是经Buffer Cache，间接影响数据块的SCN标记。

2. SCN的存储与类型：
SCN无处不在，它被记录在：

数据文件头：记录了该数据文件最后一次完成检查点时的SCN（CHECKPOINT_CHANGE#）。
控制文件：记录了每个数据文件的CHECKPOINT_CHANGE#。
重做日志文件：每一个重做记录都携带一个SCN。
数据块头部：每个数据块都有一个块SCN，记录了该块最后一次被修改时的SCN。
事务表（Undo Segment Header）：事务开始时和提交时都会记录SCN。

常见的SCN类型包括：系统当前SCN、检查点SCN、开始SCN、结束SCN、重做SCN等。

二、检查点的深入解析

1. 检查点队列 (Checkpoint Queue)
这是理解增量检查点的核心数据结构。

原理：Buffer Cache中的每一个脏数据块的缓冲区头（Buffer Header）都被链入一个双向链表，这个链表就是检查点队列。关键是，这个队列是按数据块第一次变脏时的SCN（Low RBA - Redo Block Address中的SCN部分）顺序排列的。
作用：它确保了在检查点发生时，DBWn会按照数据块被修改的顺序将它们写入磁盘。这对于恢复的一致性至关重要。

2. 增量检查点 (Incremental Checkpoint)
自Oracle 8i以来，传统的完全检查点（Full Checkpoint，如ALTER SYSTEM CHECKPOINT）已很少使用，取而代之的是增量检查点。

原理：增量检查点不要求DBWn在一次事件中写完所有脏块。而是：
1. 持续推进：CKPT进程会每隔3秒左右醒来一次，将当前最新的SCN（或RBA）写入控制文件，这个位置称为检查点位置。
2. 目标触发：DBWn会持续地在后台写出检查点队列中的脏块，但目标是让队列最前端的块（最早修改的块）的SCN（Low RBA）尽快追上控制文件中记录的检查点位置。
3. 协调工作：当发生日志切换（ALTER SYSTEM SWITCH LOGFILE）或其它触发条件时，CKPT会更新控制文件中的信息，并可能要求DBWn更多地写出脏块。
FAST_START_MTTR_TARGET参数：这是控制增量检查点行为的核心参数。你设置一个期望的实例恢复时间（秒），Oracle内部会自动计算一个目标RBA。DBWn会努力将检查点队列的头部（最早脏块）推进到这个目标RBA之前，以确保恢复时间能在你的期望之内。

第三部分：原理串联与示例

场景： 用户执行了一个UPDATE语句并提交。

事务开始：
- 服务器进程为事务分配一个SCN（比如 SCN=1001）。
- 修改Buffer Cache中的数据块，将该块的SCN更新为1001，并将其链入检查点队列。
提交（COMMIT）：
- 关键操作是LGWR将事务的提交记录同步写入重做日志文件。这个写入动作本身会获得一个新的SCN（比如 SCN=1002）来标记这个提交记录。
- 一旦写日志成功，事务就被认为是持久的。提交操作的核心是写重做日志，而非立即写数据文件。
检查点发生（例如，每3秒一次）：
- CKPT进程醒来，它发现当前系统SCN已经增长到了1010。
- 它将这个SCN（或对应的RBA）写入控制文件，作为新的检查点位置。
- 它检查检查点队列，发现最早修改的脏块SCN是1001（远早于1010）。
- CKPT通知/催促DBWn去将检查点队列中从头部开始的一定数量的脏块（SCN从1001到 around 1005）写入数据文件。
DBWn写脏块：
- DBWn从检查点队列的头部开始，将指定的脏块批量写入磁盘。
- 写入成功后，这些块被标记为干净，并从检查点队列中移除。
恢复场景：
- 假设在SCN=1010时数据库实例崩溃。
- 下次启动时，Oracle读取控制文件，找到最后一次记录的检查点位置（SCN=1010）。
- 它发现数据文件头的SCN（比如是1005）小于控制文件记录的SCN（1010），这意味着崩溃时内存中有SCN在1005到1010之间的数据尚未写入数据文件。
- 实例恢复开始：SMON进程从重做日志中找到SCN=1005的位置，开始前滚，重新应用所有SCN在1005到1010之间的重做记录，重现崩溃前的修改。
- 前滚完成后，再回滚所有未提交的事务。

通俗比喻：

SCN：就像一本巨大的小说页码。每一处修改（每一个字句的增删）都发生在特定的页码上。这本书的页码是严格递增且唯一的。
重做日志：就像是作者的写作手稿，按时间顺序记录了作者写的每一句话（每一个修改）。
检查点：就像是编辑定期把手稿内容誊写到正式书稿上。编辑不会每写一句话就抄一次，而是每隔几页抄一次（增量检查点）。他会在手稿上做个标记（更新控制文件），表示“我已经抄到这里了”。
实例崩溃：好比作者和编辑突然晕倒。
实例恢复：新来的编辑醒来，看到正式书稿最后誊写到的页码（数据文件头SCN），然后翻出手稿（重做日志），从那个页码之后开始，把手稿上后续的内容继续誊写到书稿上（前滚），最后把那些作者用铅笔写的、还没最终确认的草稿擦掉（回滚）。这样，一本完整的书就恢复了。

第四部分：争用、等待事件与排查解决

1. 检查点相关等待

等待事件：log file sync, free buffer waits, write complete waits, checkpoint not complete
场景与原理：
- log file sync：
  - 场景：用户提交（COMMIT）非常频繁。
  - 原因：提交时，服务器进程必须等待LGWR将本事务的重做记录同步写盘完成后才能返回成功给用户。如果LGWR写入慢（I/O瓶颈），或提交太快导致LGWR忙不过来，就会出现大量此等待。
  - 排查：查看V$SYSTEM_EVENT中该事件的平均等待时间。
  - 解决：
    1. 优化存储I/O（使用更快磁盘、条带化、启用异步I/O）。
    2. 减少不必要的频繁提交，改为批量提交。
    3. 考虑使用COMMIT_WRITE批量提交（但需权衡数据耐久性）。
- free buffer waits：
  - 场景：服务器进程需要将新数据块读入Buffer Cache，但找不到空闲缓冲区。
  - 原因：DBWn写出速度太慢，无法及时将脏块写入磁盘以腾出空间。而DBWn的写出受检查点进度影响。
  - 解决：
    1. 优化DBWn（增加DB_WRITER_PROCESSES）。
    2. 优化检查点，确保DBWn能及时工作（调整FAST_START_MTTR_TARGET，不要设得太小）。
    3. 增大Buffer Cache（DB_CACHE_SIZE）。
- checkpoint not complete：
  - 场景：日志切换时发生。
  - 原因：需要切换到的下一个日志文件所需要的检查点还没有完成。通俗讲，DBWn写数据块的速度跟不上LGWR写日志的速度。
  - 解决：
    1. 增加重做日志组的大小和数量，让日志切换频率降低。
    2. 优化DBWn性能（同上）。
    3. 检查是否因FAST_START_MTTR_TARGET设置过小，导致DBWn持续高负荷运行。

2. SCN相关问题（较少见但严重）

SCN耗尽（历史问题）：在老版本中，SCN有位数限制（如6字节），可能存在耗尽风险。现代版本（如11gR2以后）已通过SCN软兼容性和Headroom机制避免，它会自动延缓SCN增长并向DBA发出警报。
kcmgs_1等待事件：在RAC中，与SCN同步相关的等待，通常意味着私有网络可能存在延迟或问题。

第五部分：常用监控SQL

查看系统当前SCN：
```
SELECT CURRENT_SCN FROM V$DATABASE;
```

查看数据文件和控制文件的SCN信息：

SELECT FILE#, NAME, CHECKPOINT_CHANGE# FROM V$DATAFILE; -- 数据文件头SCN
SELECT FILE#, NAME, CHECKPOINT_CHANGE# FROM V$DATAFILE_HEADER; -- 同上，但直接从文件头读

监控检查点进度与恢复时间：

SELECT TARGET_MTTR, ESTIMATED_MTTR, CKPT_BLOCK_WRITES FROM V$INSTANCE_RECOVERY;

查看重做日志相关的统计信息：

SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%redo%';
-- 重点关注 redo synch writes (log file sync的统计), redo writes

监控等待事件：

SELECT EVENT, TOTAL_WAITS, TIME_WAITED_MICRO, AVERAGE_WAIT_MICRO
FROM V$SYSTEM_EVENT
WHERE EVENT IN ('log file sync', 'free buffer waits', 'write complete waits')
ORDER BY TIME_WAITED_MICRO DESC;