在 Oracle 数据库的内存管理中，共享池（Shared Pool）和大池（Large Pool）是 SGA（系统全局区）中负责缓存与资源分配的核心组件。合理配置和调优这两个池，能显著提升数据库性能 —— 尤其是在减少解析开销、降低锁竞争、优化内存利用率等方面。本文基于 Oracle 19c 官方文档，系统梳理共享池与大池的调优思路、关键配置及实践方法。

共享池：核心缓存与解析优化的关键

共享池是 SGA 中用于缓存 SQL/PLSQL 代码、数据字典信息、结果集等核心数据的内存区域。其核心价值在于通过重用已解析的代码和字典数据，减少 CPU 消耗、降低 I/O 操作，并避免频繁的内存锁竞争。

一、共享池的核心组件与作用

共享池的性能直接取决于内部组件的高效运作，主要包含以下核心部分：

库缓存（Library Cache）：存储 SQL/PLSQL 代码的可执行形式（解析或编译后）。当执行 SQL 时，若库缓存中存在可重用的解析结果（软解析），可避免重新解析（硬解析）；反之则需执行硬解析，消耗更多 CPU 和内存资源。
数据字典缓存（Data Dictionary Cache）：缓存数据字典元数据（如用户名、表空间信息、权限定义等）。数据库解析 SQL 或编译 PLSQL 时需频繁访问这些信息，缓存命中可减少磁盘 I/O。
服务器结果缓存（Server Result Cache，可选）：存储查询或 PLSQL 函数的结果，适用于重复执行且结果稳定的场景（如静态报表查询）。
保留池（Reserved Pool）：共享池内部分割的专用区域，用于分配超过 5KB 的大对象（如大型 PLSQL 包），避免因内存碎片导致的分配失败。

二、共享池高效使用的核心原则

要发挥共享池的性能优势，需从应用设计和数据库配置两方面入手，核心目标是最大化软解析、减少硬解析。

1. 优先使用绑定变量，避免字面量 SQL

硬解析的主要诱因之一是 SQL 语句中使用字面量（如SELECT * FROM employees WHERE dept_id=10）而非绑定变量（如SELECT * FROM employees WHERE dept_id=:dept_id）。字面量 SQL 即使逻辑相同，也会被视为不同语句，导致库缓存无法重用。

实践建议：
- 开发时强制使用绑定变量，避免动态拼接含字面量的 SQL；
- 对无法修改的 legacy 应用，可通过设置CURSOR_SHARING=FORCE（默认EXACT）让数据库自动将字面量替换为绑定变量（需注意：可能影响执行计划适应性，建议结合自适应游标共享使用）。

2. 标准化 SQL 编写规范

Oracle 判断 SQL 是否可共享的标准是 “完全一致”—— 包括大小写、空格、注释、对象引用等。例如以下语句会被视为不同 SQL：

SELECT * FROM employees;
SELECT * FROM Employees; -- 大小写不同
SELECT *  FROM employees; -- 空格数量不同

实践建议：统一 SQL 格式（如自动转为大写、压缩空格），避免注释嵌入 SQL；使用显式对象所有者（如hr.employees）而非依赖公有同义词。

3. 控制游标生命周期，减少解析频率

频繁关闭和重新打开游标会导致重复解析。应根据 SQL 执行频率优化游标管理：

对高频执行的 SQL（如 OLTP 核心交易），保持游标打开并重用（如通过 OCI 保留游标、JDBC 设置语句缓存）；
对低频执行的 SQL，可关闭游标释放内存，避免长期占用共享池。

4. 避免高峰时段执行 DDL

DDL 操作（如ALTER TABLE）会导致依赖的 SQL 失效（INVALIDATIONS），触发大量硬解析。例如修改表结构后，所有引用该表的 SQL 需重新解析。

实践建议：DDL 尽量在低峰期执行；执行后可通过DBMS_SHARED_POOL.KEEP将核心 SQL 重新固定到共享池。

三、共享池的配置与调优

共享池的调优核心是 “合理 sizing”—— 既保证缓存高频数据，又不浪费内存。需结合监控指标动态调整。

1. 共享池大小调整（SHARED_POOL_SIZE）

初始配置：OLTP 系统建议共享池占 SGA 的 20%-30%；DSS 系统可适当降低（因 SQL 重复率低）。
监控指标：
- 通过V$LIBRARYCACHE查看RELOADS（缓存项被换出后重新加载的次数）：理想值接近 0，若持续增长需增大共享池；
- 通过V$ROWCACHE计算数据字典缓存命中率：(SUM(gets - getmisses)/SUM(gets))*100，应高于 90%；
- 通过V$SGASTAT查看共享池 “free memory”：长期空闲内存过多说明配置过大，需缩减。
调整方法：通过ALTER SYSTEM SET SHARED_POOL_SIZE = <size>M;动态调整（需确保 SGA 有足够余量）。

2. 保留池配置（SHARED_POOL_RESERVED_SIZE）

保留池用于大对象分配，默认值为共享池的 5%。若大对象分配频繁失败（如 PLSQL 包编译报错），需调整：

监控指标：V$SHARED_POOL_RESERVED中的REQUEST_FAILURES（分配失败次数）：若大于 0 且增长，需增大保留池；
配置原则：SHARED_POOL_RESERVED_SIZE建议不超过共享池的 10%（避免挤压普通缓存区），调整时需同步增大SHARED_POOL_SIZE（保留池从共享池中划分）。

3. 游标缓存与固定（减少换出）

会话游标缓存：通过SESSION_CACHED_CURSORS设置每个会话缓存的关闭游标数量（默认 50），减少重复解析。可通过V$SESSTAT中 “session cursor cache hits” 监控命中率，若低于 5% 需增大该值。

固定核心对象：通过DBMS_SHARED_POOL.KEEP将高频使用的 SQL、PLSQL 包固定在共享池（避免被 LRU 算法换出），例如：

-- 固定指定SQL（需先获取SQL_ID）
SELECT address, hash_value FROM v$sql WHERE sql_id = 'abc123';
EXEC DBMS_SHARED_POOL.KEEP(address => '<address>', flag => 'C');

大池：隔离大型内存分配，减少共享池碎片

大池是独立于共享池的内存区域，专为大型内存分配设计（如共享服务器会话内存、并行查询缓冲区、RMAN 备份缓冲区）。其核心价值是避免大型分配导致共享池碎片化，保障库缓存和字典缓存的稳定性。

一、大池的适用场景

大池并非必需组件，但在以下场景中建议配置：

共享服务器架构：共享服务器的 UGA（用户全局区）需从大池分配（而非共享池），避免挤占 SQL 缓存内存；
并行查询：并行执行的消息缓冲区从大池分配，减少共享池压力；
RMAN 备份 / 恢复：RMAN 的 I/O 缓冲区（通常数百 KB）从大池分配，避免共享池碎片。

二、大池的配置与调优

大池无 LRU 机制（不会主动换出对象），配置需基于实际内存需求。

1. 大池大小调整（LARGE_POOL_SIZE）

初始配置：根据使用场景估算：
- 共享服务器：每个会话约需 200-300KB，按最大并发会话数计算（如 100 会话需 30MB）；
- 并行查询：每个并行服务器进程约需 1-2MB，按最大并行度计算；
- RMAN：单通道约需 1-4MB，按并发通道数计算。
监控指标：通过V$SGASTAT查看大池 “free memory”：若长期不足（频繁分配失败）需增大，若长期空闲需缩减；
配置方法：ALTER SYSTEM SET LARGE_POOL_SIZE = <size>M;（最小 300KB）。