在极高负荷情况下oracle redolog的配置建议

在oracle数据库的现有体系结构下，redolog承担了很大的压力。这是因为所有提交给数据库的交易都需要在commite确认前通过LGWR进程将相关信息写入redolog，而一个oracle实例只有一个LGWR进程，并且在UNIX系统上该进程是一个单线程程序，所以只能运行在一个内核上。在早期的主机系统上这个问题并不严重，但是随着多内核/多线程技术的发展-目前已经有了可以支持128个内核/256个线程的主机，而且支持更多内核和线程的主机即将出现，这个问题将表现得更加严重。
你想象一下如下场景，就可以感受到LGWR进程的处境：
有一个水池（redolog），只有一个人(LGWR)可以把水桶(transsion)里的水(transsion data)倒进去，这个人的边上站了127个人(server processor)不停的争相把手中的水桶(transsion)交到他的手中。
虽然我们很同情这个倒霉的老兄，可是由于oracle这个黑心的老板不愿意给它加派人手，我们也只好想想其它办法来加快他的工作速度了，比如强健一下他的体魄或者改造一下水池结构，让他工作起来轻松一点。
本文就是讨论如何让LGWR进程工作起来更有效率。
由于目前的主机不支持不同型号的CPU混用，所以给他吃独食（用高性能CPU运行该进程）是不可能了。但是我们可以让操作系统的进程调度程序给它开小灶，让它的运行优先级比其它oracle进程高，或者干脆把它设为实时进程，让他尽量不受操作系统进程调度的影响，尽可能多地占用CPU时间，从而达到让它多干活的目的。
那么如何改造水池（也就是redolog文件）呢？其实很简单，就是把它放到最快的存储设备上就行了。
内存毫无疑问是整个计算机系统中我们可以设置的最快存储设备，通过memory FS或者ramdisk软件，我们就可以在系统的内存空间中分出一部分来存储redolog文件。这个办法乍看起来确实不错，我们所需要付出的就是多买点内存。可是仔细想想，就会觉得有问题了。为什么呢？万一主机或主机上的软件（如:操作系统/数据库/应用）出现问题导致系统crash,oracle数据的完整性就没法保证了。所以我建议，除非你的系统是拿来演示系统性能的-如TPCC测试，就不要使用这个方法。
另外一个选择的可靠性就强多了，速度也很不错，可惜就是一个字-贵！好在支撑如此庞大和繁忙的业务系统的用户肯定不缺钱，所以应该问题不大。废话说了很多，答案到底是什么？cache LUN!目前市场上有一些厂商（如惠普/HDS）的最高档磁盘阵列支持在它的内部cache中划一部分出来存储一些对速度要求极高的数据，这部分的CACHE在主机看来和普通磁盘空间没有区别，可是由于这些数据是存在磁盘阵列的cache里，不需要写入物理硬盘，所以性能奇快。至于数据的安全性，由于高端存储都有专门的电源设计用来保证即使外部电源断电，CACHE中的数据也不会丢失，加上这些存储的控制软件可靠性极高，基本上不存在软件crash的可能性，所以应该可以放心。
如果很不幸，你的老板是既要马儿跑又要马儿不吃草的主，不愿意出钱使用cache LUN，那就只能尽量使用最好的存储设备，然后研究它的手册，把这个存储的每一滴血都榨出来。一个需要注意的事项是存储redolog的设备尽量不要与存储数据库其它文件的设备相互干扰。如果可能，最好把redolog和其它文件放在不同的存储设备上。
下面我们讨论几个在晚上经常问到的问到的问题：
1.我们应该使用裸设备还是文件系统？
如果只从性能最佳角度考虑，当然是裸设备，因为它会带来5~20%的性能提高。当然，文件系统的管理要比裸设备容易得多。
2.我想使用文件系统，但是又想尽可能的提高性能，该怎么办？
我的第一推荐是用veritas JFS软件的quick IO功能，第二个推荐就是仔细的调整文件系统的相关参数，尽可能的提高性能（详见我的另一篇文章《如何优化ORACLE redolog使用的文件系统性能》）