以Lgwr Worker为例,基于Strace 分析 Oracle 数据库行为的方法

导读	从日志中我们可以梳理出一个大致的脉络。可以看出在Oracle等待事件的统计时长与实际情况并不完全一致。事实上数据库也没必要十分精确的统计等待时长，只要是一个大致的就足够了。只要误差都是差不多的，对于实际分析来说并没有太大的问题。

可观测性能力是IT运维的强有力的支撑。日志告警、指标是两种在运维中很常用的可观测性指标。而对于数据库这样复杂的IT组件来说，有时候仅仅依靠日志和指标还是不够的。

跟踪是解决数据库复杂问题的十分常用和有效的方法。今年的openGauss 开发者大会上，华为的黄凯耀分享的案例就是使用了eBPF进行跟踪，最终精准定位了一个比较复杂的性能问题。在跟踪方面，国产数据库与Oracle等传统商用国数据库还有这很大的技术差距。做好跟踪并不容易，让运维人员或者售后服务人员能够很方便的跟踪数据库的某种运行行为可以帮助提升运维，加快BUG定位。

Oracle提供了十分强大的分析功能，特别是EVENT设置。我刚刚开始学习Oracle不久，就学会了使用event 10046去跟踪SQL语句的执行。这对于我刚刚开始接触Oracle这个黑匣子的说话帮助巨大。在缺乏必要的资料，甚至连一个METALINK账号都没有的时期，学习Oracle数据字典的基本原理，以及数据库启动时的主要动作等，都是通过10046 trace文件完成的。后来也经常使用10046/10053等事件分析，来解决用户的SQL语句性能问题。后来我学习一些Oracle新特性的说话，还是经常会使用event做一些trace。

前两天研究了一下Oracle的LGWR worker新机制，我后来也问了一些客户，在一些系统规模不是很大的场景，好像客户都没有感受到这个新的变化。也有写负载较大的用户遇到了LOG FILE SYNC延时过高的问题，后来通过将LGWR改为原来的写模式解决了问题。于是我昨天写了一篇相关的文章，猜测了一下Oracle实现这个功能的原理。当天下午和一个朋友聊起这个事情，他希望我能够进一步确认一下我的猜测是否靠谱。在网上能够找到的资料极少，于是我只能再次使用起5、6年没用过的跟踪大法来做一个分析。

分析Oracle数据库的后台进程功能有一种十分常用的方法，这个是我从Poder大师那边学来的。结合10046和LINUX的strace，可以比较清晰的分析Oracle后台进程的一些行为。因为10046中会输出某个会话执行过的SQL语句，产生过的各种等待事件，利用这个TRACE上的时间戳，结合strace对于调用堆栈的跟踪，就很容易进行问题定位了。这个方法归纳起来很简单：首先对需要跟踪的后台进程设置8级的10046 TRACE，然后开启压测脚本，同事启用strace对调用堆栈进行跟踪就可以了。我们来看看这个完整的过程。

首先我们找到要跟踪的进程，我们准备跟踪lgwr和lg00。然后分别针对这两个进程设置10046 trace。

在两个窗口中分别通过oradebug设置好之后。我们就可以启用一个压测工具slob去产生一些写负载了。为了减少跟踪的日志量，我们把slob设置为1个进程，并且只启动一个并发。

启动好压测负载后，我们就可以分别在两个窗口中对lgwr/lg00进行strace跟踪了：

对于strace不太熟悉的朋友我可以解释一下，-T -tt是在每个调用前显示时间戳，-s是对于每个调用的数据，最多显示512字节。-p -o我就不解释了，估计地球人都明白。跑上几十秒钟后，我们就可以停止跟踪了，因为大部分的行为都十分类似，没必要跑太久。

我们先来看看lg00的strace跟踪信息，因为我加上了-s参数，因此在trace里可以看到所有写入lg00 trace文件的数据的前面512字节。因此我不需要去查看orcl1_lg00_15626.trc文件了。

上面这段trace的开始是lg00完成了一个日志写入的工作，进入Idle等待状态。随后就收到了写任务，开始写入REDO文件，大家注意看因为使用了异步IO，因此lg00通过io_submit来提交IO。我们往下看，可以发现lg00随后发生了ASM IO for non-blocking poll等待，这是因为向ASM发出了IO。然后lg00产生了我们熟悉的log file parallel write等待。到收到io_getevents为止，异步写完成。于是lg00记录了log file parallel write等待完成。

从日志中我们可以梳理出一个大致的脉络。可以看出在Oracle等待事件的统计时长与实际情况并不完全一致。事实上数据库也没必要十分精确的统计等待时长，只要是一个大致的就足够了。只要误差都是差不多的，对于实际分析来说并没有太大的问题。

我们再来看看lgwr的相关时段的跟踪信息。为了方便查看，我梳理了一个表格，从中可以看出整个过程。

我们先来看lgwr，收到写请求后，找到了一个空闲的worker，然后发出写任务。同时发现所有的worker都处于忙的状态。此时正好没有写任务，于是发出一个本地IPC消息，等待ipc消息回复。

而lg00收到写任务后，首先异步提交了IO，然后产生了一系列预期的写日志的等待。完成后先通知lgwr，然后再给等待着发通知。这个算法是比较合理的，由lg00直接发消息给log file sync等待的会话，而不是通过lgwr，这样会有更高的效率。和我由lgwr发消息，lgwr worker无阻塞写的想法不一致。二者可能在面对不同场景时各有优势，到底哪种更好也不太好判断，也不在我们今天讨论的范围内。今天我们重点要介绍的是跟踪数据库后台进程行为的方法。www.linuxprobe.com