本章节主要介绍达梦数据库性能优化常见问题，为用户提供性能优化常见问题的分析和解决思路。除此之外，用户还可前往达梦技术社区参与更多问题讨论。
- 在应用中发现执行较慢的 SQL，在管理工具中执行很快
- 如何看某条 sql 语句每个操作符的执行时间？
- disql 查看执行计划
- 大量的 DML 动作(经常做增删改查)导致表的碎片很多，最终导致查询该表性能很慢，如何解决
- 执行大批量提交删除操作时，运行效率较低
- 如何对缓存中的执行计划进行过滤
- 如何开启结果集缓存
- 如何使用 DBMS_SQLTUNE 包获取 SQL 执行信息
可通过查看系统视图，及时发现活动会话中的慢 SQL，将其在计划缓存中的执行计划打印到 trc 文件中，核查是否与在管理工具中查询到的执行计划一致，偏差较大则清理缓存中执行计划。
具体方法如下：
通过 PLNDUMP 来看对应缓存中的 SQL 执行计划
- 查找出活动会话中执行时间大于 1S 的 SQL
- 找到对应慢 SQL 对应的 cache_item 值。
- 在 trace 目录中生成对应 trc 文件
- 对比管理工具的执行计划和 .trc 文件中的执行计划。
- 清理内存中执行计划缓存。
- 创建测试表
- 在管理工具中执行如下语句：
- 执行 sql 语句并获取操作符执行时间
依次点击“消息”，“590”，（或者执行 et(590) ）弹出如下的操作符执行时间对话框：
如上图所示，该 sql 语句共涉及 6 个操作符，按照执行的先后顺序分别是 SAGR2、SORT3、NSET2、CSCN2、DLCK、PRJT2。
其中，耗时最长的操作符是 SAGR2，耗时 1072 微秒，占总执行时间的 63.47%；耗时排第二位的操作符是 SORT3，耗时 536 微秒，占总执行时间的 31.73%。
根据上述的分析，我们就需要针对这 2 个操作符进行针对性的优化。
【问题说明】：
disql 中开启自动跟踪 set autotrace trace + sql ，对应的执行计划看不到统计信息是否失真的对比（估算和实际记录数），三元组中记录数只有一个数字。
【解决方法】：
该功能开启前提是 ini 参数：ENABLE_MONITOR、MONITOR_SQL_EXEC 已开启，故运行时先执行以下脚本设置参数
分析完后，记得关闭，以免影响性能
【问题解决】：
达梦的数据通过 B 树维护的。可对指定索引进行空间整理，重组数据，达到优化该表的目的。具体操作如下，以 test 为例介绍：
【问题描述】：
【问题解决】：
【问题描述】
在业务系统中 sql 的执行速度，执行计划会随着数据量和数据类型变化而变化，应用需要定时对 sql 进行巡检，保证业务性能。
【问题解决】
- 导出数据库内全部缓存的执行计划。
该命令执行后，会在 DAMENG/trace 目录下生成 trc 文件。
- 将包含 "CSCN2" 的 sql 进行梳理，过滤规则为：
① 凡是涉及到向大量客户开放使用或常用业务中频繁使用的 sql，需要根据实际情况判断是否需要优化
② 经过判断执行次数比较少的 sql 可以不做处理。 - 在导出的 trace 文件中，查找 "CSCN2"、"SSCN" 等表示全表扫描的执行计划，然后向上找到对应的 sql 文本和 cache item 编号。
【问题描述】
开启结果集缓存策略，可大大提升 sql 执行时间，达梦数据库如何开启结果集缓存？
【问题解决】
- 修改 dm.ini 参数；
当 RS_CAN_CACHE 为 1 时，还可以通过设置 INI 参数 RS_CACHE_TABLES 和 RS_CACHE_MIN_TIME 对缓存的结果集进行限制和过滤。RS_CACHE_TABLES 指定可以缓存结果集的基表清单，只有查询涉及的所有基表全部在参数指定范围内，此查询才会缓存结果集。RS_CACHE_MIN_TIME 则指定了缓存结果集的查询语句执行时间的下限，只有实际执行时间不少于指定值的查询结果集才会缓存。
参数说明：
0：禁止重用结果集；
1：强制模式，此时默认缓存所有结果集，
但可通过 RS_CACHE_TABLES 参数和语句
HINT 进行手动设置；
2：手动模式，此时默认不缓存结果集，
但可通过语句 HINT 对必要的结果集进行
缓存
静态 BUILD_FORWARD_RS 0 仅向前游标是否生成结果集。
0：不生成；
1：生成
静态 RS_CACHE_TABLES 空串 指定可以缓存结果集的基表的清单，
当 RS_CAN_CACHE=1 时，只有查
询涉及的所有基表全部在此参数指
定范围内，该查询才会缓存结果集。
当参数值为空串时，此参数失效。
手动 RS_CACHE_MIN_TIME 结果集缓存的语句执行时间下限，只
有实际执行时间不少于指定时间值的
查询，其结果集才会被缓存，仅在
RS_CAN_CACHE=1 时有效。默认值 0，
表示不限制；有效值范围（0~）
，以 MS 为单位。
动态，系统级
- 验证 dm.ini 修改是否正确；
- 重启数据库生效。
示例：
- 修改 dm.ini 参数；
- 验证 dm.ini 修改是否正确；
- 重启数据库；
- 验证结果集缓存。
- 第一次查询慢 sql 需要加载所有结果集，耗时较长。
- 第二次查询使用到结果集缓存，耗时很短。
【问题解决】
DBMS_SQLTUNE 包提供一系列对实时 SQL 监控的方法。当 SQL 监控功能开启后，DBMS_SQLTUNE 包可以实时监控 SQL 执行过程中的信息，包括：执行时间、执行代价、执行用户、统计信息等情况。SQL 监控功能开启的方法是将 DM.INI 参数 ENABLE_MONITOR 和 MONITOR_SQL_EXEC 均设置为 1。
具体操作步骤：
- 设置 disql 界面显示长度。
- 打开 MONITOR_SQL_EXEC。
- 执行需要调优的 SQL，例如如下 SQL：
- 调用 DBMS_SQLTUNE.REPORT_SQL_MONITOR，传入执行 ID 。
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/sjkxydsj/59155.html