1.1 任务日志界面报错:脏数据或Too many dirty error
1.1.1 日志界面报错Long类型不能转为Bytes
原因:
tinyint(1)类型字段被代码读取为bit类型字段
解决方案:
数据连接中增加参数?tinyInt1isBit=false
1.1.2 脏数据条数检查不通过,限制是[(0]条, 但实际上捕获了[1]条
报错:limit [0] records , but catch [13] records,继续查看fanruan.log日志是否有相关报错。
原因1:
查看来源表中某字段有空值,但是目标表中该字段设置了不可为空
解决方案:
过滤掉来源表中某字段为空的数据,或者设置目标表字段可为空
原因2:
来源数据与目标数据的字段类型或字段长度对不上
解决方案:
修改目标表字段类型、字段长度,与来源表相符
原因3:
当 IDENTITY_INSERT 设置为 OFF 时,不能为表 'CB' 中的标识列插入显式值。
解决方案:
数据库配置问题set IDENTITY_INSERT Student ON。
原因4:
报错如图,来源库或者目标库存在MySQL数据库,且存在timestamp字段类型,该字段类型下有表内容不在‘1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07'UTC范围内。
解决方案:
在数据库中将字段类型修改为datetime即可,目前FDL对于MySQL数据库的datetime字段类型会自动映射为timestamp,数据库中修改成功即可。
原因5:
报错如图,表空间不够导致数据无法写入。
解决方案:
对表空间不设上限。
原因6:
将截断字符串或二进制数据。
解决方案:
字符串长度超出限制,根据来源库的字段长度在字段映射选择合适的目标库的字段类型。
原因7:
数据类型text和nvarchar在equal to运算符中不兼容。
解决方案:
SQL Server数据库里设计的表的数据类型有text,无法完成转换。字段类型设置为varchar(n)【n根据来源表字段长度自行设置】。
小结:
报错脏数据目前发现的原因有:
1.字段类型不匹配
2.字段长度不够
3.inentity insert设置为off
4.复制节点没有点击字段映射
5.时间超过timestamp的限制范围
1.2 任务日志界面报错:您填写的参数值不合法
报错详细:
com.fr.dp.exception.FineDPException: Code:[DBUtilErrorCode-02], Description:[您填写的参数值不合法.]. - 您的配置文件中的列配置信息有误. 因为您未配置写入数据库表的列名称,fdl获取不到列信息. 请检查您的配置并作出修改.
原因:
来源表字段获取失败
解决方案:
检查来源表数据预览是否成功,若是数据库数据源,可能是sql语法错误,若是API数据源,可能token失效
1.3 预览数据来源报错:无法获取已存在的目标表
查看fanruan.log日志报错:不支持的字符集(在类路径中添加orai18n.jar)
原因:
lib中缺少orai18n.jar包
解决方案:
FDL的lib中增加orai18n.jar包即可
1.4 数据来源选择API,预览时执行失败
报错详细:
com.fr.dp.exception.FineDPException: API_DATA_INVALID_ERROR - ApiReader can't get data of column [data], please check api response.
原因:
API数据源token失效,读不到data字段
解决方案:
重新获取API数据源的token
1.5 数据来源选择API,预览时显示数据为空值
原因:
请求头中可能未指定通过json的格式进行取数
解决方案:
点开更多配置,请求头中添加: {"Content-Type":"application/json"}
1.6 数据来源选择API,预览时报错Warning: wrong json format
原因:
导入的是表格形式,如果不写,就是识别表格,会报错
解决方案:
请求头加上:{"Content-Type":"application/json"}
1.7 运行任务显示:服务器内部错误
原因1:核实触发了20009规则,该规则主要拦截POST数据请求体解码后包含”%“、”$“等特殊字符的攻击特征,这些字符通常是代码执行攻击利用到字符,所以被识别为攻击拦截了。
解决方案:
条件分支用到了$,特殊字符需要加密传输,可以先给$ 这个字符开通道,如下图,或对这个ip加白名单
原因2:
服务器禁用了put和delete请求,安装插件“put和delete转换为post”即可。
1.8 任务日志界面报错:数据连接异常
数据连接异常- DataBase[testnora]'s table[ceshi1] get pk names failed! - Table 'testnora.ceshi1' doesn't exist
原因:
可能是编码不同导致无法识别,指定数据连接编码即可。
解决方案:
要在数据连接的url处,增加:?useUnicode=true&characterEncoding=UTF-8
1.9 数据去向为GPload时,运行任务出现“connection disabled”的报错
原因:
fd和fdl服务器网络可能没互通,网络连接问题
解决方案:
检查下fdl服务器的15500端口有没有开放,fd服务器能否ping通fdl服务器
1.10 页面无报错,读取正常但是插入卡住
原因:
可能是目标库发生了锁表,导致该表无法进行数据插入
解决方案:
检查目标表是否锁表,检查方式和解锁方式见网络:https://blog.csdn.net/zbh1957282580/article/details/122457542
注:该动作会直接结束锁表进程,有可能会影响他人使用数据库,结束前请注意确认该进程来源,以免影响业务。
1.11 Oracle数据库相关报错
1.11.1 数据同步自动建表报错ORA-12899:value too large for column “xx”(actual:12,maximum:4)
原因:
设定的最大字段长度是4,但是实际上是12,超过了规定的最大字段长度
解决方案:
报错之后表已经建立成功,需要到数据库中删除已经建立好的表,然后再次自动建表,此次自动建表需要将相关字段的字段长度设置的长一点。
1.11.2 数据同步报错ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column
原因:
Oracle 10g在clob字段的一个bug,Oracle在insert语句时,会默认将所有私有属性按照首字母排序,clob字段如果恰好被排在varchar2或其他非clob字段前,就可能会出现此异常。
解决方案:
在字段映射界面将clob字段拖拽到最后。
1.11.3 数据同步报错ORA-01461: can bind a LONG value only for insert into a LONG column
原因:
插入字符串超出字符串长度。
解决方案:
如图是字段类型为varchar2,但有的字段长度超过4000,将字段类型修改为clob即可。
1.12 数据同步节点配置界面空白
原因:
Chrome浏览器版本过低,或者使用的是IE或者其它浏览器。
解决方案:
使用最新版本的Chrome浏览器。
1.13 写入配置Greenplum(并行装载)时报错gpfdist服务启动异常“”error=13, 权限不够
原因:
gpfdist权限为644,所有者只有读、取权限,没有可执行权限。
解决方案:
赋予该文件可执行权限。