DM SQL 日志文件：运维排障与性能优化的核心抓手- 惊觉

一、DM SQL 日志文件概述

1.1 什么是 DM SQL 日志文件

DM SQL 日志文件是达梦数据库 (Dameng Database) 用于记录 SQL 语句执行情况的日志文件，又称为 svr 日志。它由 DM 数据库服务器在运行过程中生成，记录了客户端发送到数据库的所有或部分 SQL 语句，以及执行时长、影响行数、错误码等关键运行时信息。与其他数据库 (如 Oracle 的 trace 文件、MySQL 的 general log) 类似，DM SQL 日志文件是 DBA 进行故障排查、安全审计与性能优化的核心抓手。

1.2 DM SQL 日志文件的核心价值

DM SQL 日志文件在实际生产环境中具有不可替代的作用，主要体现在以下几个方面：

故障排查：当业务出现异常报错或慢响应时，可通过日志快速定位问题 SQL。
性能优化：通过分析 SQL 执行耗时，识别慢 SQL 并进行针对性优化。
安全审计：记录用户操作行为，满足合规审计要求。
行为回溯：在数据被误操作时，可通过日志还原操作过程。
容量评估：通过 SQL 频次与影响行数评估系统负载。

1.3 DM SQL 日志文件与其他日志的关系

DM 数据库提供了多种日志文件，它们各司其职，共同构成完整的日志体系：

其中，dm.ini 运行日志侧重数据库自身运行状态，重做日志和归档日志用于事务持久化与备份恢复，而 DM SQL 日志文件则专注于 SQL 级别的执行记录，是本文讨论的核心对象。

二、DM SQL 日志文件的配置与开关

2.1 通过 dm.ini 参数开启 SQL 日志

DM SQL 日志文件的总开关由 dm.ini 参数 SVR_LOG 控制，该参数为静态参数，修改后需要重启数据库实例才能生效。开启步骤如下：

编辑 dm.ini 文件，找到 SVR_LOG 参数。
将其值由 0 修改为 1，表示开启 SQL 日志功能。
保存文件后重启 DM 实例使配置生效。

# dm.ini 关键配置
SVR_LOG = 1

2.2 sqllog.ini 配置详解

当 SVR_LOG = 1 后，DM 数据库会读取 sqllog.ini 文件来决定 SQL 日志的具体记录策略。sqllog.ini 通常与 dm.ini 位于同一目录下，典型配置如下：

# sqllog.ini
BUF_TOTAL_SIZE   = 10240
BUF_SIZE         = 1024
BUF_KEEP_CNT     = 6
[SLOG_ALL]
    FILE_PATH    = ../log
    PART_STOR    = 0
    SWITCH_MODE  = 2
    SWITCH_LIMIT = 512
    ASYNC_FLUSH  = 1
    FILE_NUM     = 10
    ITEMS        = 0
    SQL_TRACE_MASK = 2:3
    MIN_EXEC_TIME = 0
    USER_MODE    = 0
    USERS        =

2.3 关键参数说明

下表对 sqllog.ini 中的高频参数进行重点说明：

| 参数 | 含义 | 推荐值 |

| --- | --- | --- |

| BUF_TOTAL_SIZE | 日志 buffer 总大小，影响写入性能 | 10240 或更大 |

| SWITCH_MODE | 日志切换模式，推荐按时间切换 | 2 |

| SWITCH_LIMIT | 切换上限，模式 2 时单位为分钟 | 60 |

| FILE_NUM | 保留的日志文件数量，超出后自动删除 | 10 至 30 |

| ASYNC_FLUSH | 异步刷新，建议 1 以降低业务影响 | 1 |

| MIN_EXEC_TIME | 最小执行时间阈值，用于只记录慢 SQL | 视场景而定 |

| SQL_TRACE_MASK | SQL 类型掩码，控制记录哪些类型 SQL | 2:3 |

| USERS | 指定用户过滤，多个用逗号分隔 | 按需配置 |

各参数协同工作的整体流程如下：

三、DM SQL 日志文件的管理与运维

3.1 日志文件位置与命名规则

DM SQL 日志文件默认存放在 DM 安装目录下的 log 子目录中，文件命名遵循 dmsql_实例名_日期_时间.log 的规则。例如：

dmsql_DMSERVER_20240101_120000.log

当 SWITCH_MODE = 2 时，系统会按 SWITCH_LIMIT 指定的时间间隔自动切换日志文件，旧文件按 FILE_NUM 数量保留，超出部分会被自动清理。

3.2 日志切换与清理策略

合理的日志切换与清理策略既能保证日志可追溯，又能避免磁盘被撑满。整体策略流程如下：

生产环境建议：

SWITCH_MODE 设置为 2，按小时切换，便于按时间段排查问题。
FILE_NUM 根据磁盘容量设置，一般保留 7 天左右的日志。
对历史日志定期归档到对象存储或日志分析平台。

3.3 动态开启与关闭 SQL 日志

在生产环境中，有时需要临时开启 SQL 日志抓取问题，而不希望重启数据库。DM 提供了系统过程来动态控制 SQL 日志：

-- 动态修改 SVR_LOG 参数
CALL SP_SET_PARA_VALUE(1, 'SVR_LOG', 1);
-- 重新加载 sqllog.ini 配置
CALL SP_REFRESH_SVR_LOG_CONFIG();
-- 关闭 SQL 日志
CALL SP_SET_PARA_VALUE(1, 'SVR_LOG', 0);

动态开关的执行流程：

注意：动态修改仅在内存生效，若需持久化，仍需同步修改 dm.ini 和 sqllog.ini 文件，否则实例重启后配置会丢失。

四、DM SQL 日志文件的分析与应用

4.1 日志格式解析

DM SQL 日志文件采用文本格式存储，每条记录包含丰富的执行上下文。典型日志格式如下：

2024-01-01 12:00:00.123 [INFO] session[1234] user[SYSDBA] ip[192.168.1.100]
SQL: SELECT * FROM T1 WHERE ID = 1;
EXECTIME: 3(ms) ROWS: 1 ERRORCODE: 0

关键字段含义：

时间戳：精确到毫秒，用于分析执行顺序。
session：会话 ID，用于关联同一会话的多条 SQL。
user：执行用户，用于审计。
ip：客户端 IP，用于定位来源。
SQL：实际执行的 SQL 语句。
EXECTIME：执行耗时，单位毫秒。
ROWS：影响或返回的行数。
ERRORCODE：错误码，0 表示成功。

4.2 慢 SQL 定位实战

慢 SQL 定位是 DM SQL 日志文件最常见的应用场景。利用 Linux 文本处理工具，可以快速筛选出耗时较高的 SQL：

# 提取所有 EXECTIME 大于 100ms 的日志行
grep "EXECTIME" dmsql_DMSERVER_*.log | awk -F'EXECTIME: ' '{print $2}' | awk -F'(ms)' '$1 > 100 {print}' | sort -nr | head -20

慢 SQL 定位分析流程：

4.3 性能优化案例

某业务系统在高峰期出现接口超时，通过 DM SQL 日志文件定位到如下慢 SQL：

SQL: SELECT COUNT(*) FROM ORDER_DETAIL WHERE CREATE_TIME >= '2024-01-01';
EXECTIME: 3580(ms) ROWS: 1 ERRORCODE: 0

优化步骤：

通过 EXPLAIN 查看执行计划，发现全表扫描。
检查表结构，发现 CREATE_TIME 字段无索引。
创建 B 树索引：CREATE INDEX IDX_ORDER_DETAIL_TIME ON ORDER_DETAIL(CREATE_TIME);
重新执行，耗时降至 12ms。
更新统计信息：STAT TABLE ORDER_DETAIL;

五、常见问题与最佳实践

5.1 性能影响评估

开启 DM SQL 日志文件会对数据库产生一定开销，主要体现在：

磁盘 I/O：日志写入占用磁盘吞吐。
CPU 与内存：日志格式化与 buffer 管理。
锁竞争：高并发下日志写入可能成为瓶颈。

建议生产环境采用 ASYNC_FLUSH = 1 异步刷新，并合理设置 MIN_EXEC_TIME 只记录慢 SQL，以将性能影响降至最低。性能开销与配置关系如下图：

5.2 常见问题排查

SQL 日志未生成：检查 dm.ini 中 SVR_LOG 是否为 1，sqllog.ini 是否存在且路径正确。
日志文件过大：调整 SWITCH_MODE 和 SWITCH_LIMIT，控制单文件大小。
磁盘被撑满：减小 FILE_NUM，或开启 MIN_EXEC_TIME 过滤。
动态修改未生效：确认是否调用了 SP_REFRESH_SVR_LOG_CONFIG 重新加载配置。
日志缺少部分 SQL：检查 SQL_TRACE_MASK 掩码和 USERS 过滤配置。
日志写入延迟：确认 ASYNC_FLUSH 是否开启，buffer 大小是否充足。

5.3 最佳实践建议

分级开启：生产环境可仅记录慢 SQL (MIN_EXEC_TIME 设为 100)，测试环境全量记录。
异步刷新：始终启用 ASYNC_FLUSH = 1，降低业务影响。
定时归档：通过 cron 定期压缩归档历史日志，保留 7 至 30 天。
集中分析：将日志采集到 ELK 或类似平台，实现可视化分析。
安全管控：SQL 日志可能包含敏感数据，需控制访问权限并加密存储。
版本兼容：不同 DM 版本参数略有差异，升级前需重新核对配置。
监控告警：对日志目录磁盘使用率设置告警，避免日志撑满磁盘导致数据库异常。

通过以上配置与管理策略，DM SQL 日志文件将成为数据库运维排障与性能优化的得力助手，帮助 DBA 在复杂生产环境中快速定位问题、持续优化系统性能。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/qq_41840843/article/details/163764458

DM SQL 日志文件：运维排障与性能优化的核心抓手