归档日志快速增长分析记录

先拿到awr分析报告：

 

从报告的汇总结果，看Redo size(bypes) 

Redo size (bytes):

3,532,698.9

计算下，一天产生的归档日志的总容量

 

>>> (3532698.9*3600*24)/1024/1024/1024

284.26310509443283

>>>

 

 

然后看AWR报告中的Segments by DB Blocks Changes部分，找到DML量比较大的对象，然后再去SQL Statistics部分找相关的SQL

 

 

看图片中，temp_dynamic_cost表，的DB Block Changes是166,172,736个，计算下，这些变化最大能产生的归档日志是

>>> (166172736*819)/1024/1024/1024;

126.74878424406052

>>>

126个G。

其它几个表再加起来，基本上占据了90%+的归档日志量，把这几个表的业务梳理下，大概率能知道哪个业务细节导致的。

 

 

另外从

Segments by Physical Writes指标也可以看，只是不太好计算占据的容量

 

所以，这就很快找到了问题点，接下来就找业务开发人员，定位下这个表的业务细节，就知道是哪里出问题了。