暂无图片
暂无图片
3
暂无图片
暂无图片
暂无图片
首页 / OGG 19c 捕获进程报错 ORA-01562 解决办法

OGG 19c 捕获进程报错 ORA-01562 解决办法

原创 JiekeXu All China Database Union 5天前
108

大家好，我是 JiekeXu,江湖人称“强哥”，青学会MOP技术社区主席，荣获Oracle ACE Pro称号，OpenTenBase ACE，金仓社区最具价值倡导者KVA，崖山最具价值专家YVP，IvorySQL开源社区专家顾问委员会成员，KWDB社区MVP，墨天轮MVP，墨天轮连续多年度“墨力之星”，拥有Oracle OCP/OCM认证,MySQL 5.7/8.0 OCP认证以及金仓KCA、KCP、KCM、KCSM证书，TiDB PCTA/PCTP证书、PCA、OBCA、OGCA等众多国产数据库认证证书,专注于数据库技术、系统架构及大数据运维，致力于分享最纯粹、最接地气的 DBA 实战与前沿技术洞察。如果你也对数据技术充满热忱，欢迎关注我的微信公众号“JiekeXu DBA之路”点赞、转发与评论，谢谢！

快要下班的时候，测试环境一数据同步链路 OGG 源端捕获进程报错，持续半个小时无法自动拉起（因配有自动拉起的定时任务），只能登录环境检查原因了，也是好久没有遇到 OGG 的错误了，故此记录一下。

OGG 19c 报错 ORA-01562: failed to extend rollback segment number

登录源端 OGG 环境，查看报错信息。

GGSCI (oracle) 1> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING
EXTRACT     RUNNING     DPE1        00:00:00      00:00:01
EXTRACT     ABENDED     EXT1        00:00:01      00:53:02

GGSCI (oracle) 2> view report ext1


2026-09-24 14:10:40  INFO    OGG-01738  BOUNDED RECOVERY: CHECKPOINT: for object pool 1: p13992_extr: start=SeqNo: 2092216, RBA: 9570196, SCN: 29.1320565651 (125874617235), Timestamp: 2026-09-24 14:10:26.000000, Thread: 1
, end=SeqNo: 2092216, RBA: 9570196, SCN: 29.1320565651 (125874617235), Timestamp: 2026-09-24 14:10:26.000000, Thread: 1.

Source Context :
  SourceModule            : [er.redo.oraxo]
  SourceID                : [er/redo/oracle/redooraix.c]
  SourceMethod            : [handleReadError]
  SourceLine              : [17455]
  ThreadBacktrace         : [11] elements
                          : [/data/ogg19c/libgglog.so(CMessageContext::AddThreadContext())]
                          : [/data/ogg19c/libgglog.so(CMessageFactory::CreateMessage(CSourceContext*, unsigned int, ...))]
                          : [/data/ogg19c/libgglog.so(_MSG_Int32_String(CSourceContext*, int, int, char const*, CMessageFactory::MessageDisposition))]
                          : [/data/ogg19c/extract(RedoIE::handleReadError(char (&) [2048]))]
                          : [/data/ogg19c/extract()]
                          : [/data/ogg19c/extract(ProducerContext::readLCR(bool&, bool&))]
                          : [/data/ogg19c/extract(IXFormatter::readLCR())]
                          : [/data/ogg19c/extract(IXFormatter::FormatterThread(void*))]
                          : [/data/ogg19c/extract(ggs::gglib::MultiThreading::Thread::RunThread(ggs::gglib::MultiThreading::Thread::ThreadArgs*))]
                          : [/lib64/libpthread.so.0()]
                          : [/lib64/libc.so.6(clone)]

2026-09-24 18:02:05  ERROR   OGG-00662  OCI Error ORA-01562: failed to extend rollback segment number
 (status = 1562).

Source Context :
  SourceModule            : [er.redo.ora.IXFormatter]
  SourceID                : [er/redo/oracle/IXFormatter.cpp]
  SourceMethod            : [getResult]
  SourceLine              : [802]
  ThreadBacktrace         : [15] elements
                          : [/data/ogg19c/libgglog.so(CMessageContext::AddThreadContext())]
                          : [/data/ogg19c/libgglog.so(CMessageFactory::CreateMessage(CSourceContext*, unsigned int, ...))]
                          : [/data/ogg19c/libgglog.so(_MSG_(CSourceContext*, int, CMessageFactory::MessageDisposition))]
                          : [/data/ogg19c/extract()]
                          : [/data/ogg19c/extract(RedoIE::readLCR(ggs::gglib::gglcr::CommonLCR**, long&, bool&))]
                          : [/data/ogg19c/extract(ggs::er::OraTranLogDataSource::readLCR(ggs::gglib::gglcr::CommonLCR**, long&, bool&))]
                          : [/data/ogg19c/extract(ggs::er::ExtractContext::processExtractLoop())]
                          : [/data/ogg19c/extract(ggs::er::ExtractContext::run())]
                          : [/data/ogg19c/extract()]
                          : [/data/ogg19c/extract(ggs::gglib::MultiThreading::MainThread::ExecMain())]
                          : [/data/ogg19c/extract(ggs::gglib::MultiThreading::Thread::RunThread(ggs::gglib::MultiThreading::Thread::ThreadArgs*))]
                          : [/data/ogg19c/extract(ggs::gglib::MultiThreading::MainThread::Run(int, char**))]
                          : [/data/ogg19c/extract(main)]
                          : [/lib64/libc.so.6(__libc_start_main)]
                          : [/data/ogg19c/extract()]

2026-09-24 18:02:05  ERROR   OGG-02078  Extract encountered a fatal error in a processing thread and is abending.

问题现象是 GoldenGate Extract 进程（Integrated Extract 模式）读取源端 Oracle Redo Log 时，源端数据库报了 ORA-01562（回滚段/UNDO 表空间无法扩展），导致 Extract 进程 Abend 崩溃。

错误链路解读

OGG-00662  OCI Error ORA-01562: failed to extend rollback segment number
    ↓
源端 Oracle 的 UNDO 表空间满了，无法给 GoldenGate 的查询事务分配回滚段
    ↓
SourceModule: er.redo.oraxo (Integrated Extract 的 redo 读取模块)
SourceMethod: handleReadError → readLCR → OraTranLogDataSource::readLCR
    ↓
OGG-02078  Extract 遇到致命错误，进程 Abend

Integrated Extract 使用 Oracle LogMiner 基础设施读取 Redo Log，过程中需要查询源端数据库（LogMiner 字典构建、对象元数据查询、补充日志解析等），这些查询会消耗 UNDO 空间。当 UNDO 表空间不足时，查询事务无法扩展回滚段 → ORA-01562 → Extract 崩溃。

问题排查第一步：确认 UNDO 表空间状态

在源端 Oracle 数据库上执行：

-- 1. UNDO 表空间大小和自动扩展状态
col FILE_NAME for a60
col TABLESPACE_NAME for a15

SELECT tablespace_name, file_name,
       round(bytes/1024/1024,2) AS size_mb,
       round(maxbytes/1024/1024,2) AS max_mb,
       autoextensible
FROM dba_data_files
WHERE tablespace_name = (
  SELECT value FROM v$parameter WHERE name = 'undo_tablespace'
);

TABLESPACE_NAME FILE_NAME                                           SIZE_MB     MAX_MB AUT
--------------- -------------------------------------------------- ---------- ---------- ---
UNDOTBS1        /data/spedw/oradata/spedw/undotbs01.dbf              32767.98   32767.98 YES

-- 2. UNDO 表空间剩余空间
SELECT tablespace_name,
       round(sum(bytes)/1024/1024,2) AS free_mb
FROM dba_free_space
WHERE tablespace_name = (
  SELECT value FROM v$parameter WHERE name = 'undo_tablespace'
)
GROUP BY tablespace_name;

no rows selected    --空间耗尽查不到


-- 3. UNDO 区使用情况（按状态）
SELECT status, count(*), round(sum(bytes)/1024/1024,2) AS mb
FROM dba_undo_extents
GROUP BY status
ORDER BY status;

no rows selected    --空间耗尽查不到
STATUS      COUNT(*)         MB
--------- ---------- ----------
EXPIRED          447       2365
UNEXPIRED     499665   33219.19

-- ACTIVE = 正在使用  UNEXPIRED = 未过期  EXPIRED = 已过期可回收

-- 4. 当前消耗 UNDO 最多的会话
SELECT s.sid, s.serial#, s.username, s.program, s.machine,
       t.start_time,
       round(t.used_ublk * 8 / 1024, 2) AS undo_mb,
       s.sql_id
FROM v$session s, v$transaction t
WHERE s.taddr = t.addr
ORDER BY t.used_ublk DESC;

问题排查第二步：直接扩容 UNDO 表空间

方案 A：给 UNDO 表空间加数据文件

-- 查看 UNDO 表空间名
SHOW PARAMETER undo_tablespace;

-- 加一个数据文件（带自动扩展）
ALTER TABLESPACE undotbs1
  ADD DATAFILE '/data/spedw/oradata/spedw/undotbs02.dbf'
  SIZE 1G AUTOEXTEND ON NEXT 200M MAXSIZE 30G;

--不带自动扩展  
ALTER TABLESPACE UNDOTBS1 add datafile '/data/spedw/oradata/spedw/undotbs03.dbf' size 30g;

方案 B：开启已有数据文件的自动扩展

-- 查看现有数据文件路径
SELECT file_id,file_name,bytes/1024/1024,AUTOEXTENSIBLE FROM dba_data_files WHERE tablespace_name = (SELECT value FROM v$parameter WHERE name='undo_tablespace');

-- 开启自动扩展
ALTER DATABASE DATAFILE '/data/spedw/oradata/spedw/undotbs01.dbf'
  AUTOEXTEND ON NEXT 200M MAXSIZE 30G;

方案 C：调整 UNDO 相关参数

-- 查看当前参数
SHOW PARAMETER undo;

undo_retention                       integer     43200

-- 如果 undo_retention 过大，适当降低
ALTER SYSTEM SET undo_retention = 7200 SCOPE=BOTH;  -- 2 小时

-- 确保是自动管理模式
ALTER SYSTEM SET undo_management = AUTO SCOPE=SPFILE;

问题排查第三步：查看是否有大事务占用 UNDO

GoldenGate 报 ORA-01562 不一定是 GoldenGate 自己吃满 UNDO，可能是源端有其他大事务同时消耗 UNDO：

-- 查看是否有大事务正在运行
SELECT s.sid, s.serial#, s.username, s.program,
       t.start_time,
       round(t.used_ublk * 8 / 1024, 2) AS undo_gb,
       s.sql_id, s.event, s.wait_class
FROM v$session s, v$transaction t
WHERE s.taddr = t.addr
  AND t.used_ublk > 10000  -- 大于 80MB 的事务
ORDER BY t.used_ublk DESC;

-- 查看对应的 SQL
SELECT sql_id, sql_text
FROM v$sql
WHERE sql_id IN (
  SELECT s.sql_id FROM v$session s, v$transaction t
  WHERE s.taddr = t.addr AND t.used_ublk > 10000
);

如果发现是某个业务大事务吃满 UNDO，需要业务侧优化或拆分大事务。如果已经查不到了，需要查询 ASH 视图。

-- 查报错时刻前后的活跃会话（±5 分钟）
SELECT sample_id, sample_time,
       session_id, session_serial#, user_id,
       sql_id, sql_opcode, event, wait_class,
       program, machine, module,
       blocking_session, blocking_session_serial#
FROM   dba_hist_active_sess_history
WHERE  sample_time BETWEEN
       TO_DATE('2026-09-24 18:00:00','YYYY-MM-DD HH24:MI:SS')
  AND  TO_DATE('2026-09-24 18:10:00','YYYY-MM-DD HH24:MI:SS')
ORDER BY sample_time, session_id;

--找到 sql_opcode = 1/2/3（INSERT/UPDATE/DELETE）的会话，就是可能的大事务。

-- 查这些会话当时跑的具体 SQL
SELECT sql_id, sql_text, executions
FROM   v$sql
WHERE  sql_id IN (
  SELECT DISTINCT sql_id
  FROM   dba_hist_active_sess_history
  WHERE  sample_time BETWEEN
         TO_DATE('2026-09-24 18:00:00','YYYY-MM-DD HH24:MI:SS')
    AND  TO_DATE('2026-09-24 18:10:00','YYYY-MM-DD HH24:MI:SS')
    AND sql_id IS NOT NULL
);

问题解决：重启 Extract

UNDO 扩容后，重启 Extract：

GGSCI> START EXTRACT ext1

# 查看状态
GGSCI> INFO EXTRACT ext1

# 查看详细日志
GGSCI> VIEW REPORT ext1

如果还报 ORA-01562，继续看 report 里的完整错误上下文，一般情况下已经解决。

最后的手段：如果 UNDO 无法扩容 — 考虑切换 Extract 模式

如果源端 UNDO 表空间确实无法扩容（磁盘限制），可以考虑从集成模式 Integrated Extract 切换为经典模式 Classic Extract：

Classic Extract 直接读取 Redo Log 文件，不经过 LogMiner，几乎不消耗源端 UNDO：

# 1. 停止 Extract
GGSCI> STOP EXTRACT <extract_name>

# 2. 修改 Extract 参数，去掉 Integrated 模式
# 编辑 paramfile
GGSCI> EDIT PARAMS <extract_name>
# 删除或注释掉: EXTRACT <name> INTEGRATED
# 改为:   EXTRACT <name>

# 3. 重新注册为 Classic（取消 LogMiner 注册）
GGSCI> DBLOGIN USERID <user> PASSWORD <pwd>
GGSCI> UNREGISTER EXTRACT <extract_name> DATABASE
GGSCI> REGISTER EXTRACT <extract_name> DATABASE  -- 不带 INTEGRATED

# 4. 重启
GGSCI> START EXTRACT <extract_name>

Classic Extract 高版本已放弃支持了，不支持某些复杂数据类型的捕获，优先建议扩容 undo

常见触发场景

触发场景 说明
Extract 首次启动 / 重启后 Integrated Extract 启动时构建 LogMiner 字典，消耗大量 UNDO
新增表到 Extract（TABLE 参数） 首次解析新表需要查询对象元数据，消耗 UNDO
源端有大 DDL / 大批量 DML 业务大事务 + GoldenGate 查询同时吃 UNDO
UNDO 表空间本身就偏小 平时勉强够用，GoldenGate 查询是压垮的最后一根稻草
UNDO 数据文件未开自动扩展 固定大小，满了直接报错

总结：根因是源端 UNDO 表空间不足，GoldenGate Integrated Extract 查询源端数据库时无法扩展回滚段。最快的修复是给 UNDO 表空间加数据文件并开启自动扩展，然后重启 Extract。如果 UNDO 确实无法扩容，最后考虑切换为 Classic Extract 模式。

如果这篇文章对你有帮助，欢迎点赞、在看、转发三连，转给你团队里里的兄弟。

关注「JiekeXu DBA 之路」，数据库路上不迷路。 我们下期见。

全文完，希望可以帮到正在阅读的你，如果觉得有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~

欢迎关注我的公众号【JiekeXu DBA之路】，一起学习新知识！
——————————————————————————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
ITPUB：https://blog.itpub.net/69968215
腾讯云：https://cloud.tencent.com/developer/user/5645107
——————————————————————————

facebook_pro_light_1920 × 1080 副本.png

墨力计划oggora-01562undooracle
最后修改时间：2026-09-29 22:51:48
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

文章被以下合辑收录

JiekeXu DBA之路（共263篇）
JiekeXu：来自西北，90 后，获得 11g OCP、11g OCM 认证，墨天轮 MVP，墨天轮 2021 十大突出贡献人物之一，此专栏记录一个菜鸟 DBA 学习成长之路，欢迎关注公众号 JiekeXu DBA之路，一起学习进步。

评论