前几天我发文说希望国产数据库厂商能够多发布一些自己产品的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比较慢，也有可能是当时产生的日志量过大了。如果是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的东西，并且把它们公开发布出来。如果你们确实没有空，也没关系，可以把一些技术资料交给一些社区和第三方的专家，让他们帮你们写文章传播知识，我想还是有不少这样的热心群众愿意干这种事情的。
