DBA的新领域：调试Oracle(进阶篇)

Author:  Lv, Haibo

摘要：调试Oracle的意义 ---- 无限风光在险峰

我把用DTrace和mdb，分析、研究Oracle称为“调试Oracle”，这是一个新的领域。它比传统DBA要求更高，除掌握Oracle内部原理外，它也要求更多的计算机底层知识，因为个别时候，我们需要到反汇编代码中，一探研究。那么究竟调试Oracle技术可以为DBA带来什么改变呢？本文想给各位读者朋友一个基本的回答。

本文从DBA最常用的等待事件出发，以10G后新增的一个等待事件log file switch(private strand flush incomplete)为例，描述了如何使用DTrace和mdb，揭开这个等待事件的秘密。

不使用调试Oracle技术，我们无法用测试获得这个等待事件真正的意义。这就是调试Oracle的意义之一。它还有更多的作用，有时间我们细细道来。

一句话总结一下，“调试Oracle”需要很多基础知识和极大的耐心，是一条崎岖的山路，但它可以助你更快速的登上Oracle这做高峰，“无限风光在险峰”。

调试Oracle  之二   进阶篇

---- 解析log file switch(private strand flush incomplete)等待事件的意义

         在上一篇文章中，我大概讲述了调试Oracle的利器之一：DTrace的基本使用。本篇开始用一个简单的例子，展示“调试Oracle”的神奇之处。

       上一篇中我们主要使用了I/O提供器中的探针，其实这远不是DTrace中最强大的功能。DTrace最强大的是PID提供器中的进程探针，它可以让我们轻松进入Oracle内部，看到Oracle内部的函数调用关系，再辅以调试器gdb或mdb，威力无穷。

本篇的例子是关于等待事件解析的，等待事件是DBA重要的判断Oracle问题的依据。有一本书，中文书名《Oracle Wait Interface 性能诊断与调整实践指南》，专门讲述Oracle各种等待事件的意义，是我早年最重要的参考书。后来还有一个韩国人，也写了一本有关等待事件的书，《高级OWI与ORACLE性能调整》，也有一定参考意义，有兴趣的读者可以找一下。

如果你理解错了等待事件的意义，哪么你判断问题的方向，很可能偏离正确的轨道，这有可能会造成严重的后果。如果Oracle是你梦想中的女/男神，她告诉你她正在等待着什么（就像Oracle用等待事件告诉你，它正在等待什么），而你，却理解错了，……。

我想我已经不需要继续说下去了，又是一场悲剧，说多了都是泪。

想懂“女人的心”很难，想懂Oracle的心，所幸有了“调试Oracle”技术，这就方便多了。

下面我们以log file switch(private strand flush incomplete)等待事件为例，详细分析下如何使用DTrace+Mdb挖掘等待事件的意义，我就不再讲什么授人以鱼不如授人以渔这样的空话，我力求本文是“渔”，如果大家只能看到“鱼”，请告诉我，我会写的再简单写。

log file switch(private strand flush incomplete)等待事件是10G后针对IMU特性新增的等待事件，如果你开启了IMU，有时候就可能会遇到它。

在开始分析之前，你可以在网上搜索一下，看看大家都是如何解释此等待事件的。我先粘贴一段官方文档中关于此等待事件的描述：

User sessions trying to generate redo, wait on this event when LGWR waits for DBWR to complete flushing redo from IMU buffers into the log buffer. When DBWR is complete LGWR can then finish writing the current log, and then switch log files.

这段英文太简单，不详细解释了。由于这段文档中涉及到了DBWR，“wait on this event when LGWR waits for DBWR to complete flushing redo from IMU buffers into the log buffer”。一些人这样翻译这句：LGWR等待DBWR完成刷新Redo从IMU Buffer到Log Buffer。有一段时间，我曾经这样翻译：“LGWR等待DBWR，以便完成Redo从IMU Buffer到Log Buffer”。

但是，这面这两种说法都是错的。或者说，官方文档在这里是错误的。

先别急着“拍”砖，我知道有很多老DBA一再强调，官方文档是如何如何的重要，甚至还会有人说一切与官方文档为准。

我只想说，“尽信书不如无书”，我们在前进程过程中，千万不能有“半部论语治天下”这样的想法。我不否认官方文档的重要性，但我还是要说，有时，它可能有错误。

好了，下面用实际的测试，来解析log file switch(private strand flush incomplete)的产生原因。

第一节  福尔摩斯登场

在许多侦探故事中，作为主角的侦探，总会做很多假设，故事的发展，当然无一例外证明了主角的假设。下面，为了全面展现我的分析过程，我们不妨把自己也相像成大侦探福尔摩斯，就让福大侦探为我们分析log file switch(private strand flush incomplete)事件的原理吧。当然，也少不了他的助手华生。

好，现在切换到罪案现场。

华生：“Sir，凶案现场只能看到log file switch(private strand flush incomplete)，它是我们的唯一线索，它的原因会是什么呢？”。

福尔摩斯：“你说呢，华生，先不要急，东方古国中有一句俗语，纸包不住火。真相一定会水落石出。你再仔细看看，我觉得你应该可以看出来点什么。”

华生：“嗯，我只知道，log file switch(private strand flush incomplete)和日志切换有关，这点从名字就能看出来”。

福尔摩斯：“还有呢，这也是线索啊。继续说。private strand flush incomplete也包含了很多信息啊”

华生：“还有的话，private strand，这个是10G后的新特性吧。有关IMU的。”

福尔摩斯赞许的点了点头，受到鼓励的华生顿了一顿，继续说道：“private strand flush incomplete，也就是private strand 这块内存缓存区中的数据没有被刷新完成。再加上前面的log file switch，这个等待事件意思是LGWR在切换日志的时候，发现private strand内存区中的数据还没有刷新完成。”

福尔摩斯高兴的说：“perfect，大体上已经差不多了，但这个案子还有很多疑点。Private strand中的数据要被刷新到哪儿？为什么它刷新没有完成时，LGWR要等待？”。

华生想了想，说：“这个我就不太清楚了。”

福尔摩斯：“回忆一下IMU的原理。在IMU下，DML执行时，后映像数据先存放在哪儿？后存放在哪儿？从哪儿写磁盘？”

华生：“这些我知道，我了解过IMU方面的基础知识。DML在执行时，后映像先被存放到private strand中，在提交时被写到Public Log Buffer中，也就是通常所说的Log Buffer，再由LGWR从Log Buffer中写到磁盘中Redo File中。”

“啊！”华生惊叫道：“我明白了，这里的‘private strand flush incomplete’，应该是把Private strand中的后映像写到Log Buffer中。”

福尔摩斯肯定的答道：“是的，在这个刷新操作没有完成时，LGWR开始日志切换，切换操作被刷新操作阻塞，因此就产生了这个等待事件。”

华生：“是啊，Sir，最终情况应该就是这样。”

福尔摩斯说：“还有些问题，……”

福尔摩斯还没有说完，华生就抢着说道：“我知道还有什么问题，是谁在完成‘flush private strand to public log buffer’。”

福尔摩斯说：“你变聪明了，华生。”

华生说：“Of cause，只有找到这个元凶，我们才能‘调试’它。”

福尔摩斯说：“对的，我们的案犯嫌疑人，有可能是谁？”

华生说：“DML执行时，后映像数据是由Server Process产生的。在IMU方式下，后映像数据会先被Server Process放到Private Stand Area。”

福尔摩斯说：“是的，这是大家都知道的常识。还有后映像数据到达Log Buffer后，一定是由LGWR写进磁盘中的Redo File。这一点也是大家都知道的常识。关键是中间呢？后映像数据到达Private Strand Area后，由谁传送到Public Log Buffer？”

华生说：“我猜，嫌疑人只可能是两个，Server Process或LGWR。”

福尔摩斯：“Yes，I think so.”

顿了一顿，福尔摩斯接着说：“我猜嫌疑人更有可能是Server Process。LGWR是核心人物，他负责很重要的事务，他未必有时间作案。”

“Yes，I think so.”华生学着福尔摩斯刚才的语气说。

“哪么，接下来，”福尔摩斯顿了顿。华生接着说：“开始跟踪嫌疑人Server Process。”

第 二 节  跟踪Server Process

必须要先从案发现场回来了，因为我们要说说我们的跟踪脚本：

bash-3.2# cat case1.d

#!/usr/sbin/dtrace -s -n

 

dtrace:::BEGIN

{

        i=1;

}

 

pid$1:::entry