FAQ

Tapdata 启动可能会碰到oracle max servers bug,怎么解决?

原因:触发oracle bug 19587324 bug 描述:在oracle 参数parallel_degree_limit,parallel_threads_per_cpu, cpu_count, parallel_max_servers设置非常大的情况下,在调用logminer时候可能会触发logminer使用256并发访问logminer相关的基表。

影响:造成服务器高cpu消耗。 触发版本:oracle 11.2.0.4全版本,12.1.0.2 全版本 修复版本:12.2.0.1

Tapdata 任务数量太多导致oracle 压力增加,怎么处理?

处理建议:尽量将多个要同步的表合并到一个任务中去,减少任务数,即可减少任务对oracle的请求。从而减少oracle的压力。

同步任务中,有一些源表并没有数据同步到目标表中,日志中也没有报错,什么原因?

答:可能原因之一,在一个任务中,作为同一源连接的同一源表节点,不能同时存在2个或以上。比如下图这种情况,同一源表BD_ADDRESS存在了2个,第二个的同步会被忽略,改为一个源表连接2个目标节点就可以解决。

安装部署MongoTimeoutError: Server selection timed out after 30000 ms

原因:tapdata 启动需要连接mongodb,在mongodb中存储相关软件配置信息。该错误提示 MongoDB 连接不上。

解决方法:重新配置tapdata 配置,确认账号密码是否正确在 tapdata 软件目录下执行以下命令,重新配置:./tapdata init

授权过期,More than the free trial period

原因:tapdata 企业版默认 2 个月免费试用期,免费试用过期后,需要向tapdata 团队申请授权 license

排查方法:查看tapdata-web日志,有关键字:More than the free trial period

日志位置:~/.tapdata/log/tapdata-web.日期

管理端配置文件写错

排查方法:确认 tapdata 配置文件的内容是否正确

配置文件位置:~/.tapdata/application.yml

确认配置文件中 tapdata.conf.backendUrl 是否正确,ip 是否正确截图中,tapdataPort 端口是 3030,但是 backendUrl 缺少了 3030 端口

解决方法:修改 tapdata.conf.backendUrl 为 'http://172.16.46.138:3030/api/'

The test connection service is not available, please check if the Data Synchronization Agent is started correctly.

原因分析:创建连接后,需要通过 tapdata agent 去测试数据源可用。所以需要启动 tapdata agent。

解决方法:检查 agent 是否正确启动,并启动 agent。

进入 tapdata 目录,./tapdata start backend

ORA-00942: table or view does not exist

原因分析:作为源端连接,tapdata 要求源端 schema 下有数据表。

解决方法:在源端 schema 下创建一张表

User miss [UNLIMITED TABLESPACE, CREATE ANY INDEX, CREATE ANY TABLE] privileges

原因分析:作为 Oracle 源端连接,经常会因为 table space 不足的问题导致同步任务中断,tapdata 若具备 UNLIMITED TABLESPACE 即可自动扩容

解决方法:这个提示信息是一个warning ,所以不会影响正常任务,当同步过程中遇到table space 不足的时候,任务设置为 stopOnError,任务即会停止。

Source read block

  1. 看源端数据库压力

  2. 源端数据库有没有 死锁

  3. 同步节点 cpu 内存 有没有异常

  4. 网络是否通畅

  5. 找到最一开始的block 时间点,看看前后日志

  6. 如果是 一个flow 下拆了多个子任务,看看 是哪个子任务 堵住了(子任务就是日志里报的 任务名_1/2/3 )

进入增量,但没有拿到新增数据 刚进入日志

需要一些时间来挖,等待一段时间(5-10分钟) ,之后就好了

ORA-12899: value too large for column "<SCHEMA>"."<TABLE>"."COLUMN" (actual: 68, maximum: 60) and stop on error is true, will stop replicator..

  1. 确认源端和目标端表结构是否一致

  2. 源端和目标端执行:select * from NLS_DATABASE_PARAMETERS; 对比结果是否一致。确认字符集等系统设置是否一致。

  3. 查看数据是否有异常

  4. 查看数据库版本:select * from v$version;

聚合节点Ag,分组统计的数据出现重复

版本1.13.2

同步任务的【初始化+增量同步】设置中,去重写入机制:强制去重写入;目标写入线程数:1。

数据目录,丢失字段描述(别名、数据字典)的原因分析及解决

处理人:sam

日期:2020-10-27

出现版本:v1.11.(1-6)-v1.12.(1-8)版本

复现流程

  1. 重新测试一个已存在的目标连接

  2. 当测试完成后,在一段时间内,数据目录会无法看到之前已加载的表,这个时间长短取决于中间库的压力,以及数据库中表和字段的数量

  3. 创建同步任务并运行,或者重置已有任务并运行,则有几率会触发该问题

原因分析

  • 元数据的删除为逻辑删除(即通过一个字段is_deleted,来控制是否显示在界面)

  • 当测试数据连接时,会将该库所有的表修改为逻辑删除的状态,此时数据目录无法看到所有这个库下面的表模型,此时后台会以异步的方式对每个表模型进行处理并更新数据库

  • 在这段时间中,重置同步任务并运行,会触发同步任务的模型推算逻辑,该逻辑会去数据库中查找已存在的目标表模型

    • 如果找到,则会对字段属性进行合并,则原有的字段属性不会有任务变动

    • 如果找不到,则会用推算后,新的字段属性覆盖已存在的字段属性,这里导致该问题的发生

结论:该问题由于程序bug导致,正常情况下,发生几率较低,当中间库压力较大时,发生几率增高

解决方案

  1. 已对1.11及1.12修复该问题,可以通过升级到版本v1.11.7、v1.12.9,可以解决该问题

  2. 已在v1.13版本验证,不存在该问题,所以升级到版本v1.13.x及后续版本,也可以解决该问题

  3. 如果不能进行升级,则需要在操作时注意,测试连接后,等待数据目录中可以看到表模型后,再对同步任务进行重置并启动的操作,也不会出现该问题