一份AWR报告的请教

lujiaguai

唐sir,一份AWR报告请教（见附件 awr_report_31808_31809.rar (44.5 KB, 下载次数: 593)

2018-1-17 14:26 上传

点击文件名下载附件 ）。
该环境在半夜2点到3点之间执行了一些任务，具体怎么执行的不清楚，大概是在操作系统本身的shell脚本以及应用程序上都有动作。

该报告中，top中sql的主要的性能开销都是由SYS产生的。
比如下面这2条，不明白在做什么，执行了各执行了3万多次。
update hist_head$ set bucket_cnt=:3, row_cnt=:4, cache_cnt=:5, null_cnt=:6, timestamp#=:7, sample_size=:8, minimum=:9, maximum=:10, distcnt=:11, lowval=:12, hival=:13, density=:14, spare1=:15, spare2=:16, avgcln=:17, col#=:18 where obj#=:1 and intcol#=:2

update ind$ set ts#=:2, file#=:3, block#=:4, intcols=:5, type#=:6, flags=:7, property=:8, pctfree$=:9, initrans=:10, maxtrans=:11, blevel=:12, leafcnt=:13, distkey=:14, lblkkey=:15, dblkkey=:16, clufac=:17, cols=:18, analyzetime=:19, samplesize=:20, dataobj#=:21, degree=decode(:22, 1, null, :22), instances=decode(:23, 1, null, :23), rowcnt=:24, pctthres$=:31*256+:25, indmethod#=:26, trunccnt=:27, spare4=:29, spare2=:30, spare6=:32where obj#=:1

select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#, sample_size, minimum, maximum, distcnt, lowval, hival, density, col#, spare1, spare2, avgcln from hist_head$ where obj#=:1 and intcol#=:2

看的很明确的就是2条
1，delete aud$  删三十天以外的数据
2，select 拼了一个串，用analyze table来分析所有表的串，估计下一步就是在shell下执行拼出来的串


是不是这2个动作，尤其是第二个动作后接下来逐个执行analyze table，导致了top sql中大量的sys的sql?
（大量update hist_head$ 以及 update ind$是否就是批量analyze table的结果？）


书上说 analyze 是过去的老办法，为了兼容而存在。目前建议使用dbms_stats包来收集统计信息。
那么按这份AWR报告里面这么做，就是不对的。
2点在3点这个时间段应用程序做了一些拿临时表当作中间表，进行了类似库龄计算的任务，某些表会有一些较大的变化。
猜测这可能是拼出analyze table语法的原因，若是这样，把自动维护任务的时间窗口从22：00移到凌晨3点以后，才是正确的做法。
唐SIR，这么理解对不对？

botang

1. 没注意到这帖，延迟了。快速看了一下，这段时间，除了你说的，还有个大delete和大排序（PGA有个多趟IO）。日志也是这些DML引起的，太多了。文件IO有很大的问题。
2. analyze和dbms_stats都会更新以上sys的表，sys语句都不能简单看。不过的确不要在这个时候做自动优化器统计信息收集。
3. analyze不如dbms_Stats精确。
4. 这个案例典型的首先要调SQL。

lujiaguai

delete和排序动作，这些肯定是他们在做一些类似账套备份的动作，就是通过一张临时的中间表做一些腾挪，不可避免的，每段时间半夜都要来这么一次。最严重的是月初的某一两个晚上。
但是这份报告的时间并非这种情况，我怀疑就是他们每天晚上用select 拼出analyze的语法，对所有表做分析，然后一次全部执行一遍，而且每晚都做，表很多。。。。。
自动优化任务很早之前是被我取消了，当时因为有一个sql tunning 过不去，估计是卡在某一个sql 语句上导致。当时形而上学，关闭了整个自动优化任务，算起来有很长很长一段时间了，是我错了~
我去了解一下，如果晚上中间表腾挪是必须要做的，而且避开了高峰期，就可以了。自动优化任务还是应该开起来了的，单独关闭sql tuning那个任务就好了。