1 概述
在信创产业快速发展的背景下,国家正在积极推动信息技术创新,打造自主可控的 IT 环境。数据库作为企业业务系统的核心组成部分,进行国产化替换或迁移到新平台,成为落实这一战略的重要工作。
本方案针对企业迁移数据库时遇到的常见问题(如大小写规则不一致、语法差异等),提供了一套简单易懂的操作方法,帮助 Smartbi 等数据分析工具与新数据库顺利对接,确保企业业务系统在新环境下稳定运行,让数据迁移更轻松、更可靠。
1.1 备份“目标环境”的知识库
迁移操作会覆盖目标环境的知识库。因此,在迁移前,请务必备份目标环境的知识库。后续若需恢复目标环境,可通过备份文件进行操作。
备份知识库功能请参考:备份知识库。
2 数据库迁移完全兼容的前置条件
数据库本身迁移好后,如果希望Smartbi产品中对应的数据源及相关的资源都能正常使用,需要满足一些必要条件,同时通过产品自动或人工手动对产品中的资源进行调整。
完全兼容的前置条件 |
---|
1、迁移前后的数据库都是Smartbi产品支持的数据库类型。 |
2、数据库的字符集一致,或者新的数据库在新的字符集下不乱码。 |
3、迁移前后的数据库名称、表名、字段名完全一致(包括大小写)。 |
4、迁移前后数据库的Schema/Catalog名称及支持完全一致。 |
5、迁移前后表字段的数据类型、数值字段的精度完全一致。 |
6、有在产品中使用存储过程的,存储过程的名称,参数,和返回结果完全一致。 |
7、有在产品中使用分区字段的,迁移后需要有相同的分区字段设置。 |
3 业务库迁移可能遇到的问题以及解决方案
序号 | 问题分类 | 兼容性问题说明 | 可能影响效果 | 迁移场景(源库——》目标库) | 影响范围 数据源(表、字段) | Smartbi产品兼容处理方案 | 建议解决方案 |
1 | 命名与大小写问题 | 不同数据库对表名、列名等的大小写区分规则不同,迁移前后大小写规则可能变化 | 查询失败、BI图表报错 | 源库大小写规则——》目标库大小写规则不一致 | 1、数据源(表、字段) | 自动兼容 | 统一命名规范,使用小写并避免保留字;如需保留大小写,建议统一使用双引号或数据库特定设置。 |
2、拖动生成的数据集、计算字段等:手写sql(数据源下的业务视图(sql查询)、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段)) | 手动兼容 | 手工调整成目标业务库的大小写规则 | |||||
源库大小写规则——》目标库大小写规则一致 | 无 | 自动兼容 | |||||
2 | SQL语法差异 | 不同数据库的 SQL 语法有差别,比如分页(LIMIT vs TOP)、子查询支持程度不同 | 手写SQL失效,BI图表报错 | 源库——》目标库的SQL语法有差异 | 1、数据源(表、字段) 2、拖动生成的数据集、计算字段等:xx | 自动兼容 | 避免手写SQL,优先使用BI工具生成的兼容SQL,或在迁移过程中进行SQL重构与适配。 |
手写sql(数据源下的业务视图(sql查询)、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段)) | 手动兼容 | 手工调整成目标业务库的语法 | |||||
3 | 函数不一致 | 不同数据库的函数名或语法不同(如 NVL、IFNULL、COALESCE) | 指标计算错误、查询失败,BI图表报错 | 源库——》目标库的函数不一致 | 1、数据源(表、字段) 2、拖动生成的数据集、计算字段等:xx | 自动兼容 | 抽象封装公共函数或使用BI平台提供的函数映射功能;复杂逻辑建议使用统一的计算层。 |
手写sql(数据源下的业务视图(sql查询)、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段)) | 手动兼容 | 手工调整成目标业务库对应的函数 | |||||
4 | Catalog 和 Schema 支持差异 | 一些数据库只有 database,无 schema;有些同时有 catalog 和 schema | 表找不到、权限错误、SQL报错 | 源库——》目标库的catalog、Schema 一致 | 直接修改数据源连接 | 自动兼容 | 在迁移前设计好 Schema/Catalog 映射策略;BI中使用动态变量配置 schema/catalog 前缀。 |
源库——》目标库的catalog、Schema 不一致 | 手工兼容 | 需通过 ID 规则统一大小写(如 UPPER_CATALOG 规则,详细查看:业务库迁移之后ID替换操作)。 | |||||
5 | 分区与分布机制 | 一些数据库支持分区表而目标数据库不支持 | 查询效率降低 | 源库有分区表设置——》目标库无分区表设置 | 数据库表分区字段设置 | 不兼容 | 无法兼容,之前设置的分区字段不生效 数据迁移后重新设计分区策略,或使用分布式中间件(如Doris、StarRocks等)适配分析场景。 |
6 | 编码/字符集问题 | 源数据库和目标数据库字符集不同,可能导致中文乱码 | 文本乱码,查询结果错误 | 源库—》目标库,编码/字符集不同 | 手动兼容 | 迁移前统一字符集编码(如UTF-8);采用ETL工具进行字符转换并校验。 | |
7 | NULL处理差异 | 某些数据库不允许空字符串作为NULL,或者布尔字段处理不一致 | 逻辑判断出错 | 源库—》目标库,NULL处理差异 | 回写、excel导入、指标模型创建表 | 手动兼容 | ETL中明确NULL与空值的处理规则;统一布尔字段值的处理方式(如0/1或TRUE/FALSE)。 |
8 | 数据精度问题 | 数值字段在不同数据库中精度定义不一致(如浮点型精度丢失) | 数据计算结果不准 | 源库—》目标库,数据精度不一致 | 手动兼容 | 明确字段精度范围,在迁移脚本中定义精度转换;关键字段建议使用字符串或DECIMAL类型保存。 | |
9 | 事务隔离级别与锁机制差异 | 数据库事务隔离机制不同(如Snapshot、Serializable),锁粒度不一致 | 并发异常、数据脏读 | 源库—》目标库,数据库事务隔离机制不同 | 手动兼容 | 避免在BI中使用事务;使用ETL调度平台时明确隔离级别,尽量避免行级锁冲突。 | |
10 | 执行计划优化器差异 | 不同数据库的执行计划优化器行为不同(如JOIN顺序、并行策略) | 查询变慢、索引失效 | 源库—》目标库的执行计划优化器行为不同 | 手动兼容 | 避免强依赖某一数据库的执行计划逻辑;关键SQL可手动优化,或写入提示(hint)适配。 | |
11 | 跨库引用与远程表支持 | 部分数据库支持dblink/FDW远程表,部分不支持 | 查询失败 | 源库—》目标库, | 手动兼容 | 使用数据同步中间层;或将所有依赖表迁移至同一数据库。 | |
12 | 数据库对象名长度限制 | 不同数据库对表名、字段名长度有限制(如 Oracle 30 字符) | 无法创建表,BI建模失败 | 源库—》目标库 表名、字段名长度有限制不一样 | 手动兼容 | 统一命名规范,限制对象名长度 ≤ 30;可使用简写或别名方式规避。 | |
13 | 数据类型不兼容 | 同一数据在不同数据库中数据类型不同(如 TEXT vs CLOB,BOOLEAN vs CHAR(1)) | 导入/导出失败,BI报错 | 源库—》目标库 数据类型不同 | 手动兼容 | 在ETL/数据同步前统一数据类型映射规则,使用中间层或数据建模工具进行类型转换。 |
4 业务库迁移具体操作示例
4.1 源库与目标库信息完全一致的迁移
具体操作步骤:
1、打开已有的数据源,修改其连接字符串的数据库名称及其对应的用户名密码:
2、点击【测试连接】确保数据库能正常连接,再点击【保存】按钮即可。
3、验证功能:
- 打开历史报表,检查数据加载是否正常。
- 测试自助数据集、数据模型的查询功能。
4.2 源库与目标库“大小写规则不一致”的迁移
背景:
某银行计划将原有 Impala 数据库替换为 StarRocks 数据库,需迁移表和数据。但 StarRocks 要求表名、字段名必须为全小写,不支持大小写混合(例如 Impala 中表名 “OrderInfo” 在 StarRocks 中需改为 “orderinfo”)。
问题影响:
Smartbi 中表和字段的 “身份 ID”(即系统识别的唯一标识)是根据数据库实际名称生成的。若迁移后表名 / 字段名变更(如从 “OrderInfo” 变为 “orderinfo”),Smartbi 中基于旧库创建的报表、数据集、数据模型等上层资源,会因找不到对应的 “旧 ID” 而报错(例如提示 “表不存在”“字段匹配失败”)。
解决方案:
4.3 源库与目标库“SQL语法有差异”的迁移
如果源库与目标库的SQL语法有差异,需要手工调整SQL语句。
比如源库 mySQL——》目标库PostgreSQL,在数据模型中使用SQL查询使用子查询,如果替换成了oracle 业务库,需要手动在SQL语句中调整成Oracle 语法:
其他数据库之间不同语法,可通过AI搜索进行调整。
4.4 源库与目标库”函数不一致“的迁移
比如源库 mySQL——》目标库PostgreSQL,在数据模型中使用SQL查询获取当前日期,如果替换成了PostgreSQL业务库,需要在手动在SQL语句中调整成PostgreSQL函数: