Oracle数据库共享池内存结构，保留池详细介绍

原创于 2025-09-13 10:15:56 发布 · 1k 阅读

29 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #oracle

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

584 篇文章

订阅专栏

在这里插入图片描述

好的，我们将深入探讨 Oracle 共享池中一个精巧而重要的设计——保留池（Reserved Pool / Reserved Heap）。它是解决共享池碎片化问题、预防 ORA-04031 错误的关键机制。

1. 保留池的核心作用与原理

官方/专业解释

保留池是共享池内部一块被预先保留出来的独立内存区域，由其自身的内存管理器（Heap）进行管理。它专门用于满足大的内存分配请求（通常大于 _shared_pool_reserved_min_alloc 隐含参数，默认值约为 4400 字节）。

其设计目的是防止单次大的内存分配操作对主共享池（Main Shared Pool）的结构造成严重破坏，从而避免内存碎片化。

通俗解释

想象共享池主堆是一个繁忙的“公共自习室”，里面有很多学生在用大小不一的桌子（Chunk）学习。

问题场景：突然来了一个小组项目团队，需要拼起一张非常大的长桌（大内存分配请求）。如果只能在自习室里拼桌，他们就不得不把很多张正在被使用的小桌子强行挪开、合并。这个过程会打扰很多其他同学（产生碎片），而且拼完后，自习室里会留下很多难以利用的犄角旮旯（小空闲块）。
解决方案（保留池）：自习室的管理员很聪明，他专门在旁边隔出了一个“VIP小组讨论室”（保留池）。这个讨论室里预先放了几张固定的大长桌。
- 以后，但凡有需要大桌子的小组（大内存请求），直接领到VIP室去。
- 这样，无论他们在里面怎么折腾，都不会影响到外面公共自习室的布局和秩序。

保留池就是这样一间“VIP室”，它通过隔离大请求，有效地保护了主共享池的结构完整性。

2. 工作原理与分配流程

官方/专业解释

阈值判断：当内存管理器收到一个分配请求时，首先会检查其请求的大小。
路由决策：
- 如果请求的大小 小于或等于 _shared_pool_reserved_min_alloc，则该请求由主共享池的 Free Lists 来满足。
- 如果请求的大小大于 _shared_pool_reserved_min_alloc，则该请求会被路由到保留池的 Free List 进行处理。
独立管理：保留池拥有自己独立的 Free List 结构。它从主共享池中“挖走”一大块内存后，就自行管理这块区域的分配和释放，与主堆互不干扰。
Fallback 机制：如果保留池中的空间不足，无法满足一个大请求，内存管理器会** fallback **（回退）到主共享池中去尝试分配。这个过程记录在 V$SHARED_POOL_RESERVED.REQUEST_MISSES 中。

通俗解释

继续上面的比喻：
自习室管理员定了个规矩：需要超过 4 个人的桌子（>4400字节），请直接去VIP室。

一个3人小组来了，需求小，就在公共区找空位（主堆分配）。
一个8人项目组来了，需求大，管理员直接带他们去VIP室（路由到保留池）。
某天VIP室满了，但又来了一个8人组。管理员没办法，只好破例，在公共区艰难地给他们拼一张大桌（Fallback 到主堆）。这个过程很麻烦，管理员会记录下来（REQUEST_MISSES +1）。
如果在公共区也拼不出大桌，那就只能拒绝请求了（REQUEST_FAILURES +1，可能导致 ORA-04031）。

3. 相关查询与管理 SQL 命令

监控和管理保留池，主要依靠 V$SHARED_POOL_RESERVED 动态性能视图。

查询 1：查看保留池的整体状态和使用情况

这是最重要的诊断查询。

SELECT *
FROM v$shared_pool_reserved;

关键字段解读：

字段	官方解释	通俗解释	健康指标
`FREE_SPACE`	保留池中当前空闲的内存总量（字节）。	VIP室里还剩下多少“空着的桌子面积”。	应大于0。
`REQUEST_MISSES`	请求在保留池中分配失败、不得不回退（fallback）到主共享池的次数。	“VIP室满员，被迫在公共区拼大桌”的次数。	这是核心指标。理想应为0或长期稳定。如果持续增长，是调整信号。
`REQUEST_FAILURES`	请求即使在主共享池中也分配失败的次数。	“在公共区也拼不出大桌”的次数。	必须为0。大于0则可能已发生ORA-04031错误。
`LAST_FAILURE_SIZE`	最近一次分配失败所请求的大小（字节）。	最近一次是哪个大小的“桌子”没拼起来。	用于诊断问题大小。
`MAX_USED_SPACE`	自实例启动以来，保留池使用空间达到的最大值。	VIP室历史上最多同时用了多大的地方。	用于评估保留池大小是否合理。

查询 2：检查保留池的大小配置

-- 查看当前保留池的配置大小
SELECT name, value 
FROM v$parameter 
WHERE name = 'shared_pool_reserved_size';

-- 查看隐含参数（最小分配阈值），通常无需修改
SELECT ksppinm, ksppstvl 
FROM x$ksppi x, x$ksppcv y 
WHERE x.indx = y.indx 
AND ksppinm = '_shared_pool_reserved_min_alloc';

查询 3：深入保留池内部（谨慎使用）

与查询主堆类似，可以查看保留池内部的 Chunk 分布，但需格外小心其对性能的影响。

SELECT 
    KSMCHCLS AS chunk_class,
    COUNT(*) AS chunk_count,
    ROUND(SUM(KSMCHSIZ) / 1024, 2) AS total_size_kb,
    ROUND(AVG(KSMCHSIZ)) AS avg_size_bytes
FROM x$ksmsp 
WHERE KSMCHCLS LIKE 'R-%' -- 专门查看保留池中的块（以'R-'前缀开头）
GROUP BY KSMCHCLS;

R-free: 保留池中的空闲块。
R-rcre: 保留池中的可重建块。
R-perm: 保留池中的永久块。

4. 管理命令与优化建议

基于 V$SHARED_POOL_RESERVED 的监控结果，可以采取以下管理措施：

场景一：`REQUEST_MISSES` 持续增长，但 `REQUEST_FAILURES` 为 0

诊断：保留池大小不足，导致大请求频繁 fallback 到主堆。这会加剧主堆的碎片化风险。

解决方案： 增加保留池的大小。

-- 首先检查当前设置和SGA大小
SHOW PARAMETER shared_pool_reserved_size;
SHOW PARAMETER shared_pool_size;

-- 通常设置为 shared_pool_size 的 5% 到 10%
ALTER SYSTEM SET shared_pool_reserved_size = 100M; -- 例如，增加到100M

场景二：`REQUEST_FAILURES` > 0

诊断：情况紧急。不仅保留池满了，主堆也由于碎片化无法满足大请求，应用程序可能已经开始报 ORA-04031 错误。
解决方案：
1. 立即补救：临时刷新共享池（注意：这是重磅操作，会导致所有SQL硬解析，务必谨慎！）。
```
ALTER SYSTEM FLUSH SHARED_POOL;
```
  这会清空所有可重建对象，合并碎片，瞬间提供大量连续空间。
2. 根本解决：
  - 如上所述，增加 shared_pool_reserved_size。
  - 考虑增加整个 shared_pool_size。
  - 优化应用程序：这是最根本的。检查是否有大量未经绑定变量的SQL，或者是否可以避免在运行时加载极大的PL/SQL包。

场景三：`FREE_SPACE` 始终很大，`REQUEST_MISSES` 为 0

诊断：保留池尺寸配置过大，内存未被充分利用。
解决方案：可以考虑适当调小 shared_pool_reserved_size，将更多内存留给主共享池使用。
```
ALTER SYSTEM SET shared_pool_reserved_size = 50M;
```

总结

保留池是 Oracle 设计的一个精巧的“防火墙”机制，通过空间换稳定的策略，将具有破坏性的大内存分配操作隔离到一个独立区域，从而保护主共享池的结构。

最佳实践：

持续监控：定期检查 V$SHARED_POOL_RESERVED 视图，重点关注 REQUEST_MISSES 的趋势。
合理配置：将 shared_pool_reserved_size 设置为 shared_pool_size 的 5%-10% 是一个良好的起点，并根据监控数据进行调整。
治本之策：优化应用程序，使用绑定变量，减少不必要的解析操作，这才是减轻共享池整体压力、避免碎片化的根本办法。

通过理解和有效管理保留池，你可以显著提高数据库的稳定性，减少令人头疼的 ORA-04031 错误的发生。

欢迎关注我的公众号《IT小Chen》