OGG ERRORS 总结

1. libnnz11.so
2. 00446
- 2.1. missing filename opening checkpoint file
  - 2.1.1. 错误信息
  - 2.1.2. 分析与解决
- 2.2. could not find archived log
  - 2.2.1. 错误信息
  - 2.2.2. 分析与解决
3. 00918
4. 01163
5. 01168
6. 01201
- 6.1. 案例1
- 6.2. 案例2
7. 01223
8. 01877
9. 02422
10. 02245

1 libnnz11.so

完整的错误信息如下:

ggsci: error while loading shared libraries: libnnz11.so: cannot open shared object file: No such file or directory

在通过ggsci启动时，有可能会遇到如上错误。找不到libnnz11.so动态库文件. 通过find命令发现该文件在"$ORACLE_HOME/lib"路径中存在的:

$ find $ORACLE_HOME/ -name libnnz11.so
/u01/app/oracle/product/11.2.0/dbhome_1/inventory/Scripts/ext/lib/libnnz11.so
/u01/app/oracle/product/11.2.0/dbhome_1/inventory/backup/2019-03-08_10-41-36PM/Scripts/ext/lib/libnnz11.so
/u01/app/oracle/product/11.2.0/dbhome_1/lib/libnnz11.so

难道是LD_LIBRARY_PATH 没有配置该路径么？

查看LD_LIBRARY_PATH 配置:

$ echo $LD_LIBRARY_PATH
/u01/app/oracle/product/11.2.0/dbhome_1/lib:/opt/jdk1.8.0_181//jre/lib/amd64/server/:/opt/jdk1.8.0_181//lib:

配置是对的。那问题出在哪儿呢？

追踪进程吧:

strace ggsci
execve("/u01/app/ogg/ggsci", ["ggsci"], [/* 28 vars */]) = 0
..........
mmap(NULL, 2197528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f6c71c70000
mprotect(0x7f6c71c89000, 2093056, PROT_NONE) = 0
mmap(0x7f6c71e88000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7f6c71e88000
close(3)                                = 0
open("/u01/app/ogg/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./tls/x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./tls/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib64/tls/x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls/x86_64", 0x7ffd64847c10) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls", {st_mode=S_IFDIR|0555, st_size=6, ...}) = 0
open("/lib64/x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/x86_64", 0x7ffd64847c10)   = -1 ENOENT (No such file or directory)
open("/lib64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64", {st_mode=S_IFDIR|0555, st_size=77824, ...}) = 0
open("/usr/lib64/tls/x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls/x86_64", 0x7ffd64847c10) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls", {st_mode=S_IFDIR|0555, st_size=6, ...}) = 0
open("/usr/lib64/x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/x86_64", 0x7ffd64847c10) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64", {st_mode=S_IFDIR|0555, st_size=77824, ...}) = 0
writev(2, [{"ggsci", 5}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"libnnz11.so", 11}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10ggsci: error while loading shared libraries: libnnz11.so: cannot open shared object file: No such file or directory
) = 116
exit_group(127)                         = ?
+++ exited with 127 +++

从追踪结果来看，ggsci 设定的查询路径是"u01/app/ogg"(这是我的 OGG_HOME路径),及该路径下的tls, "/lib64","/usr/lib64" 三个主路径, 并没有根据LD_LIBRARY_PATH的设置去查找。那么我们只有一个办法: 将该库文件复制一份到以上三个路径中的一个即可。

解决方法

cp $ORACLE_HOME/lib/libnnz11.so $OGG_HOME/

2 00446

2.1 missing filename opening checkpoint file

2.1.1 错误信息

2019-07-02t23:26:17.998+0800  error   ogg-00446  oracle goldengate delivery, xmsys.prm:  missing filename opening checkpoint file.
2019-07-02t23:26:17.999+0800  error   ogg-01668  oracle goldengate delivery, xmsys.prm:  process abending.

2.1.2 分析与解决

出现此错误，原因是参数配置与命令不匹配。比如from file方式的数据应用进程,如果使用ggsci命令start命令来启动, 则会出现这种错误。下面是两个案例，根本原因都是命令与参数配置不匹配，一种是初始化，一种是实时应用。

参数配置 以下配置为一例 OGG FOR KAFKA 的 FROM FILE 方式初始化应用进程的配置。

  SPECIALRUN
END RUNTIME
SETENV(NLS_LANG="AMERICAN_AMERICA.ZHS16GBK")
TARGETDB LIBFILE LIBGGJAVA.SO SET PROPERTY=DIRPRM/XMINS.PROPS
EXTFILE DIRDAT/II
REPORTCOUNT EVERY 1 MINUTES , RATE
GROUPTRANSOPS 10000

启动命令
```
START INITSP
```

日志

  .........
2019-07-02T23:26:15.409+0800  INFO    OGG-01360  ORACLE GOLDENGATE DELIVERY, XMSYS.PRM:  REPLICAT IS RUNNING IN SPECIAL RUN MODE.
2019-07-02T23:26:15.615+0800  INFO    OGG-15052  ORACLE GOLDENGATE DELIVERY, XMSYS.PRM:  USING JAVA CLASS PATH: GGJAVA/GGJAVA.JAR:GGJAVA/RESOURCES/LIB/OPTIONAL/LOG4J-API-2.9.1.JAR:GGJAVA/RESOURCES/LIB/OPTIONAL/LOG4J-CORE-2.9.1.JAR:GGJAVA/RESOURCES/LIB/OPTIONAL/LOG4J-SLF4J-IMPL-2.9.1.JAR.
2019-07-02T23:26:17.988+0800  INFO    OGG-01815  ORACLE GOLDENGATE DELIVERY, XMSYS.PRM:  VIRTUAL MEMORY FACILITIES FOR: COM
                                  ANON ALLOC: MMAP(MAP_ANON)  ANON FREE: MUNMAP
                                  FILE ALLOC: MMAP(MAP_SHARED)  FILE FREE: MUNMAP
                                  TARGET DIRECTORIES:
                                  /HOME/OGG/DIRTMP.
2019-07-02T23:26:17.998+0800  ERROR   OGG-00446  ORACLE GOLDENGATE DELIVERY, XMSYS.PRM:  MISSING FILENAME OPENING CHECKPOINT FILE.
2019-07-02T23:26:17.999+0800  ERROR   OGG-01668  ORACLE GOLDENGATE DELIVERY, XMSYS.PRM:  PROCESS ABENDING.

解决

通过操作系统命令 REPLICAT 执行初始化:

$OGG_HOME/REPLICAT PARAMFILE $OGG_HOME/DIRPRM/XMSYS.PRM

参数配置

  passthru
rmthost 192.168.153.129, mgrport 7809
rmttrail /u02/ggs/dirdat/td
gettruncates
table scott.*;
sequence scott.*;

分析

作为抽取进行，第一行应为进程类型标识，应为:
```
extract <group name>
```

2.2 could not find archived log

遇到这个错误时，有可能真的是找不到归档文件，而有的时候可能未配置必要参数引起的找不到归档文件。

2.2.1 错误信息

在ggserr.log 中发现如下错误:

2019-05-31t10:56:53.629+0800  error   ogg-00446  oracle goldengate capture for oracle, extxmdev.prm:  could not find archived log for sequence 2649 thread 1 under default destinations sql <select  name    from v$archived_log   where sequence# = :ora_seq_no and         thread# = :ora_thread and         resetlogs_id = :ora_resetlog_id and         archived = 'yes' and         deleted = 'no' and         name not like '+%'         and standby_dest = 'no' >, error retrieving redo file name for sequence 2649, archived = 1, use_alternate = 0not able to establish initial position for sequence 2649, rba 13816848.
2019-05-31t10:56:53.641+0800  error   ogg-01668  oracle goldengate capture for oracle, extxmdev.prm:  process abending.

2.2.2 分析与解决

从错误信息提示来看，是归档日志找不到引起的中断。那么归档文件是不是真的不存在呢？

经查看归档日志确实不存在。可根据数据的重要性采取不同的方法来处理此错误。
数据不重要
此时可以修改extract 的起始值,跳过缺失的归档文件，这在测试和开发环境中应用较多。首先查看可用归档:
```
select sequence# ,first_change#, next_change# ,deleted,applied,status from v$archived_log;

 sequence# first_change# next_change# del applied   s
---------- ------------- ------------ --- --------- -
      3759      16360310     16401138 yes no        a
      3760      16401138     16419033 no  no        a
```
从上面的查询结果来看，3759号归档已被删除，最新可用归档是3760. 对应最早的 scn号是16401138. 将extract 进程的scn 值调整至16401138:
```
alter extrace extxmdev, scn 16401138
start ext extxmdev
```
数据重要

此时需要从备份中恢复相应的归档文件

归档存在，仍遇到这种错误，很有可能 OGG所查找的归档文件与实际归档文件的存储路 径不同 。这种情况在源端为RAC环境中较为常见。因为 OGG 是通过oracle instance 中的参数来查找归档文件的: log_archive_dest[_n]/log_archive_format 而RAC 存储归档至ASM时，实际存储路径可能与参数配置有差异(因为ASM实行文件名自动管理).

这种情况，主要是通过tranlogoptions参数，让OGG 登录 ASM实例查找正确的归档文件。需要在extract进程中配置如下参数:

tranlogoptions asmuser <username@tnsname>,ASMPASSWORD <passwrod>
tranlogoptions rawdeviceoffset 0

Table of Contents