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

先拿到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指标也可以看,只是不太好计算占据的容量

 

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

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值