记一次对DM数据库的优化过程

某年某月某日的一个下午，接收到监控服务器的一条告警短信： 尊敬的运维工程师 XX，你好： “192.168.136.200”数据库服务器 CPU 异常，CPU 使用率 98.7%，请尽快处理。 看到这个消息浑身一紧，赶忙掐灭手中的烟，跑回办公室。

以上段子纯属捏造，若有雷同，我反正是不改。

言归正传，本文是记录一次对达梦数据库的优化过程。

处理问题的第一步，是须要了解当前服务器的情况，咱们经过如下两种手段确认服务器瓶颈。

系统情况

• 经过服务器性能监控大盘观察当前系统性能 经过上图咱们看出 CPU 基本耗尽，IO 飙升。

• 经过 sar 命令观察服务器实时状态
  sar 10 3 确认 CPU 被耗满，没有空闲。

经过个人细致观察，发现服务器 CPU 被耗满。接下来须要查看数据库服务器的配置参数是否合理，是否有慢查询脚本。

参数优化

• 查看 dm 配置文件
  cd /dm7/dmdbms/devdb cat dm.ini | grep -E "MEMORY_POOL|MEMORY_TARGET|BUFFER" 发现数据库参数配置为安装时候的默认配置，参数不合理，须要优化参数配置。

• 备份原配置文件
  cp dm.ini dm.ini.bak

• 修改配置 修改以下几个关键参数，根据以前文章数据库优化-实例优化中的表格进行优化（ps：当前数据库内存 2G）

参数	优化建议	优化后的值，单位 M
MEMORY_POOL	建议为内存的 90%	1800
MEMORY_TARGET	建议为内存的 90%	1800
BUFFER	建议为内存的 60%	1200
MAX_BUFFER	建议为内存的 70%	1400
MAX_SESSIONS		1000

• 重启数据库服务
  service DmServerdm restart

参数优化后咱们尝试找出当前数据库存在的慢查询 SQL，看看是否能够优化。

慢 SQL 优化

达梦数据库不像 MySQL 能够直接将慢查询存放在指定位置，达梦须要经过 AWR 报告中找出慢查询。(AWR 报告你们自行百度)
启用 DM 快照须要调用 DBMS_WORKLOAD_REPOSITORY 包。

• 使用 DBA 帐户登陆数据库
  disql SYSDBA/password

• 建立 DBMS_WORKLOAD_REPOSITORY 系统包，开启 AWR 快照功能。
  SP_INIT_AWR_SYS(1);

• 启用状态检测。
  SELECT SF_CHECK_AWR_SYS;

• 设置 AWR 快照间隔时间（30 分钟）
  CALL DBMS_WORKLOAD_REPOSITORY.AWR_SET_INTERVAL(30);

• 手动建立快照：
  DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();
  这里咱们能够间隔几分钟多执行几遍建立几个不一样的快照。

• 查看建立的快照信息，包括快照 id：
  SELECT * FROM SYS.WRM$_SNAPSHOT;

• 查看 AWR 报告内容
  SELECT * FROM TABLE (DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(1,2));
  查看 snapshot 的 id 在 1~2 范围内的 AWR 分析报告的带 html 格式的内容。 这个内容格式基本没办法看，咱们须要将其转化成 html 页面查看。

• 生成 HTML 文件(须要先对 awr 文件夹受权)

  chmod 777 /awr
  SYS.AWR_REPORT_HTML(1,2,'/awr','awr1.html');

• 经过 AWR 报告找出慢 SQL
  SQL Ordered by Elapsed Time 的内容就是慢查询语句。
  在拿到慢查询语句后咱们须要联系开发人员修改查询语句，此次优化过程当中我经过给相关字段添加索引，改写一部分 SQL 完成。

  可是数据表自己设计不合理这个没有优化，因为设计不合理致使查询没办法走索引；而有些查询则须要从业务角度进行优化，好比是否有必要对大表进行全表查询而后再排序？等等等等。。。（至于数据库 SQL 优化的具体策略咱们下期再聊）

在完成优化后重启应用，再次经过sar 10 3观察 CPU 性能，较优化前仍是有很多的提高的，又能够抽空去抽根烟了。

欢迎关注个人我的公众号：JAVA日知录