数据库慢--分析

最新推荐文章于 2024-06-20 15:17:43 发布

lyfhehe

最新推荐文章于 2024-06-20 15:17:43 发布

阅读量298

点赞数

分类专栏： oracle database

本文链接：https://blog.youkuaiyun.com/lyfhehe/article/details/105784424

版权

oracle database 专栏收录该内容

15 篇文章

订阅专栏

本文记录了一次针对数据库慢查询的分析和优化过程。通过AWR报告，发现DB Time远高于elapsed时间，主要等待事件为'cursor: pin S wait on X'。调整PGA_AGGREGATE_TARGET参数至6G，然后设置CURSOR_SHARING为'FORCE'，并在数据库重启后观察到性能提升。然而，dbtime在工作高峰期再次升高，后续计划启用自动内存管理以持续优化。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

背景：
2020年4月26日，财务人员反映最近系统运行慢。
分析及排查过程
1、业务反映慢，生成了awr报告：awr报告：awrrpt_1_24556_24559系统反应慢.html，该awr报告信息截取如下：
在这里插入图片描述

可以看到DB Time相对于elapsed时间是10倍量级。

在这里插入图片描述
可以看到top10的等待事件

可以看到服务器及实例的CPU占用率很低，CPU的资源是充足的。

可以看到主要的等待事件

可以看到top的sql执行情况。frjd8zfy2jfdq执行的次数最多，且每次执行需要的dbtime和CPUtime多。
在这里插入图片描述
以上选了其中一个ADDM报告建议

2、查看了alert日志发现，从系统运行初期，pga一直不足
采取措施：将pga_aggreget_target 由2G调整到了6G;
3、业务反映依然慢：生成了awr报告：awrrpt_1_24562_24563after_pga_goup.html
4、通过ADDM报告建议，将系统参数调整：alter system set cursor_sharing=‘FORCE’;业务反映系统依然慢，有时会好点。

5、晚上重启数据库之前生成了awr报告：awrrpt_1_24564_24565_before_dbstartup.html
6、重启数据库后，业务反映系统明显加快。同样的一个数据同步程序，重启之前需要跑近10个小时，重启后跑2个小时左右。
生成awr报告：awrrpt_1_24578_245979_after_dbstartup.html。
在这里插入图片描述
可以看到db时间下降很多，同时，ADDM报告也未生成建议。
7、再一次收集了数据库重启后，上午10点至11点（工作忙时）的awr数据，发现dbtime又开始增加

在这里插入图片描述

以上标红的语句又开始执行多次了

可以看到在top等待事件中的相关top的sql.

根据ADDM报告的各项情况（尽管看来目前的SGA=10G是够用的。）
4月27日，对系统的内存启用了自动管理，功能将在下次重启数据库后生效。
参考文档： Automatic Memory Management (AMM) on 11g & 12c (Doc ID 443746.1)
Troubleshooting ‘cursor: pin S wait on X’ waits. (Doc ID 1349387.1)

SQL> ALTER SYSTEM SET memory_max_target=30G SCOPE=SPFILE;

System altered.

SQL> ALTER SYSTEM SET memory_target=30G SCOPE=SPFILE;

System altered.

SQL> ALTER SYSTEM RESET sga_target=0 SCOPE=SPFILE;
ALTER SYSTEM RESET sga_target=0 SCOPE=SPFILE
                             *
ERROR at line 1:
ORA-00922: missing or invalid option


SQL> ALTER SYSTEM SET sga_target=0 SCOPE=SPFILE;

System altered.

SQL> ALTER SYSTEM SET pga_aggregate_target=0 SCOPE=SPFILE;

System altered.