应优先配置LARGE_POOL_SIZE而非盲目调大SGA或PGA；RMAN通道缓冲默认从LARGE_POOL分配，未配置时退至PGA易致ORA-04030；需按通道数×单通道缓冲（1–4MB）预估并静态设置LARGE_POOL_SIZE。
RMAN备份报 ORA-04030：内存不足，怎么办
直接结论：不是加大 sga 或盲目调高 pga_aggregate_target 就能解决；rman 通道缓冲默认走 pga，但大块并行备份/恢复时，更应优先配 large_pool_size，否则容易触发 ora-04030: out of process memory —— 尤其在启用 backup ... parallelism 或使用 sbt_tape 通道时。
为什么 RMAN 不走 SGA，而依赖 LARGE_POOL（或 PGA）
RMAN 的 I/O 缓冲区（比如每个通道的 1MB~4MB buffer）不从共享池分配，也不走标准 SGA。它优先尝试从 LARGE_POOL 分配；若未配置，则退回到 PGA。但 PGA 是按会话独占的，多个 RMAN 通道并发时，每个通道都申请自己的缓冲区，极易耗尽单个进程的 PGA 上限（尤其 PGA_AGGREGATE_LIMIT 设得保守时）。
-
LARGE_POOL是共享内存池，专为需要大块连续内存的操作设计（如 RMAN、MTS、DBWR_IO_SLAVES） - 如果没开
LARGE_POOL，RMAN 会把缓冲塞进 PGA，但 PGA 的 per-process 限制（_pga_max_size隐含参数或PGA_AGGREGATE_LIMIT）常比预期小 - Oracle 12c+ 默认不启用
LARGE_POOL，除非显式设置；11g 可能随 AMM 自动分配，但不可靠
怎么配 LARGE_POOL_SIZE 才有效
关键不是“越大越好”，而是匹配你的通道数 × 单通道缓冲大小。RMAN 默认单通道缓冲是 1MB，但实际可到 4MB（取决于块大小和设备类型）。用 ALLOCATE CHANNEL ... MAXPIECESIZE 或压缩/加密会间接影响缓冲需求。
- 先查当前配置：
SHOW PARAMETER large_pool_size；若返回 0 或空，说明未启用 - 基本公式：设你跑 4 个通道，每通道按 2MB 缓冲算 → 至少预留
8M，再加 20% 余量 → 建议设LARGE_POOL_SIZE = 10M - 动态生效需重启实例（
LARGE_POOL_SIZE是静态参数），不能ALTER SYSTEM SET ... SCOPE=BOTH - 验证是否生效：运行 RMAN 后查
V$SGASTAT，过滤NAME = 'free memory' AND POOL = 'large pool'，看剩余是否明显下降
什么时候该调 PGA，而不是 LARGE_POOL
只在两种场景下才考虑动 PGA：一是根本没法改 LARGE_POOL_SIZE（比如生产库不允许重启），二是你用的是非归档模式下的快速增量备份（INCREMENTAL LEVEL 1 CUMULATIVE），且启用了 CHANGE TRACKING，此时部分元数据处理逻辑会多占 PGA。
- 临时缓解：在 RMAN 脚本开头加
SET COMMAND ID TO 'rman_bk_01';，配合ALTER SYSTEM KILL SESSION快速回收异常卡住的通道进程，避免 PGA 泄漏 - 真要调 PGA：优先调
PGA_AGGREGATE_LIMIT（硬上限），而非PGA_AGGREGATE_TARGET（软目标）；否则可能被自动 kill 进程 - 注意
_pga_max_size隐含参数（默认约 200MB），它会单方面限制每个进程 PGA 上限，即使PGA_AGGREGATE_LIMIT很大也无效 —— 查它要用SELECT KSPPINM, KSPPSTVL FROM X$KSPPSV WHERE KSPPINM = '_pga_max_size';
最常被忽略的一点：RMAN 的 ALLOCATE CHANNEL 语句里加 MAXOPENFILES 或 READRATE 看似能控资源，其实不影响缓冲区分配逻辑；真正起作用的只有 LARGE_POOL_SIZE 是否存在、够不够，以及单个通道有没有因 bug（如某些 11.2.0.4 补丁缺失）把缓冲错误地反复重分配。
