原因:触发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文件已生成。