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

本贴最后更新于 1829 天前,其中的信息可能已经物是人非

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

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

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

处理问题的第一步,是需要了解当前服务器的状况,我们通过以下两种手段确认服务器瓶颈。

系统状况

  • 通过服务器性能监控大盘观察当前系统性能
    image.png

    通过上图我们看出 CPU 基本耗尽,IO 飙升。

  • 通过 sar 命令观察服务器实时状态
    sar 10 3
    image.png

    确认 CPU 被耗满,没有空闲。

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

参数优化

  • 查看 dm 配置文件
    cd /dm7/dmdbms/devdb cat dm.ini | grep -E "MEMORY_POOL|MEMORY_TARGET|BUFFER"
    image.png

    发现数据库参数配置为安装时候的默认配置,参数不合理,需要优化参数配置。

  • 备份原配置文件
    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;
    image.png

  • 查看 AWR 报告内容
    SELECT * FROM TABLE (DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(1,2));
    查看 snapshot 的 id 在 1~2 范围内的 AWR 分析报告的带 html 格式的内容。
    image.png

    这个内容格式基本没办法看,我们需要将其转化成 html 页面查看。

  • 生成 HTML 文件(需要先对 awr 文件夹授权)

    chmod 777 /awr
    SYS.AWR_REPORT_HTML(1,2,'/awr','awr1.html');
    
  • 通过 AWR 报告找出慢 SQL
    image.png

    SQL Ordered by Elapsed Time 的内容就是慢查询语句。
    在拿到慢查询语句后我们需要联系开发人员修改查询语句,这次优化过程中我通过给相关字段添加索引,改写一部分 SQL 完成。

    但是数据表本身设计不合理这个没有优化,由于设计不合理导致查询没办法走索引;而有些查询则需要从业务角度进行优化,比如是否有必要对大表进行全表查询然后再排序?等等等等。。。(至于数据库 SQL 优化的具体策略我们下期再聊)

在完成优化后重启应用,再次通过 sar 10 3 观察 CPU 性能,较优化前还是有不少的提升的,又可以抽空去抽根烟了。
image.png

  • 数据库

    据说 99% 的性能瓶颈都在数据库。

    340 引用 • 708 回帖
  • Prometheus
    20 引用 • 8 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...