上一期分享了，由于系统IO性能较差，以致于数据库DBWR和CKPT进程写入慢，checkpoint迟迟不能完成，从而引发大量的buffer busy waits 和 log file switch(checkpoint incomplete)等待事件，导致数据库性能变差的案例。这一期又是继续系列
（对我来说取标题太难了。。），分享的案列又是数据库中出现大量的buffer busy waits 和 log file switch(checkpoint incomplete) 等待事件，虽然现象与上一期相同，但是根本原因却不同。某客户反馈，某系统在10点多突然变慢，很多在线业务被阻塞，希望帮忙查下具体原因。（大家听到这个的时候，第一反应是去查什么呢？）
2. 查看单次等待耗时最长的等待事件
单次等待时间最长的等待事件为buffer busy waits/log file switch(checkpoint incomplete)。
4332/22993这个session在等待buffer busy waits, 被9052这个session阻塞. 阻塞总时间为160秒左右.3. 查看blocking session的等待事件9052这个session正在等待log file switch (checkpoint incomplete), 每次等待最长20秒左右, 偶尔也有几秒钟. 看起来并不是一直被卡在log file switch上. 而是多次被卡住.
阻塞9052这个session的是lgwr进程, 主要等待control file sequential read每次的等待的时间并不长在0.2ms以下.
1. 作checkpint时，会在数据库块上加排他的pin锁，此时前台进程又想要拿到这个pin锁对块数据进行写操作，所以就被阻塞了。2. 等待checkpoint进程，并不一直在等一次checkpoint，而是过几秒等一次, 也就是说，checkpoint是能够正常进行的，只是切换频率太快了。3. 平时redo量大的情况下，多数是单进程，并行处理；而这次是100个进程以上，在同时更新数据，在相同checkpont频率的情况下，阻塞时间不会这么长。1.千万不要在在线业务高峰期，执行大的跑批操作。
2.适当加大redo log size 减少 log file switch的频率，能够缓解上述问题。
上一期收到很多朋友的私信，希望我继续写下去，搞一个小白友好专栏。。
