当前位置：首页 > news >正文

达梦数据库CASE_SENSITIVE参数深度解析与DTS迁移实战指南

news 2026/3/26 18:56:06

1. 达梦数据库CASE_SENSITIVE参数深度解析

第一次接触达梦数据库时，我就被这个CASE_SENSITIVE参数给难住了。当时在客户现场做迁移，应用系统突然报出一堆"对象不存在"的错误，折腾了半天才发现是这个参数在作怪。今天我就把这个参数的来龙去脉给大家讲透。

CASE_SENSITIVE是达梦数据库初始化时通过dminit命令设置的参数，它决定了数据库对大小写的处理方式。这个参数一旦设置就不能修改，所以建库时必须慎重考虑。参数有两个取值：

1：大小写敏感（区分大小写）
0：大小写不敏感（不区分大小写）

我在测试环境创建了两个库来做对比实验：

# 大小写敏感库 /dm8/dmdbms/bin/dminit PATH=/dm8/data DB_NAME=PROD1 INSTANCE_NAME=TEST1 PORT_NUM=5238 CASE_SENSITIVE=1 # 大小写不敏感库 /dm8/dmdbms/bin/dminit PATH=/dm8/data DB_NAME=PROD2 INSTANCE_NAME=TEST2 PORT_NUM=5239 CASE_SENSITIVE=0

1.1 字符串比较的差异

登录敏感库(PROD1)执行：

select 1 from dual where 'a'='A'; -- 无结果返回，说明不相等

而在不敏感库(PROD2)执行同样的语句：

select 1 from dual where 'a'='A'; -- 返回1，说明认为相等

这个差异直接影响SQL查询结果。比如用户登录时输入的用户名是"Admin"，但数据库中存的是"admin"，在敏感库就会登录失败，而在不敏感库可以成功。

1.2 对象名处理的玄机

更复杂的是表名、字段名的处理规则。在敏感库中做了个实验：

-- 创建测试表 create table tb_test (c1 int, c2 varchar2(10)); create table "tb_TEST" ("c1" int, c2 varchar2(10)); -- 查询表定义 SP_TABLEDEF('SYSDBA','TB_TEST'); -- 能查到 SP_TABLEDEF('SYSDBA','tb_test'); -- 查不到

这里有个关键发现：不加双引号的对象名会被统一转为大写存储，加了双引号则保留原样。这意味着：

tb_test和TB_TEST在敏感库中是同一个表
"tb_TEST"则是另一个独立的表

而在不敏感库中，无论是否加引号，所有对象名都会被转为小写存储。实际测试发现：

create table tb_test (c1 int); create table TB_TEST (c1 int); -- 会报"表已存在"错误

2. DTS迁移中的大小写陷阱

去年帮某银行做Oracle到达梦的迁移，就踩过大小写的坑。他们的应用里有大量混合大小写的表名，比如"Acct_Info"、"ACCT_DETAIL"等。当时没注意这个参数，结果迁移后应用直接瘫痪。

2.1 迁移选项的关键选择

达梦数据迁移工具(DTS)有个"保持对象名大小写"的选项，这个勾不勾大有讲究：

情况一：源库是大小写敏感的(如Oracle)

建议：不勾选
原因：保持应用SQL书写习惯，避免到处加引号

情况二：源库是大小写不敏感的(如MySQL)

建议：可勾选可不勾选
原因：不影响最终使用效果

实测发现，如果源库是Oracle(CASE_SENSITIVE=1)，在DTS中勾选了"保持大小写"，迁移后查询必须这样写：

select * from "hr"."employees"; -- 能查 select * from hr.employees; -- 报错

2.2 最佳实践方案

根据多次迁移经验，我总结出这个决策流程图：

先确认源库的大小写敏感特性
目标库的CASE_SENSITIVE参数建议与源库一致
源库若敏感：
- 对象名全大写：DTS不勾选
- 对象名有大小写混合：建议应用改造，统一为大写
源库若不敏感：
- DTS勾选与否均可
- 建议勾选以保留原始对象名信息

有个特例要注意：如果应用代码中已经大量使用带引号的SQL，比如SELECT "userId" FROM "App_User"，那么无论参数如何设置，都必须保持这种写法。

3. 常见问题解决方案

3.1 对象找不到的典型场景

最近处理过一个案例：迁移后应用报"表TB_USER不存在"。排查过程如下：

检查数据库确实有该表
发现应用连接字符串用的是小写：jdbc:dm://localhost/TEST1?schema=hr
数据库是大小写敏感的，实际表名存储为"TB_USER"
应用SQL写的是select * from tb_user

解决方案有三种：

修改应用SQL为select * from "TB_USER"
重建数据库为大小写不敏感
使用DTS重新迁移，不勾选"保持对象名大小写"

3.2 性能优化的隐藏细节

大小写敏感还会影响索引使用。在敏感库中：

create index idx_name on employee(last_name); select * from employee where last_name='SMITH'; -- 能用索引 select * from employee where last_name='Smith'; -- 可能用不了索引

这是因为字符串比较时，'Smith'和'SMITH'被视为不同值。建议在敏感库中统一存储大写数据，查询时用UPPER函数：

select * from employee where UPPER(last_name)='SMITH';

4. 实战配置指南

4.1 数据库初始化建议

对于新项目，我的经验建议是：

金融等传统行业：建议CASE_SENSITIVE=0，兼容性更好
互联网新系统：建议CASE_SENSITIVE=1，更符合开发习惯

初始化命令示例：

# 金融系统推荐配置 /dm8/dmdbms/bin/dminit PATH=/dm8/data CASE_SENSITIVE=0 UNICODE_FLAG=1 # 互联网系统配置 /dm8/dmdbms/bin/dminit PATH=/dm8/data CASE_SENSITIVE=1 LENGTH_IN_CHAR=1