本文档详细介绍DM数据库性能问题诊断的方法和技巧，包括性能问题诊断概念、性能指标、性能问题诊断方法、性能诊断工具、性能诊断流程、性能诊断策略、实施方案等内容，风哥教程参考DM官方文档《DM8性能调优》手册，适合DBA人员进行DM数据库性能问题的诊断和分析。
Part01-基础概念与理论知识
1.1 DM数据库性能问题诊断概念
DM数据库性能问题诊断是指通过监控和分析数据库的各种性能指标，找出导致数据库性能下降的原因，并提出相应的优化方案。性能问题诊断是数据库运维的重要组成部分，对于确保数据库的稳定运行和性能优化至关重要。
性能问题诊断的重要性：
- 及时发现问题：通过性能诊断可以及时发现数据库性能问题
- 定位问题原因：通过性能诊断可以准确定位性能问题的原因
- 提出优化方案：通过性能诊断可以提出相应的优化方案
- 预防性能问题：通过性能诊断可以预防潜在的性能问题
1.2 DM数据库性能指标
DM数据库性能指标：
# 性能指标
#
# 1. 系统级指标
##
# CPU指标
– CPU使用率：系统CPU的使用情况
– 上下文切换率：进程/线程切换的频率
– 运行队列长度：等待CPU处理的进程数
##
# 内存指标
– 内存使用率：系统内存的使用情况
– 交换空间使用率：交换空间的使用情况
– 内存页交换率：内存页换入/换出的频率
##
# IO指标
– IOPS：每秒IO操作数
– 吞吐量：每秒IO数据量
– 平均响应时间：IO操作的平均响应时间
– 队列长度：等待IO处理的请求数
#
# 2. 数据库级指标
##
# 会话指标
– 活跃会话数：当前活跃的会话数
– 会话等待：会话的等待情况
– 会话状态：会话的状态分布
##
# 事务指标
– 事务数量：每秒事务数
– 事务响应时间：事务的平均响应时间
– 事务成功率：事务的成功比例
##
# SQL指标
– SQL执行次数：每秒SQL执行次数
– SQL响应时间：SQL语句的平均响应时间
– 慢SQL：执行时间超过阈值的SQL语句
##
# 缓存指标
– 缓存命中率：数据缓存的命中比例
– 缓存使用率：缓存的使用情况
– 缓存写入率：缓存写入的频率
##
# 锁指标 风哥提示：
– 锁等待：锁等待的情况
– 死锁：死锁的发生情况
– 锁竞争：锁竞争的激烈程度
#
# 1. 系统级指标
##
# CPU指标
– CPU使用率：系统CPU的使用情况
– 上下文切换率：进程/线程切换的频率
– 运行队列长度：等待CPU处理的进程数
##
# 内存指标
– 内存使用率：系统内存的使用情况
– 交换空间使用率：交换空间的使用情况
– 内存页交换率：内存页换入/换出的频率
##
# IO指标
– IOPS：每秒IO操作数
– 吞吐量：每秒IO数据量
– 平均响应时间：IO操作的平均响应时间
– 队列长度：等待IO处理的请求数
#
# 2. 数据库级指标
##
# 会话指标
– 活跃会话数：当前活跃的会话数
– 会话等待：会话的等待情况
– 会话状态：会话的状态分布
##
# 事务指标
– 事务数量：每秒事务数
– 事务响应时间：事务的平均响应时间
– 事务成功率：事务的成功比例
##
# SQL指标
– SQL执行次数：每秒SQL执行次数
– SQL响应时间：SQL语句的平均响应时间
– 慢SQL：执行时间超过阈值的SQL语句
##
# 缓存指标
– 缓存命中率：数据缓存的命中比例
– 缓存使用率：缓存的使用情况
– 缓存写入率：缓存写入的频率
##
# 锁指标 风哥提示：
– 锁等待：锁等待的情况
– 死锁：死锁的发生情况
– 锁竞争：锁竞争的激烈程度
1.3 DM数据库性能问题诊断方法
DM数据库性能问题诊断方法：
- 监控法：通过监控系统和数据库的性能指标，发现性能异常
- 日志分析法：通过分析数据库日志，找出性能问题的原因
- 执行计划分析法：通过分析SQL语句的执行计划，找出SQL性能问题
- 基准测试法：通过基准测试，评估数据库的性能水平
- 压力测试法：通过压力测试，模拟高负载情况下的性能表现
- 对比分析法：通过对比不同时期的性能数据，找出性能变化的原因
风哥提示：性能问题诊断是一个系统性的工作，需要综合考虑各种因素，从多个角度进行分析。
Part02-生产环境规划与建议
2.1 DM数据库性能诊断工具
DM数据库性能诊断工具：
# 性能诊断工具
#
# 1. 系统工具
##
# top
– 监控CPU和内存使用情况
– 查看进程的CPU和内存占用
##
# vmstat
– 监控系统状态，包括CPU、内存、IO等
– 查看系统的运行情况
##
# iostat 学习交流加群风哥微信: itpux-com
– 监控IO性能
– 查看磁盘的IO使用情况
##
# netstat
– 监控网络连接情况
– 查看网络的使用情况
#
# 2. 数据库工具
##
# DM管理工具
– 图形化管理工具，提供性能监控功能
– 查看数据库的运行状态和性能指标
##
# DMSQL工具
– SQL执行工具，提供执行计划分析功能
– 分析SQL语句的执行计划
##
# DM性能监控工具
– 专门的性能监控工具，提供实时性能数据
– 监控数据库的各项性能指标
#
# 3. 系统视图
##
# V
$SYSSTAT
– 存储系统级统计信息
– 查看系统的各种统计数据
##
# V
$SESSION
– 存储会话信息
– 查看会话的状态和等待情况
##
# V
$SQL
– 存储SQL语句信息
– 查看SQL语句的执行情况
##
# V
$SQL_STATISTICS
– 存储SQL语句的执行统计信息
– 查看SQL语句的执行统计数据
##
# V
$LOCK
– 存储锁信息
– 查看锁的使用情况
##
# V
$TRANSACTION
– 存储事务信息
– 查看事务的执行情况
##
# V
$BUFFER
– 存储缓存信息
– 查看缓存的使用情况
#
# 1. 系统工具
##
# top
– 监控CPU和内存使用情况
– 查看进程的CPU和内存占用
##
# vmstat
– 监控系统状态，包括CPU、内存、IO等
– 查看系统的运行情况
##
# iostat 学习交流加群风哥微信: itpux-com
– 监控IO性能
– 查看磁盘的IO使用情况
##
# netstat
– 监控网络连接情况
– 查看网络的使用情况
#
# 2. 数据库工具
##
# DM管理工具
– 图形化管理工具，提供性能监控功能
– 查看数据库的运行状态和性能指标
##
# DMSQL工具
– SQL执行工具，提供执行计划分析功能
– 分析SQL语句的执行计划
##
# DM性能监控工具
– 专门的性能监控工具，提供实时性能数据
– 监控数据库的各项性能指标
#
# 3. 系统视图
##
# V
$SYSSTAT
– 存储系统级统计信息
– 查看系统的各种统计数据
##
# V
$SESSION
– 存储会话信息
– 查看会话的状态和等待情况
##
# V
$SQL
– 存储SQL语句信息
– 查看SQL语句的执行情况
##
# V
$SQL_STATISTICS
– 存储SQL语句的执行统计信息
– 查看SQL语句的执行统计数据
##
# V
$LOCK
– 存储锁信息
– 查看锁的使用情况
##
# V
$TRANSACTION
– 存储事务信息
– 查看事务的执行情况
##
# V
$BUFFER
– 存储缓存信息
– 查看缓存的使用情况
2.2 DM数据库性能诊断流程
DM数据库性能诊断流程：
学习交流加群风哥QQ113257174
性能诊断流程：
- 收集性能数据：收集系统和数据库的性能数据
- 分析性能数据：分析收集到的性能数据，找出性能异常
- 定位问题原因：根据性能数据，定位性能问题的原因
- 提出优化方案：根据问题原因，提出相应的优化方案
- 实施优化方案：实施提出的优化方案
- 验证优化效果：验证优化方案的效果
2.3 DM数据库性能诊断策略
DM数据库性能诊断策略：
- 定期诊断：定期进行性能诊断，及时发现潜在问题
- 实时监控：实时监控数据库的性能指标，及时发现性能异常
- 重点监控：重点监控关键业务系统的性能指标
- 对比分析：定期对比不同时期的性能数据，找出性能变化的原因
- 基准测试：定期进行基准测试，评估数据库的性能水平
- 压力测试：定期进行压力测试，模拟高负载情况下的性能表现
Part03-生产环境项目实施方案
3.1 DM数据库性能诊断实施方案
3.1.1 性能数据收集
# 性能数据收集
#
# 1. 系统性能数据
##
# 收集CPU数据
# 使用top命令收集CPU数据
$ top -b -n 1 > /tmp/cpu.txt
##
# 收集内存数据
# 使用free命令收集内存数据
$ free -h > /tmp/memory.txt
##
# 收集IO数据
# 使用iostat命令收集IO数据
$ iostat -x 1 10 > /tmp/io.txt
##
# 收集网络数据
# 使用netstat命令收集网络数据
$ netstat -tuln > /tmp/network.txt
#
# 2. 数据库性能数据 更多视频教程www.fgedu.net.cn
##
# 收集会话数据
SQL> SELECT * FROM v$session;
##
# 收集SQL数据
SQL> SELECT * FROM v$sql WHERE executions > 10 ORDER BY elapsed_time DESC;
##
# 收集锁数据
SQL> SELECT * FROM v$lock;
##
# 收集事务数据
SQL> SELECT * FROM v$transaction;
##
# 收集缓存数据
SQL> SELECT * FROM v$buffer;
#
# 3. 性能监控脚本
##
# 性能监控脚本
#!/bin/bash
# performance_monitor.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`
# 收集系统性能数据
echo “===== 系统性能数据 =====”
echo “CPU数据：”
top -b -n 1 | head -20
echo “\n内存数据：”
free -h
echo “\nIO数据：”
iostat -x 1 5
echo “\n网络数据：”
netstat -tuln
# 收集数据库性能数据
echo “\n===== 数据库性能数据 =====”
sqlplus -s SYSDBA/SYSDBA < 10 ORDER BY elapsed_time DESC LIMIT 10;
echo “锁数据：”
SELECT * FROM vlock WHERE wait = 1;
echo “事务数据：”
SELECT * FROM vtransaction;
echo “缓存数据：”
SELECT * FROM vbuffer; 更多学习教程公众号风哥教程itpux_com
EOF
#
# 1. 系统性能数据
##
# 收集CPU数据
# 使用top命令收集CPU数据
$ top -b -n 1 > /tmp/cpu.txt
##
# 收集内存数据
# 使用free命令收集内存数据
$ free -h > /tmp/memory.txt
##
# 收集IO数据
# 使用iostat命令收集IO数据
$ iostat -x 1 10 > /tmp/io.txt
##
# 收集网络数据
# 使用netstat命令收集网络数据
$ netstat -tuln > /tmp/network.txt
#
# 2. 数据库性能数据 更多视频教程www.fgedu.net.cn
##
# 收集会话数据
SQL> SELECT * FROM v$session;
##
# 收集SQL数据
SQL> SELECT * FROM v$sql WHERE executions > 10 ORDER BY elapsed_time DESC;
##
# 收集锁数据
SQL> SELECT * FROM v$lock;
##
# 收集事务数据
SQL> SELECT * FROM v$transaction;
##
# 收集缓存数据
SQL> SELECT * FROM v$buffer;
#
# 3. 性能监控脚本
##
# 性能监控脚本
#!/bin/bash
# performance_monitor.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`
# 收集系统性能数据
echo “===== 系统性能数据 =====”
echo “CPU数据：”
top -b -n 1 | head -20
echo “\n内存数据：”
free -h
echo “\nIO数据：”
iostat -x 1 5
echo “\n网络数据：”
netstat -tuln
# 收集数据库性能数据
echo “\n===== 数据库性能数据 =====”
sqlplus -s SYSDBA/SYSDBA <
echo “锁数据：”
SELECT * FROM vlock WHERE wait = 1;
echo “事务数据：”
SELECT * FROM vtransaction;
echo “缓存数据：”
SELECT * FROM vbuffer; 更多学习教程公众号风哥教程itpux_com
EOF
3.1.2 性能数据分析
# 性能数据分析
#
# 1. 系统性能数据分析
##
# CPU分析
– 查看CPU使用率：如果CPU使用率持续高于80%，可能存在CPU瓶颈
– 查看上下文切换率：如果上下文切换率过高，可能存在进程/线程竞争
– 查看运行队列长度：如果运行队列长度持续大于CPU核心数，可能存在CPU瓶颈
##
# 内存分析
– 查看内存使用率：如果内存使用率持续高于90%，可能存在内存瓶颈
– 查看交换空间使用率：如果交换空间使用率持续高于50%，可能存在内存不足
– 查看内存页交换率：如果内存页交换率过高，可能存在内存不足
##
# IO分析
– 查看IOPS：如果IOPS接近磁盘的最大IOPS，可能存在IO瓶颈
– 查看吞吐量：如果吞吐量接近磁盘的最大吞吐量，可能存在IO瓶颈
– 查看平均响应时间：如果平均响应时间持续高于10ms，可能存在IO瓶颈
– 查看队列长度：如果队列长度持续大于2，可能存在IO瓶颈
#
# 2. 数据库性能数据分析
##
# 会话分析
– 查看活跃会话数：如果活跃会话数持续高于预期，可能存在会话竞争
– 查看会话等待：如果会话等待时间过长，可能存在资源竞争
– 查看会话状态：如果会话状态异常，可能存在问题
##
# SQL分析
– 查看慢SQL：如果存在大量慢SQL，可能存在SQL性能问题
– 查看SQL执行计划：如果SQL执行计划不合理，可能存在SQL优化空间
– 查看SQL执行统计：如果SQL执行统计数据异常，可能存在SQL性能问题
##
# 锁分析
– 查看锁等待：如果存在大量锁等待，可能存在锁竞争 from DB视频:www.itpux.com
– 查看死锁：如果存在死锁，可能存在事务设计问题
– 查看锁竞争：如果锁竞争激烈，可能存在锁策略问题
##
# 事务分析
– 查看事务数量：如果事务数量异常，可能存在业务逻辑问题
– 查看事务响应时间：如果事务响应时间过长，可能存在事务性能问题
– 查看事务成功率：如果事务成功率低，可能存在事务设计问题
##
# 缓存分析
– 查看缓存命中率：如果缓存命中率低于90%，可能存在缓存配置问题
– 查看缓存使用率：如果缓存使用率异常，可能存在缓存配置问题
– 查看缓存写入率：如果缓存写入率过高，可能存在IO压力
#
# 1. 系统性能数据分析
##
# CPU分析
– 查看CPU使用率：如果CPU使用率持续高于80%，可能存在CPU瓶颈
– 查看上下文切换率：如果上下文切换率过高，可能存在进程/线程竞争
– 查看运行队列长度：如果运行队列长度持续大于CPU核心数，可能存在CPU瓶颈
##
# 内存分析
– 查看内存使用率：如果内存使用率持续高于90%，可能存在内存瓶颈
– 查看交换空间使用率：如果交换空间使用率持续高于50%，可能存在内存不足
– 查看内存页交换率：如果内存页交换率过高，可能存在内存不足
##
# IO分析
– 查看IOPS：如果IOPS接近磁盘的最大IOPS，可能存在IO瓶颈
– 查看吞吐量：如果吞吐量接近磁盘的最大吞吐量，可能存在IO瓶颈
– 查看平均响应时间：如果平均响应时间持续高于10ms，可能存在IO瓶颈
– 查看队列长度：如果队列长度持续大于2，可能存在IO瓶颈
#
# 2. 数据库性能数据分析
##
# 会话分析
– 查看活跃会话数：如果活跃会话数持续高于预期，可能存在会话竞争
– 查看会话等待：如果会话等待时间过长，可能存在资源竞争
– 查看会话状态：如果会话状态异常，可能存在问题
##
# SQL分析
– 查看慢SQL：如果存在大量慢SQL，可能存在SQL性能问题
– 查看SQL执行计划：如果SQL执行计划不合理，可能存在SQL优化空间
– 查看SQL执行统计：如果SQL执行统计数据异常，可能存在SQL性能问题
##
# 锁分析
– 查看锁等待：如果存在大量锁等待，可能存在锁竞争 from DB视频:www.itpux.com
– 查看死锁：如果存在死锁，可能存在事务设计问题
– 查看锁竞争：如果锁竞争激烈，可能存在锁策略问题
##
# 事务分析
– 查看事务数量：如果事务数量异常，可能存在业务逻辑问题
– 查看事务响应时间：如果事务响应时间过长，可能存在事务性能问题
– 查看事务成功率：如果事务成功率低，可能存在事务设计问题
##
# 缓存分析
– 查看缓存命中率：如果缓存命中率低于90%，可能存在缓存配置问题
– 查看缓存使用率：如果缓存使用率异常，可能存在缓存配置问题
– 查看缓存写入率：如果缓存写入率过高，可能存在IO压力
3.2 DM数据库性能诊断参数
DM数据库性能诊断参数：
# 性能诊断参数
#
# 1. 系统参数
##
# OS参数
– fs.file-max：文件描述符最大值
– kernel.sem：信号量参数
– kernel.shmmax：共享内存最大值
– kernel.shmall：共享内存总量
– vm.swappiness：交换空间使用策略
#
# 2. 数据库参数
##
# 内存参数
– BUFFER：数据缓冲区大小
– SORT_BUF_SIZE：排序缓冲区大小
– HASH_AREA_SIZE：哈希连接缓冲区大小
– SHARED_POOL_SIZE：共享池大小
– LIBRARY_CACHE_SIZE：库缓存大小
##
# IO参数
– DBWR_IO_SLAVES：DBWR进程数量
– LOG_BUFFER：日志缓冲区大小
– LOG_WRITE_SIZE：日志写入大小
– ROLLBUF_SIZE：回滚缓冲区大小
##
# 并发参数
– MAX_SESSIONS：最大会话数
– SESS_POOL_SIZE：会话池大小
– WORKER_THREADS：工作线程数
– LOCK_TIMEOUT：锁超时时间
##
# 优化器参数
– OPTIMIZER_MODE：优化器模式
– OPTIMIZER_DYNAMIC_SAMPLING：动态采样级别
– OPTIMIZER_INDEX_COST_ADJ：索引成本调整因子
– OPTIMIZER_INDEX_CACHING：索引缓存因子
#
# 3. 参数调优
##
# 调优步骤
1. 分析当前性能数据
2. 识别性能瓶颈
3. 调整相关参数
4. 验证调优效果
##
# 调优示例
# 调整内存参数
SQL> sp_set_para_value(1, ‘BUFFER’, 2097152);
SQL> sp_set_para_value(0, ‘SORT_BUF_SIZE’, 67108864);
SQL> sp_set_para_value(0, ‘HASH_AREA_SIZE’, 67108864);
# 调整IO参数
SQL> sp_set_para_value(1, ‘DBWR_IO_SLAVES’, 4);
SQL> sp_set_para_value(1, ‘LOG_BUFFER’, 67108864);
# 调整并发参数
SQL> sp_set_para_value(1, ‘MAX_SESSIONS’, 1000);
SQL> sp_set_para_value(0, ‘SESS_POOL_SIZE’, 200);
# 调整优化器参数
SQL> sp_set_para_value(0, ‘OPTIMIZER_MODE’, ‘ALL_ROWS’);
SQL> sp_set_para_value(0, ‘OPTIMIZER_DYNAMIC_SAMPLING’, 2);
#
# 1. 系统参数
##
# OS参数
– fs.file-max：文件描述符最大值
– kernel.sem：信号量参数
– kernel.shmmax：共享内存最大值
– kernel.shmall：共享内存总量
– vm.swappiness：交换空间使用策略
#
# 2. 数据库参数
##
# 内存参数
– BUFFER：数据缓冲区大小
– SORT_BUF_SIZE：排序缓冲区大小
– HASH_AREA_SIZE：哈希连接缓冲区大小
– SHARED_POOL_SIZE：共享池大小
– LIBRARY_CACHE_SIZE：库缓存大小
##
# IO参数
– DBWR_IO_SLAVES：DBWR进程数量
– LOG_BUFFER：日志缓冲区大小
– LOG_WRITE_SIZE：日志写入大小
– ROLLBUF_SIZE：回滚缓冲区大小
##
# 并发参数
– MAX_SESSIONS：最大会话数
– SESS_POOL_SIZE：会话池大小
– WORKER_THREADS：工作线程数
– LOCK_TIMEOUT：锁超时时间
##
# 优化器参数
– OPTIMIZER_MODE：优化器模式
– OPTIMIZER_DYNAMIC_SAMPLING：动态采样级别
– OPTIMIZER_INDEX_COST_ADJ：索引成本调整因子
– OPTIMIZER_INDEX_CACHING：索引缓存因子
#
# 3. 参数调优
##
# 调优步骤
1. 分析当前性能数据
2. 识别性能瓶颈
3. 调整相关参数
4. 验证调优效果
##
# 调优示例
# 调整内存参数
SQL> sp_set_para_value(1, ‘BUFFER’, 2097152);
SQL> sp_set_para_value(0, ‘SORT_BUF_SIZE’, 67108864);
SQL> sp_set_para_value(0, ‘HASH_AREA_SIZE’, 67108864);
# 调整IO参数
SQL> sp_set_para_value(1, ‘DBWR_IO_SLAVES’, 4);
SQL> sp_set_para_value(1, ‘LOG_BUFFER’, 67108864);
# 调整并发参数
SQL> sp_set_para_value(1, ‘MAX_SESSIONS’, 1000);
SQL> sp_set_para_value(0, ‘SESS_POOL_SIZE’, 200);
# 调整优化器参数
SQL> sp_set_para_value(0, ‘OPTIMIZER_MODE’, ‘ALL_ROWS’);
SQL> sp_set_para_value(0, ‘OPTIMIZER_DYNAMIC_SAMPLING’, 2);
3.3 DM数据库性能诊断监控
DM数据库性能诊断监控：
# 性能诊断监控
#
# 1. 监控工具
##
# Prometheus + Grafana
– 开源监控系统，提供实时性能监控
– 支持自定义监控面板，可视化性能数据
##
# Zabbix
– 企业级监控系统，提供全面的监控功能
– 支持告警机制，及时通知性能异常
##
# DM监控工具
– 达梦官方提供的监控工具，专门针对DM数据库
– 提供详细的性能监控指标
#
# 2. 监控配置
##
# Prometheus配置
# prometheus.yml
scrape_configs:
– job_name: ‘dm_exporter’
static_configs:
– targets: [‘fgedu.localhost:9161’]
##
# Grafana面板
– 创建CPU监控面板
– 创建内存监控面板
– 创建IO监控面板
– 创建数据库监控面板
##
# Zabbix配置
– 创建主机监控项
– 创建触发器
– 创建告警动作
#
# 3. 监控脚本
##
# 性能监控脚本
#!/bin/bash
# performance_monitor.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`
# 监控CPU使用率
CPU_USAGE=$(top -b -n 1 | grep “%Cpu(s)” | awk ‘{print $2 + $4}’)
if (( $(echo “$CPU_USAGE > 80” | bc -l) )); then
echo “CPU使用率过高：$CPU_USAGE%”
# 发送告警
fi
# 监控内存使用率
MEMORY_USAGE=$(free | grep Mem | awk ‘{print $3/$2 * 100.0}’)
if (( $(echo “$MEMORY_USAGE > 90” | bc -l) )); then
echo “内存使用率过高：$MEMORY_USAGE%”
# 发送告警
fi
# 监控IO响应时间
IO_RESPONSE=$(iostat -x | grep sda | awk ‘{print $10}’)
if (( $(echo “$IO_RESPONSE > 10” | bc -l) )); then
echo “IO响应时间过长：$IO_RESPONSE ms”
# 发送告警
fi
# 监控数据库活跃会话数
ACTIVE_SESSIONS=$(sqlplus -s SYSDBA/SYSDBA < 100 )); then
echo “活跃会话数过多：$ACTIVE_SESSIONS”
# 发送告警
fi
# 监控慢SQL
SLOW_SQL=$(sqlplus -s SYSDBA/SYSDBA < 10000000;
EOF
)
if (( $SLOW_SQL > 10 )); then
echo “慢SQL过多：$SLOW_SQL”
# 发送告警
fi
#
# 1. 监控工具
##
# Prometheus + Grafana
– 开源监控系统，提供实时性能监控
– 支持自定义监控面板，可视化性能数据
##
# Zabbix
– 企业级监控系统，提供全面的监控功能
– 支持告警机制，及时通知性能异常
##
# DM监控工具
– 达梦官方提供的监控工具，专门针对DM数据库
– 提供详细的性能监控指标
#
# 2. 监控配置
##
# Prometheus配置
# prometheus.yml
scrape_configs:
– job_name: ‘dm_exporter’
static_configs:
– targets: [‘fgedu.localhost:9161’]
##
# Grafana面板
– 创建CPU监控面板
– 创建内存监控面板
– 创建IO监控面板
– 创建数据库监控面板
##
# Zabbix配置
– 创建主机监控项
– 创建触发器
– 创建告警动作
#
# 3. 监控脚本
##
# 性能监控脚本
#!/bin/bash
# performance_monitor.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`
# 监控CPU使用率
CPU_USAGE=$(top -b -n 1 | grep “%Cpu(s)” | awk ‘{print $2 + $4}’)
if (( $(echo “$CPU_USAGE > 80” | bc -l) )); then
echo “CPU使用率过高：$CPU_USAGE%”
# 发送告警
fi
# 监控内存使用率
MEMORY_USAGE=$(free | grep Mem | awk ‘{print $3/$2 * 100.0}’)
if (( $(echo “$MEMORY_USAGE > 90” | bc -l) )); then
echo “内存使用率过高：$MEMORY_USAGE%”
# 发送告警
fi
# 监控IO响应时间
IO_RESPONSE=$(iostat -x | grep sda | awk ‘{print $10}’)
if (( $(echo “$IO_RESPONSE > 10” | bc -l) )); then
echo “IO响应时间过长：$IO_RESPONSE ms”
# 发送告警
fi
# 监控数据库活跃会话数
ACTIVE_SESSIONS=$(sqlplus -s SYSDBA/SYSDBA <
echo “活跃会话数过多：$ACTIVE_SESSIONS”
# 发送告警
fi
# 监控慢SQL
SLOW_SQL=$(sqlplus -s SYSDBA/SYSDBA <
EOF
)
if (( $SLOW_SQL > 10 )); then
echo “慢SQL过多：$SLOW_SQL”
# 发送告警
fi
Part04-生产案例与实战讲解
4.1 DM数据库CPU性能问题诊断
以下是一个CPU性能问题诊断的案例：
#
# CPU性能问题诊断案例
##
# 场景描述
系统CPU使用率持续过高，数据库响应缓慢
##
# 诊断步骤
# 1. 收集CPU数据
$ top -b -n 1
# 输出
top – 10:00:00 up 10 days, 2:00, 2 users, load average: 8.50, 7.20, 6.80
Tasks: 200 total, 1 running, 199 sleeping, 0 stopped, 0 zombie
%Cpu(s): 90.0 us, 5.0 sy, 0.0 ni, 5.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
# 2. 分析CPU使用情况
– CPU使用率：95%（用户空间90%，系统空间5%）
– 空闲率：5%
– 负载平均值：8.50（系统有8核CPU）
# 3. 查看进程使用情况
$ top -b -n 1 | head -30
# 输出
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1234 dmdba 20 0 20.0g 5.0g 1.0g R 90.0 12.5 1:30.00 dmserver
# 4. 分析数据库情况
SQL> SELECT * FROM v$session WHERE status = ‘ACTIVE’;
# 输出
行号 SESSION_ID USERNAME STATUS SQL_TEXT
———- ———– ———- ——– ———————————
1 100 FGEDU ACTIVE SELECT * FROM fgedu.t_user WHERE id > 1000000
2 101 FGEDU ACTIVE SELECT * FROM fgedu.t_order WHERE user_id > 1000000
3 102 FGEDU ACTIVE SELECT * FROM fgedu.t_product WHERE price > 1000
# 5. 分析SQL语句
SQL> EXPLAIN SELECT * FROM fgedu.t_user WHERE id > 1000000;
# 输出
行号 PLAN_ID OPERATION NAME EST_ROWS COST
———- ———- ————- ———- ———- ———-
1 1 TABLE ACCESS T_USER 900000 1000
# 6. 诊断结果
– 问题原因：SQL语句执行全表扫描，导致CPU使用率过高
– 解决方案：为查询条件创建索引
# 7. 实施优化
SQL> CREATE INDEX idx_t_user_id ON fgedu.t_user(id);
SQL> CREATE INDEX idx_t_order_user_id ON fgedu.t_order(user_id);
SQL> CREATE INDEX idx_t_product_price ON fgedu.t_product(price);
# 8. 验证优化效果
$ top -b -n 1
# 输出
top – 10:05:00 up 10 days, 2:05, 2 users, load average: 1.20, 2.50, 4.80
Tasks: 200 total, 1 running, 199 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.0 us, 2.0 sy, 0.0 ni, 88.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
# 分析数据库情况
SQL> SELECT * FROM v$session WHERE status = ‘ACTIVE’;
# 输出
行号 SESSION_ID USERNAME STATUS SQL_TEXT
———- ———– ———- ——– ———————————
1 100 FGEDU ACTIVE SELECT * FROM fgedu.t_user WHERE id > 1000000
2 101 FGEDU ACTIVE SELECT * FROM fgedu.t_order WHERE user_id > 1000000
3 102 FGEDU ACTIVE SELECT * FROM fgedu.t_product WHERE price > 1000
# CPU性能问题诊断案例
##
# 场景描述
系统CPU使用率持续过高，数据库响应缓慢
##
# 诊断步骤
# 1. 收集CPU数据
$ top -b -n 1
# 输出
top – 10:00:00 up 10 days, 2:00, 2 users, load average: 8.50, 7.20, 6.80
Tasks: 200 total, 1 running, 199 sleeping, 0 stopped, 0 zombie
%Cpu(s): 90.0 us, 5.0 sy, 0.0 ni, 5.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
# 2. 分析CPU使用情况
– CPU使用率：95%（用户空间90%，系统空间5%）
– 空闲率：5%
– 负载平均值：8.50（系统有8核CPU）
# 3. 查看进程使用情况
$ top -b -n 1 | head -30
# 输出
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1234 dmdba 20 0 20.0g 5.0g 1.0g R 90.0 12.5 1:30.00 dmserver
# 4. 分析数据库情况
SQL> SELECT * FROM v$session WHERE status = ‘ACTIVE’;
# 输出
行号 SESSION_ID USERNAME STATUS SQL_TEXT
———- ———– ———- ——– ———————————
1 100 FGEDU ACTIVE SELECT * FROM fgedu.t_user WHERE id > 1000000
2 101 FGEDU ACTIVE SELECT * FROM fgedu.t_order WHERE user_id > 1000000
3 102 FGEDU ACTIVE SELECT * FROM fgedu.t_product WHERE price > 1000
# 5. 分析SQL语句
SQL> EXPLAIN SELECT * FROM fgedu.t_user WHERE id > 1000000;
# 输出
行号 PLAN_ID OPERATION NAME EST_ROWS COST
———- ———- ————- ———- ———- ———-
1 1 TABLE ACCESS T_USER 900000 1000
# 6. 诊断结果
– 问题原因：SQL语句执行全表扫描，导致CPU使用率过高
– 解决方案：为查询条件创建索引
# 7. 实施优化
SQL> CREATE INDEX idx_t_user_id ON fgedu.t_user(id);
SQL> CREATE INDEX idx_t_order_user_id ON fgedu.t_order(user_id);
SQL> CREATE INDEX idx_t_product_price ON fgedu.t_product(price);
# 8. 验证优化效果
$ top -b -n 1
# 输出
top – 10:05:00 up 10 days, 2:05, 2 users, load average: 1.20, 2.50, 4.80
Tasks: 200 total, 1 running, 199 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.0 us, 2.0 sy, 0.0 ni, 88.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
# 分析数据库情况
SQL> SELECT * FROM v$session WHERE status = ‘ACTIVE’;
# 输出
行号 SESSION_ID USERNAME STATUS SQL_TEXT
———- ———– ———- ——– ———————————
1 100 FGEDU ACTIVE SELECT * FROM fgedu.t_user WHERE id > 1000000
2 101 FGEDU ACTIVE SELECT * FROM fgedu.t_order WHERE user_id > 1000000
3 102 FGEDU ACTIVE SELECT * FROM fgedu.t_product WHERE price > 1000
4.2 DM数据库内存性能问题诊断
以下是一个内存性能问题诊断的案例：
#
# 内存性能问题诊断案例
##
# 场景描述
系统内存使用率持续过高，数据库响应缓慢
##
# 诊断步骤
# 1. 收集内存数据
$ free -h
# 输出
total used free shared buff/cache available
Mem: 64G 60G 1.0G 2.0G 3.0G 1.0G
Swap: 16G 10G 6.0G
# 2. 分析内存使用情况
– 内存使用率：93.75%（60G/64G）
– 可用内存：1.0G
– 交换空间使用率：62.5%（10G/16G）
# 3. 查看进程内存使用情况
$ top -b -n 1 | head -30
# 输出
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1234 dmdba 20 0 20.0g 15.0g 1.0g S 10.0 23.4 1:30.00 dmserver
# 4. 分析数据库内存配置
SQL> select para_name, para_value from v$dm_ini where para_name in (
‘BUFFER’, ‘SORT_BUF_SIZE’, ‘HASH_AREA_SIZE’, ‘SHARED_POOL_SIZE’
);
# 输出
行号 PARA_NAME PARA_VALUE
———- —————- ———-
1 BUFFER 4194304
2 SORT_BUF_SIZE 67108864
3 HASH_AREA_SIZE 67108864
4 SHARED_POOL_SIZE 1073741824
# 5. 分析数据库缓存使用情况
SQL> SELECT * FROM v$buffer;
# 输出
行号 BUFFER_STATUS BUFFER_COUNT BUFFER_SIZE
———- ————- ————- ————
1 FREE 10000 8192
2 USED 499000 8192
3 DIRTY 50000 8192
# 6. 诊断结果
– 问题原因：数据库内存配置过大，导致系统内存不足
– 解决方案：调整数据库内存配置
# 7. 实施优化
SQL> sp_set_para_value(1, ‘BUFFER’, 2097152);
SQL> sp_set_para_value(0, ‘SORT_BUF_SIZE’, 33554432);
SQL> sp_set_para_value(0, ‘HASH_AREA_SIZE’, 33554432);
SQL> sp_set_para_value(1, ‘SHARED_POOL_SIZE’, 536870912);
# 8. 验证优化效果
$ free -h
# 输出
total used free shared buff/cache available
Mem: 64G 40G 20G 2.0G 4.0G 20G
Swap: 16G 2.0G 14G
# 分析数据库缓存使用情况
SQL> SELECT * FROM v$buffer;
# 输出
行号 BUFFER_STATUS BUFFER_COUNT BUFFER_SIZE
———- ————- ————- ————
1 FREE 50000 8192
2 USED 199000 8192
3 DIRTY 20000 8192
# 内存性能问题诊断案例
##
# 场景描述
系统内存使用率持续过高，数据库响应缓慢
##
# 诊断步骤
# 1. 收集内存数据
$ free -h
# 输出
total used free shared buff/cache available
Mem: 64G 60G 1.0G 2.0G 3.0G 1.0G
Swap: 16G 10G 6.0G
# 2. 分析内存使用情况
– 内存使用率：93.75%（60G/64G）
– 可用内存：1.0G
– 交换空间使用率：62.5%（10G/16G）
# 3. 查看进程内存使用情况
$ top -b -n 1 | head -30
# 输出
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1234 dmdba 20 0 20.0g 15.0g 1.0g S 10.0 23.4 1:30.00 dmserver
# 4. 分析数据库内存配置
SQL> select para_name, para_value from v$dm_ini where para_name in (
‘BUFFER’, ‘SORT_BUF_SIZE’, ‘HASH_AREA_SIZE’, ‘SHARED_POOL_SIZE’
);
# 输出
行号 PARA_NAME PARA_VALUE
———- —————- ———-
1 BUFFER 4194304
2 SORT_BUF_SIZE 67108864
3 HASH_AREA_SIZE 67108864
4 SHARED_POOL_SIZE 1073741824
# 5. 分析数据库缓存使用情况
SQL> SELECT * FROM v$buffer;
# 输出
行号 BUFFER_STATUS BUFFER_COUNT BUFFER_SIZE
———- ————- ————- ————
1 FREE 10000 8192
2 USED 499000 8192
3 DIRTY 50000 8192
# 6. 诊断结果
– 问题原因：数据库内存配置过大，导致系统内存不足
– 解决方案：调整数据库内存配置
# 7. 实施优化
SQL> sp_set_para_value(1, ‘BUFFER’, 2097152);
SQL> sp_set_para_value(0, ‘SORT_BUF_SIZE’, 33554432);
SQL> sp_set_para_value(0, ‘HASH_AREA_SIZE’, 33554432);
SQL> sp_set_para_value(1, ‘SHARED_POOL_SIZE’, 536870912);
# 8. 验证优化效果
$ free -h
# 输出
total used free shared buff/cache available
Mem: 64G 40G 20G 2.0G 4.0G 20G
Swap: 16G 2.0G 14G
# 分析数据库缓存使用情况
SQL> SELECT * FROM v$buffer;
# 输出
行号 BUFFER_STATUS BUFFER_COUNT BUFFER_SIZE
———- ————- ————- ————
1 FREE 50000 8192
2 USED 199000 8192
3 DIRTY 20000 8192
4.3 DM数据库IO性能问题诊断
以下是一个IO性能问题诊断的案例：
#
# IO性能问题诊断案例
##
# 场景描述
系统IO响应时间过长，数据库响应缓慢
##
# 诊断步骤
# 1. 收集IO数据
$ iostat -x 1 10
# 输出
Linux 5.4.0-91-generic (fgedu.net.cn) 04/09/2025 _x86_64_ (16 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
10.0 0.0 5.0 50.0 0.0 35.0
device r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 100.0 200.0 10.0 20.0 204.8 10.0 33.3 10.0 40.0 3.0 90.0
# 2. 分析IO使用情况
– IO使用率：90%
– 平均响应时间：33.3ms
– 队列长度：10.0
– 读IOPS：100
– 写IOPS：200
– 读吞吐量：10MB/s
– 写吞吐量：20MB/s
# 3. 分析数据库IO活动
SQL> SELECT * FROM v$iostat;
# 输出
行号 DEVICE_NAME READ_IOPS WRITE_IOPS READ_BYTES WRITE_BYTES
———- ———– ———- ———– ———– ————
1 /dev/sda 100 200 10485760 20971520
# 4. 分析数据库SQL活动
SQL> SELECT sql_id, sql_text, executions, disk_reads FROM v$sql WHERE disk_reads > 1000 ORDER BY disk_reads DESC;
# 输出
行号 SQL_ID SQL_TEXT EXECUTIONS DISK_READS
———- ———- ———————————– ———- ———–
1 1234567890 SELECT * FROM fgedu.t_user WHERE id > 1000000 10 10000
2 0987654321 SELECT * FROM fgedu.t_order WHERE user_id > 1000000 10 8000
# 5. 分析表结构和索引
SQL> SELECT * FROM all_indexes WHERE table_name IN (‘T_USER’, ‘T_ORDER’);
# 输出
行号 OWNER INDEX_NAME TABLE_NAME UNIQUENESS
———- ——– ——————– ———— ———-
1 FGEDU PK_T_USER T_USER UNIQUE
2 FGEDU PK_T_ORDER T_ORDER UNIQUE
# 6. 诊断结果
– 问题原因：SQL语句执行全表扫描，导致IO压力过大
– 解决方案：为查询条件创建索引，优化SQL语句
# 7. 实施优化
SQL> CREATE INDEX idx_t_user_id ON fgedu.t_user(id);
SQL> CREATE INDEX idx_t_order_user_id ON fgedu.t_order(user_id);
# 8. 验证优化效果
$ iostat -x 1 10
# 输出
Linux 5.4.0-91-generic (fgedu.net.cn) 04/09/2025 _x86_64_ (16 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
10.0 0.0 5.0 5.0 0.0 80.0
device r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 10.0 20.0 1.0 2.0 204.8 1.0 5.0 3.0 6.0 1.0 3.0
# 分析数据库SQL活动
SQL> SELECT sql_id, sql_text, executions, disk_reads FROM v$sql WHERE disk_reads > 1000 ORDER BY disk_reads DESC;
# 输出
行号 SQL_ID SQL_TEXT EXECUTIONS DISK_READS
———- ———- ———————————– ———- ———–
# IO性能问题诊断案例
##
# 场景描述
系统IO响应时间过长，数据库响应缓慢
##
# 诊断步骤
# 1. 收集IO数据
$ iostat -x 1 10
# 输出
Linux 5.4.0-91-generic (fgedu.net.cn) 04/09/2025 _x86_64_ (16 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
10.0 0.0 5.0 50.0 0.0 35.0
device r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 100.0 200.0 10.0 20.0 204.8 10.0 33.3 10.0 40.0 3.0 90.0
# 2. 分析IO使用情况
– IO使用率：90%
– 平均响应时间：33.3ms
– 队列长度：10.0
– 读IOPS：100
– 写IOPS：200
– 读吞吐量：10MB/s
– 写吞吐量：20MB/s
# 3. 分析数据库IO活动
SQL> SELECT * FROM v$iostat;
# 输出
行号 DEVICE_NAME READ_IOPS WRITE_IOPS READ_BYTES WRITE_BYTES
———- ———– ———- ———– ———– ————
1 /dev/sda 100 200 10485760 20971520
# 4. 分析数据库SQL活动
SQL> SELECT sql_id, sql_text, executions, disk_reads FROM v$sql WHERE disk_reads > 1000 ORDER BY disk_reads DESC;
# 输出
行号 SQL_ID SQL_TEXT EXECUTIONS DISK_READS
———- ———- ———————————– ———- ———–
1 1234567890 SELECT * FROM fgedu.t_user WHERE id > 1000000 10 10000
2 0987654321 SELECT * FROM fgedu.t_order WHERE user_id > 1000000 10 8000
# 5. 分析表结构和索引
SQL> SELECT * FROM all_indexes WHERE table_name IN (‘T_USER’, ‘T_ORDER’);
# 输出
行号 OWNER INDEX_NAME TABLE_NAME UNIQUENESS
———- ——– ——————– ———— ———-
1 FGEDU PK_T_USER T_USER UNIQUE
2 FGEDU PK_T_ORDER T_ORDER UNIQUE
# 6. 诊断结果
– 问题原因：SQL语句执行全表扫描，导致IO压力过大
– 解决方案：为查询条件创建索引，优化SQL语句
# 7. 实施优化
SQL> CREATE INDEX idx_t_user_id ON fgedu.t_user(id);
SQL> CREATE INDEX idx_t_order_user_id ON fgedu.t_order(user_id);
# 8. 验证优化效果
$ iostat -x 1 10
# 输出
Linux 5.4.0-91-generic (fgedu.net.cn) 04/09/2025 _x86_64_ (16 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
10.0 0.0 5.0 5.0 0.0 80.0
device r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 10.0 20.0 1.0 2.0 204.8 1.0 5.0 3.0 6.0 1.0 3.0
# 分析数据库SQL活动
SQL> SELECT sql_id, sql_text, executions, disk_reads FROM v$sql WHERE disk_reads > 1000 ORDER BY disk_reads DESC;
# 输出
行号 SQL_ID SQL_TEXT EXECUTIONS DISK_READS
———- ———- ———————————– ———- ———–
4.4 DM数据库SQL性能问题诊断
以下是一个SQL性能问题诊断的案例：
#
# SQL性能问题诊断案例
##
# 场景描述
SQL语句执行缓慢，数据库响应时间长
##
# 诊断步骤
# 1. 收集SQL数据
SQL> SELECT sql_id, sql_text, executions, elapsed_time FROM v$sql WHERE elapsed_time > 10000000 ORDER BY elapsed_time DESC;
# 输出
行号 SQL_ID SQL_TEXT EXECUTIONS ELAPSED_TIME
———- ———- ———————————– ———- ————-
1 1234567890 SELECT * FROM fgedu.t_user u JOIN fgedu.t_order o ON u.id = o.user_id WHERE u.id > 1000000 10 50000000
# 2. 分析SQL语句
SQL> EXPLAIN SELECT * FROM fgedu.t_user u JOIN fgedu.t_order o ON u.id = o.user_id WHERE u.id > 1000000;
# 输出
行号 PLAN_ID OPERATION NAME EST_ROWS COST
———- ———- ————- ———- ———- ———-
1 1 NESTED LOOP 100000 50000
2 TABLE ACCESS T_USER 100000 25000
3 INDEX SCAN PK_T_USER 100000 12500
4 TABLE ACCESS T_ORDER 1 1
5 INDEX SCAN IDX_T_ORDER_USER_ID 1 0.5
# 3. 分析表结构和索引
SQL> SELECT * FROM all_indexes WHERE table_name IN (‘T_USER’, ‘T_ORDER’);
# 输出
行号 OWNER INDEX_NAME TABLE_NAME UNIQUENESS
———- ——– ——————– ———— ———-
1 FGEDU PK_T_USER T_USER UNIQUE
2 FGEDU PK_T_ORDER T_ORDER UNIQUE
3 FGEDU IDX_T_ORDER_USER_ID T_ORDER NONUNIQUE
# 4. 分析统计信息
SQL> SELECT * FROM dba_tab_statistics WHERE table_name IN (‘T_USER’, ‘T_ORDER’);
# 输出
行号 OWNER TABLE_NAME NUM_ROWS LAST_ANALYZED
———- ——– ———— ———- —————
1 FGEDU T_USER 1000000 2025-01-01
2 FGEDU T_ORDER 5000000 2025-01-01
# 5. 诊断结果
– 问题原因：SQL语句使用嵌套循环连接，对于大表连接效率低下
– 解决方案：使用哈希连接，更新统计信息
# 6. 实施优化
# 更新统计信息
SQL> ANALYZE TABLE fgedu.t_user COMPUTE STATISTICS;
SQL> ANALYZE TABLE fgedu.t_order COMPUTE STATISTICS;
# 使用哈希连接
SQL> EXPLAIN SELECT /*+ USE_HASH(u, o) */ * FROM fgedu.t_user u JOIN fgedu.t_order o ON u.id = o.user_id WHERE u.id > 1000000;
# 输出
行号 PLAN_ID OPERATION NAME EST_ROWS COST
———- ———- ————- ———- ———- ———-
1 1 HASH JOIN 100000 25000
2 TABLE ACCESS T_USER 100000 12500
3 INDEX SCAN PK_T_USER 100000 6250
4 TABLE ACCESS T_ORDER 100000 12500
5 INDEX SCAN IDX_T_ORDER_USER_ID 100000 6250
# 7. 验证优化效果
SQL> SELECT sql_id, sql_text, executions, elapsed_time FROM v$sql WHERE sql_id = ‘1234567890’;
# 输出
行号 SQL_ID SQL_TEXT EXECUTIONS ELAPSED_TIME
———- ———- ———————————– ———- ————-
1 1234567890 SELECT /*+ USE_HASH(u, o) */ * FROM fgedu.t_user u JOIN fgedu.t_order o ON u.id = o.user_id WHERE u.id > 1000000 10 10000000
# SQL性能问题诊断案例
##
# 场景描述
SQL语句执行缓慢，数据库响应时间长
##
# 诊断步骤
# 1. 收集SQL数据
SQL> SELECT sql_id, sql_text, executions, elapsed_time FROM v$sql WHERE elapsed_time > 10000000 ORDER BY elapsed_time DESC;
# 输出
行号 SQL_ID SQL_TEXT EXECUTIONS ELAPSED_TIME
———- ———- ———————————– ———- ————-
1 1234567890 SELECT * FROM fgedu.t_user u JOIN fgedu.t_order o ON u.id = o.user_id WHERE u.id > 1000000 10 50000000
# 2. 分析SQL语句
SQL> EXPLAIN SELECT * FROM fgedu.t_user u JOIN fgedu.t_order o ON u.id = o.user_id WHERE u.id > 1000000;
# 输出
行号 PLAN_ID OPERATION NAME EST_ROWS COST
———- ———- ————- ———- ———- ———-
1 1 NESTED LOOP 100000 50000
2 TABLE ACCESS T_USER 100000 25000
3 INDEX SCAN PK_T_USER 100000 12500
4 TABLE ACCESS T_ORDER 1 1
5 INDEX SCAN IDX_T_ORDER_USER_ID 1 0.5
# 3. 分析表结构和索引
SQL> SELECT * FROM all_indexes WHERE table_name IN (‘T_USER’, ‘T_ORDER’);
# 输出
行号 OWNER INDEX_NAME TABLE_NAME UNIQUENESS
———- ——– ——————– ———— ———-
1 FGEDU PK_T_USER T_USER UNIQUE
2 FGEDU PK_T_ORDER T_ORDER UNIQUE
3 FGEDU IDX_T_ORDER_USER_ID T_ORDER NONUNIQUE
# 4. 分析统计信息
SQL> SELECT * FROM dba_tab_statistics WHERE table_name IN (‘T_USER’, ‘T_ORDER’);
# 输出
行号 OWNER TABLE_NAME NUM_ROWS LAST_ANALYZED
———- ——– ———— ———- —————
1 FGEDU T_USER 1000000 2025-01-01
2 FGEDU T_ORDER 5000000 2025-01-01
# 5. 诊断结果
– 问题原因：SQL语句使用嵌套循环连接，对于大表连接效率低下
– 解决方案：使用哈希连接，更新统计信息
# 6. 实施优化
# 更新统计信息
SQL> ANALYZE TABLE fgedu.t_user COMPUTE STATISTICS;
SQL> ANALYZE TABLE fgedu.t_order COMPUTE STATISTICS;
# 使用哈希连接
SQL> EXPLAIN SELECT /*+ USE_HASH(u, o) */ * FROM fgedu.t_user u JOIN fgedu.t_order o ON u.id = o.user_id WHERE u.id > 1000000;
# 输出
行号 PLAN_ID OPERATION NAME EST_ROWS COST
———- ———- ————- ———- ———- ———-
1 1 HASH JOIN 100000 25000
2 TABLE ACCESS T_USER 100000 12500
3 INDEX SCAN PK_T_USER 100000 6250
4 TABLE ACCESS T_ORDER 100000 12500
5 INDEX SCAN IDX_T_ORDER_USER_ID 100000 6250
# 7. 验证优化效果
SQL> SELECT sql_id, sql_text, executions, elapsed_time FROM v$sql WHERE sql_id = ‘1234567890’;
# 输出
行号 SQL_ID SQL_TEXT EXECUTIONS ELAPSED_TIME
———- ———- ———————————– ———- ————-
1 1234567890 SELECT /*+ USE_HASH(u, o) */ * FROM fgedu.t_user u JOIN fgedu.t_order o ON u.id = o.user_id WHERE u.id > 1000000 10 10000000
Part05-风哥经验总结与分享
5.1 DM数据库性能问题诊断最佳实践
基于多年DM数据库运维经验，总结以下性能问题诊断最佳实践：
- 定期监控：定期监控系统和数据库的性能指标，及时发现性能异常
- 综合分析：综合分析系统和数据库的性能数据，找出性能瓶颈
- 准确定位：准确定位性能问题的原因，避免盲目优化
- 系统优化：从系统层面进行优化，如CPU、内存、IO等
- 数据库优化：从数据库层面进行优化，如SQL语句、索引、参数等
- 持续优化：持续进行性能优化，不断提高系统性能
- 建立基准：建立性能基准，便于对比分析性能变化
- 文档化：记录性能诊断和优化的过程，便于后续参考
生产环境建议：性能问题诊断是一个系统性的工作，需要综合考虑各种因素，从多个角度进行分析，才能找出根本原因并提出有效的优化方案。
5.2 DM数据库常见性能问题
DM数据库常见性能问题及解决方案：
#
# 问题1：CPU使用率过高
#
# 原因分析
– SQL语句执行效率低
– 全表扫描
– 复杂查询
– 并发用户过多
#
# 解决方案
– 优化SQL语句
– 创建合适的索引
– 调整并发参数
– 使用分区表
#
# 问题2：内存使用率过高
#
# 原因分析
– 数据库内存配置过大
– 内存泄漏
– 缓存使用不当
– 大查询
#
# 解决方案
– 调整数据库内存配置
– 检查内存泄漏
– 优化缓存使用
– 优化大查询
#
# 问题3：IO性能差
#
# 原因分析
– 全表扫描
– 频繁的IO操作
– 存储设备性能差
– IO配置不当
#
# 解决方案
– 优化SQL语句
– 创建合适的索引
– 使用SSD存储
– 调整IO参数
#
# 问题4：SQL执行缓慢
#
# 原因分析
– SQL语句编写不当
– 缺少索引
– 统计信息不准确
– 执行计划不合理
#
# 解决方案
– 优化SQL语句
– 创建合适的索引
– 更新统计信息
– 使用SQL提示
#
# 问题5：锁竞争严重
#
# 原因分析
– 长事务
– 锁粒度过大
– 锁顺序不一致
– 并发用户过多
#
# 解决方案
– 减小事务范围
– 使用行级锁
– 统一锁顺序
– 调整并发参数
#
# 问题6：会话数过多
#
# 原因分析
– 并发用户过多
– 会话泄漏
– 连接池配置不当
– 长会话
#
# 解决方案
– 调整MAX_SESSIONS参数
– 检查会话泄漏
– 优化连接池配置
– 缩短会话生命周期
# 问题1：CPU使用率过高
#
# 原因分析
– SQL语句执行效率低
– 全表扫描
– 复杂查询
– 并发用户过多
#
# 解决方案
– 优化SQL语句
– 创建合适的索引
– 调整并发参数
– 使用分区表
#
# 问题2：内存使用率过高
#
# 原因分析
– 数据库内存配置过大
– 内存泄漏
– 缓存使用不当
– 大查询
#
# 解决方案
– 调整数据库内存配置
– 检查内存泄漏
– 优化缓存使用
– 优化大查询
#
# 问题3：IO性能差
#
# 原因分析
– 全表扫描
– 频繁的IO操作
– 存储设备性能差
– IO配置不当
#
# 解决方案
– 优化SQL语句
– 创建合适的索引
– 使用SSD存储
– 调整IO参数
#
# 问题4：SQL执行缓慢
#
# 原因分析
– SQL语句编写不当
– 缺少索引
– 统计信息不准确
– 执行计划不合理
#
# 解决方案
– 优化SQL语句
– 创建合适的索引
– 更新统计信息
– 使用SQL提示
#
# 问题5：锁竞争严重
#
# 原因分析
– 长事务
– 锁粒度过大
– 锁顺序不一致
– 并发用户过多
#
# 解决方案
– 减小事务范围
– 使用行级锁
– 统一锁顺序
– 调整并发参数
#
# 问题6：会话数过多
#
# 原因分析
– 并发用户过多
– 会话泄漏
– 连接池配置不当
– 长会话
#
# 解决方案
– 调整MAX_SESSIONS参数
– 检查会话泄漏
– 优化连接池配置
– 缩短会话生命周期
5.3 DM数据库性能问题诊断建议
DM数据库性能问题诊断建议：
- 建立监控体系：建立完善的性能监控体系，实时监控系统和数据库的性能指标
- 定期诊断：定期进行性能诊断，及时发现潜在问题
- 综合分析：综合分析系统和数据库的性能数据，找出性能瓶颈
- 准确定位：准确定位性能问题的原因，避免盲目优化
- 系统优化：从系统层面进行优化，如CPU、内存、IO等
- 数据库优化：从数据库层面进行优化，如SQL语句、索引、参数等
- 持续优化：持续进行性能优化，不断提高系统性能
- 建立基准：建立性能基准，便于对比分析性能变化
- 文档化：记录性能诊断和优化的过程，便于后续参考
- 学习新技术：不断学习新的性能诊断和优化技术，提高诊断能力
风哥提示：性能问题诊断是数据库运维的重要组成部分，DBA人员必须掌握性能问题诊断的方法和技巧，根据实际的业务需求和系统环境进行合理配置和优化，提高系统的性能和稳定性。
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
联系我们
在线咨询：
微信号：itpux-com
工作日：9:30-18:30，节假日休息
