重做日志

重做日志文件中存放了各种记录，你可以撤销对数据库的各种操作，这些被称为重做记录。重做记录用于循环缓冲器中，因为它一般是小I/O，所以用RAID-1就不错。由于需要两个或以上的重做日志文件，通常将日志文件放在不同的RAID-1卷上。

操作系统

数据库一般都需要具备操作系统的一些特性和功能，如共享内存和标志等。另外，数据库也经常利用计算机内大量的内存，这通常由改变数据库中的可调参数来实现。

在许多操作系统中，I/O请求的大小限制在256 KB或128 KB，不能改变，所以如果必须对存储和操作系统完成更多的请求，就会影响到I/O性能。

文件系统和卷管理器

架构决策中最重要的事情之一就是为每个数据库组件确定最理想的卷管理器和文件系统设置，对于每种类型的I/O，你可能希望进行不同的设置，请考虑以下的I/O类型：

长和短的连续块

长和短的随机块

长和短的多重数据流块

所有的读

所有的写

多线程

对所有这些类型的I/O来说，只有一组设置的文件系统表现得都不好，而且我敢说对于上述任何两种类型的I/O来说，只有一组可调参数的文件系统也无法做好，也不可能通过改变参数来提升性能。

设计中要确定的两个关键因素是：

1.对于所要处理的I/O类型，什么是最好的卷管理器和文件系统

2.对于该文件系统和卷管理器，什么又是最好的可调参数

几年前我曾做过一个数据库，由于一些原因而无法进行扩展，不过我认为其中最主要的原因是RAID缓存在进行索引查找时未得到有效利用。RAID的读访问率小于20%，而且我认为大部分是不规则的连续读(先对几个请求连续读，然后随机跳过几个，又开始连续读)。

检查卷管理器后，我发现了问题所在。每个文件系统有32个LUN(逻辑单元号)，每个LUN为8 GB。文件系统上的数据条设置为32 KB，与RAID分配相符。每个索引文件是2 GB。

考虑到RAID缓存的工作方式，你必须先读两个连续块再读第三个块，这是常用的算法，因此在下一个I/O到达缓存之前，需要32 KB*32 LUN*2，即2 MB的连续读数据。

RAID缓存利用率如此低下并不奇怪。客户被告知他们有两个办法提升性能，一是为卷管理器数据条分配2 GB，这样每个索引文件均被连续分配;二是使用另一种文件系统，可以使数据进行循环而不是条带化。循环状态下，每个开放的系统请求都会被分配给另一个LUN，并且被打开的文件中所有数据也都会被分配在那个LUN上。

当我们使用循环分配方法和读缓存测试这种配置时，访问率从20%上升到80%，性能也超过了当时客户的要求。

主机总线适配器(HBA)

即使价值2,000美元的HBA也会对大型数据库的性能造成重大影响。对HBA要考虑两个地方：

1.未处理的I/O请求量

2.可以实现的最大请求量

大多数HBA在驱动器软件中将未处理的请求量默认值设置为16，这就限制了发送给RAID设备的命令数，即使拥有很多的磁盘驱动器和随机I/O，这个数值也可能无法充分利用存储资源。

许多操作系统和设备驱动器都限制了I/O请求的大小，使之小于从表空间读或向表空间写所需的请求量。应该将设备驱动器内所设的限制更改为允许更大的请求量。当然，对每个设备驱动器和操作系统要做不同的设置，而且有意思的是，这些设置常常改变。