log file switch (checkpoint incomplete)案例-凯发app官方网站

跑批很慢，抓一下awr看看吧

8c、32g的配置，db time不是很夸张

直接top 10 event

log file switch...，看看redo log切换的是否频繁

每小时15次，不太符合每小时4次的标准

看看日志文件状态
select group#,thread#,status,bytes/1024/1024 m from v$log;

都处于活动，看来redo不足，那就增加redo log吧
很合乎逻辑，增加5组1g的redo即可

对吗？

此事件最好多看一眼

关于此事件的说明

先看awr中的 iostat by function/filetype

有些不对，为什么lgwr读取8.6g的控制文件？

看一眼top吧

dbw进程有些卡

很好，看出些异常了，再iostat -dmx 2 9

果真，写入不太正常。

再看看其他参数

虚拟机，测试一下io速度
time cp users01.dbf u.dbf
4g的文件花了2分8秒。

看一下dia0的trc文件

早些时间的健康问题

再看看lg00的trc信息

应该是频繁的db block change （insert as select...）导致redo都处于活动状态，需要写入新的redo时，ckpt要写入控制文件头不能完成，因为ckpt要通知dbw写入缓存数据到磁盘上，而缓慢的io导致dbw 写入数据文件的操作不能完成，阻塞了lgwr。

怎么解决呢？
1、增大redo还是有好处的
2、替换性能较高的存储（cp时写入速度16mb/s，太低了，怎么也得400mb起步呀）
3、减少db block change也许会更佳，例如设置为分区表，用exchange partition进行置换（这只是一个构思，有待验证）

查看历史的事件统计情况

-- from tanelpoder.com
col last_update_time for a36
col evh_event head wait_event for a40
col evh_est_time head "est_time_s*"
col wait_count_graph for a22
col evh_wait_time_milli head wait_time_milli for a15 just right
break on evh_event skip 1
select
event evh_event
, lpad('< ' ||wait_time_milli, 15) evh_wait_time_milli
, wait_count
, case when wait_count = 0 then null else round(wait_time_milli * wait_count * case when wait_time_milli = 1 then 0.5 else 0.75 end / 1000, 3) end evh_est_time
, last_update_time -- 11g
from
v$event_histogram
where
regexp_like(event, '&1', 'i')
order by
event
, wait_time_milli
/

保存为evh.sql，然后执行效果如下：

参考

数据库检查点概述（文档id 1490838.1）
检查点（checkpoint）优化及故障排除指南 (doc id 1526118.1)
tanelpoder.com/posts/log-file-switch-checkpoint-incomplete-and-lgwr-waiting-for-checkpoint-progress/

阅读(3602) | 评论(0) | 转发(0) |

上一篇：为什么归档文件名是thread_1_seq_4374.2639.1072053711

下一篇：查询 v$lock 很慢，hint来帮忙

给主人留下些什么吧！~~

| | | | |

感谢所有关心和支持过chinaunix的朋友们