1. 概述
本文列举 配置外接数据库 时,可能出现的报错和解决方案。
2. 数据库迁移后升级 JAR ,无法打开平台
问题描述:
用户已配置外接数据库,升级 JAR 后,无法打开平台,报错:TASKNAMECALCCULATEATEONCE 标识符和 USERALIAS 标识符无效
原因分析:
进行迁移用户没有 alter 权限,无法生成字段。
解决方案:
给迁移的用户授权 alter 权限。
3. 用户 root 登录失败 ClientConnectionId:XXX
问题现象:
配置外接数据库时,出现报错:用户 root 登录失败,ClientConnectionId:e484a26e-8f2b-4e28-b9e4-32798ec032b7 ,以及外置数据无法连接配置等报错
原因分析:
报错是由于 FineBI 外接数据库的配置错误,需要删除 FineBI 的外接数据库的配置信息,重新配置外接数据库。
解决方案:
删除FineBI/webapps/webroot/WEB-INF/config下的后缀名为 db.properties 文件,重新对 FineBI 外置数据库进行配置。
4. 迁移数据库后,回退JAR包平台登录失败
问题描述:
报表工程已迁移至外接数据库,升级 JAR 后,又迁移至另一外接数据库,回退 JAR,发现平台登录失败,显示数据库连接异常,如下图所示:
原因分析:
JAR 回退,但存储外接数据库配置的 db.properties 文件没有跟随其变化。
解决方案:
检查 %FineBI_HOME%/webapps/webroot/WEB-INF/config 路径下 db.properties 文件,手动修改相关配置。
举例:一工程迁移到 MySQL8 数据库,升级 JAR 后 重新迁移到 MySQL5.7.28 数据库,回退工程,启动失败,前台显示连接不上数据库,将db. properties中方言的 8 改为 5 即可。
修改前:
hibernate.dialect=com.fr.third.org.hibernate.dialect.MySQL8Dialect
修改后:
hibernate.dialect=com.fr.third.org.hibernate.dialect.MySQL5Dialect
5. 集群环境下 FineDB 迁移失败
问题描述:
集群环境下迁移 FineDB 数据库,使用平台功能迁移,出现如下图所示的界面后,点击登录会反复刷新此界面。
原因分析:
集群环境下的迁移操作方法出错。
解决方案:
集群迁移需要把其他节点关闭,只启动一个节点进行迁移。
迁移成功后,把 db.properties 文件复制到没迁移的节点,然后关闭集群所有节点再启动。
6. CAS单点环境下 FineDB 迁移失败
问题现象:
1)迁移外接数据库时一直卡在数据导入阶段。
2)后台存在报错:database is locked。
3)工程做了 CAS 单点,报错里有 CAS 相关的日志。
原因分析:
迁移时有其他用户访问了平台,导致部分表被锁死,无法迁移。
解决方案:
先将 CAS 单点撤掉,保证没有用户访问平台。
外接数据库迁移成功之后,再将 CAS 单点加上。
7. 定时调度任务导致迁移失败
问题现象:
迁移外接数据库失败,报错:
Null value was assigned to a property [class com.fr.scheduler.quartz.entity.QuartzFiredTriggers.isNonconcurrent] of primitive type setter of com.fr.scheduler.quartz.entity.QuartzFiredTriggers.isNonconcurrent
原因分析:
定时调度执行过程中,FineDB 中的 QRTZ_FIRED_TRIGGERS 表会临时记录定时调度数据,任务执行成功后,数据自动删除。
当定时调度任务执行了一半,数据已生成时,进行外接数据库迁移操作,暂停定时调度任务失败,导致迁移失败。
解决方案:
按照报错信息,清空相关表,例如清空 QRTZ_FIRED_TRIGGERS 表数据。
8. Table 'finedb.QRTZ_PAUSED_TRIGGER_GRPS' doesn't exist
配置 MySQL 数据库,导入数据失败,页面前端报错:could not execute statement;
接着查看%FineBI%/logs/fanruan.log,报错为:Table 'finedb.QRTZ_PAUSED_TRIGGER_GRPS' doesn't exist
排查步骤一:
MySQL数据库的编码不正确,字符集应当为 utf8 ,排序规则为 utf8_bin。
修改数据库编码,使用utf8编码,不支持 utf8mb4 编码
排查步骤二:
MySQL数据库的数据引擎不正确,应当为InnoDB
1)在 MySQL 数据库配置文件 my.cnf 中的 [mysqld] 下面加入default-storage-engine=INNODB 一句,保存;
2)重启 MySQL 服务器:mysqladmin -u root -p shutdown或者service mysqld restart。
3)登录 MySQL 数据库,在mysql>提示符下输入show engines命令。如果出现 InnoDB |DEFAULT,则表示设置 InnoDB 为默认引擎成功。
9. Incorrect string value: 'xxx' for column 'id' at row 1
配置外接数据库 MySQL 报错,报错日志如下所示:
16:59:48 Thread-45 ERROR [standard] could not execute batch
com.fr.third.org.hibernate.exception.GenericJDBCException: could not execute batch
......Caused by: java.sql.SQLException:Incorrect string value: 'xE6xA8xA1xE6x9DxBF...' for column 'id' at row 1
原因分析:
检查确保是有权限的
Incorrect string value: 'xE6xA8xA1xE6x9DxBF...' for column 'id' at row 1
是数据库编码的原因
解决方案:
查看客户建 FineDB 数据库的语句:create database finedb
发现没有加约束条件,将语句改为:create database finedb DEFAULT CHARSET utf8 COLLATE utf8_bin
导入成功。
10. MySQL The table 'fine_conf_entity' is full
问题现象:
配置 MySQL 数据库,导入数据的时候报错:java.lang.Exception: migrate table com.fr.config.entity.Entity failed
查看%FineBI%/logs/fanruan.log,报错:The table 'fine_conf_entity' is full,如下图所示:
解决方案:
进入 MySQL 的配置文件/etc/my.cnf,在[mysqld]下添加/修改两行:
tmp_table_size = 256M
max_heap_table_size = 256M
系统默认是 16M ,修改完后重启 MySQL 。
11. 数据库连接失败 wait millis 10000,active0,maxActive 50
问题现象:
配置 SQL Server 和 Oracle等含有「模式」的数据库时,出现报错:数据库连接失败,wait millis 10000,active0,maxActive 50
如下图所示:
排查思路:
1)确认数据库名称,主机地址,端口用户名和密码是否正确。
2)确认此服务器此端口是否开放给其他电脑,可在其他地方进行数据库连接测试。
3)更改模式,使其与数据库用户名一样,如下图所示:
12. ORA-01654: 索引无法通过128(在表空间xxx中)扩展
问题现象:
配置外接数据库 Oracle 报错java.lang.Exception: migrate table com.fr.config.entity.Entity failed
日志报错:Caused by: java.sql.BatchUpdateException: ORA-01654: 索引 BI_REPORT_RO.SYS_C0011297 无法通过 128 (在表空间 BI_REPORT_RO 中) 扩展
数据表创建成功,但是导入数据失败。
原因分析:
数据库表空间不足。
解决方案:
默认表空间数据文件大小与DATA BLOCKS的大小有关,默认最大为32GB。
用户可通过如下SQL增加表空间数据文件:
alter tablespace USERS add datafile 'D:appAdministratororadataorclUSERS02.DBF' size 10240M;
13. Oracle19c 数据迁移卡住
问题现象:
Oracle19c数据库,数据连接成功,但是在配置外接数据库时一直卡在正在连接状态。
原因分析:
用户环境禁用了 PUT、DELETE请求,导致平台一些请求不正常。
解决方案:
用户可通过安装「PUT、DELETE请求转成POST」插件,将 PUT、DELETE 请求转成 POST 请求。
详情请参见:PUT、DELETE请求转成POST插件