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

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

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

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

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

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

系统状况

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

参数优化

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

参数优化后我们尝试找出当前数据库存在的慢查询 SQL,看看是否可以优化。

慢 SQL 优化

达梦数据库不像 MySQL 可以直接将慢查询存放在指定位置,达梦需要通过 AWR 报告中找出慢查询。(AWR 报告大家自行百度)
启用 DM 快照需要调用 DBMS_WORKLOAD_REPOSITORY 包。

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

  • 数据库

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

    288 引用 • 599 回帖 • 1 关注
  • Prometheus
    11 引用 • 5 回帖

赞助商 我要投放

欢迎来到这里!

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

注册 关于
请输入回帖内容 ...
  • tiangao
    捐赠者

    封面图好评