本文转自 https://blogs.oracle.com/database4cn/log-file-switch-checkpoint-incomplete-%e5%ae%b9%e6%98%93%e8%a2%ab%e8%af%af%e8%af%8a%e7%9a%84event
 
首先来看如下的一份AWR，12分钟的采样，DB Time 105分钟。
DB Name DB Id Instance Inst num Startup Time Release RAC

R11204 2114874159 R11204 1 23-Oct-17 10:10 11.2.0.4.0 NO

Host Name Platform CPUs Cores Sockets Memory (GB)

nascds18 Linux x86 64-bit 2 2 1 11.64

Snap Id Snap Time Sessions Cursors/Session

Begin Snap: 3 23-Oct-17 10:55:46 37 2.5

End Snap: 4 23-Oct-17 11:08:27 53 2.3

Elapsed:   12.67 (mins)

DB Time:   105.90 (mins)
 
Top event 发现 buffer busy waits 和 log file switch (checkpoint incomplete) 几乎占用了所有的DB Time
Top 10 Foreground Events by Total Wait Time

Event Waits Total Wait Time (sec) Wait Avg(ms) % DB time Wait Class

buffer busy waits 11 3310.6 300960 52.1 Concurrency

log file switch (checkpoint incomplete) 10 3034.8 303479 47.8 Configuration

DB CPU   5.5   .1

log file sync 28 2.3 82 .0 Commit

log buffer space 24 .8 32 .0 Configuration
通过ASH不难发现 buffer busy waits 被 log file switch (checkpoint incomplete) 阻塞，而 log file switch (checkpoint incomplete) 又被 LGWR 的 control file sequential read 阻塞。
2017-10-23 11:05:31.563 1 37 perl@nascds18 (TNS V1-V3) buffer busy waits WAITING 1 150

2017-10-23 11:05:31.563 1 150 sqlplus@nascds18 (TNS V1-V3) buffer busy waits WAITING 1 141

2017-10-23 11:05:31.563 1 141 OMS log file switch (checkpoint incomplete) WAITING 1 130

2017-10-23 11:05:31.563 1 130 oracle@nascds18 (LGWR) control file sequential read WAITING NO HOLDER
接下来再看一眼AWR的iostat，很快发现LGWR有大量的读取，并且都是在读取控制控制文件，12分钟内的读取高达1.5G。
IOStat by Function summary

Function Name Reads: Data

LGWR 1.5G

Others 210M

DBWR 0M

Buffer Cache Reads 10M

Direct Writes 0M

TOTAL: 1.7G

IOStat by Filetype summary

Filetype Name Reads: Data

Control File 1.5G

Log File 185M

Archive Log 0M

Data File 10M

Temp File 0M

TOTAL: 1.7G
结合ASH中的 LGWR 是最终holder，并且 LGWR 等待 control file sequential read 的事实，我们可能很快将 LGWR 列为重点怀疑对象，如果真是这样，那就跑偏了。
 
此时不妨停下来思考一下，什么是 log file switch (checkpoint incomplete)？
 
log file switch (checkpoint incomplete) 指的是当redo需要向下一组 redo group 切换的时候，发现下组日志是 active 的，也就是说下组日志中对应的一些 buffer cache 中的脏块尚未写入到数据文件中，因此必须等待这些脏块被完毕后，才可以复用下一组 redo group。
 
接下来再思考一下，哪个进程负责将脏块写入到数据文件？答案是DBWn，因此我们更需要关注的是DBWn。分析一下OSWatcher不难发现DBW0的状态是D，man一下ps命令: D指的是Uninterruptible sleep (usually IO)，也就是说DBW0 hang在I/O上了，这才是问题的根本原因。
 
那么为什么LGWR会执行如此多的 control file sequential read ？答案是DBWn出现问题导致 LGWR不断查询control 文件获取redo 状态(看它有没有切换成功)导致大量的 control file sequential read
 
下面通过实验来演示这个现象:
 
Test on 12.1.0.2
 
Session 1:  创建一个表，并且update一下让其产生redo
Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> select sid from v$mystat where rownum=1;

      SID

----------

       11   <<<< session 1的 sid 为11

SQL> create table t as select * from dba_objects;

Table created.

SQL> update t set object_name=object_name;

93841 rows updated.
Session 2:  用于查看redo的切换状态
SQL> set line 200 pages 1000

SQL> select group#,thread#,status from v$log;

   GROUP#    THREAD# STATUS

---------- ---------- ----------------

        1          1 INACTIVE

        2          1 INACTIVE

        3          1 CURRENT

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

SQL> select group#,thread#,status from v$log;

   GROUP#    THREAD# STATUS

---------- ---------- ----------------

        1          1 ACTIVE     <<<<<< 让下一组是active的

        2          1 ACTIVE

        3          1 CURRENT
Session 3: 确定DBWn以及LGWR的 spid，并且通过 oradebug 将 DBW0 suspend住让其不工作
SQL> set line 200 pages 1000

SQL> select spid,program from v$process where program like '%DBW%' or program like '%LG%';

SPID                     PROGRAM

------------------------ ----------------------------------------------------------------

5768                     ORACLE.EXE (DBW0)

7248                     ORACLE.EXE (LGWR)

6384                     ORACLE.EXE (LG00)

6308                     ORACLE.EXE (LG01)

SQL> oradebug setospid 5768

Oracle pid: 11, Windows thread id: 5768, image: ORACLE.EXE (DBW0)

SQL> oradebug suspend

Statement processed.
接下来在Session 1中再执行几次update让其自动切换日志:
Session 1:
SQL> update t set object_name=object_name;

93841 rows updated.

SQL> /

93841 rows updated.

SQL> /

93841 rows updated.

SQL> /   ---- 在这里hang住了
Session 4: 观察等待事件
SQL> set line 200 pages 1000

SQL> col program for a15

SQL> col event for a40

SQL> select sid,serial#,program,event,state from v$session where program like '%sqlplus%';

      SID    SERIAL# PROGRAM         EVENT                                    STATE

---------- ---------- --------------- ---------------------------------------- -------------------

       10      33682 sqlplus.exe     SQL*Net message from client              WAITING

       11      48189 sqlplus.exe     log file switch (checkpoint incomplete)  WAITING

      129      25471 sqlplus.exe     SQL*Net message to client                WAITED SHORT TIME

      130      64963 sqlplus.exe     SQL*Net message from client              WAITING
接下来我们对LGWR做10046 trace，观察其等待: 可见反复的 control file sequential read
SQL> oradebug setospid 7248

Oracle pid: 12, Windows thread id: 7248, image: ORACLE.EXE (LGWR)

SQL> oradebug event 10046 trace name context forever, level 8

Statement processed.

SQL> oradebug tracefile_name

D:\ORACLE\diag\rdbms\r12102\r12102\trace\r12102_lgwr_7248.trc

tail -f D:\ORACLE\diag\rdbms\r12102\r12102\trace\r12102_lgwr_7248.trc

WAIT #0: nam='LGWR all worker groups' ela= 72 p1=0 p2=0 p3=0 obj#=-1 tim=25178622234

WAIT #0: nam='control file sequential read' ela= 407 file#=0 block#=1 blocks=1 obj#=-1 tim=25178622880

WAIT #0: nam='control file sequential read' ela= 262 file#=1 block#=1 blocks=1 obj#=-1 tim=25178623344

WAIT #0: nam='control file sequential read' ela= 717 file#=0 block#=15 blocks=1 obj#=-1 tim=25178624315

WAIT #0: nam='control file sequential read' ela= 1774 file#=0 block#=17 blocks=1 obj#=-1 tim=25178626427

WAIT #0: nam='control file sequential read' ela= 311 file#=0 block#=19 blocks=1 obj#=-1 tim=25178627527

WAIT #0: nam='control file sequential read' ela= 269 file#=0 block#=284 blocks=1 obj#=-1 tim=25178627983

WAIT #0: nam='control file sequential read' ela= 238 file#=0 block#=22 blocks=1 obj#=-1 tim=25178628363

WAIT #0: nam='LGWR all worker groups' ela= 51 p1=0 p2=0 p3=0 obj#=-1 tim=25178628590

WAIT #0: nam='control file sequential read' ela= 503 file#=0 block#=1 blocks=1 obj#=-1 tim=25178629320

WAIT #0: nam='control file sequential read' ela= 322 file#=1 block#=1 blocks=1 obj#=-1 tim=25178630389

WAIT #0: nam='control file sequential read' ela= 276 file#=0 block#=15 blocks=1 obj#=-1 tim=25178630864

WAIT #0: nam='control file sequential read' ela= 253 file#=0 block#=17 blocks=1 obj#=-1 tim=25178631286

WAIT #0: nam='control file sequential read' ela= 250 file#=0 block#=19 blocks=1 obj#=-1 tim=25178631696

WAIT #0: nam='control file sequential read' ela= 658 file#=0 block#=284 blocks=1 obj#=-1 tim=25178632935

WAIT #0: nam='control file sequential read' ela= 303 file#=0 block#=22 blocks=1 obj#=-1 tim=25178633812

......
最后我们将DBWn恢复，结束这个无限的 control file sequential read 等待。
回到Session 3，resume DBW0：
SQL> oradebug resume

Statement processed.
只要理解了原理，这个问题本来不难诊断，但是ASH和AWR的信息会让DBA错误的认为是 LGWR 的等待control file sequential read导致的问题。

log file switch (checkpoint incomplete) - 容易被误诊的event的更多相关文章

  1. log file switch (checkpoint incomplete)

    接手了一个新交接的库,alert日志频繁报告log file switch (checkpoint incomplete)事件 oracle文档解释: Waiting for a log switch ...

  2. ORACLE等待事件: log file parallel write

    log file parallel write概念介绍 log file parallel write 事件是LGWR进程专属的等待事件,发生在LGWR将日志缓冲区(log_buffer)中的重做日志 ...

  3. 理解LGWR,Log File Sync Waits以及Commit的性能问题[转]

    理解LGWR,Log File Sync Waits以及Commit的性能问题 一．概要: 1.  Commit和log filesync的工作机制 2.  为什么log file wait太久 3. ...

  4. Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql) (文档 ID 1064487.1)

    the article from :http://m.blog.itpub.net/31393455/viewspace-2130875/ Script to Collect Log File Syn ...

  5. log file sync等待超高案例浅析

    监控工具DPA发现海外一台Oracle数据库服务器DB Commit Time指标告警,超过红色告警线(40毫秒左右,黄色告警是10毫秒,红色告警线是20毫秒),如下截图所示,生成了对应的时段的AWR ...

  6. Oracle 联机重做日志文件(ONLINE LOG FILE)

    --========================================= -- Oracle 联机重做日志文件(ONLINE LOG FILE) --================== ...

  7. Linux/Unix shell 监控Oracle告警日志(monitor alter log file)

    使用shell脚本实现对Oracle数据库的监控与管理将大大简化DBA的工作负担,如常见的对实例的监控,监听的监控,告警日志的监控,以及数据库的备份,AWR report的自动邮件等.本文给出Linu ...

  8. log file sync

    Recently, our application system has updated one app. I receive a email of complain the db server ch ...

  9. 1025InnoDB log file 设置多大合适

    转自 http://blog.csdn.net/langkeziju/article/details/51094289 数据库的东西,往往一个参数就牵涉N多知识点.所以简单的说一下.大家都知道inno ...

随机推荐

  1. 通过Centreon监控apache、MySQL、Hadoop服务状态

    在上面的章节中,只是简单介绍了Centreon的几个基础监控项,例如添加主机.服务等,这些对于一个监控系统来说是远远不够的,本节将重点介绍对一些扩展服务的监控,也就是对一些常见应用的监控. 一. Na ...

  2. 用.NET模拟天体运动

    用.NET模拟天体运动 这将是一篇罕见而偏极客的文章. 我上大学时就见过一些模拟太阳系等天体运动的软件和网站,觉得非常酷炫,比如这个(http://www.astronoo.com/en/articl ...

  3. 【Vuejs】269- 提升90%加载速度——vuecli下的首屏性能优化

    前言 之前用 ,所以接下来还会介绍一些它们在优化上的异同 分析 vuecli 2.x自带了分析工具只要运行 npm run build --report 如果是 vuecli 3的话,先安装插件 cn ...

  4. UWP 中的全局异常处理

    问题 在开发一款应用的过程中,我们开发者很难考虑到所有问题,往往会忘记处理一些可能发生的异常.随之而来的结果就是用户使用过程中接连不断的崩溃.所以,我们有必要处理所有未被我们处理的异常. 本文介绍了 ...

  5. 【Eclipse】Spring Tool Suite插件

    Spring Tool Suite插件 最新下载地址:https://spring.io/tools3/sts/all 以前下载地址:https://spring.io/tools3/sts/lega ...

  6. drf源码分析系列---认证

    认证的使用 from rest_framework.authentication import BaseAuthentication from api import models # 认证类 clas ...

  7. 将数据库中数据导出为excel表格

    public class Excel { private static Logger logger = LoggerFactory.getLogger(Excel.class); /** * 导出项目 ...

  8. 自定义滚动条(Custom ScrollBar)

    时间如流水,只能流去不流回! 点赞再看,养成习惯,这是您给我创作的动力! 本文 Dotnet9 https://dotnet9.com 已收录,站长乐于分享dotnet相关技术,比如Winform.W ...

  9. css重点知识和bug解决方法

    1.图片向下撑大3像素问题 在一个盒子里面放一张图片,默认情况下,图片会向下撑大3像素,有以下几种解决方法: 1.1 给图片添加display:block: 1.2 给图片添加 float:left: ...

  10. 【CV现状-3.2】纹理与材质

    #磨染的初心--计算机视觉的现状 [这一系列文章是关于计算机视觉的反思,希望能引起一些人的共鸣.可以随意传播,随意喷.所涉及的内容过多,将按如下内容划分章节.已经完成的会逐渐加上链接.] 缘起 三维感 ...