Oracle 下马观花看redo

awr报告信息提示：

      1.对于log file switch (checkpoint incomplete)等待事件，容易误导dba的排查思路，awr报告里该等待事件平均等待 601.22毫秒，占用当前dbtime 31%,同时db cpu占用dbtime的比例达到41%。这里我们不妨分析这个等待事件产生的成因，log file switch (checkpoint incomplete)指的是当redo需要向下一组redo group切换的时候，发现下组日志是active活动状态的，简单的说就是下组日志中对应的一些buffer cache中的脏块压根没有写入到数据文件中，因此必须等待这些dirty block被flush完毕 后，才可以复用下一组redo group

     2.既然是把dirty block flush到datafile，那么自然是dbwn的工作，实际我们需要更多关注的是dbwn这个进程的写io负载情 况，那么awr里有8.3g的控制文件io负载是为什么，其实是dbw本身的io问题导致 lgwr不断查询control 文件获取redo 状态，获 取状态最根本的目的就是想知道究竟redo切换是否成功，所以后台产生大量控制文件io操作。

       3.在以前的文章中我们分享过log file sync等待事件，写redo很慢，从而导致gc buffer busy acquire /release 等待事件，其 实这个就比较方便定位，只要我们做了addm，可以看到诸如如下的提示：waits on event “log file sync” were the cause of significant database wait on “gc buffer busy” when releasing a data block. waits on event“log file sync” in this instance can cause global cache contention on remote instances，那么基本可以确认gc buffer busy的源头是log file sync(虽然本质上不是)，那么优先解决log file sync的问题。

       oracle 9i时代，企业业务数据还没井喷，无论是事务还是日志生成量都相对较少，那个年代没有所谓大数据的概念，基本都 维持在一次变更，一条数据，一次内存分配即可完成的状态，随着企业业务数据激增，尤其oltp系统，老的redo机制已经无法满足 高并发，大写入量的需求，到10g版本以后oracle推出了private redo 和imu，也就是in-memory undo的机制，这样一来，一个 进程就可以以整个事务的方式去工作，生成所有的改变向量，并将它们存入私有重做日志缓冲区，也就是private redo log buffer 中，当事务提交时，进程将存于私有重做日志缓冲区的记录复制到公共的重做日志缓冲区，这时，跟传统的重做日志缓冲区工作原 理保持一致，那么写到重做日志文件的过程，一个进程在一个事务里只需要获得一次公共的redo allocation latch，而不是每次变 更都要获取一次latch。

     既然是下马看花，为了方便大家理解，我们至少要搞懂几个事情，才能做到真正意义的赏花望月，imu机制带来的in memory undo latch是否影响数据库负载，是否有威胁，同时分析重做日志文件，搞清楚redo entry都记录了什么，同时我们还要 分析x$kcrfstrand x$ktifp理解各种实例活动信息之间的关联关系，这里涉及的技术知识点比较多，由于篇幅原因，和大家分享两个 相对重要的：

     1. 关于redo方面增量的基础结构由两组内存结构组成，一组是x$kcrfstrand私有redo区域，主要处理前滚改变向量， 另一组x$ktifp imu区域，处理undo改变向量，私有redo区域里面也包含传统的公共重做日志缓冲区，因此如果查询这个固化视图 发现有两类不同的信息，不要担心，是正常现象。 

      2. x$ktifp表示imu区域中的池个数，取决于持有事务的细节v$transaction的数组大小，它由oracle的参数 transactions设定，但是这个参数通常随session 或者processes参数调整自动更新，基本上，池的个数默认为transactions/10,比 如transactions是1000，那么池的个数就是100，每个池是由自己的imu latch受保护的。 

      3. x$ktifp中的每一条记录在x$kcrfstrand中都有与之对应的一条私有redo记录，不过x$kcrfstrand还会涉及其他信 息，公共的redo记录个数由cpu_count参数决定，算法是ceiling(1 + cpu_count/16) 

     4. x$kcrfstrand中的每一条私有重做记录都由自身的redo allocation latch来保护，每一条公共的重做记录都由传统 的redo copy latch保护，每个cpu一个redo copy latch