oracle redo与undo_笔记6:日志竞争

日志竞争

如果你遭遇到日志竞争，可能会看到对“日志文件同步”事件的等待时间相当长，另外Statspack报告的“日志文件并行写”事件中写次数(写I/O数)可能很大。如果观察到这种情况，就说明你遇到了重做日志的竞争;重做日志写得不够快。发生这种情况可能有许多原因。其中一个应用原因(所谓应用原因是指DBA无法修正这个问题，而必须由开发人员解决)是：提交得太过频繁，例如在重复执行INSERT的循环中反复提交。假设你的所有事务都有适当的大小(完全遵从业务规则的要求，而没有过于频繁地提交)，但还是看到了这种日志文件等待，这就有其他原因了。下面是其中最常见的原因：

.redo放在一个慢速设备上：磁盘表现不佳。该购买速度更快的磁盘了。

.redo与其他频繁访问的文件放在同一个设备上。redo设计为要采用顺序写，而且要放在专用的设备上。如果系统的其他组件(甚至其他Oracle组件)试图与LGWR同时读写这个设备，你就会遭遇某种程度的竞争。在此，只要有可能，你就会希望确保LGWR拥有这些设备的独占访问权限。

.以缓冲方式装载日志设备。你在使用一个"cooked"文件系统(而不是RAW磁盘)。操作系统在缓冲数据，而数据库也在缓冲数据(重做日志缓冲区)。这种双缓冲会让速度慢下来。如果可能，应该以一种“直接”方式来装载设备。

.redo采用了一种慢速技术，如RAID5。通常，RAID5很适合读，但是用于写时表现则很差。

只要有可能，实际上你会希望至少有5个专用设备来记录日志，最好还有第6个设备来镜像归档日志。如果能留出4块你能找到的最小、最快的磁盘，再有一个或两个磁盘，就可以很好地促进LGWR和ARCH的工作。安排这些磁盘时，可以把它们分为3组。

将重做日志组(包括成员A和B)放在磁盘1和磁盘3上。把重做日志组2(包括成员C和D)放在磁盘2和磁盘4上。如果还有组3、4等，将分别放在相应的奇数和偶数磁盘组上。这样做的作用是，数据库当前使用组1时，LGWR会同时写至磁盘1和3。这一组填满时，LGWR会转向磁盘2和4。等这一组再填满时，LGWR会回到磁盘1和3。与此同时，ARCH会处理完整的在线重做日志，并将其写至磁盘5和6(即大磁盘)。最终的效果是，不论是ARCH还是LGWR都不会读正在由别人写的磁盘，也不会写正在由别人读的磁盘，所以在此没有竞争。

本文来源 我爱IT技术网 http://www.52ij.com/jishu/5267.html 转载请保留链接。