如何发现问题
曾经有一个网友咨询我，说在自己的系统中看到了log file sync等待事件，问我该如何“消灭”这个等待事件，解决log file sync争用的问题。之所以提出这样的问题，还是对log file sync的产生过程不清楚导致的，log file sync不是争用产生的等待事件，而是事务在提交过程中产生的一个正常等待事件，只能去优化，而不能被消灭。也并不是所有系统的log file sync都需要优化，如果你系统的事务数非常少，而且它没有出现在系统的TOP 5等待事件里，并不建议在生产环境下去优化它，即使出现在了数据库的TOP 5里，是不是需要优化也要看情况，如果在TOP 5等待里，它占DB time%很小，一般也不需要优化它。当然如果读者是在测试环境做测试，那么都可以尝试去优化log file sync，生产环境下，不要去做过度优化，除非是发现log file sync已经使系统产生了瓶颈。读者理解了上节所描述的log file sync包含的环节后，应该可以知道诊断log file sync的思路可以从IO、CPU、系统负载等方面去入手，如果log file parallel write延迟过大，则可以从诊断IO性能去入手，我们可以根据系统日志盘的配置、系统每秒的日志量来判断是否log file parallel write的延迟过大，比如，一个系统每秒产生的日志量有3m，log file parallel write的延迟为3ms，另一个系统每秒产生的日志量有100m，log file parallel write的延迟有15ms，但是并不能说后者IO有问题，因为Lgwr需要做的工作多了，log file parallel write的延迟也就上去了，还有把日志放在PC本地盘上和放在存储上log file parallel write的延迟也是有区别的，一般存储上会更好些，具体问题要具体分析。如果系统中的log file sync过高，而log file parallel write则要小的多，那么可以从系统的负载和CPU使用率去入手，因为系统负载过大和CUP出现瓶颈后，会导致系统调用的延迟，增加log file sync的时间。
我们可以通过如下几个手段来发现log file sync和log file parallel的延迟、等待次数、等待占DB time的权重值，以及系统的负载、CPU使用率。
方式一：从awr里去发现
阅读awr报告是DBA每天必不可少的工作，我们上面提到的信息都可以从awr报告中去获取，如果你使用了企业管理器等软件，可以很方便的获取到系统的awr报告，当然也可以手工生成AWR报告，这里不过多的进行介绍。
例如我给出的这个系统每秒的事务数有8000多，每秒产生的日志量有85M之多，每个事物产生的日志量有10K，很显然这是一个事务数非常大的系统，在这种系统里，非常可能会遭遇到log file sync的瓶颈。
根据操作系统的信息，我们可以得出系统的负载情况，系统的CPU资源尚且充足，使用率只有百分之30多。
在这个提交数庞大的系统里，log file sync已经出现在了TOP 5等待的第一名，在%DB time里的权重值也已经达到了61.33，Avg wait时间为5ms。
log file parallel write的平均延迟为1ms，这个系统每秒产生的日志量接近80m，因此log file parallel write的延迟时间1ms非常理想，其实这个数据库的日志是存放在PCIe SSD介质上的，因此IO情况非常好。
通过上面AWR报告的内容，我们大体了解了系统每秒产生的日志量、每个事务的日志量、系统的负载、log file sync和log file parallel write的平均延迟时间。通过AWR报告来观察log file sync等待事件是否有问题，往往是我们第一步需要看的，虽然有些时候不能直接通过AWR报告定位到问题，但是作为发现问题的手段和工具，AWR报告都是首先应该阅读的。在我所给出的AWR报告的片段里，log file sync平均响应时间、log file parallel write的平均响应时间都比较正常，在每秒事务数8000多的系统里，这个响应时间已经非常优秀了，读者如果在自己的系统里发现这两个响应时间异常，那么就要继续通过其他工具做进一步的诊断了。例如如果发现log file parallel write响应时间非常大，那么可以从诊断IO性能入手来解决问题，如果log file sync延迟过大，而log file parallel write延迟却并不高，可以从系统的负载、CPU资源利用率情况来入手，我曾经遭遇过log file sync过高的案例，是由于内存不够导致lgwr进程被swap，进而影响了log file sync延迟过大。因此log file sync是一个复杂的、综合性的问题，需要一步步的排除才能最终定位到原因。
方式二：通过moats工具去辅助诊断
moats是一个数据库的监控工具，这个工具做的非常小巧灵便，安装它后，可以非常容易在SQLPLUS环境下使用，如果你觉得AWR报告太重，可以尝试使用moats来辅助诊断，，通过moats工具，我们可以很方便的知道当前数据库的top wait有哪些、是否有log file sync等待、log file sync占的权重值是多少，这个工具只能作为辅助的诊断工具，因为这个工具展示的数据是实时的，它不能告诉你历史的数据，也不能告诉你log file sync的延迟以及你可能关注的例如log file parallel write的延迟、系统的负载等信息。工具下载地址：http://www.oracle-developer.net/utilities.php。
方式三：通过lewis的snap_events脚本，获得系统级别等待事件的等待次数、平均等待时间。
rem execute snap_events.start_snap
rem execute snap_events.end_snap
方式四：通过tanel poder的snap脚本采样lgwr后台进程的等待事件分布以及lgwr进程相关的统计信息。
| SQL> @snapper out 1 10 1096 |
获取log file sync、log file parallel write时间分布
如果我们仅仅观察AWR报告，获取log file sync、log file parallel write某一段时间的平均等待时间，有时候是不够的，我们可能想更精细化的知道，在某段时间内，有多少次等待是在1ms以内，有多少次是在2ms以内，等等。因为平均值有时候是没有意义的，就像一个人一个脚站在冰上，一个脚站在开水里，虽然平均温度可能很舒适，但是真实的情况可能是他已经求生不能了。通过查询V$EVENT_HISTOGRAM可以告诉我们等待事件的直方图信息，对于我们诊断性能问题非常有帮助。V$EVENT_HISTOGRAM视图记录的是自实例启动以来的绝对值，绝对值对我们的帮助意义往往不大，我们经常需要的是一个特定时间段内的相对值。我们可以通过采样两次V$EVENT_HISTOGRAM的信息然后取差值来达到这一目的，这个思想跟AWR思想如出一辙。我们来看一看V$EVENT_HISTOGRAM的输出。
| SQL> select event, wait_time_milli,wait_count 2 from v$event_histogram 3 where event = 'log file parallel write'; EVENT WAIT_TIME_MILLI WAIT_COUNT ------------------------- --------------- ---------- log file parallel write 1 22677 log file parallel write 2 424 log file parallel write 4 141 log file parallel write 8 340 log file parallel write 16 1401 log file parallel write 32 812 log file parallel write 64 391 log file parallel write 128 21 log file parallel write 256 6 |
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22034023/viewspace-2153127/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/22034023/viewspace-2153127/
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
