一、实验前言
本人已顺利通过达梦数据库DCP认证考试，本次通过手动完成DM8数据库AWR快照采集、压力构造、AWR报告生成、性能指标分析全套实验，熟练掌握达梦数据库自动负载仓库AWR的使用方法，能够通过AWR报告定位数据库运行负载、慢SQL、等待事件、IO瓶颈等常见性能问题。
二、实验目的
1、了解达梦数据库AWR的作用、工作原理，
2、掌握DM8 AWR功能开启、手动创建快照、查看快照的完整操作。
3、学会通过压测工具构造数据库业务压力，模拟生产繁忙场景。
4、熟练生成达梦数据库文本格式AWR性能分析报告。
5、读懂AWR核心性能指标，完成数据库性能瓶颈分析与问题总结。
三、实验环境
操作系统：麒麟V10
数据库版本：DM8.1.4.170
操作用户：SYSDBA
前置条件：数据库实例正常启动、状态OPEN
工具：DM管理工具、disql命令行、开源压测工具sysbench
四、AWR基础原理
AWR全称自动工作负载仓库，是达梦数据库内置的性能数据采集与分析工具。数据库会定期采集系统运行的性能数据，包括SQL执行统计、会话信息、等待事件、磁盘IO、内存使用、锁等待、事务信息等，以快照的形式存储在系统字典表中。
分析性能，就是选取开始快照、结束快照两个时间点，生成时间段内的完整性能报告，从而分析数据库忙时的性能状态，定位卡顿、慢SQL、资源瓶颈问题。
重点：达梦AWR默认不会自动开启，需要手动参数开启。
五、实验操作步骤
步骤1：开启达梦AWR功能
--1、检查AWR是否已经初始化，返回1=已初始化；0=未初始化
SQL> SELECT SF_CHECK_AWR_SYS;

LINEID SF_CHECK_AWR_SYS

1 0

--2、初始化AWR组件（生成DBMS_WORKLOAD_REPOSITORY包，自动创建SYSAUX表空间）
SP_INIT_AWR_SYS(1);

--3、检查AWR是否已经初始化
SQL> SELECT SF_CHECK_AWR_SYS;

LINEID SF_CHECK_AWR_SYS

1 1

--4、配置快照：保留时间(分钟)，采集间隔(分钟)；示例：保留7天(10080分钟)，每15分钟快照
CALL DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(10080,15);
步骤2：手动创建初始快照（压力前快照）

--5、手动创建第一个快照（压测前）
CALL DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

--查看快照列表，拿到BEGIN_SNAP_ID
SELECT * FROM SYS.WRM$_SNAPSHOT;
步骤3：构造数据库业务压力（模拟生产负载）
-----------sysbench--------------------
SQL statistics:
queries performed:
read: 1612540
write: 460308
other: 244432
total: 2317280
transactions: 115864 (385.74 per sec.)
queries: 2317280 (7714.78 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)

Throughput:
events/s (eps): 385.7389
time elapsed: 300.3690s
total number of events: 115864

Latency (ms):
min: 0.05
avg: 0.33
max: 1.24
95th percentile: 467.30
sum: 38419.71
1、压测SQL执行统计
读请求量：1612540 次、写请求量：460308 次、其他操作：244432 次，总执行SQL量高达 2317280 次，整体读写交互频繁，完全模拟生产高峰期业务流量。本次压测共完成事务 115864 笔，全程无报错、无重连，数据库运行稳定。
2、数据库吞吐量指标
压测总时长300.37秒，数据库平均事务处理能力达到 385.74 TPS，每秒处理SQL语句 7714.78 条，系统吞吐负载充足，成功为AWR快照采集提供了饱满的业务压力。
3、事务延迟响应指标
事务最小延迟0.05ms、平均延迟0.33ms、最大延迟1.24ms，95分位延迟为467.30ms。平均响应速度极快，少量高峰时段出现延迟波动，
步骤4：创建结束快照（压力后快照）

--压测结束，手动创建第二个快照
CALL DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

--再次查询快照，拿到END_SNAP_ID
SELECT * FROM SYS.WRM$_SNAPSHOT;

步骤5：生成AWR完整性能报告
--生成HTML AWR报告，服务器路径dmdba要有读写权限
--参数：起始快照ID，结束快照ID，服务器目录，输出文件名
CALL SYS.AWR_REPORT_HTML(1,3,'/opt/dmdbms/data','awr_report.html');

[dmdba@dm2087447142040891392-0 data]$ ll *.html
-rw-r--r-- 1 dmdba dinstall 400041 Aug 12 16:14 awr_report.html

六、AWR报告指标解读

1. 负载比较高
   
   我首先看最上面的 Load Profile（负载概况） 这一块。
   我找到 Executes（执行次数），这里写着 2616 次/秒。意思是这一秒钟数据库就帮我把两千多条 SQL 跑完了，说明我的压测真的打进去了，数据库负载比较高。
   再看 Physical reads（物理读），这里写着 0。说明数据库没去慢吞吞的硬盘里找数据，全在内存里读的。
2. 主要卡在日志和网络
   
   接着我翻到 Top 5 Timed Foreground Events（前 5 等待事件）。
   排第一的是 network idle wait（网络空闲等待）。我看它占了 100% 的时间。我查了资料，这是达梦在高并发压测时的正常现象，意思是 CPU 算得太快了，反而在等网络发数据，说明我电脑的 CPU 很强劲。
   排第二的是 rlog flush wait（日志刷盘等待）。平均等待时间有 77 毫秒。这里就是瓶颈了，说明数据库把数据记到日志文件里有点慢。
   3.造成rlog flush wait的原因
   
   物理读只是把数据搬进内存，不改数据就不记 redo，不会直接造成 rlog flush wait。
   报告里 Physical reads 是 0，但 Commit 有 9.4/s、Block changes 有 2199/s，说明有事务提交，提交必须等日志刷盘。
   DISTINCT / ORDER BY 虽然只是查，但排序占 CPU、带动事务提交，所以间接让 rlog 更忙，不是物理读导致的，也不是逻辑读本身导致的，而是排序带来的 CPU 消耗和事务提交行为导致的。
   找到 SQL Statistics（SQL 统计），看 SQL ordered by Gets（按逻辑读排序）。
   特别是有一条带 DISTINCT（去重）的语句，它读内存的次数最多（Gets 那一列数字最大）。因为要排序去重，所以才占用了 CPU，导致日志刷盘等待。
3. 总结
   我这 13 分钟的压测里，数据库主要就是在飞快地查那些测试表。因为数据都在内存里，所以硬盘没拖后腿。最大的问题就是日志写得慢，还有就是查数据的时候去重排序太费劲。

七、实验总结
通过本次DM8 AWR性能分析实验，我从零掌握了达梦数据库AWR功能的开启、快照创建、压力构造、报告生成、指标解读全流程。深刻理解了达梦AWR的工作机制，能够通过AWR报告分析数据库负载、定位慢SQL、排查资源与等待事件瓶颈，具备基础的达梦数据库性能排查与优化能力，圆满完成DCP认证结业实操要求，为后续生产运维、性能调优积累了扎实的实操经验。