ogg抽取进程找不到归档处理事件

本文记录了一次Oracle GoldenGate (OGG) 捕获进程异常导致的数据同步问题及解决方案。面对缺失归档日志的问题,通过调整检查点时间戳确保进程正常启动,并使用特定参数避免后续异常。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >



系统事件:

周1一大早接到某保险客户电话,说某套系统源端OGG捕获进程ABENDED了,并且延时达34小时之久。考虑到目标端ODS数据仓库层需要实时同步过来的数据,火速赶往之,去看看到底是什么情况导致的。

 

查看报错信息:
GGSCI> info all

Program     Status      Group       Lag           Time Since Chkpt

MANAGER     RUNNING                                         
EXTRACT     ABENDED    EDBCONTR    00:00:12      35:24:15  
EXTRACT     RUNNING     PDBCONTR    00:00:00      00:00:08  
EXTRACT     RUNNING     PODSDBSY    00:00:00      00:00:08  

 

尝试重新start ,进程还是ABENDED,查看具体错误信息:

GGSCI > view report EDBCONTR


***********************************************************************
                 Oracle GoldenGate Capture for Oracle
                      Version 10.4.0.19 Build 002
   Linux, IA64, 64bit (optimized), Oracle 10 on Sep 23 2009 16:34:26
 
Copyright (C) 1995, 2009, Oracle and/or its affiliates.  All rights reserved.


                    Starting at 2014-06-30 11:30:21
***********************************************************************

--More--(89%)
2014-06-30 11:31:51  GGS ERROR       500  Could not find archived log for sequen
ce 101258 thread 2 under default destinations SQL
ved_log   WHERE sequence# = :ora_seq_no AND         thread# = :ora_thread AND 
      resetlogs_id = :ora_resetlog_id AND         archived = 'YES' AND         d
eleted = 'N>, error retrieving redo file name for sequence 101258, archived = 1,
 use_alternate = 0Not able to establish initial position for sequence 101258, rb
a 2306576.

2014-06-30 11:31:51  GGS ERROR       190  PROCESS ABENDING.

 从报错信息来看,捕获进程之所以起不来,是因为找不到 节点2上 sequence 为101258对应的归档日志。

结合以往的经验,给我的第一预感就是节点2上101258对应的归档日志已经不存在了。

 

检查归档日志:

检查节点2上的归档日志,发现最早的一个归档日志号为101316.  sequence 为101258已经被删除掉了。


经过和客户的确认,该系统归档日志默认保留4天,正常情况来讲,35小时的延时似乎属于4天内的范围内,怎么会出现Could not find archived log 这一错误呢?

继续分析:

首先确认下sequence 为101258对应的归档日志是哪天生成的?

SQL>select * from v$archived_log where sequence#=101258;                          select * from v$log_history;        select * from v$loghist;

175079 850987275  1 2 101258 525781 2008-4-26 0:40:34 653013634 49178294895 2014-6-23 9:00:03 49178520498 2014-6-23 9:21:14 33779 512 ARCH ARCH NO YES NO YES D 2014-6-23 9:21:15 NO NO NO 5 2 3971134011 NO NO NO

结果为101258号归档的产生时间为 2014-6-23 9:21:14,对照归档日志保留4天的策略,23号产生的归档日志的确是不存在的。

可问题是捕获进程延时才35小时(推算下进程失败的时间为6月29号凌晨0点左右),可为什么启动后需要去找6月23号的归档日志呢?以下的检查帮我找到了原因:

GGSCI > info edbcontr,showch

EXTRACT    EDBCONTR  Last Started 2014-06-19 00:43   Status ABENDED
Checkpoint Lag       00:00:12 (updated 35:24:41 ago)
Log Read Checkpoint  Oracle Redo Logs
                     2014-06-29 00:20:16  Thread 1, Seqno 73918, RBA 28440336
Log Read Checkpoint  Oracle Redo Logs
                     2014-06-29 00:20:15  Thread 2, Seqno 101361, RBA 8411200


Current Checkpoint Detail:

Read Checkpoint #1

  Oracle RAC Redo Log

  Startup Checkpoint (starting position in the data source):
    Thread #: 1
    Sequence #: 73704
    RBA: 92702736
    Timestamp: 2014-06-19 00:39:07.000000
    SCN: 11.1862969941 (49107610197)
    Redo File: Not Avaliable

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
    Thread #: 1
    Sequence #: 73918
    RBA: 28439056
    Timestamp: 2014-06-29 00:20:16.000000
    SCN: 11.2033818536 (49278458792)
    Redo File: Not Avaliable

  Current Checkpoint (position of last record read in the data source):
    Thread #: 1
    Sequence #: 73918
    RBA: 28440336
    Timestamp: 2014-06-29 00:20:16.000000
    SCN: 11.2033818540 (49278458796)
    Redo File: Not Available

Read Checkpoint #2

  Oracle RAC Redo Log

  Startup Checkpoint (starting position in the data source):
    Thread #: 2
    Sequence #: 101180
    RBA: 67709456
    Timestamp: 2014-06-19 00:39:07.000000
    SCN: 11.1862969945 (49107610201)
    Redo File: +RECO/cjww/onlinelog/group_10.652.669224139

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
    Thread #: 2
    Sequence #: 101258
    RBA: 2306576
    Timestamp: 2014-06-23 09:02:36.000000
    SCN: 11.1933686105 (49178326361)
    Redo File: Not Avaliable

  Current Checkpoint (position of last record read in the data source):
    Thread #: 2
    Sequence #: 101361
    RBA: 8411200
    Timestamp: 2014-06-29 00:20:15.000000
    SCN: 11.2033818386 (49278458642)
    Redo File: Not Available

Write Checkpoint #1

  GGS Log Trail

  Current Checkpoint (current write position):
    Sequence #: 9879
    RBA: 96417801
    Timestamp: 2014-06-29 00:20:28.803436
    Extract Trail: ./dirdat/n1

我们知道,当OGG捕获进程重启后,内部会进行Recovery 操作,会去读取恢复检查点(Recovery Checkpoint )指定的归档日志,从上面的结果显示,该日志号为 Sequence #: 101258。

 

常规处理方法:

       遇到此问题常规的处理方法就是通过RMAN将节点2上从101258号归档日志至101315号归档日志恢复出来,恢复完成后直接重启捕获进程即可。

       但客户这边的实际情况是23号的归档日志已经被删除掉了,没有任何备份了。

       常规处理方法看来是行不通的。

 

实际处理方法:

       Recovery Checkpoint 对应的Timestamp: 2014-06-23 09:02:36,而Current Checkpoint 对应的 Timestamp: 2014-06-29 00:20:15,为什么这2个checkpoint时间相差这么大呢??

同客户确认,23号到29号的同步一直是正常的。

为此,我们的处理方法是:将Recovery Checkpoint 对应的Timestamp改成

Current Checkpoint 对应的Timestamp,均为2014-06-29 00:20:15

具体操作步骤:

GGSCI>alter extract EDBCONTR ,tranlog ,begin 2014-06-29 00:20:15

GGSCI>start EDBCONTR

进程能够正常起来了,但该过程中陆续有挂掉的现象,再重新start下仍然可以继续运行,主要报以下2个错误:

2014-06-30 12:22:37  GGS ERROR       182  OCI Error describe for query SELECT *
FROM "YXXT"."SYS_EXPORT_SCHEMA_01" (bad syntax) (status = 942-ORA-00942: table o
r view does not exist
2014-06-30 12:25:01  GGS ERROR       109  ORA-01000: maximum open cursors exceed

从报错的情况来看,进程是在29号晚上0点左右abended掉的,而0点左右系统在执行expdp操作,故上述报错是进程abended的罪魁祸首。

错误1:SYS_EXPORT_SCHEMA_01这类表是业务用户在执行expdp导数据生成的,为防止这个错误,我通过在捕获进程参数文件里面添加tableexclude参数来排除掉这类表;

错误2:超过系统最大游标数,该错误有可能是错误1引起的,在expdp过程中系统超过了最大游标数,故报该错误。

 

总结:

1: 通过手工修改 Recovery Checkpoint Timestamp ,和Current Checkpoint Timestamp 保持一致,保证进程重启后,能够跳过去读Sequence #: 101258号日志,而是让进程去读取Log Read Checkpoint对应的日志(2014-06-29 00:20:15 Thread 2, Seqno 101361, RBA 8411200),从而保证进程的后续捕获并追平延时。至于为什么这2个时间相差这么长,怀疑是不是23号存在某个事务,一直到29号都没有commit导致的?当然需要测试验证下。

2: 通过添加tableexclude 参数排除expdp操作产生的SYS_EXPORT_SCHEMA_01类型的表,防止进程异常abended.









原文:http://blog.sina.com.cn/s/blog_aa84cfe40102uwa3.html

<think>好的,我现在需要解决用户提出的问题:OGG在SQL Server 2012上无法抽取日志的问题。用户还提供了几个相关的引用内容,我需要结合这些信息来到解决方案。 首先,用户提到的错误是OGG无法从SQL Server 2012抽取日志。根据引用[1],在Oracle环境中需要设置`enable_goldengate_replication`参数,但SQL Server可能没有这个参数,所以可能需要类似的配置。不过需要确认SQL Server是否也有类似的设置,比如开启CDC(变更数据捕获)或者复制功能。 然后,参考引用[2]中提到的配置检查步骤,尤其是添加replicat和检查点表的配置是否正确。用户可能在配置OGG抽取进程时遗漏了一些关键参数,或者在指定路径时出错。例如,检查点表ogg.ggs_checkpoint是否存在,以及权限是否正确。 引用[3]提到Active Data Guard的故障切换需要将OGG部署到DBFS,但这里的问题是关于SQL Server,所以可能不适用。不过可以联想到是否SQL Server的日志文件路径或权限问题导致OGG无法访问。 引用[4]中的投递进程配置显示需要正确配置rmthost、mgrport以及用户认证信息。用户需要检查抽取进程的配置文件,确保目标主机和端口正确,用户名密码无误,并且网络连接正常。此外,动态解析表是否正确指定了需要捕获的数据库和表。 接下来,可能的错误原因包括: 1. SQL Server的日志未正确配置,未启用CDC或事务日志备份。 2. OGG抽取进程配置错误,比如表名、路径、权限问题。 3. 网络问题导致OGG无法连接到SQL Server实例。 4. SQL Server版本兼容性问题,需要确认OGG是否支持2012版本。 5. 防火墙或安全软件阻止了OGG访问日志文件或网络端口。 解决方案步骤可能包括: 1. 检查并启用SQL Server的CDC功能,确保日志记录足够详细。 2. 验证OGG抽取进程参数文件,确保正确指定了数据库、表和路径。 3. 检查网络连接和端口是否开放,使用telnet或测试工具确认连通性。 4. 确认使用的OGG版本是否支持SQL Server 2012,必要时升级OGG。 5. 检查SQL Server和OGG运行账户的权限,确保有足够的权限读取日志。 6. 查看OGG的错误日志,定位具体的错误信息,根据日志提示调整配置。 此外,用户可能需要参考官方文档或微软的支持文章,确认SQL Server 2012与OGG的兼容性,以及具体的配置步骤。比如,可能需要安装特定的驱动程序或补丁。 最后,生成的相关问题需要围绕OGG配置、SQL Server日志设置、故障排查方法等方面展开,帮助用户进一步理解可能遇到的挑战和解决方案。</think>### OGG在SQL Server 2012无法抽取日志的解决方案 #### **错误原因分析** 1. **日志配置未启用** SQL Server需启用变更数据捕获(CDC)或事务日志备份功能,否则OGG无法读取增量数据[^2]。 2. **OGG进程配置错误** 抽取进程(Extract)参数可能未正确指定数据库、表或路径,例如`rmttrail`路径权限不足或格式错误[^4]。 3. **权限问题** OGG运行账户可能缺乏访问SQL Server日志或目标表的权限。 4. **网络或端口限制** 防火墙可能阻止OGG与SQL Server的通信,或`mgrport`未正确配置。 5. **版本兼容性** OGG版本可能不支持SQL Server 2012,需确认官方兼容性列表。 --- #### **解决步骤** 1. **启用SQL Server的CDC功能** ```sql -- 启用数据库级别的CDC EXEC sys.sp_cdc_enable_db; -- 启用表级别的CDC(以scott.kafka为例) EXEC sys.sp_cdc_enable_table @source_schema = 'scott', @source_name = 'kafka', @role_name = NULL; ``` 完成后检查`sys.databases`确认CDC已启用。 2. **检查OGG抽取进程配置** 编辑抽取进程参数文件(如`d_ka`),确保以下配置正确: ```bash extract d_ka sourcedb <数据库名>@<SQL Server实例>, userid ogg, password ogg rmthost 192.168.1.21, mgrport 7809 rmttrail ./dirdat/ka dynamicresolution table scott.kafka; ``` 需确认: - `sourcedb`格式为`数据库名@实例名`(若为默认实例则省略`@`)。 - `rmttrail`路径存在且OGG用户有写入权限。 3. **配置检查点表** 在SQL Server中创建检查点表并授权: ```sql CREATE TABLE ogg.ggs_checkpoint ( group_name NVARCHAR(50) PRIMARY KEY, checkpoint XML ); GRANT SELECT, INSERT, UPDATE ON ogg.ggs_checkpoint TO ogg; ``` 4. **验证网络和端口** 使用`telnet 192.168.1.21 7809`测试目标主机的MGR进程端口是否可达。 5. **查看OGG错误日志** 在OGG安装目录的`dirrpt`文件夹中查错误详情(如权限拒绝、表不存在等)。 6. **升级OGG版本** 若使用旧版OGG,需升级至支持SQL Server 2012的版本(如Oracle GoldenGate 12.3或更高)。 --- #### **配置示例** ```bash GGSCI> add extract e_cms, tranlog, begin now GGSCI> add exttrail ./dirdat/ms, extract e_cms GGSCI> edit params e_cms -- 抽取进程参数文件内容 -- extract e_cms sourcedb MyDB@SQL2012, userid ogg, password ogg exttrail ./dirdat/ms dynamicresolution table dbo.test_table; ``` ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值