有套数据库运行缓慢，重启后恢复正常，我的分析过程如下，麻烦各位大佬帮忙看看是不是有根本原因没找到，还有这个sql的执行计划为什么变化了，谢谢
1.提取故障时间点的awr和ash看到有条全表扫的语句在故障时间段多次执行，怀疑是这条sql导致的
2.提取正常时间段awr看到该sql照样执行了多次，但是未造成性能问题
3.看了下这条sql是很简单的select A from table where B=X这种，表有100多万数据，查看最新执行计划，是走了索引
4.查看dba_hist_sql_plan看到sql的执行计划发生过改变，此前都是走索引，故障时间点开始了全表扫
5.查看dba_indexes中该索引的情况，发现最新统计信息是在重启后
会是统计信息不完整导致执行计划改变的么，还是有其他原因造成这条sql只能全表扫，目前我想到的解决办法是绑定执行计划，但是为什么执行计划会改变还是没有明确
第一个问题，你需要查询确认你慢的SQL的执行计划，是什么，你的问题没有说清楚2个不同的执行计划，分别走什么，另外就是执行计划的平均执行时间，这个你对sql创建个sqlreport网上搜一下，基本上可以得到报告。
第二个问题，如何分析是不是统计信息收集导致执行计划的改变，https://blog.csdn.net/lihuarongaini/article/details/100983838
参考这个文档，你查下这个表及索引历史收集的情况，在看看时间点是不是匹配的。 如果有问题的时间段统计信息不准，确实很容易出现执行计划改变的情况。
评论
有用 0
AWR里的因果关系一直捋不清，像SQL ordered by Elapsed Time里有几条insert之前执行也很快，但是故障时间点超慢，是全表扫导致的insert慢， 还是insert导致得只能走全表扫，enq: HW - contention这个等待事件也不熟悉，查了下是大量insert导致的HW锁争用，但是执行次数也不多，一小时一个节点才600多次
评论 有用 0我说下我的判断哈，不一定准。
1、首先数据库缓慢是整体缓慢，还是部分业务、部分SQL缓慢，如果是整体缓慢，那主要的方向还是在整个数据库层面，就比如你这个出现的GC争用和HW–contention。
2、如果是部分业务或者具体到SQL缓慢，那就主要放在你后面SQL执行计划的分析上。
可以将故障时间段的ash做个dump上传供大家分析。
评论 有用 0可以提供下故障时间段的ash dump嘛。
如果保密性或者客户要求严格不允许泄露信息的话，就不要往外发了。
如果可以提供，可以参考下面的方法：
-- 生产环境备份ash源数据 create table SYSTEM.t_ash tablespace sysaux as select * from dba_hist_active_sess_history where sample_time >to_date('20220527 09:00:00','yyyymmdd hh24:mi:ss') and sample_time <to_date('20220527 11:00:00','yyyymmdd hh24:mi:ss') ; -- 生产环境导出ash数据 expdp \"\/ as sysdba\" directory=BACKUP tables=SYSTEM.t_ash dumpfile=ash_dump.dmp logfile=ash_dump.log复制
评论 有用 0从你top10看，存在热块争用和TX锁，可以根据Buffer Busy Waits看下是哪个表或索引，或根据该时间段的ash看下详细描述，然后有些争用时间长的，会被记录到alert报警日志中，报警日志中有记录的，可以根据报警内指定的会话信息找到对应具体是那个块引起的
评论 有用 0
墨值悬赏