2. Oracle体系结构快速回顾

交易型数据库的性能问题，很少是孤立出现的。一条转账SQL变慢，可能既涉及SGA中共享池的硬解析，也涉及DBWn的脏块写出节奏，还可能与UNDO表空间的I/O争用有关。要定位这类问题，必须先把Oracle体系结构还原成一条“SQL进入数据库后经过哪些内存与进程、最终落到哪些存储对象”的完整链路。本节不重复教科书式的组件罗列，而是围绕交易性能，把实例内存、后台进程、存储结构三者串成一条可观察、可判断的因果链。

一、实例内存结构：SQL执行的第一现场

Oracle实例由内存结构（SGA、PGA）和后台进程组成。对交易性能影响最直接的是SGA中的几个池：

• 共享池（Shared Pool）：存放SQL解析结果（游标、执行计划）和数据字典缓存。交易系统中大量短小SQL反复执行，如果绑定变量使用不当，会导致硬解析频繁，表现为latch争用、CPU升高、library cache lock等待。
• 数据库缓冲区缓存（Buffer Cache）：缓存数据块。交易热点表（如账户表、订单表）的命中率直接决定物理读数量。缓冲区不足时，DBWn频繁写脏块，同时前台进程频繁等待free buffer。
• 重做日志缓冲区（Log Buffer）：存放重做记录。交易提交时LGWR必须把重做写入在线日志，因此Log Buffer过小或提交过于频繁，会放大log file sync等待。
• 大池与Java池：交易系统若使用RMAN备份、并行查询或Java存储过程，会占用大池；配置不当会挤压共享池空间。

PGA则是每个服务器进程私有的内存，排序、哈希连接、位图合并都在PGA中完成。交易SQL若出现大量排序（如未建索引的ORDER BY），PGA不足会触发磁盘排序，直接拖慢响应时间。可以用下面的查询观察PGA与SGA的分配情况：

-- 查看SGA各组件大小
SELECT component, current_size/1024/1024 AS mb
FROM v$sga_dynamic_components;

-- 查看PGA聚合目标与实际使用
SELECT name, value/1024/1024 AS mb
FROM v$pgastat
WHERE name IN ('aggregate PGA target parameter','total PGA allocated');

二、后台进程：把内存变化落到磁盘的执行者

后台进程是内存与存储之间的搬运工，交易性能瓶颈往往体现在它们的等待事件上：

• DBWn：把脏缓冲区写入数据文件。写太慢会导致free buffer wait；写太频繁会抢占I/O带宽，影响前台读。
• LGWR：把Log Buffer写入在线重做日志。提交必须等LGWR完成，因此log file sync是交易系统最典型的提交等待。
• CKPT：更新控制文件与数据文件头，触发检查点。检查点过于密集会增加DBWn压力。
• SMON/PMON：负责实例恢复与进程清理。异常终止的会话若大量存在，PMON清理会消耗资源。
• ARCn：归档日志写入。归档目的地I/O慢会间接导致LGWR等待。

判断后台进程是否成为瓶颈，最直接的方法是看等待事件。例如交易高峰期若log file sync平均等待超过5ms，就应检查在线日志所在磁盘的写延迟与提交频率；若db file sequential read平均等待偏高，则要检查索引回表是否过多、缓冲区命中率是否下降。

三、存储结构：逻辑与物理的映射决定I/O形态

Oracle存储结构分为逻辑结构和物理结构。逻辑结构从大到小为：表空间→段→区→块；物理结构为：数据文件、控制文件、在线重做日志、归档日志。交易性能与以下三点强相关：

• 块大小（DB_BLOCK_SIZE）：常见8KB。块越大，单次I/O读取的数据越多，但可能放大不必要的读；OLTP通常8KB较均衡。
• 区与段管理：本地管理表空间（LMT）配合自动段空间管理（ASSM）可减少字典争用。频繁插入删除的表若区分配不合理，会产生大量碎片与递归SQL。
• 日志与数据文件分离：在线重做日志应与数据文件放在不同物理设备，避免LGWR与DBWn争抢同一磁盘队列。

下面这张图把“SQL执行—内存—后台进程—存储”的链路与对应的典型等待事件对应起来，便于在排障时快速定位环节。

四、把三者串起来看交易性能

以一个典型转账交易为例：会话发起UPDATE，服务器进程先在共享池查找游标，若未命中则硬解析；随后在Buffer Cache中定位账户数据块，若未命中则从数据文件物理读；修改产生重做记录写入Log Buffer；提交时LGWR把重做刷入在线日志，DBWn在后续时机把脏块写回数据文件。整条链路中，任何一个环节的等待都会体现为响应时间。