问题描述:ogg停止抽取进程停止不下来
GGSCI (ex02db02.iris.cl.sh.cos) 6> stop extu6 Sending STOP request to EXTRACT EXTU6 ... There are open, long-running transactions. Before you stop Extract, make the archives containing data for those transactions available for when Extract restarts. To force Extract to stop, use the SEND EXTRACT EXTU6, FORCESTOP command. Oldest redo log files necessary to restart Extract are: Redo Thread 1, Redo Log Sequence Number 2010, SCN 0.2340216775 (2340216775), RBA 2150464016 Redo Thread 2, Redo Log Sequence Number 3767, SCN 0.2578644069 (2578644069), RBA 3712786960. GGSCI (ex02db02.iris.cl.sh.cos) 7>
分析抽取进程停不下来的原因:
GGSCI (ex02db02.iris.cl.sh.cos) 7> info extu6, showch ---查看抽取进程extu6的具体信息 EXTRACT EXTU6 Last Started 2016-03-30 12:22 Status RUNNING Checkpoint Lag 00:00:01 (updated 00:00:06 ago) Log Read Checkpoint Oracle Redo Logs 2016-04-09 07:13:53 Thread 1, Seqno 2164, RBA 1977981456 ------日志1,当前的节点 SCN 0.2578649132 (2578649132) Log Read Checkpoint Oracle Redo Logs 2016-04-09 07:13:52 Thread 2, Seqno 3767, RBA 3712910848 ------日志2,当前的节点 SCN 0.2578648996 (2578648996) Current Checkpoint Detail: Read Checkpoint #1 Oracle Threaded Redo Log Startup Checkpoint (starting position in the data source): Thread #: 1 Sequence #: 1438 RBA: 210499600 Timestamp: 2016-03-30 12:22:03.000000 SCN: 0.1566106138 (1566106138) Redo File: Not Available Recovery Checkpoint (position of oldest unprocessed transaction in the data source): Thread #: 1 Sequence #: 2010 RBA: 2150464016 Timestamp: 2016-04-07 10:40:45.000000 SCN: 0.2340216775 (2340216775) Redo File: Not Available Current Checkpoint (position of last record read in the data source): -----停止抽取进程的时候,发现Redo Thread 1, Redo Log Sequence Number 2010, SCN 0.2340216775 (2340216775), RBA 2150464016指向了一个比较老的日志点。而当前的日志点在2016-04-09 07:13:53 Thread 1, Seqno 2164, RBA 1977981456,SCN 0.2578649132 (2578649132) ------日志1,当前的节点 Thread #: 1 Sequence #: 2164 RBA: 1977981456 Timestamp: 2016-04-09 07:13:53.000000 SCN: 0.2578649132 (2578649132) Redo File: +RECO_EX01/oraods/onlinelog/group_3.260.906566199 BR Previous Recovery Checkpoint: Thread #: 1 Sequence #: 0 RBA: 0 Timestamp: 2016-03-30 12:22:40.228062 SCN: Not available Redo File: BR Begin Recovery Checkpoint: Thread #: 1 Sequence #: 2158 RBA: 601906176 Timestamp: 2016-04-09 04:28:28.000000 SCN: 0.2568814282 (2568814282) Redo File: BR End Recovery Checkpoint: Thread #: 1 Sequence #: 2158 RBA: 601906176 Timestamp: 2016-04-09 04:28:28.000000 SCN: 0.2568814282 (2568814282) Redo File: Read Checkpoint #2 Oracle Threaded Redo Log Startup Checkpoint (starting position in the data source): Thread #: 2 Sequence #: 2538 RBA: 2046847504 Timestamp: 2016-03-30 12:21:23.000000 SCN: 0.1566051805 (1566051805) Redo File: Not Available Recovery Checkpoint (position of oldest unprocessed transaction in the data source): Thread #: 2 Sequence #: 3767 RBA: 3712910352 Timestamp: 2016-04-09 07:13:52.000000 SCN: 0.2578648996 (2578648996) Redo File: +RECO_EX01/oraods/onlinelog/group_7.423.906566119 Current Checkpoint (position of last record read in the data source): ---可以看出日志组2,没有什么问题,是指向当前的日志组的。 Thread #: 2 Sequence #: 3767 RBA: 3712910848 Timestamp: 2016-04-09 07:13:52.000000 SCN: 0.2578648996 (2578648996) Redo File: +RECO_EX01/oraods/onlinelog/group_7.423.906566119 BR Previous Recovery Checkpoint: Thread #: 2 Sequence #: 0 RBA: 0 Timestamp: 2016-03-30 12:22:40.228062 SCN: Not available Redo File: BR Begin Recovery Checkpoint: Thread #: 2 Sequence #: 3753 RBA: 3358690304 Timestamp: 2016-04-09 04:28:27.000000 SCN: 0.2568813956 (2568813956) Redo File: BR End Recovery Checkpoint: Thread #: 2 Sequence #: 3753 RBA: 3358690304 Timestamp: 2016-04-09 04:28:27.000000 SCN: 0.2568813956 (2568813956) Redo File: Write Checkpoint #1 GGS Log Trail Current Checkpoint (current write position): Sequence #: 212216 RBA: 11597034 Timestamp: 2016-04-09 07:13:54.176777 Extract Trail: /home/gggate/goldengate/dirdat/e6 Trail Type: EXTTRAIL Header: Version = 2 Record Source = A Type = 11 # Input Checkpoints = 2 # Output Checkpoints = 1 File Information: Block Size = 2048 Max Blocks = 100 Record Length = 4096 Current Offset = 0 Configuration: Data Source = 3 Transaction Integrity = 1 Task Type = 0 Status: Start Time = 2016-03-30 12:22:40 Last Update Time = 2016-04-09 07:13:54 Stop Status = A Last Result = 0 GGSCI (ex02db02.iris.cl.sh.cos) 8>
处理方法:将抽取进程,修改到当前的日志组,然后再进行停止抽取进程。
通过ggsci>help alter extract -----查看帮助
ALTER EXTRACT extu6, IOEXTSEQNO 2164, IOEXTRBA 0,thread 1
相关推荐
- 在OGG抽取进程的参数文件中添加隐含参数以增强事务处理能力。具体参数可以参考Oracle官方文档或支持论坛上的相关讨论。 2. **监控事务状态:** - 定期检查事务状态,并根据需要调整相关设置或优化数据处理逻辑。...
OGG增量抽取Oracle业务数据到kafka部署手册 OGG(Oracle GoldenGate)是一种数据集成工具,用于实时集成和复制数据 zwischen Oracle 数据库和 Kafka 消息队列。下面是 OGG 增量抽取 Oracle 业务数据到 Kafka 的部署...
可以使用OGG提供的工具来监控OGG的运行状况,例如检查OGG的日志文件、监控OGG的进程等。 本文档详细介绍了在异构环境下,使用OGG将MySQL数据同步到Oracle数据库的步骤。该文档对于实现异构环境下的数据同步和集成...
本文将对 OGG 之 ORA-01403 案例进行详细的分析,包括出现错误的原因、解决方法、handlecollisions 参数的解析和使用注意事项等。 一、错误原因分析 OGG 之 ORA-01403 案例中,出现了复制进程 abended 状态,报告...
- 当单个抽取进程在业务峰值时每小时处理的redo量超过40G时,建议进行拆分,以确保处理量不超过阈值。 - 业务耦合优先级高于redo日志量配置原则。 2. 抽取进程拆分细则: - 若schema之间存在业务耦合,则应当为...
- 配置源端extract抽取进程:定义抽取进程,从源数据库中提取变更数据。 - 配置源端dump投递进程:设置将抽取的数据转换为中间格式并写入到本地磁盘的进程。 1.4. 配置目标数据库 - 环境准备:在目标数据库上进行...
#### 七、OGG 源端常见错误及解决方法 在实际使用过程中,可能会遇到以下一些常见错误: 1. **ORA-01034: ORACLE not available** - **错误描述**:无法开始会话,提示 ORACLE 不可用。 - **解决方法**:在 ...
接下来,清除默认的清理作业,使用`sys.sp_cdc_drop_job 'cleanup'`,并用OGG的清理脚本创建新的清理作业,如`ogg_cdc_cleanup_setup.bat createjob ogg ogg dbname (local) ogg2`。 进入OGG的ggsci控制台,创建...
这通常意味着需要重新创建源端的抽取进程 (Extract) 和目标端的应用进程 (Replicat)。重新初始化数据前,请确保备份现有数据,避免数据丢失。 4. **检查 OGG 配置文件**:确认 OGG 的配置文件(如 `ggsci.prm`)中...
1. **从Integrated到Classic**:当需要跨数据库平台复制或者在数据库不支持Integrated模式时,需要将OGG从Integrated切换到Classic模式。这通常涉及停止数据库内的GoldenGate进程,然后配置和启动独立的GGExtract和...
- **Manager进程**:管理其他OGG进程,负责启动、停止、监控和配置OGG。 - **Extract进程**:在源数据库上运行,抽取变更数据。 - **Pump进程**:传输由Extract进程抽取的数据到Trail文件。 - **Replicat进程**...
这些进程各自负责OGG的不同任务,如数据抽取、传输和应用。 2. **数据延迟监测**:监控脚本可以计算源数据库与目标数据库之间的数据延迟,这对于满足SLAs(Service Level Agreements)和保证业务连续性至关重要。 ...
在使用Oracle GoldenGate与Oracle ASM(自动存储管理)环境进行集成时,可以采用多种方法来进行数据抽取。Oracle ASM是为了优化数据库性能和高可用性,同时减少存储维护操作而设计的。自Oracle Database 10g起引入了...
5. **配置抽取进程**:抽取进程是OGG的核心组件之一,负责捕获源数据库的事务变化。 6. **配置传输进程**:传输进程负责将抽取进程捕获的数据发送到目标服务器。 #### 六、配置目标服务器 1. **登录数据库**:与源...
在源端和目标端分别创建并配置OGG进程,包括定义数据源、抽取(Extract)、泵(Pump)和复用器(Replicat)。具体步骤包括创建数据泵、定义数据流、配置参数文件等。 **6. 验证和监控** 安装完成后,启动OGG进程并...
Oracle GoldenGate的工作原理大致如下:首先,ogg的抽取进程(Extract)在源数据库上运行,实时捕获数据库的变化,这些变化以trail文件的形式存储。然后,ogg的传输进程(Replicat)将这些变更应用到目标数据库。在...
- **创建提取进程(EXTRACT)**:配置OGG的抽取进程,它从源数据库中读取更改并将其放入本地队列。 - **创建泵进程(PUMP)**:配置PUMP进程,负责将队列中的更改发送到目标端。 - **创建投递进程(REPLICAT)**...
- 启动OGG进程,并进行数据抽取、传输和加载的测试。 5. **微服务集成**: OGG BigData微服务可能涉及到以下集成: - 使用OGG的Hadoop和NoSQL Gateway,实现与Hadoop生态系统的交互。 - 配置OGG与微服务架构中...
在本场景中,端口扫描可能导致OGG进程的不稳定,因为它可能导致端口的快速释放和重新绑定。 4. **解决策略**: - **更改端口配置**:可以修改OGG的配置文件(如 mgr.prm 或者 extract.prm),为extract和replicat...
1. **Manager管理进程**:这是OGG的核心组件之一,负责在源端和目标端启动,主要功能包括监控其他进程状态并在出现问题时进行自动重启、分配数据存储空间、记录错误及事件信息等。 2. **Extract进程**:该进程从源...