搜索

7.8. Oracle 连接器常见问题

download PDF
是否支持 Oracle 11g?
Oracle 11g 不支持;但是,我们的目标是以最佳的方式与 Oracle 11g 向后兼容。我们依赖社区与 Oracle 11g 沟通兼容性问题,并在识别回归时提供 bug 修复。
是否弃用了 Oracle LogMiner?
不,Oracle 只弃用了 Oracle LogMiner 在 Oracle 12c 中带有 Oracle LogMiner 的持续 mining 选项,并删除了从 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,最后一个偏移是遵循该键的内容。

  3. 要移动到以前的偏移中,应该停止连接器,且必须发出以下命令:

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

    这会写入给定 key 和 offset 值的 my_connect_offsets 主题的分区 11。在本例中,我们将连接器重新定向到 SCN 3245675000 而不是 324567897

如果连接器无法找到给定偏移 SCN 的日志,会发生什么?

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

发生这种情况时,有两个选项。第一个是删除连接器的历史记录主题和偏移,并重启连接器,按照建议执行新的快照。这样可保证任何主题消费者不会发生数据丢失。第二个方法是手动操作偏移,将 SCN 提升到 redo 或 archive 日志中可用的位置。这会导致在旧的 SCN 值和新提供的 SCN 值之间发生的更改会丢失,且不会写入主题。不建议这样做。

各种 mining 策略之间有什么区别?

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

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

备用选项 online_catalog 不会将数据字典写入 redo 日志。相反,Oracle LogMiner 始终使用包含表结构当前状态的在线数据字典。这也意味着,如果表的结构发生变化,且不再与在线数据字典匹配,如果表的结构已更改,Oracle LogMiner 将无法解析表或列名称。如果捕获的表受到频繁的模式更改,则不应使用这个 mining 策略选项。重要的是,所有数据更改都会锁定模式更改,以便所有更改都已从表的日志捕获,停止连接器,应用模式更改,然后重新启动连接器,并恢复表中的数据更改。这个选项需要较少的 Oracle 数据库内存和 Oracle LogMiner 会话,因为数据字典不需要由 LogMiner 进程加载或入门。

为什么连接器似乎停止捕获 AWS 上的更改?

由于 AWS 网关 Load Balancer 上 350 秒的固定空闲超时,需要超过 350 秒的 JDBC 调用可以无限期地挂起。

如果调用 Oracle LogMiner API 需要超过 350 秒才能完成,则可能会触发超时,从而导致 AWS 网关 Load Balancer 挂起。例如,当一个 LogMiner 会话处理大量数据与 Oracle 的定期检查点任务同时运行时,可能会出现这样的超时。

要防止在 AWS 网关 Load Balancer 上出现超时,请以 root 或超级用户身份执行以下步骤,从 Kafka Connect 环境启用 keep-alive 数据包:

  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 数据包。因此,当对 LogMiner API 的 JDBC 调用超过 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 的原因是什么以及如何处理它?

当数据库更改不常时,De Debezium Oracle 连接器可能会报告 ORA-04036 异常。在检测到日志切换前,启动了 Oracle LogMiner 会话并重新使用。会话被重新使用,因为它为 Oracle LogMiner 提供最佳性能利用率,但应该有长时间运行的 mining 会话,这可能会导致过量 PGA 内存用量,最终导致以下异常:

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

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

ORA-01882 的原因是什么以及如何处理它?

Debezium Oracle 连接器可能会在连接到 Oracle 数据库时报告以下异常:

ORA-01882: timezone region not found

当时区信息无法被 JDBC 驱动程序正确解决时,会出现这种情况。为解决与此驱动程序相关的问题,需要告知驱动程序不使用地区解析时区详细信息。这可以通过使用 driver. oracle.jdbc.timezoneAsRegion=false 指定驱动程序 pass through 属性来实现。

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 配置选项,以防止连接器访问这些表。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.