一、核心配置管理

达梦数据库性能高度依赖 dm.ini 配置文件，参数调整需基于硬件资源和业务负载，可通过 SQL 优化脚本配置参数。

1.1 BUFFER — 数据缓冲区

决定数据页在内存中的缓存大小，是最重要的性能参数。服务器建议设置为物理内存的 60%~80%，例如 4G 内存环境，设置 BUFFER 为 2.4G 可大幅提升命中率。

1.2 BUFFER_POOLS — 缓冲区分区数

控制数据缓冲区分区数量，减少并发访问冲突。原则上与 CPU 核数保持一致，例如 2 核 CPU 设置 BUFFER_POOLS 为 2。

1.3 CACHE_POOL_SIZE — SQL 缓存池

缓存执行计划与字典信息，提升“软解析”命中率。

• 执行计划需进行语法/语义校验，并根据统计信息通过代价算法生成最优执行计划；
• 字典信息存储数据库元数据，包括表结构、统计信息等。

1.4 SORT_BUF_SIZE — 排序缓冲区

影响 ORDER BY、GROUP BY 等排序操作性能。在大 SQL 排序频繁场景下，可适当提高 SORT_BUF_SIZE 使排序耗时减少，需根据并发场景综合评估（不是越大越好）。

1.5 WORKER_THREADS 与 TASK_THREADS

• WORKER_THREADS（工作线程）：处理客户端业务会话请求，与 CPU 核数匹配；
• TASK_THREADS（任务线程）：处理数据库内部后台任务，默认配置。

1.6 MAX_SESSIONS

限制最大连接数，通常设置为 峰值连接数 × 1.5。

1.7 归档与日志参数

生产环境必须开启归档（ARCH_INI=1），同时设置 LOG_BUFFER_SIZE（日志缓存区大小）和 CHECKPOINT_INTERVAL（检查点间隔），避免频繁刷盘影响性能。

1.8 配置文件说明

文件	用途
dm.ini	实例的核心配置文件，包括内存、缓冲区、线程、归档、日志等参数
dmmal.ini	MAL 系统通信配置文件，定义集群各节点 IP、端口等参数
dmarch.ini	归档配置文件，指定归档类型、归档路径与文件大小等参数
dmwatcher.ini	守护进程配置文件，定义故障检测超时与自动切换策略等参数

1.9 守护主备集群一次 INSERT 同步流程

主库侧

1. 客户端向主库发送 INSERT SQL，服务线程解析后确定目标数据页；
2. 检查目标数据页是否存在于 BUFFER 中，若不存在则从磁盘加载到 BUFFER；
3. 在 BUFFER 的数据页中插入新数据，该页变为脏页；
4. 根据 WAL 原则，同时生成对应的 Redo 日志，写入 LOG_BUFFER；
5. 客户端发起 COMMIT，触发日志刷盘：将 LOG_BUFFER 中的 Redo 日志强制写入磁盘日志文件，日志落盘后即事务提交成功；
6. 后续检查点进程根据 Redo 日志异步写入磁盘数据文件，完成一致性。

主库侧 → 备库侧

根据 dmarch.ini 定义的远程归档规则（实时归档/同步归档/异步归档），将 Redo 日志以日志包为单位，通过 dmmal.ini 配置的 MAL 通信系统发送给备库。

备库侧

1. 备库收到日志包后，后台线程对 Redo 日志进行重演，即在备库内存重复执行主库相同的 SQL 操作，修改对应数据页（备库该数据页变为脏页）；
2. 备库的 Redo 日志同样先写入备库自身的 LOG_BUFFER，适时刷入备库日志文件；
3. 根据检查点进程完成一致性，最终实现主备同步。

---

二、监控与告警

达梦数据库提供两种监控方案：DM 性能监视工具与 DEM。

2.1 BUFFER 池命中率

衡量查询是否优先从内存读取数据页。命中率低意味着频繁访问磁盘，响应慢、负载高。生产环境通常要求 ≥ 95%。

实战验证：物理内存 8G，设置 BUFFER 为 5G（约内存 62.5%）。创建三张测试表并插入约 600 万行数据，总耗时 38 秒。批量插入性能良好，验证了 BUFFER 扩容后写入刷盘能跟上，未出现因缓冲区不足导致刷盘等待。

在订单表与用户表创建索引。

600 万行数据的数据页在内存，数据检索直接命中内存缓冲区（逻辑读），物理 I/O 极少（物理读），命中率为 99.68%（接近 100%）。结果表明当前 BUFFER 容量与业务数据规模匹配，参数配合合理有效。

2.2 锁等待

会话事务等待其他会话释放锁的时间。锁等待时间长或数量多，通常存在死锁、慢 SQL 等。

示例：会话 1 开启事务并执行 UPDATE，此时会话 1 持有锁；会话 2 开启事务也执行 UPDATE 同一行数据，会话 2 被阻塞；开启会话 3 查询锁等待，显示事务 30081 被 30078 阻塞，已等待约 67.5 秒。后续会话 1 执行 COMMIT 或 ROLLBACK，会话 2 的 UPDATE 自动继续执行。

2.3 表空间使用率

监控表空间，防止磁盘写满导致数据库宕机。当表空间使用率 ≥ 85% 时预警，≥ 95% 时告警。

2.4 活跃会话数

监控当前正在执行 SQL 语句的活跃会话数量。若活跃会话数突增，通常伴随着慢 SQL、高并发或锁等待。

示例：开启多个会话，会话 1 和会话 2 开启事务不提交，会话 3 登录 SQL 什么也不干，在会话 4 查询当前会话，包括 3 个非活跃状态会话与自身活跃会话。

2.5 慢 SQL

慢 SQL 指执行耗时超过预设阈值的 SQL 语句，通常由于缺少有效索引、多表复杂关联、处理数据量过大导致。慢 SQL 监控是数据库性能调优的核心环节，可通过动态视图 V$LONG_EXEC_SQLS 捕获超时执行的 SQL，为 SQL 分析与优化提供可靠依据。

对慢 SQL 进行分析：

SQL 类型	执行耗时	判定结论
【② 锁等待】UPDATE	128978 ms	锁等待阻塞导致，无需主动修改
【① BUFFER 池命中率】INSERT	32371 ms	批量写入，无需主动修改
多表关联查询	5709 ms	在 WHERE 和 ON 关键词后存在索引，检索较慢
聚合查询	1540 ms	仅 GROUP BY 后存在索引，检索较慢

• 优化多表关联查询：创建覆盖索引，查询时间由原来的 5.709 秒 变为 51.297 毫秒，提升约 112 倍。
  CREATE INDEX idx_orders_user_time_amount ON test_orders_big(user_id, order_time, order_amount);

• 优化聚合查询：创建覆盖索引，按 order_status 分组统计时间由原来的 1.540 秒 变为 2.347 毫秒，提升约 665 倍。
  CREATE INDEX idx_orders_status_user_amount ON test_orders_big(order_status, user_id, order_amount);

2.6 QPS / TPS

QPS（每秒查询数）和 TPS（每秒事务数）是衡量数据库吞吐量的核心指标，用于评估系统性能。

• QPS：数据库每秒能处理的查询数量；
• TPS：数据库每秒能完成的事务数量。

---

三、日志分析

数据库运行日志记录了服务启动、检查点、归档、刷盘等关键事件，是判断数据库是否健康运行的重要依据。

文件名	用途
dm_DMTEST_202608.log	实例运行日志，记录实例启动/关闭、检查点、归档、刷盘
DmServiceDMTEST_err.log	实例服务错误日志，记录实例服务运行期间的异常信息
dm_dmap_202608.log	DMAP 辅助进程日志，记录备份还原操作
error.log	用户 grep 手动筛选的错误汇总日志
dminit_*.log	数据库初始化日志
install.log / install_ant.log	数据库安装日志
DmServiceDMTEST.log	实例服务启停日志，记录实例服务启动/停止控制台输出
tool.log	管理工具（如 Manager）操作日志

注意：以下警告为认证库缺失，与数据库运行无关，不影响数据库的正常启动、连接及数据读写。

【file dm.key not found, use default license!】 表示未找到授权文件，使用默认授权，正常；
【License will expire on 2027-04-14】 表示授权到期时间，正常。