6.8. Oracle 连接器常见问题

Oracle 11g 是否受支持？
不支持 Oracle 11g，但是，我们以最佳的方式与 Oracle 11g 向后兼容。我们依赖社区与 Oracle 11g 通信兼容性，并在识别回归时提供程序错误修复。
是否弃用 Oracle LogMiner?
否，Oracle 在 Oracle 12c 中只弃用了 Oracle LogMiner 的持续最小选项，并删除从 Oracle 19c 开始的选项。Debezium Oracle 连接器不依赖于这个选项才能正常工作，因此可以安全地用于较新的 Oracle 版本，而不影响。
如何更改偏移中的位置？

Debezium Oracle 连接器在偏移中维护两个关键值，即名为 scn 的字段，另一个名为 commit_scn。scn 字段是一个字符串，代表捕获更改时使用的连接器的低水位开始位置。

  1. 找到包含连接器偏移的主题名称。这根据设为 offset.storage.topic 配置属性的值进行配置。

  2. 找到连接器的最后一个偏移量，在其中存储的密钥并标识用于存储偏移的分区。这可以通过 Kafka 代理安装提供的 kafkacat 工具脚本来完成。一个示例可能类似如下： 

    kafkacat -b localhost -C -t my_connect_offsets -f 'Partition(%p) %k %s\n'
Partition(11) ["inventory-connector",{"server":"server1"}] {"scn":"324567897", "commit_scn":"324567897: 0x2832343233323:1"}

    inventory-connector 的键是 ["inventory-connector",{"server":"server1"}]，分区是 11，最后一个偏移是 key 的内容。

  3. 要回到以前的偏移量，应该停止连接器，且必须发出以下命令： 

    echo '["inventory-connector",{"server":"server1"}]|{"scn":"3245675000","commit_scn":"324567500"}' | \
kafkacat -P -b localhost -t my_connect_offsets -K \| -p 11

    这会写入 my_connect_offsets 的分区 11，主题给定的键和偏移值。在这个示例中，我们将连接器重新遍历回 SCN 3245675000 而不是 324567897。

如果连接器无法找到给定偏移 SCN 的日志，则会出现什么情况？

Debezium 连接器在连接器偏移中维护低和高 - 水位线 SCN 值。低水位线 SCN 代表启动位置，必须存在于可用的在线红色或归档日志中，以便连接器成功启动。当连接器报告它无法找到这个偏移 SCN 时，这表示仍然可用的日志不包含 SCN，因此连接器无法从其中停止更改。

发生这种情况时，有两个选项。首先是删除连接器的历史记录主题和偏移量，并重启连接器，如建议进行新的快照。这将保证不会给任何主题用户发生数据丢失。第二个是手动操作偏移，将 SCN 贡献红色或存档日志中可用的位置。这会导致旧 SCN 值和新提供的 SCN 值间发生的更改丢失且不写入主题。不建议这样做。

不同最小策略之间的区别是什么？

Debezium Oracle 连接器为 log.mining.strategy 提供了两个选项。

默认值为 redo_in_catalog，这指示连接器在每次检测到日志交换机时将 Oracle 数据字典写入 redo 日志。对于 Oracle LogMiner，在解析红色和归档日志时，需要此数据字典来跟踪架构更改。这个选项将生成超过常见的归档日志数，但允许实时操作表，而不影响捕获数据更改。这个选项通常需要更多 Oracle 数据库内存，并会导致 Oracle LogMiner 会话和进程在每个日志交换机后启动稍长的时间。

替代选项 online_catalog 不会将数据字典写入红色日志。相反，Oracle LogMiner 始终使用包含表结构当前状态的在线数据字典。这也意味着，如果表的结构改变，且不再与在线数据字典匹配，如果表的结构改变，Oracle LogMiner 将无法解析表或列名称。如果捕获的表经常更改，则不应使用此减策略选项。务必要确保所有数据更改都被架构更改锁定，以便所有更改都已从表的日志捕获，停止连接器，应用模式更改，然后重新启动连接器并在表中恢复数据更改。这个选项需要较少的 Oracle 数据库内存和 Oracle LogMiner 会话，因为数据字典不需要由 LogMiner 进程加载或控制。

为什么 SYS 或 SYSTEM 用户没有捕获的变化？
Oracle 数据库使用 SYS 和 SYSTEM 用户帐户在 redo 日志中执行多内部操作，这对更改数据捕获并不重要。当 Debezium Oracle 连接器从 Oracle LogMiner 读取更改时，由这两个用户帐户所做的更改会自动过滤掉。因此，如果您使用这两个用户帐户之一且没有看到更改事件，这就是为什么不会捕获这些用户所做的更改。您应该使用指定的非系统用户帐户来执行您要捕获的所有更改。
为什么连接器会出现在 AWS 上停止捕获更改的原因？

由于 AWS 网关 Load Balancer 上的固定闲置超时 350 秒，需要超过 350 秒的 JDBC 调用可能会无限期挂起。

如果调用 Oracle LogMiner API 需要超过 350 秒才能完成，可以触发超时，从而导致 AWS 网关负载均衡器挂起。例如，当 LogMiner 会话处理与 Oracle 的定期检查点任务同时运行大量数据时，可能会发生此类超时。

要防止 AWS 网关负载均衡器上发生超时，请启用来自 Kafka Connect 环境的 keep-alive 数据包，以 root 或超级用户执行以下步骤：

  1. 在终端中运行以下命令： 

    sysctl -w net.ipv4.tcp_keepalive_time=60

  2. 编辑 /etc/sysctl.conf 并设置以下变量的值，如下所示： 

    net.ipv4.tcp_keepalive_time=60

  3. 重新配置 Oracle 连接器的 Debezium 以使用 database.url 属性而不是 database.hostname，并添加 (ENABLE=broken) Oracle 连接字符串描述符，如下例所示： 

    database.url=jdbc:oracle:thin:username/password!@(DESCRIPTION=(ENABLE=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(Host=hostname)(Port=port)))(CONNECT_DATA=(SERVICE_NAME=serviceName)))

前面的步骤将 TCP 网络堆栈配置为每 60 秒发送 keep-alive 数据包。因此，当 JDBC 对 LogMiner API 调用完成的时间超过 350 秒时，AWS Gateway Load Balancer 不会超时，以便连接器继续从数据库的事务日志中读取更改。

ORA-01555 的原因以及如何处理它？

当初始快照阶段执行时，Debezium Oracle 连接器使用闪存查询。闪存查询是一种特殊类型的查询，它依赖于闪存区域，由数据库的 UNDO_RETENTION 数据库参数维护，根据表内容在给定时间或给定 SCN 时返回查询的结果。默认情况下，Oracle 通常仅维护大约 15 分钟的撤销或闪存区域，除非数据库管理员已增加或减少。对于捕获大型表的配置，可能需要超过 15 分钟或您配置的 UNDO_RETENTION 执行初始快照，这会导致这个异常： 

ORA-01555: snapshot too old: rollback segment number 12345 with name "_SYSSMU11_1234567890$" too small

处理此例外的第一个方法是与数据库管理员合作，并查看它们是否可以临时增加 UNDO_RETENTION 数据库参数。这不需要重启 Oracle 数据库，因此可以在不影响数据库可用性的情况下在线完成此操作。但是，如果表空间没有足够空间来存储必要的撤销数据，则更改可能仍然会导致上述异常或"快照太老"异常。

处理此异常的第二个方法是完全依赖初始快照，将 snapshot.mode 设置为 schema_only，然后依赖增量快照。增量快照不依赖于闪存查询，因此不会受到 ORA-01555 异常。

ORA-04036 的原因以及如何处理它？

当数据库更改时，Debebe Oracle 连接器可能会报告 ORA-04036 异常。Oracle LogMiner 会话启动并重新使用，直到检测到日志交换机为止。会话被重新使用，因为它为 Oracle LogMiner 提供最佳性能利用率，但应该发生长时间运行的最小会话，这可能会导致过量 PGA 内存用量，从而导致以下例外： 

ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

通过指定 Oracle 切换 redo 日志的频率或 Debezium Oracle 连接器可以重复使用最小的会话，来避免此异常。Debezium Oracle 连接器提供了一个配置选项 log.mining.session.max.ms，它控制当前 Oracle LogMiner 会话在关闭和新会话启动前可以重新使用多久。这允许数据库资源保持检查，而不超过数据库允许的 PGA 内存。

ORA-01882 的原因以及如何处理它？

在连接到 Oracle 数据库时，Debebe Oracle 连接器可能会报告以下异常： 

ORA-01882: timezone region not found

当 JDBC 驱动程序无法正确解析时区信息时会出现这种情况。为了解决这个问题，需要告知驱动程序不使用区域解析时区详情。这可以通过使用 driver. oracle.jdbc.timezoneAsRegion=false 指定驱动程序 通过属性来实现。

ORA-25191 的原因以及如何处理它？

Debezium Oracle 连接器自动忽略索引组织化表(IOT)，因为它们不被 Oracle LogMiner 支持。但是，如果抛出 ORA-25191 异常，这可能是因为此类映射的唯一情况，并且可能需要额外规则来自动排除这些异常。ORA-25191 异常示例可能类似如下： 

ORA-25191: cannot reference overflow table of an index-organized table

如果抛出 ORA-25191 异常，请引发一个 JIRA 问题，其中包含有关表的详细信息，以及映射、与其他父表相关的映射等。作为临时解决方案，可以调整 include/exclude 配置选项，以防止连接器访问此类表。