从log file sync问题的根因分析谈起：我们为什么需要了解国产数据库的一些原理性知识

发布时间：2025-11-05 04:05:41 来源：云智核 作者：域名

前几天我发文说希望国产数据库厂商能够多发布一些自己产品的问题INTERNAL的资料出来。有些朋友不大理解，因分原理数据库厂商只要多发一些故障处理的析谈需解性知方案出来不比发INTERNAL资料更香吗，比如XX数据库就很不错，起们文档里有大几十种常见故障的国产分析处置详细方案。实际上数据库故障是数据识个十分复杂的系统性问题，很难用多少种来涵盖，问题有些时候，因分原理某个组件在不同的析谈需解性知情况下也会有多种多样的故障场景。如果像网友所说的起们那种国产数据库，把客户侧常见的国产故障整理得很好，但是数据识对自己的内部原理藏得很深，那么如果遇到了文档没有涵盖的问题问题，不还是因分原理抓瞎吗？

今天我用Log file sync问题的分析让大家更加直观地了解到理解数据库的某些原理，对于故障 排查是析谈需解性知如何的重要。Log File Sync是服务器租用一个十分常见的问题，不过要分析起来也不那么容易。因为想要涵盖复杂的场景十分困难。幸运的是OCP培训教材里有好几张对于理解Log File Sync问题十分有效的示意图，下面是第一张。

图片

上面一张图列出了单机数据库等待Log File Sync时的Oracle内部处理流程。从图中可以很清楚地看出，Log File Sync等待与Log File parallel write等待关系很大。事务提交时，在等待LGWR将该事务相关的所有REDO矢量写盘时，就会产生这个等待。我们可以很清晰地了解到，如果log file parallel write的等待时间比较长时，log File sync肯定也会比较长。如果log file parallel write/log file sync>0.7，那么问题的根因大概率会落在这个问题上。    

这就是Log File sync等待最常见的问题根因-日志文件写入比较慢。日志文件写入比较慢可能是因为底层IO比较慢，也有可能是当时产生的b2b信息网日志量过大了。如果是LGWR写入过慢，那么查看LGWR的TRACE文件（如果是12.2以后的版本，还需要看lgxx日志）可能会得到一些蛛丝马迹。

图片

如果频繁出现日志写延时超过500毫秒的告警，那么很可能就是LGWR写得太慢了。如果存在偶发性的告警，则可以忽略。    

如果log file parallel write的等待时间很正常，而且与log file sync的比例很低，那么说明问题出在其他方面。比如Log buffer太小（和每秒redo量的比值可以看出是否过小），或者是因为adaptive redo log的设置问题（这个问题在 11.2中存在问题），自适应切换POST /WAIT,POLLING两种IPC机制，可能会导致log file sync变坏。P/W是传统的模式，适合于REDO并发生成量并不是很大，亿华云计算每次LGWR写的总量并不多的情况，POLLING在大并发下性能更加。Oracle会根据负载自动切换模式，从而获得更好的性能。不过有时候切换过于频繁了，很多时间都消耗在切换模式上了，反而会引发性能问题。这时候就需要关闭这种动态切换机制了。

图片

从第一张图中，我们已经把很常见的log File sync性能问题分析清楚了，不过还不足够，有时候上面的问题都不存在，但是Log File sync延时还是很大。对了，这是在RAC环境中。如果我们不了解第二章图，那么我们对Log file sync问题的认知是存在瑕疵的。因为在RAC环境中，还存在一个RAC集群中的commit SCN广播问题，Log File sync的时间当然也还包含这些延时。因此LMS后台进程的卡顿，集群网络通讯的延时，以及GCS方面的等待，都可能会影响log file sync。去年一个银行的朋友和我探讨是否要把他们核心系统的RAC拆成HA，因为从他们的分析发现，RAC带来的核心交易延时的增加已经超过了10%。    

图片

除此之外，在分析Log File sync问题的时候，还需要关注redo write broadcast ack count/redo write broadcast ack time这组指标。它们的值和RAC环境中Log File sync等待延时是密切相关的。

当然，Log File sync等待过大，还和很多BUG有关，这些BUG在MOS上都可以很方便地查到。这就是在使用Oracle数据库时做根因分析相对比较容易的主要原因。

我今天所表述的知识在Oracle官方文档、OCP培训教材和MOS上都可以轻松找到。而通过对这些INTERNAL知识的学习，我们可以十分准确地将某个问题可能的根因都分析得清清楚楚，哪怕遇到了一些十分诡异和古怪的事情的时候，也能够轻松地应对。

对于运维数据库这样的复杂IT系统时，最大的恐惧来自于未知。对于原理的一无所知，是运维中最为可怕的事情。所以我还是希望国产数据库原厂大佬们，哪怕你们再忙，也抽出点空来，多写一写Internal的东西，并且把它们公开发布出来。如果你们确实没有空，也没关系，可以把一些技术资料交给一些社区和第三方的专家，让他们帮你们写文章传播知识，我想还是有不少这样的热心群众愿意干这种事情的。

相关文章