一次达梦数据库备库 coredump 故障分析：replace 函数在「大小写不敏感 + UTF8」下的全角半角混写陷阱

本文基于某银行生产环境的一次真实故障报告整理，已对用户单位、系统名称、主机名、真实地址等敏感信息做脱敏处理，技术细节、复现步骤与版本信息完整保留。

• 数据库版本：DM8 1-3-100 Pack2（构建号 --03134284132-20240115-215128-20081）

---

一、故障概述

某业务系统（主备架构）的备库在业务高峰期发生异常重启。现场分析 core dump 文件后定位到：某条看似普通的 replace 查询，在处理一条包含全角与半角混写的地址数据时，触发了数据库底层的内存越界，直接导致进程崩溃。

这类故障具有很强的隐蔽性——SQL 本身没有任何语法问题，也不是每条数据都会触发，只有当数据同时满足「大小写混写 + 全角半角混写」时才会稳定复现。下面把完整的排查思路、复现方法和解决方案整理出来，供同行参考避坑。

---

二、环境信息

项目	内容
系统架构	主备（数据守护）
数据库版本	DM8 1-3-100 Pack2（--03134284132-20240115-215128-20081）
操作系统	Kylin Linux Advanced Server release V10 (Sword)
CPU / 内存	8 核 + 14 GB
服务器类型	虚拟机
故障发生时间	2026-06-26 14:48
故障节点	备库

---

三、故障现象

• 备库实例在 14:48 突然重启，产生 core dump 文件。
• 重启后备库恢复正常，但再次执行到特定查询时依旧会崩溃，属于可稳定复现的崩溃。
• 主库执行同样的 SQL 未出现异常（数据在主备间一致，因此问题与数据内容相关，而非主备差异）。

---

四、排查过程

4.1 堆栈分析

对 core dump 文件做堆栈分析，发现崩溃点集中在查询相关表时的字符处理逻辑上，初步判断与表中的数据内容有关，而不是 SQL 结构或并发问题。

4.2 二分法定位问题数据

原报告描述：

针对 core dump 文件进行堆栈分析发现查询相关表存储的数据异常，结合 SQL 日志通过二分法进行数据验证找到一条异常的数据。

这一步是整个排查的关键。由于表数据量较大，采用二分法逐步缩小范围，最终锁定到一条具体的记录。

问题数据（已脱敏，全角/半角混写特征完整保留）：

某某省某市某区某路２０号某广场１Ｆ-Ａ５Ａ５ａ

注意其中的字符构成：

• 汉字：某某省某市某区某路号某广场
• 全角数字：２０
• 全角字母：１Ｆ
• 全角大写：Ａ５Ａ５
• 半角小写：ａ

4.3 数据清洗验证

在主库按 ID 把该条记录清洗为规范写法（全角改半角、大小写统一）：

清洗前：某某省某市某区某路２０号某广场１Ｆ-Ａ５Ａ５ａ
清洗后：某某省某市某区某路20号某广场1F-5A5Aa

脏数据修正后，备库查询立即恢复正常，反证了问题确实由该条数据的内容特征引发。

4.4 本地环境复现

为了彻底定位，用与生产完全一致的实例参数在本地环境复现：

• 大小写不敏感：CASE_SENSITIVE=N
• 字符集 UTF-8：CHARSET=1

使用同样的参数初始化实例后，对同样的数据执行 replace 查询，问题可稳定复现，从而确认与操作系统、虚拟机环境无关，是数据库本身在该参数组合下的缺陷。

---

五、根因分析

最终定位结论：

实例处于大小写不敏感（CASE_SENSITIVE=N） 且字符集为 UTF-8 的情况下，处理包含大小写 + 全角半角混写的数据时，底层在进行大小写转换的过程中存在内存越界，从而导致 coredump。

简单说，这是一个在特定参数组合下、由特定字符形态触发的底层缺陷：

1. 大小写不敏感模式下，数据库需要对字符做大小写归一化处理；
2. UTF-8 是多字节字符集，全角字符占用多个字节；
3. 当数据中同时存在全角、半角、大写、小写时，大小写转换逻辑在计算缓冲区长度时出现偏差，越界写入导致进程崩溃。

---

六、完整复现步骤

以下为脱敏后的可复现流程，建议在测试环境验证（请勿在生产线执行触发语句）。

6.1 初始化实例（关键参数）

./dminit path=/dmdata/testdb EXTENT_SIZE=32 PAGE_SIZE=32 CASE_SENSITIVE=N CHARSET=1 LENGTH_IN_CHAR=1 PORT_NUM=5239 db_name=testdb instance_name=testdb

核心是 CASE_SENSITIVE=N + CHARSET=1（UTF-8），缺一不可。

6.2 新建大字段表并插入全角字符

create table t_clob_test (id int, addr clob);

INSERT INTO t_clob_test VALUES (6, '某某省某市某区某路２０号某广场１Ｆ-Ａ５Ａ５ａ');
commit;

select * from t_clob_test;

6.3 触发 coredump 的查询

select id, replace(replace(addr, char(13), ' '), char(10), ' ') as addr from t_clob_test;

执行该语句后，实例进程崩溃并产生 core 文件。

6.4 绕过方案：改用 REGEXP_REPLACE

同样的清洗需求，换用 REGEXP_REPLACE 可以正常执行：

SELECT id, REGEXP_REPLACE(addr, CHR(13)||CHR(10), ' ') AS addr FROM t_clob_test;

---

七、触发条件矩阵

为摸清精确的触发边界，构造了多组不同字符组合进行测试：

序号	构造数据	字符构成	执行结果
1	AＡ５Ａ５	半角大写 + 全角	正常
2	aＡ５Ａ５	半角小写 + 全角	正常
3	Ａ５Ａ５	纯全角	正常
4	Ａ５ａ５	全角大写 + 全角小写	正常
5	全角 + 半角 + 大写 + 小写全部包含	混合	coredump

对应的测试语句：

truncate table t_clob_test;
INSERT INTO t_clob_test VALUES (1, 'AＡ５Ａ５');
commit;
select id, replace(replace(addr, char(13), ' '), char(10), ' ') as addr from t_clob_test;
-- 正常返回

结论：只有「全角、半角、大写、小写」四种形态同时出现时才会触发，这也是该故障难以被发现的原因——单一类型的字符组合都不会出问题。

---

八、解决方案

8.1 临时绕过（立即可用）

调整静态参数 CASE_CONVERSION_ENHANCED = 0：

CASE_CONVERSION_ENHANCED = 0

⚠️ 该参数为静态参数，修改后需要重启实例生效。

参数说明：

参数名称	默认值	属性	说明
CASE_CONVERSION_ENHANCED	1	静态	是否支持多字节字符的大小写转换。0：不支持，只支持原有的单字节 ASCII 字符的大小写转换；1：支持，增加支持多字节字符的大小写转换

或者在 SQL 层面改用 REGEXP_REPLACE 替代 replace，可绕过该缺陷。

8.2 根治方案

• 从源头规范数据输入：协调开发商在数据录入环节做规范化处理，避免全角/半角、大小写混写的数据进入数据库。
• 存量数据清洗：对历史脏数据做批量清洗，统一字符形态。
• 参考本次的清洗方式：

-- 清洗前：某某省某市某区某路２０号某广场１Ｆ-Ａ５Ａ５ａ
-- 清洗后：某某省某市某区某路20号某广场1F-5A5Aa
UPDATE t_clob_test SET addr = '某某省某市某区某路20号某广场1F-5A5Aa' WHERE id = 6;

8.3 其他验证结论

• 初始化为大小写敏感（CASE_SENSITIVE=Y）的实例，执行同样的转换查询一切正常，可作为规避方向之一（但需评估业务兼容性）。
• 在大小写敏感的基础上调整 CASE_CONVERSION_ENHANCED = 0，查询同样正常。

---

九、经验总结

1. 参数组合有风险面：CASE_SENSITIVE=N + CHARSET=1（UTF-8）是一个需要重点关注的组合，在字符处理上存在已知缺陷。新建实例时如果业务允许，优先考虑大小写敏感模式。

2. coredump 不一定来自高并发或大事务：本次故障由一条普通 SELECT 和一条脏数据引发。遇到实例崩溃时，除了看并发、内存、磁盘，也要怀疑数据内容本身。

3. 二分法是定位脏数据的利器：面对"某张表查询就崩"的情况，用二分法逐步缩小数据范围，比全表扫描或逐条排查高效得多。

4. 优先在测试环境复现：用与生产一致的参数初始化实例，在本地复现问题，既能确认根因，也避免在生产上反复试错。

5. 多一条 SQL 写法就多一条退路：replace 出问题，REGEXP_REPLACE 能绕过。日常开发中遇到数据库缺陷，换个等价写法往往是最快的止血手段。

6. 数据规范化是长期工程：全角/半角混写在中文业务场景中极其常见（地址、姓名、备注字段），建议在应用层就做好输入校验与归一化。

---

十、影响范围提示

该问题影响所有使用 CASE_SENSITIVE=N + UTF-8 字符集的 DM8 实例，且业务表中存在全角/半角混写的字符大字段（CLOB/VARCHAR）时均可能触发。在本次故障中，相关业务系统涉及多个上下游系统，建议同版本、同参数组合的环境一并排查。

排查建议：对存在字符大字段且数据来源于外部录入的表，检查是否存在全角半角混写记录；同时评估 CASE_CONVERSION_ENHANCED 参数的调整可行性。

---

本文档由真实故障报告脱敏整理，保留原报告版本 v1.0.20260701 与数据库版本信息，仅用于技术交流。