FAQ
原因：触发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
处理建议：尽量将多个要同步的表合并到一个任务中去，减少任务数，即可减少任务对oracle的请求。从而减少oracle的压力。
答：可能原因之一，在一个任务中，作为同一源连接的同一源表节点，不能同时存在2个或以上。比如下图这种情况，同一源表BD_ADDRESS存在了2个，第二个的同步会被忽略，改为一个源表连接2个目标节点就可以解决。
原因：tapdata 启动需要连接mongodb，在mongodb中存储相关软件配置信息。该错误提示 MongoDB 连接不上。
解决方法：重新配置tapdata 配置，确认账号密码是否正确在 tapdata 软件目录下执行以下命令，重新配置：./tapdata init
原因：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/'
原因分析：创建连接后，需要通过 tapdata agent 去测试数据源可用。所以需要启动 tapdata agent。
解决方法：检查 agent 是否正确启动，并启动 agent。
进入 tapdata 目录，./tapdata start backend
原因分析：作为源端连接，tapdata 要求源端 schema 下有数据表。
解决方法：在源端 schema 下创建一张表
原因分析：作为 Oracle 源端连接，经常会因为 table space 不足的问题导致同步任务中断，tapdata 若具备 UNLIMITED TABLESPACE 即可自动扩容
解决方法：这个提示信息是一个warning ，所以不会影响正常任务，当同步过程中遇到table space 不足的时候，任务设置为 stopOnError，任务即会停止。
看源端数据库压力
源端数据库有没有 死锁
同步节点 cpu 内存 有没有异常
网络是否通畅
找到最一开始的block 时间点，看看前后日志
如果是 一个flow 下拆了多个子任务，看看 是哪个子任务 堵住了（子任务就是日志里报的 任务名_1/2/3 ）
需要一些时间来挖，等待一段时间（5-10分钟） ，之后就好了
确认源端和目标端表结构是否一致
源端和目标端执行：select * from NLS_DATABASE_PARAMETERS; 对比结果是否一致。确认字符集等系统设置是否一致。
查看数据是否有异常
查看数据库版本：select * from v$version;
版本1.13.2
同步任务的【初始化+增量同步】设置中，去重写入机制：强制去重写入；目标写入线程数：1。
复现流程
重新测试一个已存在的目标连接
当测试完成后，在一段时间内，数据目录会无法看到之前已加载的表，这个时间长短取决于中间库的压力，以及数据库中表和字段的数量
创建同步任务并运行，或者重置已有任务并运行，则有几率会触发该问题
原因分析
元数据的删除为逻辑删除(即通过一个字段is_deleted，来控制是否显示在界面)
当测试数据连接时，会将该库所有的表修改为逻辑删除的状态，此时数据目录无法看到所有这个库下面的表模型，此时后台会以异步的方式对每个表模型进行处理并更新数据库
在这段时间中，重置同步任务并运行，会触发同步任务的模型推算逻辑，该逻辑会去数据库中查找已存在的目标表模型
如果找到，则会对字段属性进行合并，则原有的字段属性不会有任务变动
如果找不到，则会用推算后，新的字段属性覆盖已存在的字段属性，这里导致该问题的发生
结论：该问题由于程序bug导致，正常情况下，发生几率较低，当中间库压力较大时，发生几率增高
解决方案
已对1.11及1.12修复该问题，可以通过升级到版本v1.11.7、v1.12.9，可以解决该问题
已在v1.13版本验证，不存在该问题，所以升级到版本v1.13.x及后续版本，也可以解决该问题
如果不能进行升级，则需要在操作时注意，测试连接后，等待数据目录中可以看到表模型后，再对同步任务进行重置并启动的操作，也不会出现该问题
报错：
[ERROR] 2020-11-15 09:55:32 [Transformer initial sync runner-threadNo-0-[5fb08a8cacee195adb14dfe2]] com.tapdata.transformer.TransformerInitialSyncProcess - Bulk operation to target failed, message: Process message ProcessResult{query=Query: { }, Fields: { }, Sort: { }, update={ }, op='i', collectionName='mdm_project_info_tmp1', [email protected][resumeToken=,debeziumOffset=,ts=], fromTable='mdm_project_info', processSize=1, relationship='OneOne', writeModel=null, targetpath=''} failed null.
排查：
报错信息中， query=Query:{}, Fields:{}, Sort:{}, update={}, 表示有从源表查询获取的记录全部为空，连关联条件joinkeys也为空。
原因：
源表节点后跟字段节点，字段节点的处理只保留了源表记录中的5个字段，然后写入到目标表中关联条件是5个字段之一project_id, 但有部分记录project_id是没有的，造成报错并且任务中断。
解决：
或在源表中加过滤条件，把project_id不存在的字段去掉。
或在字段节点前加JS节点，把project_id不存在的去掉（在字段节点后JS脚本无法判断完全不存在的记录）。
原因：
如果MongoDB的Collection，其中文档的field不一致，那么会累计显示所有的field。
在【数据目录】，浏览某一张表，其中的【数据模型】中的【是否覆盖】，默认是被勾选的，这样新的数据模型会覆盖旧的。如果没有被勾选，那么在任务中，即使点击更新模型，也不会加载最新的数据模型。
解决：
或者在【数据目录】，找到这张表，勾选其中的【数据模型】-【是否覆盖】。
或者在【数据目录】，删除这张表（注意：这里不是物理删除，只是在数据目录中删除，但如果已经对这张表某些field做了别名，或者其他处理，则会被一起删除），然后在任务中，点击这张表的【更新模型】。
报错：
io.tapdata.CustomSourceAndTarget.lambda$initialSync$0(CustomSourceAndTarget.java:133) java.lang.Thread.run(Thread.java:748) , err=unknown error: Could not extract response: no suitable HttpMessageConverter found for response type [interface java.util.List] and content type [application/octet-stream]}, err_message=request error: Could not extract response: no suitable HttpMessageConverter found for response type [interface java.util.List] and content type [application/octet-stream]}
原因：
在Custom Connection的脚本中如下语句，以为API接口返回的object，所以设置为'object'，但实际上返回的是长得象object的string。
解决：
首先，指定返回的是string；
// 以为API返回的是objectvar result = rest.get(reqURL,{},'object');// 实际API返回的是stringvar result = rest.get(reqURL,{},'string');
其次，API返回的body，是被放置在以下的data[ ]中的；
Http Return Instructions// data为返回的body，可能是array或object或string{code:200, data:[]}
所以，API接口返回的string，还需要转化成对象如下：
// 获取API返回的结果var result = rest.get(reqURL,{},'string');// 其中的返回结果部分data是string，转化成对象var newObject = JSON.parse(result.data);
原因：
默认接收API接口返回的body，文本编码是UTF-8；
但是实际返回的body，文本编码是ISO-8859-1。
解决：
在Custom Connection的脚本中，API接口返回的body是string，且文本编码是ISO-8859-1，所以对接收的body首先要正确编码，然后再从string转为object，代码如下：
// 获得API接口的返回数据var result = rest.get(reqURL,{},'string');// 转化ISO-8859-1文本编码var newString = new java.lang.String((result.data.toString()).getBytes("ISO-8859-1"));// 把string转成对象var newObject = JSON.parse(newString);
报错：
Change stream listening cdc event error Command failed with error 280 (ChangeStreamFatalError): 'cannot resume stream; the resume token was not found.
原因：
Mongo 同步需要依赖 oplog，oplog 本身是一个固定大小的集合，和 Oracle、MySQL 不一样，oplog 保存的是固定大小内的日志，而不是指定时间内的日志。
当业务非常频繁，产生大量 oplog 时，就有可能引起同步任务未追到最新日志，而 oplog 已被冲走的情况，此时同步任务无非找到 oplog offset，从而引起该报错。
解决：
reset 任务
重新初始化
最佳实践：
采用 mongo 共享挖掘任务，可解决 oplog 在短时间内被冲走的情况（1.19 及以上版本支持）
合理评估业务增量，设定合理 oplog 大小
在不支持共享挖掘的版本中，在收到告警后，可以通过以下步骤定位：
查看中间库 Jobs 表，确认所有子任务 offset
use tapdata;function checkOffset1(jobName) {db.getCollection('Jobs').find({}).forEach(function (job) {if (job.name.indexOf(jobName) > -1) {if (job.offset) {if (job.offset.offset) {if (job.offset.offset.ts) {print(job.name + ": " + new Date(job.offset.offset.ts * 1000))} else if (job.offset.offset.timestamp) {print(job.name + ": " + new Date(job.offset.offset.timestamp))}} else if (job.offset.ts) {print(job.name + ": " + new Date(job.offset.ts * 1000))} else if (job.offset.timestamp) {print(job.name + ": " + new Date(job.offset.timestamp))}}}})}var jobNames = ["任务名"];jobNames.forEach(function (name) {checkOffset1(name)})
2. 2.22.11
2. 确认当前 oplog 的最早时间
db.printReplicationInfo（）
3. 确认子任务中，有一个确实超出了 #2 中的 oplog first event time
4. 重置任务
5. 任务设置：增量
6. 设置任务 cdc time point 为所有子任务最新时间，保存任务
7. 启动任务
报错：
[ERROR] 2020-11-16 21:03:59 [Connector runner-log_20200818_1-[5fb278b787f6244aa9f518dc]] io.tapdata.LogCollectSource - Database type log_collect when increamentalSync error, need stop: true, message: java.lang.Exception: Init oracle connector error: Convert sync time 2020-11-16 21:00:00 to scn failed, maybe there is not in redo log file..
原因：
在Oracle日志挖掘节点的设置中挖掘日志时间，选择【用户浏览器时区】，设置了当前的时间。但是用户浏览器时区是东八区，而Oracle数据库是0时区，对于Oracle数据库来说，用户浏览器时区是未来的时间，所以当前时间的redo log file还不存在。
解决：
在挖掘日志时间，选择【此刻】，即从当前时间开始挖掘。
如果选择【用户浏览器时区】，设置时间，要考虑Oracle数据库的时区，以确定redo log file文件已生成。
报错：
[ERROR] 2021-05-26 10:30:55 [Transformer Start Job Handler[4baed3]] io.tapdata.manager.TransformerJobManager - Automatically create target index(s) failed, job name: 01MDM今日报警资料_宽表 _1, err: io.tapdata.exception.MongodbException: Automatic index creation in target table 60a39a6ca39c6e1a5c6dff76_ddb673b9-4a28-42a9-8a97-cb04fc781fc4_TPORIG_tdm_jx_mechanics_monitor_1_TPORIG skipped. Target table count 55,296,620, greater than threshold 5,000,000. Index key is: { "DeviceID" : 1 }, stacks: sun.reflect.GeneratedMethodAccessor595.invoke(Unknown Source)
原因：
为目标表创建索引，会占用数据库的空间，对于超过500万条的表，由于不知道用户的目标库是否有足够空间，出于对数据库稳定性的考虑，让用户视情况手动建索引。
上述这种情况，也适用于在从表同步时产生的缓存表。
创建索引很有必要，否则会同步速度会变得很缓慢，并拖累整个数据库的性能。
解决：
停止任务，进入编辑状态，在顶部的【初始化+增量同步】中，关闭【自动创建索引】选项。
进入数据库，对目标表手动建立索引；索引的建立，可以根据任务中源表同步到目标表的【关联条件】来设置，注意请设置成以后台方式建立索引。从表以及它的缓存表都可以按照这个关联条件来设置索引。
重置启动任务。
附注：
在产品中创建MongoDB集合索引的方法：
【数据治理】-【元数据管理】中找到需要建索引的表，点击这张表的最右侧的【查看详细】，进入这张表的【数据目录】页面，点击【索引】Tab，可以创建索引。