1 概述

在信创产业快速发展的背景下，国家正在积极推动信息技术创新，打造自主可控的 IT 环境。数据库作为企业业务系统的核心组成部分，进行国产化替换或迁移到新平台，成为落实这一战略的重要工作。
本方案针对企业迁移数据库时遇到的常见问题（如大小写规则不一致、语法差异等），提供了一套简单易懂的操作方法，帮助 Smartbi 等数据分析工具与新数据库顺利对接，确保企业业务系统在新环境下稳定运行，让数据迁移更轻松、更可靠。

1.1 备份“目标环境”的知识库

迁移操作会覆盖目标环境的知识库。因此，在迁移前，请务必备份目标环境的知识库。后续若需恢复目标环境，可通过备份文件进行操作。
备份知识库功能请参考：备份知识库。

注意

注意：如果知识库也需要迁移，在迁移业务库之前，需要先做好知识库的迁移。

2 数据库迁移完全兼容的前置条件

数据库本身迁移好后，如果希望Smartbi产品中对应的数据源及相关的资源都能正常使用，需要满足一些必要条件，同时通过产品自动或人工手动对产品中的资源进行调整。

完全兼容的前置条件
1、迁移前后的数据库都是Smartbi产品支持的数据库类型。
2、数据库的字符集一致，或者新的数据库在新的字符集下不乱码。
3、迁移前后的数据库名称、表名、字段名完全一致（包括大小写）。
4、迁移前后数据库的Schema/Catalog名称及支持完全一致。
5、迁移前后表字段的数据类型、数值字段的精度完全一致。
6、有在产品中使用存储过程的，存储过程的名称，参数，和返回结果完全一致。
7、有在产品中使用分区字段的，迁移后需要有相同的分区字段设置。

3 数据库迁移常见问题及应对方案

下表列出了在产品中使用或者需要在产品中调整的内容，如果是数据库本身迁移的更多常见问题，可参考后面章节“附录”进行处理。

序号	问题分类	兼容性问题说明	可能影响效果	迁移场景(源库——》目标库)	影响Smartbi产品的功能范围	Smartbi产品兼容处理方案	建议解决方案
1	命名与大小写问题	不同数据库对表名、列名等的大小写区分规则不同，迁移前后大小写规则可能变化	查询失败、BI图表报错	源库——》目标库表、字段的大小写规则一致	1、数据源（表、字段）。 2、拖动生成的数据集、计算字段等。 3、手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段））	自动兼容
				源库的表、字段全部大写或全部小写——》目标库不区分大小写	1、数据源（表、字段）。 2、拖动生成的数据集、计算字段等。 3、手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段））	自动兼容	统一命名规范，使用小写并避免保留字；如需保留大小写，建议统一使用双引号或数据库特定设置。
				源库的表、字段全部大写或全部小写——》目标库区分大小写	1、数据源（表、字段）。 2、拖动生成的数据集、计算字段等。	自动兼容	需要先把源库改成目标支持的大小写规则。
				源库的表、字段全部大写或全部小写——》目标库区分大小写	手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段）	手动兼容	在产品中手工调整对应资源，以适配新的规则
				源库表、字段不区分大小写含有大小写混合——》目标库区分大小	1、数据源（表、字段）。 2、拖动生成的数据集、计算字段等。	需要定制	产品不知道用什么规则配对已生成的表、字段ID，需要通过定制扩展包处理。要定制并配置t_schema_idrule表，sql查询等要手工调整。
				源库表、字段不区分大小写含有大小写混合——》目标库区分大小	1、手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段）	手动兼容
				源库表、字段不区分大小写含有大小写混合——》目标库不区分大小	1、数据源（表、字段）。 2、拖动生成的数据集、计算字段等。	需要定制	要定制并配置t_schema_idrule表
				源库表、字段不区分大小写含有大小写混合——》目标库不区分大小	1、手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段）	定制扩展包之后会自动兼容
2	SQL语法差异	不同数据库的 SQL 语法有差别，比如分页（LIMIT vs TOP）、子查询支持程度不同	手写SQL失效，BI图表报错	源库——》目标库的SQL语法有差异	1、数据源（表、字段） 2、拖动生成的数据集、计算字段等	自动兼容	避免手写SQL，优先使用BI工具生成的兼容SQL，或在迁移过程中进行SQL重构与适配。
2	SQL语法差异	不同数据库的 SQL 语法有差别，比如分页（LIMIT vs TOP）、子查询支持程度不同	手写SQL失效，BI图表报错	源库——》目标库的SQL语法有差异	手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段））	手动兼容	在产品中手工调整成目标业务库的语法
3	函数不一致	不同数据库的函数名或语法不同（如 NVL、IFNULL、COALESCE）	指标计算错误、查询失败，BI图表报错	源库——》目标库的函数不一致	1、数据源（表、字段） 2、拖动生成的数据集、计算字段等	自动兼容	抽象封装公共函数或使用BI平台提供的函数映射功能；复杂逻辑建议使用统一的计算层。
3	函数不一致	不同数据库的函数名或语法不同（如 NVL、IFNULL、COALESCE）	指标计算错误、查询失败，BI图表报错	源库——》目标库的函数不一致	手写sql（数据源下的业务视图（sql查询）、原生sql查询、sql查询、模型中的sql查询、所有数据集及报表中直接写的计算字段(计算列、计算度量、分组字段））	手动兼容	在产品中手工调整成目标业务库对应的函数
4	Catalog 和 Schema 支持差异	一些数据库只有 database，无 schema；有些同时有 catalog 和 schema	表找不到、权限错误、SQL报错	源库——》目标库的catalog、Schema 一致	直接修改数据源连接	自动兼容	在迁移前设计好 Schema/Catalog 映射策略；BI中使用动态变量配置 schema/catalog 前缀。
4	Catalog 和 Schema 支持差异	一些数据库只有 database，无 schema；有些同时有 catalog 和 schema	表找不到、权限错误、SQL报错	源库——》目标库的catalog、Schema 不一致		手工兼容	需通过 ID 规则统一大小写（如 UPPER_CATALOG 规则,详细查看：业务库迁移之后ID替换操作）。
5	分区与分布机制	一些数据库支持分区表而目标数据库不支持	查询效率降低	源库有分区表设置——》目标库无分区表设置	数据库表分区字段设置	不兼容	无法兼容，之前设置的分区字段不生效数据迁移后重新设计分区策略，或使用分布式中间件（如Doris、StarRocks等）适配分析场景。
6	NULL处理差异	某些数据库不允许空字符串作为NULL，或者布尔字段处理不一致	逻辑判断出错	源库—》目标库，NULL处理差异	回写、excel导入、指标模型创建表	自动兼容
6	NULL处理差异	某些数据库不允许空字符串作为NULL，或者布尔字段处理不一致	逻辑判断出错	源库—》目标库，NULL处理差异	ETL写入	手动兼容	在产品中调整ETL对应节点，在ETL中明确NULL与空值的处理规则；统一布尔字段值的处理方式（如0/1或TRUE/FALSE）。

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” 而报错（例如提示 “表不存在”“字段匹配失败”）。

解决方案：

统一命名规范：在数据迁移前，将 Impala 数据库中的表名、字段名统一修改为全小写（如 “OrderInfo”→“orderinfo”，“CreateTime”→“createtime”），确保与 StarRocks 的命名规则一致。
ID 规则自动映射（兼容旧资源）：使用 ID 规则强制转换（如 LOWER_CATALOG规则将表ID转为小写）,详细可查看：业务库迁移之后ID替换操作。

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

背景：

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

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

5 附录

5.1 数据库迁移其他问题与解决方案参考

该表列出了数据库迁移中跟产品功能没有直接关系，需要先在数据库层面处理好的问题。

序号	问题分类	兼容性问题说明	可能影响效果	迁移场景(源库——》目标库)	建议解决方案
1	分区与分布机制	一些数据库支持分区表而目标数据库不支持	查询效率降低	源库有分区表设置——》目标库无分区表设置	无法兼容，之前设置的分区字段不生效数据迁移后重新设计分区策略，或使用分布式中间件（如Doris、StarRocks等）适配分析场景。
2	编码/字符集问题	源数据库和目标数据库字符集不同，可能导致中文乱码	文本乱码，查询结果错误	源库—》目标库，编码/字符集不同	迁移前统一字符集编码（如UTF-8）；采用ETL工具进行字符转换并校验。
3	NULL处理差异	某些数据库不允许空字符串作为NULL，或者布尔字段处理不一致	逻辑判断出错	源库—》目标库，NULL处理差异
3	NULL处理差异	某些数据库不允许空字符串作为NULL，或者布尔字段处理不一致	逻辑判断出错	源库—》目标库，NULL处理差异	ETL中明确NULL与空值的处理规则；统一布尔字段值的处理方式（如0/1或TRUE/FALSE）。
4	数据精度问题	数值字段在不同数据库中精度定义不一致（如浮点型精度丢失）	数据计算结果不准	源库—》目标库，数据精度不一致	明确字段精度范围，在迁移脚本中定义精度转换；关键字段建议使用字符串或DECIMAL类型保存。
5	事务隔离级别与锁机制差异	数据库事务隔离机制不同（如Snapshot、Serializable），锁粒度不一致	并发异常、数据脏读	源库—》目标库，数据库事务隔离机制不同	避免在BI中使用事务；使用ETL调度平台时明确隔离级别，尽量避免行级锁冲突。
6	执行计划优化器差异	不同数据库的执行计划优化器行为不同（如JOIN顺序、并行策略）	查询变慢、索引失效	源库—》目标库的执行计划优化器行为不同	避免强依赖某一数据库的执行计划逻辑；关键SQL可手动优化，或写入提示（hint）适配。
7	跨库引用与远程表支持	部分数据库支持dblink/FDW远程表，部分不支持	查询失败	源库—》目标库，	使用数据同步中间层；或将所有依赖表迁移至同一数据库。
8	数据库对象名长度限制	不同数据库对表名、字段名长度有限制（如 Oracle 30 字符）	无法创建表，BI建模失败	源库—》目标库表名、字段名长度有限制不一样	统一命名规范，限制对象名长度 ≤ 30；可使用简写或别名方式规避。
9	数据类型不兼容	同一数据在不同数据库中数据类型不同（如 TEXT vs CLOB，BOOLEAN vs CHAR(1)）	导入/导出失败，BI报错	源库—》目标库数据类型不同	在ETL/数据同步前统一数据类型映射规则，使用中间层或数据建模工具进行类型转换。

5.2 Smartbi适配的数据库，大小写敏感配置参考

数据库名称	默认大小写敏感	配置方式	备注
星环ArgoDB	敏感	无动态配置，需手动处理	基于分布式架构，标识符严格区分大小写。
星环Inceptor	敏感	无动态配置	兼容Hive语法，表名和字段名区分大小写。
Aliyun AnalyticDB	不敏感	自动转换为小写	表名存储为小写，查询时不区分大小写。
Aliyun MaxCompute	不敏感	无配置项	表名和字段名统一转换为小写。
CirroData	敏感	需使用双引号包裹标识符	基于PostgreSQL扩展，继承其敏感特性。
ClickHouse	敏感	无配置项	严格区分大小写。
DaMeng7（达梦）	敏感	安装时设置CASE_SENSITIVE参数（0=不敏感，1=敏感）	默认敏感，建议迁移前统一标识符格式。
DB2	敏感	通过CREATE DATABASE时指定COLLATE规则	默认区分大小写，可通过排序规则调整。
Doris	不敏感	自动转换为小写	表名和字段名存储为小写。
GaussDB	敏感	类似PostgreSQL，需用双引号保留大小写	华为数据库，兼容PostgreSQL语法。
GaussDB（DWS）	敏感	同GaussDB	华为数据仓库版，行为与GaussDB一致。
Gbase-8S-V8.8	敏感	无动态配置	表名和字段名严格区分大小写。
GoldenDB	不敏感	同MySQL配置（lower_case_table_names）	基于MySQL开发，默认不敏感。
Greenplum	敏感	类似PostgreSQL	基于PostgreSQL，需用双引号保留大小写。
HANA	敏感	默认区分大小写，可通过CASE_INSENSITIVE参数设为不敏感	SAP内存数据库，建议统一大写命名。
Hive[HADOOP_HIVE]	不敏感	通过hive.conf设置hive.support.quoted.identifiers=none强制不敏感	元数据存储为小写，但查询时不敏感。
HSQL（HyperSQL）	不敏感	无配置项	默认不区分大小写。
HuaWei FusionInsight HD	敏感	依赖底层组件（如Hive或HBase）的配置	需根据具体组件调整。
IMPALA	不敏感	同Hive配置	与Hive元数据兼容，默认不敏感。
Infobright	敏感	无配置项	基于MySQL，但默认敏感。
Informix	敏感	通过DBCASE环境变量设置（lower/preserve）	默认区分大小写。
Kingbase	敏感	通过LOWER_CASE_TABLE_NAMES参数（0=敏感，1=不敏感）	人大金仓数据库，类似MySQL配置逻辑。
Kingbase Analytics	敏感	同Kingbase	分析版与标准版行为一致。
Kylin（麒麟）	不敏感	无配置项	表名和字段名统一转换为大写。
Kyligence	不敏感	同Kylin	商业版Kylin，默认不敏感。
MariaDB	同MySQL	与MySQL配置参数一致（lower_case_table_names）	继承MySQL特性。
MogDB	敏感	类似PostgreSQL	基于openGauss，需用双引号保留大小写。
MonetDB	不敏感	无配置项	表名存储为小写。
MongoDB	敏感	无配置项	集合和字段名严格区分大小写。
MySQL	系统依赖	lower_case_table_names=1（不敏感），0（敏感）	Linux敏感，Windows不敏感。
Obase	不敏感	无配置项	表名自动转换为小写。
OceanBase	不敏感	无动态配置	表名和字段名统一小写存储。
Oracle	不敏感	强制大写，双引号包裹保留大小写	未加双引号的标识符会被转换为大写。
Oracle TimesTen	敏感	无配置项	内存数据库，区分大小写。
PanWeiDB	敏感	需手动处理	基于PostgreSQL，继承其敏感特性。
PostgreSQL	敏感	使用双引号包裹标识符可保留大小写	表名存储为小写，双引号保留原始大小写。
Presto	不敏感	依赖底层数据源（如Hive）的配置	查询引擎自身不敏感，但数据源可能敏感。
RapidsDB	敏感	无配置项	高性能数据库，严格区分大小写。
SelectDB	不敏感	自动转换为小写	基于Doris，表名统一小写存储。
ShenTong（神通）	敏感	类似Oracle，需双引号保留大小写	国产数据库，默认区分大小写。
SinoDB	敏感	通过CREATE DATABASE指定COLLATION	原Informix数据库分支，默认敏感。
Smartbi Jdbc4Olap	依赖数据源	由连接的OLAP数据库决定	仅为JDBC连接器，无独立行为。
Smartbi JDBC for Excel	不敏感	无配置项	虚拟JDBC驱动，统一处理为不敏感。
Spark SQL	不敏感	同Hive配置	默认不敏感，与Hive元数据兼容。
SQL Server	取决于排序规则	安装时选择Case-Sensitive或CI排序规则	全局配置，无法动态修改。
StarRocks	不敏感	自动转换为小写	表名和字段名统一小写存储。
Sybase	敏感	通过case参数设置（case=ignore/respect）	默认敏感，需调整配置。
Teradata	不敏感	无配置项	表名存储为大写，查询时不敏感。
TiDB	不敏感	同MySQL（lower_case_table_names=1）	兼容MySQL，默认不敏感。
Tinysoft	不敏感	无配置项	金融领域数据库，表名自动小写。
Vastbase	敏感	类似PostgreSQL	基于openGauss，需用双引号保留大小写。
Vertica	不敏感	通过EnableCaseSensitiveIdentifier参数配置（默认关闭）	默认不敏感，开启后严格区分大小写。
YMatrix	敏感	无配置项	时序数据库，严格区分大小写。
Gbase 8C	敏感	无动态配置	基于PostgreSQL，需手动处理大小写。
TDSQL MySQL	不敏感	同MySQL（lower_case_table_names=1）	腾讯云分布式MySQL，默认不敏感。

关注我们

服务支持

页面树结构

业务库迁移方案