可观察性能力是IT运维的有力支撑。日志告警和指标是运维中常用的两个可观察性指标。对于数据库等复杂的IT组件，有时仅靠日志和指标是不够的。跟踪是解决复杂数据库问题的一种非常常用和有效的方法。在今年的openGauss开发者大会上，华为的黄凯耀分享了一个使用eBPF做追踪的案例，最后指出了一个比较复杂的性能问题。在跟踪方面，国产数据库与Oracle等传统商业数据库在技术上还有较大差距。做好跟踪工作并不容易。让运维人员或售后服务人员可以方便地跟踪数据库的某些操作行为，有助于改进运维，加快BUG定位。Oracle提供了非常强大的分析功能，尤其是EVENT设置。刚开始学习Oracle没多久，我就学会了用事件10046来跟踪SQL语句的执行情况。这对我刚开始讲Oracle黑盒的时候帮助很大。在缺乏必要资料甚至没有METALINK帐号的时期，学习Oracle数据字典的基本原理和数据库启动时的主要动作都是通过10046跟踪文件来完成的。后来经常使用10046/10053等事件分析来解决用户SQL语句性能问题。后来学习了一些Oracle新特性的语言，还是经常用事件来做一些trace。前两天研究了Oracle新的LGWRworker机制，后来也问了一些客户。在一些系统规模不是很大的场景下，客户似乎还没有感受到这个新变化。一些写负载大的用户遇到LOGFILESYNC延迟高的问题，后来通过将LGWR改成原来的写模式解决了这个问题。于是昨天写了一篇相关的文章，猜测一下Oracle实现这个功能的原理。那天下午我和一个朋友聊起这件事，他希望我进一步证实我的猜测是否可靠。网上能查到的资料非常少，只能用自己5、6年没用过的tracking方法做一个分析。分析Oracle数据库的后台进程功能有一个很常用的方法。这是我从Poder大师那里学到的。结合10046和LINUX的strace，可以清晰的分析出Oracle后台进程的一些行为。因为10046会输出某个session执行的sql语句，以及已经发生的各种等待事件，利用这个TRACE上的时间戳，结合strace对调用栈的trace，很容易定位问题。这个方法总结起来很简单：先给需要跟踪的后台进程设置level810046TRACE，然后启动压测脚本，开启strace跟踪调用栈。我们来看看这个完整的过程。首先我们找到要跟踪的进程，我们要跟踪lgwr和lg00。然后分别为这两个进程设置10046trace。在两个窗口分别通过oradebug设置后。我们可以启用压力测试工具slob来生成一些写入负载。为了减少跟踪日志量，我们将slob设置为1个进程，并发只启动一个。启动压测负载后，我们可以在两个窗口对lgwr/lg00进行strace跟踪：对于不熟悉strace的朋友，我可以解释一下，-T-tt是显示每次调用前的时间戳，-s是每次调用的数据，最多显示512个字节。-p-o就不解释了，估计地球人都懂。运行几十秒后，我们就可以停止跟踪了，因为大部分行为都非常相似，没有必要运行太久。我们先看一下lg00的stracetrace信息，因为我加了-s参数，所以在trace中可以看到写入lg00trace文件的所有数据的前512字节。所以我不需要查看orcl1_lg00_15626.trc文件。上面trace的开始是lg00完成了一个logwritejob，进入Idle等待状态。然后接到写任务，开始写REDO文件。请注意异步IO的使用，所以lg00通过io_submit提交IO。我们往下看可以发现，非阻塞poll的ASMIO等待lg00，这是因为IO是发给ASM的。然后lg00产生熟悉的日志文件并行写入等待。直到接收到io_getevents，异步写入才算完成。所以lg00记录了等待完成的logfileparallelwrite。从日志中，我们可以梳理出一个大概的脉络。可以看出，Oracle中等待事件的统计时间与实际情况并不完全一致。其实数据库不需要很精确的统计等待时间，只要大致够就行。只要误差相似，实际分析问题不大。我们来看看lgwr相关时间段的tracking信息。为了方便查看，我整理了一张表格，从中可以看出整个过程。我们先来看lgwr。收到写请求后，找一个空闲的worker，发出写任务。同时发现所有worker都在忙。此时没有写入任务，于是发送一条本地IPC消息，等待ipc消息的回复。lg00收到写任务后，先异步提交IO，然后产生一系列写日志的预期等待。完成后，先通知lgwr，再通知服务员。这个算法比较合理。lg00直接向等待日志文件同步的session发送消息，而不是通过lgwr，效率会更高。和我lgwrworker非阻塞写的思路不一致。两者在面对不同的场景时，或许各有优势。至于哪个更好，不好判断，也不在我们今天的讨论范围之内。今天我们将重点关注跟踪数据库后台进程行为的方法。
