Smartbi Insight 信创版帮助中心
页面树结构
转至元数据结尾
转至元数据起始

正在查看旧版本。 查看 当前版本.

与当前比较 查看页面历史

« 前一个 版本 9 下一个 »

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查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段））手动兼容手工调整成目标业务库的大小写规则
源库——》目标库大小写规则一致无自动兼容
2SQL语法差异不同数据库的 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查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段））手动兼容手工调整成目标业务库对应的函数
4Catalog 和 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工具进行字符转换并校验。
7NULL处理差异某些数据库不允许空字符串作为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 源库与目标库信息完全一致的迁移

适用情况

  • 同类型数据库迁移（如 Oracle→Oracle、MySQL→MySQL）。

  • 仅更换服务器地址 / 端口，数据库结构（Schema、Catalog、表名）完全不变

具体操作步骤：

1、打开已有的数据源，修改其连接字符串的数据库名称及其对应的用户名密码：

2、点击【测试连接】确保数据库能正常连接，再点击【保存】按钮即可。
3、验证功能：

  • 打开历史报表，检查数据加载是否正常。
  • 测试自助数据集、数据模型的查询功能。

4.2 源库与目标库“大小写规则不一致”的迁移

背景：

某银行计划将原有 Impala 数据库替换为 StarRocks 数据库，需迁移表和数据。但 StarRocks 要求表名、字段名必须为全小写，不支持大小写混合（例如 Impala 中表名 “OrderInfo” 在 StarRocks 中需改为 “orderinfo”）。

问题影响：
Smartbi 中表和字段的 “身份 ID”（即系统识别的唯一标识）是根据数据库实际名称生成的。若迁移后表名 / 字段名变更（如从 “OrderInfo” 变为 “orderinfo”），Smartbi 中基于旧库创建的报表、数据集、数据模型等上层资源，会因找不到对应的 “旧 ID” 而报错（例如提示 “表不存在”“字段匹配失败”）。


解决方案：

  1. 统一命名规范：在数据迁移前，将 Impala 数据库中的表名、字段名统一修改为全小写（如 “OrderInfo”→“orderinfo”，“CreateTime”→“createtime”），确保与 StarRocks 的命名规则一致。

  2. ID 规则自动映射（兼容旧资源）：使用 ID 规则强制转换（如 LOWER_CATALOG规则将表ID转为小写）,详细可查看：业务库迁移之后ID替换操作。


4.3 源库与目标库"Catalog 、Schema 不一致"的迁移

背景：

在企业数字化转型中，数据库迁移常面临跨类型数据库架构差异与版本升级适配两大核心挑战：

  1. 跨数据库类型的天然差异：当从无 Catalog/Schema 的数据库（如旧版 MySQL）迁移至有层级结构的数据库（如 PostgreSQL）时，表的定位路径（如 “Schema. 表名”）会发生根本变化。

  2. 版本升级与多 Catalog 支持：

    • 旧版 Smartbi（如 V10.5.8 前）不支持多 Catalog，字段 ID 格式为 “数据源名.表名.字段名”；
    • 新版本（V11）引入多 Catalog 支持后，字段 ID 变为 “数据源名.Catalog.Schema. 表名.字段名”。若旧库升级时未适配新规则，原有的报表、数据集会因 ID 格式不匹配而无法识别新库表结构。

问题影响：元数据解析失效

Smartbi 通过 “数据源→Catalog→Schema→表→字段” 的层级关系生成唯一标识（ID），若 Catalog/Schema 名称或层级变更，上层资源（报表、数据集、数据模型）会因 “找不到旧 ID 对应的新路径” 报错，具体表现为：

  • 报表 / 数据集提示 “表不存在” 或 “字段匹配失败”；
  • 数据模型关联关系失效，拖放表时无法自动识别字段映射。

解决方案：

这时候需要先把Schema/Catalog的ID替换成新的规则，详细操作可查看：业务库迁移之后ID替换操作。

4.4 源库与目标库“SQL语法有差异”的迁移

如果源库与目标库的SQL语法有差异，需要手工调整SQL语句。

比如源库 mySQL——》目标库PostgreSQL，在数据模型中使用SQL查询使用子查询，如果替换成了oracle 业务库，需要手动在SQL语句中调整成Oracle 语法：

其他数据库之间不同语法，可通过AI搜索进行调整。


4.5 源库与目标库”函数不一致“的迁移

比如源库 mySQL——》目标库PostgreSQL，在数据模型中使用SQL查询获取当前日期，如果替换成了PostgreSQL业务库，需要在手动在SQL语句中调整成PostgreSQL函数：



  • 无标签