Oracle事务与一致性读
Oracle 事务以读一致性和多版本机制著称。查询通过 SCN 和 Undo 构造一致性视图，写入通过锁保护当前版本，理解这一点才能正确处理并发、长事务和 ORA-01555。
# 1. 学习目标与定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 核心到专家 |
| 核心目标 | 从底层运行链路理解本篇主题，能把概念、SQL、指标、故障和工程取舍连起来 |
| 适合人群 | 开发人员关注事务边界和并发正确性；运维人员关注 Undo、长事务、锁等待和快照过旧。 |
# 2. 核心概念总览
Oracle事务与一致性读
├─ ACID
├─ SCN
├─ Commit
├─ Rollback
├─ Read Consistency
├─ Current Read
├─ Undo
├─ ORA-01555
└─ Savepoint
这张图只用来定位本章范围。正文不会把每个词机械拆成固定问答，而是按 Oracle 的真实运行机制解释它们之间如何协作、在哪里影响开发、在哪里影响运维。
# 3. 底层原理详解
Oracle 通过 SCN 构建数据库时间线。查询开始时确定一致性点，如果数据块中的行版本晚于查询 SCN，Oracle 会沿 Undo 找到旧版本，构造出查询应该看到的数据。
写入不是基于快照完成的。UPDATE、DELETE、SELECT FOR UPDATE 等当前读需要访问最新可修改版本，并通过行锁保护并发写入。这就是为什么读通常不阻塞写，写仍然会阻塞写。
提交时事务 Redo 必须持久化，锁释放，其他事务才能看到新版本。回滚则沿 Undo 撤销变更。大事务提交和回滚都不是免费的，它们会影响 Undo、Redo、锁和恢复。
# 4. 关键机制拆解
# 4.1. SCN 与一致性读
SCN 可以理解为 Oracle 的逻辑时间。普通 SELECT 不需要锁住正在读取的行，而是根据 SCN 和 Undo 还原旧版本，从而实现非阻塞读。
一致性读让并发性能很好，但前提是旧版本仍在 Undo 中可用。长查询遇到频繁更新对象时，如果需要的旧版本被覆盖，就可能触发 ORA-01555。
# 4.2. 当前读、行锁和提交
当前读必须面对最新数据。两个事务修改同一行时，后来的事务要等待前一个事务提交或回滚。提交不是把数据文件立即写盘，而是把 Redo 刷到联机日志。
开发人员要避免长时间持有事务，例如在事务中等待用户输入、调用外部接口或处理大文件。事务越长，锁和 Undo 风险越大。
# 4.3. Undo、回滚和 Savepoint
Undo 同时服务回滚和一致性读。Savepoint 可以在一个事务内部建立局部回滚点，但不会释放已持有的所有资源，也不会减少大事务的整体成本。
大批量 DML 应分批提交并记录处理进度。指望一个超大事务失败后快速回滚，是非常危险的。
# 4.4. ORA-01555 的真实含义
ORA-01555 通常不是“数据库坏了”，而是查询需要的旧版本已经无法从 Undo 中构造。根因可能是查询太久、Undo 保留不足、更新太频繁或提交策略不合理。
排查要找长查询 SQL、被频繁修改的对象、Undo 表空间、undo_retention、提交频率和执行计划。只调大 Undo 不治理 SQL，问题可能复发。
# 5. 功能模块细节补充
本节围绕概念图中的模块逐个补充底层细节，重点讲它们在 Oracle 运行链路中的位置和相互关系，而不是按固定角色模板拆分。
# 5.1. ACID
ACID 在 Oracle 中不是抽象口号。原子性依赖 Undo 回滚未提交变更，一致性依赖约束、触发器、应用规则和事务边界共同保证，隔离性依赖一致性读与行锁协作，持久性依赖 Redo 在提交时被安全写入联机日志。
# 5.2. SCN
SCN 是 Oracle 判断版本先后的核心逻辑时间。查询、提交、检查点、恢复、Data Guard 应用都会围绕 SCN 推进；当你说“恢复到某个时间点”时，数据库内部最终仍要落到一个可恢复的 SCN 或日志位置。
# 5.3. Commit
Commit 的关键动作不是把所有脏块写回数据文件，而是为事务分配提交 SCN，并等待 LGWR 将提交相关 Redo 写入联机日志。提交完成后锁释放，其他会话可以看到新版本；如果提交过程中客户端超时，应用需要通过业务流水号确认最终状态。
# 5.4. Rollback
Rollback 沿 Undo 记录反向撤销当前事务的未提交修改。小事务回滚很快，大事务回滚可能持续很久，并继续占用资源；强杀会话不等于立刻释放影响，PMON 或恢复过程仍要完成清理。
# 5.5. Read Consistency
Read Consistency 让普通查询在不阻塞写入的情况下看到一个一致时间点的数据。Oracle 读取数据块时，如果发现行版本晚于查询 SCN，就使用 Undo 构造旧版本；这也是为什么长查询会依赖足够长的 Undo 保留窗口。
# 5.6. Current Read
Current Read 面向最新可修改版本，常见于 UPDATE、DELETE、MERGE、SELECT FOR UPDATE 和约束检查。它必须与行锁配合，不能像普通一致性读那样只看历史快照；读后要写的业务逻辑应该明确使用当前读语义。
# 5.7. Undo
Undo 同时服务事务回滚、一致性读、闪回查询和部分恢复场景。它的压力来自写入量、事务持续时间和长查询窗口；Undo 不足或复用过早，会直接影响历史版本构造能力。
# 5.8. ORA-01555
ORA-01555 表示查询需要的旧版本已经无法从 Undo 中取得。它通常由长查询、频繁提交的小批量更新、Undo 保留不足、执行计划变慢或热点对象持续修改共同触发；解决时要同时看 SQL 耗时和 Undo 生命周期。
# 5.9. Savepoint
Savepoint 是事务内部的局部回滚标记，可以回滚到某个中间点，而不结束整个事务。它适合复杂过程中的局部容错，但不能替代合理事务拆分；保存点之后产生的锁和资源释放仍受整体事务边界影响。
# 6. 开发人员重点提醒
- 事务只包必要数据库操作，不包远程调用和人工等待。
- 读后写要用条件更新、唯一约束或 SELECT FOR UPDATE 明确并发语义。
- 批量任务要分批提交并可重试。
# 7. 运维人员重点提醒
- 监控长事务、Undo 使用率、ORA-01555、锁等待和回滚进度。
- 为报表和批处理规划隔离窗口或只读库。
- 评估 undo_retention 时结合最长查询和更新压力。
# 8. 典型问题与排查
- ORA-01555：定位长查询、Undo 保留和热点更新对象。
- 回滚很慢：评估事务修改量，不要盲目杀进程叠加恢复成本。
- 锁等待：查阻塞会话、SQL_ID 和事务开始时间。
# 9. 实践建议与检查清单
- 事务边界短
- 批量任务分批
- 长查询有隔离方案
- Undo 有容量基线
- ORA-01555 有排查路径
# 10. 阶段小结
本篇的学习重点不是记住术语，而是能把底层机制、业务语义和生产证据连起来。读完本篇后，应该能解释关键组件如何协作、常见问题为什么发生、开发侧如何避免制造风险、运维侧如何用指标和日志把问题定位到具体链路。