log file switch (checkpoint incomplete)案例

780阅读 0评论2021-05-17 brjl
分类:Oracle

跑批很慢,抓一下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进行置换(这只是一个构思,有待验证)

查看历史的事件统计情况

  1. -- from tanelpoder.com

  2. col last_update_time for a36
  3. COL evh_event HEAD WAIT_EVENT for a40
  4. COL evh_est_time HEAD "EST_TIME_S*"
  5. COL wait_count_graph FOR A22
  6. COL evh_wait_time_milli HEAD WAIT_TIME_MILLI FOR A15 JUST RIGHT
  7. BREAK ON evh_event SKIP 1

  8. SELECT
  9.     event evh_event
  10.   , LPAD('< ' ||wait_time_milli, 15) evh_wait_time_milli
  11.   , wait_count
  12.   , 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
  13.   , last_update_time -- 11g
  14. fROM
  15.     v$event_histogram
  16. WHERE
  17.     regexp_like(event, '&1', 'i')
  18. ORDER BY
  19.     event
  20.   , wait_time_milli
  21. /
保存为evh.sql,然后执行效果如下:


参考

  1. 数据库检查点概述(文档ID 1490838.1)
  2. 检查点(Checkpoint)优化及故障排除指南 (Doc ID 1526118.1)
  3. tanelpoder.com/posts/log-file-switch-checkpoint-incomplete-and-lgwr-waiting-for-checkpoint-progress/

上一篇:为什么归档文件名是thread_1_seq_4374.2639.1072053711
下一篇:查询 v$lock 很慢,hint来帮忙