今日在开发一个核心系统库上执行一个非常大的数据库脱敏脚本，由于脚本涉及到40多个表，开发保证要一次脱敏成功，一次，在执行40多个表的脱敏脚本时，不能一个一个表的提交数据，要等待最后一次提交，这样就造成一个非常大的事务。由于这个开发库还使用了ogg同步数据，使用的ogg Downstream 集成捕获方式，因此ogg抽取进程ABENDING，查看ogg的报错信息如下。我猜想应该是事务太大，造成的抽取进程ABENDING.

2026-07-27T09:54:25.753+0800  ERROR   OGG-00662  Oracle GoldenGate Capture for Oracle, extuat1.prm:  OCI Error ORA-03113: end-of-file on communication channel
                              Process ID: 215847
                              Session ID: 410 Serial number: 35343
                               (status = 3113).
2026-07-27T09:54:25.827+0800  ERROR   OGG-02078  Oracle GoldenGate Capture for Oracle, extuat1.prm:  Extract encountered a fatal error in a processing thread and is abending.
2026-07-27T09:54:25.845+0800  ERROR   OGG-01668  Oracle GoldenGate Capture for Oracle, extuat1.prm:  PROCESS ABENDING.
2026-07-27T09:55:02.003+0800  INFO    OGG-00987  Oracle GoldenGate Command Interpreter for Oracle:  GGSCI command (oracle): info *.
2026-07-27T09:55:02.237+0800  INFO    OGG-00987  Oracle GoldenGate Command Interpreter for Oracle:  GGSCI command (oracle): info PMQ.
2026-07-27T09:55:10.043+0800  INFO    OGG-00987  Oracle GoldenGate Command Interpreter for Oracle:  GGSCI command (oracle): info *.
2026-07-27T09:55:17.816+0800  INFO    OGG-00987  Oracle GoldenGate Command Interpreter for Oracle:  GGSCI command (oracle): start EXTUAT1.
2026-07-27T09:55:17.834+0800  INFO    OGG-00963  Oracle GoldenGate Manager for Oracle, mgr.prm:  Command received from GGSCI on host [127.0.0.1]:30270 (START EXTRACT EXTUAT1 ).
2026-07-27T09:55:17.844+0800  INFO    OGG-00960  Oracle GoldenGate Manager for Oracle, mgr.prm:  Access granted (rule #1).
2026-07-27T09:55:17.850+0800  INFO    OGG-00975  Oracle GoldenGate Manager for Oracle, mgr.prm:  EXTRACT EXTUAT1 starting.
2026-07-27T09:55:17.901+0800  INFO    OGG-00992  Oracle GoldenGate Capture for Oracle, extuat1.prm:  EXTRACT EXTUAT1 starting.
2026-07-27T09:55:17.909+0800  INFO    OGG-03059  Oracle GoldenGate Capture for Oracle, extuat1.prm:  Operating system character set identified as UTF-8.
2026-07-27T09:55:17.909+0800  INFO    OGG-02695  Oracle GoldenGate Capture for Oracle, extuat1.prm:  ANSI SQL parameter syntax is used for parameter parsing.
2026-07-27T09:55:17.910+0800  INFO    OGG-02095  Oracle GoldenGate Capture for Oracle, extuat1.prm:  Successfully set environment variable NLS_LANG=AMERICAN_AMERICA.ZHS16GBK.
2026-07-27T09:55:17.984+0800  INFO    OGG-01360  Oracle GoldenGate Capture for Oracle, extuat1.prm:  EXTRACT is running in Integrated mode.
2026-07-27T09:55:18.598+0800  WARNING OGG-04033  Oracle GoldenGate Capture for Oracle, extuat1.prm:   LOGALLSUPCOLS has set the NOCOMPRESSDELETES and GETUPDATEBEFORES parameters on.
2026-07-27T09:55:18.671+0800  INFO    OGG-02734  Oracle GoldenGate Capture for Oracle, extuat1.prm:  Using heartbeat table from schema ggadmin.
2026-07-27T09:55:18.681+0800  INFO    OGG-01815  Oracle GoldenGate Capture for Oracle, extuat1.prm:  Virtual Memory Facilities for: BR
                                  anon alloc: mmap(MAP_ANON)  anon free: munmap
                                  file alloc: mmap(MAP_SHARED)  file free: munmap
                                  target directories:
                                  /oradata/ogg19c_uat/BR/EXTUAT1.
2026-07-27T09:55:18.683+0800  INFO    OGG-01851  Oracle GoldenGate Capture for Oracle, extuat1.prm:  filecaching started: thread ID: 140484993349184.
2026-07-27T09:55:18.685+0800  INFO    OGG-01815  Oracle GoldenGate Capture for Oracle, extuat1.prm:  Virtual Memory Facilities for: COM
                                  anon alloc: mmap(MAP_ANON)  anon free: munmap
                                  file alloc: mmap(MAP_SHARED)  file free: munmap
                                  target directories:
                                  /oradata/ogg19c_uat/dirtmp.
2026-07-27T09:55:18.695+0800  INFO    OGG-01639  Oracle GoldenGate Capture for Oracle, extuat1.prm:  BOUNDED RECOVERY:  ACTIVE: for object pool 1: p866047_extr.
2026-07-27T09:55:18.695+0800  INFO    OGG-01640  Oracle GoldenGate Capture for Oracle, extuat1.prm:  BOUNDED RECOVERY: recovery start XID: 1.15.25.74321.

OGG部署方式是采用的是Downstream 集成模式，（针对你 Downstream 集成捕获场景）

MAX_SGA_SIZE 控制的是下游挖掘库 LogMiner 内核缓冲区（streams_pool）， LogMiner 本身没有 “本地磁盘缓存溢出” 能力。当源库存在长时间未提交超大事务，所有 redo 变更必须全部缓存在 MAX_SGA_SIZE 划定的内存里；内存填满之后：

LogMiner 无法继续缓存 redo；
Oracle 内核直接杀掉 LogMiner 会话；
OGG Extract 收到 ORA-03113，进程 ABEND。

👉 关键点区分两套独立缓存，千万不要混淆：

LogMiner 缓冲区（MAX_SGA_SIZE /streams_pool）：数据库内核内存，不能溢出到磁盘！内存满直接崩。
OGG Extract CACHEMGR 缓存：OGG 进程用户态缓存，可以溢出到本地磁盘。

很多运维踩坑：调大了 CACHEMGR，但是不去解决 MAX_SGA_SIZE不足，依旧崩溃。因为瓶颈发生在数据库 LogMiner 阶段（还没走到 OGG CACHEMGR）。

一、两层缓存完整数据流（Downstream 集成捕获）

源库redo → 下游Mining库LogMiner（MAX_SGA_SIZE/streams_pool）
           ↓（解析完成事务数据输出）
        OGG Extract进程 → CACHEMGR（内存/磁盘溢出）→ trail文件

顺序不可逆：先过 LogMiner 内存，再进 OGG 进程缓存。LogMiner 内存撑不住，直接断会话，OGG 侧磁盘缓存完全没有机会生效。

二、分方案解决：MAX_SGA_SIZE 不足

方案 1：治本最优方案（业务层面）

拆分长事务，杜绝几小时不提交的超大事务只要事务及时 commit，LogMiner 立刻释放该事务占用的 streams_pool 内存，不会持续累积。没有任何参数可以替代这个方案。

方案 2：数据库侧扩容（LogMiner 内存层）

下游挖掘库增大 streams_pool_size

alter system set streams_pool_size=6G scope=spfile; -- 根据业务调整，重启库生效

2. Extract 参数上调 MAX_SGA_SIZE

TRANLOGOPTIONS INTEGRATEDPARAMS (
MAX_SGA_SIZE 4096,
PARALLELISM 4,
DOWNSTREAM_REAL_TIME_MINE Y
)

约束：单 Extract

上限：不建议单进程 MAX_SGA 超过 4G；受限于数据库 SGA 硬件资源。

方案 3：OGG 进程侧启用磁盘缓存（只能解决第二层瓶颈，无法救 LogMiner 内存溢出）

即便 LogMiner 正常解析出事务，巨型事务会占用 Extract 进程内存，此时开启 CACHEMGR 磁盘溢出。添加到 Extract 参数：

CACHEMGR CACHESIZE 2048M
CACHEMGR CACHEDIRECTORY /ogg/tmp

参数含义

CACHESIZE：优先使用内存缓存上限；
CACHEDIRECTORY：内存满后，事务临时落地磁盘，避免 OGG 进程直接 abend；

⚠️ 重要提醒：这条配置无法解决「MAX_SGA_SIZE 过小导致 LogMiner 会话被杀」问题！仅仅防止 “解析成功之后” OGG 进程缓存溢出。

三、大家最关心的问题：能不能让 LogMiner 把溢出数据缓存到本地磁盘？

明确答案：

✅ 原生 Oracle LogMiner（集成捕获）不支持磁盘溢出！Classic 传统 Extract 可以依靠 OGG 自身缓存，但是 Integrated Capture（Downstream / 本地集成捕获）底层 LogMiner 由数据库内核驱动，设计约束：未提交事务的 redo 必须保存在 SGA streams_pool，没有磁盘 swap 机制。

对比两种 Extract 模式巨大差异：

Classic Extract（非集成）OGG 进程直接读取 redo，事务缓存由 OGG CACHEMGR 管理，可以溢出磁盘。
Integrated Capture（Downstream / 本地集成捕获）解析工作交给数据库 LogMiner，第一道关卡内存不能落地磁盘，内存上限由 MAX_SGA_size 控制。

这就是 Downstream 模式处理大事务天生更脆弱的根源。

四、应急兜底组合配置（直接复制使用）

EXTRACT extuat1
USERIDALIAS ogg_mining
TRANLOGOPTIONS MININGUSERALIAS ogg_mining
TRANLOGOPTIONS INTEGRATEDPARAMS (
MAX_SGA_SIZE 4096,
PARALLELISM 4,
DOWNSTREAM_REAL_TIME_MINE Y
)
# OGG进程缓存，内存溢出落地磁盘（第二层保护）
CACHEMGR CACHESIZE 2048M
CACHEMGR CACHEDIRECTORY /ogg/tmp
WARNLONGTRANS 1H, CHECKINTERVAL 5M
LOGALLSUPCOLS
UPDATERECORDFORMAT COMPACT
EXTTRAIL /ogg/dirdat/lt
TABLE src.*;

五、监控判断瓶颈在哪

1、判断瓶颈在 LogMiner（你的故障场景）

下游挖掘库持续观察 streams_pool 占用持续上涨，出现： ORA-04031 / Extract 报 OGG-02051 / ORA-03113

👉 解决方案：扩容 streams_pool、上调 MAX_SGA_SIZE、拆分大事务。

2、判断瓶颈在 OGG CACHEMGR

Extract 报告出现 OGG-01668 OGG-02074 Large transaction exceeds cache limits

👉 启用 CACHEMGR 磁盘缓存即可。

六、如果硬件无法继续扩容下游库 SGA，终极备选架构方案

当业务持续产生超大型事务，内存无论怎么调都扛不住 Downstream 集成捕获：

放弃 Downstream 模式，切换为 Classic Extract（传统抽取）Classic Extract 不依赖 LogMiner、不占用下游库 streams_pool，事务缓存由 OGG 进程接管，支持磁盘溢出；
弊端：源库需要部署 OGG 软件，源库压力上升。

七、高频误区汇总

❌ 配置 CACHEMGR 磁盘目录，就能解决 MAX_SGA_SIZE 不足错误！瓶颈在数据库内核 LogMiner 阶段，还没走到 OGG 缓存。
❌ MAX_SGA 调大到超过 streams_pool 可用内存触发 OGG-02050，启动直接失败。
❌ Downstream 实时挖掘和归档挖掘，内存压力一致DOWNSTREAM_REAL_TIME_MINE Y（实时挖掘）内存压力更大，需要预留更多 streams_pool。

极简总结

LogMiner（MAX_SGA_SIZE）没有磁盘缓存能力，内存满直接会话断开；
CACHEMGR 磁盘溢出只保护 OGG 进程层，不能保护 LogMiner；
Downstream 模式遇到超大事务最优路径：拆分事务 > 扩容 streams_pool+MAX_SGA_SIZE；
硬件资源达到上限，可考虑切换 Classic Extract 架构规避 LogMiner 内存约束。

ITPub博客

第74期 ogg Downstream 集成捕获max_sga_size 过小导致EXTRACT 进程ABENDING