问题现象：
抽取异常， 抽取进程停在 2 02 4 -07-28 16:38:36 ，具体 报错OGG-01937 Oracle GoldenGate Capture for Oracle, e1_ss.prm: Extract is not configured to capture changes from thread 3. To avoid data loss, the Extract must be dropped and recreated with the THREADS option to specify the correct number of RAC instances. See the Oracle GoldenGate administration documentation for the procedure to follow.
问题排查：
报错提示当前挖掘进程并未配置对 thread 3 的抽取，为了防止数据丢失，请删除当前进程，并重新创建抽取进程，针对 3个thread做数据抽取。
虽然存在疑惑， dg端节点数是没有变更过的，怎么会突然多出一个节点，不过为优先恢复同步，先 根据 报错 提示对进程进行重建，并指定新进程从停止时间点开始抽取，具体操作如下： （ 重建前一定要保留进程信息 ）
GGSCI > delete e1_ss GGSCI > add extract e1_ss tranlog threads 3 begin now GGSCI > add exttrail ./dirdat/ss extract e1_ss GGSCI > alter extract e1_ss extsegno 104730 extrba 293057596 thread 1 GGSCI > alter extract e1_ss extsegno 104561 extrba 29884848 thread 2 GGSCI > alter extract e1_ss extsegno 1 extrba 0 thread 3
以 3个thread新建进程后，进程出现新报错 OGG-00868 The number of Oracle redo threads (2) is not the same as the number of checkpoint threads (3). EXT
RACT groups on RAC systems should be created with the THREADS parameter (e.g., ADD EXT <group name>, TRANLOG, THREADS 2, BEGIN...) ，提示当前数据库只有 2个节点，但是检查点文件中配置了3个节点，请重新按照2个thread重建抽取进程。
可以看到 ogg在这一阶段判断进入互斥阶段，死循环， 疑似 ogg在查询数据库信息并做对应判断时出现偏差。
查询 v$thread 做确认 ，具体信息如下：
SOL> seLect THREAD#,STATUS,ENABLED,LAST_REDO_SEQUENCE# from v$thread;
THREAD# STATUS ENABLED LAST_REDO_SEOUENCE#
------- ------- ------- -------------------
1 OPEN PUBLIC 104768
2 OPEN PUBLIC 104599
3 CLOSED DISABLED 0
发现 thread 3 状态为 CLOSED，不确定该DG是否状态一直是这样（从alert日志可以看到，该dg每天做自动恢复）。但基本可以确定本次ogg抽取之所以出现异常的原因就在这里。
进一步检查生产库，发现生产库 在 2 8 日做了新增节点的操作， thread 3 为新增操作，第一个日志从 7 月 2 8 日 1 6 : 38 左右开始产生 ， 且操作人员回顾只对生产做了添加节点的操作，并未对 dg做任何操作和检查 。
再次检查 DG库，发现 生产端添加节点后，并未重新同步 dg端控制文件， 怀疑该问题 导致 dg端系统视图信息和生产端存在差异。在生产重新生成一个控制文件并传输到dg端， 重启 DG，并添加三节点standby redo log 。
再次 查询视图， 看到 本次状态恢复正常。
SOL> seLect THREAD#,STATUS,ENABLED,LAST_REDO_SEQUENCE# from v$thread;
THREAD# STATUS ENABLED LAST_REDO_SEOUENCE#
------- ------- ------- -------------------
1 OPEN PUBLIC 104789
2 OPEN PUBLIC 104619
3 OPEN PUBLIC 52
尝试启动重建的 3 个 thread的挖掘进程，可以正常抽取数据。
