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。
处理人：sam
日期：2020-10-27
重新测试一个已存在的目标连接
当测试完成后，在一段时间内，数据目录会无法看到之前已加载的表，这个时间长短取决于中间库的压力，以及数据库中表和字段的数量
创建同步任务并运行，或者重置已有任务并运行，则有几率会触发该问题
元数据的删除为逻辑删除(即通过一个字段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', offset=com.tapdata.entity.MongodbOffset@2c3eec63[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);
[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文件已生成。