前言
决定应该赋予数据库什么样的存储和配置，已经成为一项杂乱无章的工作，这种现象我见得多了。数据库工程师一般都是数据库的专家，而对于存储配置的低层细节几乎一无所知。另外存储治理员和工程师也往往不知道数据库如何利用下层的存储，以及数据库、索引文件、记录文件，当然还有文件系统和卷治理器的需求和最佳配置又是什么。
这往往造成了存储资源利用率低，增加了整体成本，导致性能降低甚至可能无法满足你的需求，此外预算也总是很紧张，而治理上又要求有效地利用可获得的预算。本文将解决数据库治理员和存储工程师在解决架构问题而进行协作时的一些问题。
数据库与存储架构配置
组件
大部分数据库的端到端存储架构所需硬件和软件如下：
数据库
* 控制文件（Control file）
* 表空间（Table space）
* 索引文件（Index file）
* 重做日志（亦称在线日志，Redo log）
操作系统
文件系统和卷治理器（假如数据库运行在裸设备上，这一项可能没有关系）
主机总线适配器（HBA）
存储硬件
以上每一部分都拥有多个组件，具有多种特性和功能，对整体性能影响显著。
数据库
数据库应用本身具有多重特性和功能，必须加以考虑。Oracle的组件如下：
控制文件――记录数据库的物理结构，用于激活数据库
表空间――来自数据库各行各列的实际数据
索引文件／空间――Oracle中并不需要索引，不过大型数据库总会用到索引，因为在数据库中进行查找时，索引可以大幅提升查找速度
重做日志――被激活的数据库请求，答应你在数据库崩溃后进行重建并重新启动（这些日志本质上类似于文件系统日志）
因为上述组件都有不同类型的访问模式，所以每种文件类型均被存储在不同的文件系统中，并有调节选项。其它数据库也拥有相似的文件类型，需要以相似的方式考虑。
控制文件
大部分数据库都建议使用多个控制文件以确保可靠性。控制文件并不需要常写常读，不过你必须确定各文件被放置在不同的RAID集上，适用于不同的RAID控制器。
表空间
表空间一般是数据库中量最大的数据。当读取列上的大表时，表空间可以由更大的I/O请求访问。根据大小和更新频率的不同，表空间经常位于更大的数据条带化RAID-5上，以便获得较RAID-1更高的密度和提升的性能。
索引文件／空间
在许多数据库中，索引文件是被访问频率最高的数据。查找索引文件有可能需要很大的IOPS（每秒I/O操作）。另外，有时候数据库被重新索引，这在计算上非常密集，并且需要大量的I/O带宽。因为数据库和所需的查找类型不同，索引空间也许会很大，一般来说，根据传统的UNIX文件尺寸，索引文件的大小为2 GB。
重做日志
重做日志文件中存放了各种记录，你可以撤销对数据库的各种操作，这些被称为重做记录。重做记录用于循环缓冲器中，因为它一般是小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请求的大小，使之小于从表空间读或向表空间写所需的请求量。应该将设备驱动器内所设的限制更改为答应更大的请求量。当然，对每个设备驱动器和操作系统要做不同的设置，而且有意思的是，这些设置经常改变。
存储硬件
存储硬件很可能是为数据库构建系统时最重要的部分之一。你也许希望拥有许多不同的LUN，以便用于数据库中将发生的各种类型的I/O。举例来说，一般情况下你希望：
重做日志文件拥有高带宽需求（64 KB），发送到重做日志的I/O大部分是写
索引查找拥有高带宽小块随机I/O（8 KB），并且多数情况下对索引的I/O大部分是读
表空间拥有大块I/O（256 KB），并且一般情况下对表空间的I/O大部分是读
正如你所看到的，一种大小是无法满足所有需求的，因此你必须完成以下几组匹配工作：
1．RAID级别与典型的读／写访问类型
2．数据条宽度与请求大小
3．带宽需求与RAID级别和请求大小
4．缓存策略与所处理的I/O类型
这些似乎都不太轻易，不过假如你从最基本的问题着手，解决起来也不难。
重做日志
根据重做日志的大小和带宽量，你可能最初会认为需要RAID-5数据条。这其实要看情况而定，因为大多数10K RPM磁盘的数据传送速度为外磁道柱面每秒69 MB，内磁道柱面每秒39 MB，15K RPM的磁盘则更快。另外再加上RAID缓存的大小，你就无须使用RAID-5了。真正的决定因素在于：
1．带宽需求――每秒多少MB的日志数据
2．日志的大小――能够适应缓存吗？
3．你的RAID速度
你必须收集到上述三项重要信息，用各种不同的数据库和系统工具查看系统，确定重做日志的表现是否会限制数据库的性能和扩展，而假如是，那么重做日志的I/O需求又是什么。
索引文件
索引文件的结构相当简单。假如你需要速度快一些，就使用数据条带化值很小的RAID-1加上一块高性能15K磁盘。因为索引文件是小块读文件，并且经常是随机I/O，所以这是目前最快的方式。
表空间
根据表的大小及其被访问和查找的方式，RAID-1有时是更好的方法，不过其它时候RAID-5就是最佳选择了。要害是决定表空间的I/O请求大小是多少，请求的大小经常取决于数据库中的可调参数。
结论
关于不同操作系统上的各种可调数据库有许多书籍和文献供参考，下面是我读过觉得有用的几本：
《在Solaris平台上配置和调节数据库（Configuring and Tuning Databases on the Solaris Platform）》，作者：Allan N. Packer，Sun微系统公司出版社，出版商：Prentice Hall（2001年12月5日），ISBN：0130834173。
《Oacle9i性能调节方法和技巧（erformance Tuning Tips & Techniques）》，作者：Richard J. Niemiec，出版商：McGraw-Hill Osborne Media（2003年5月12日），ISBN：0072224738。
《创建一个自调节Oracle数据库：自动化Oracle9i动态SGA性能［Oracle焦点系列］（Creating a Self-Tuning Oracle Database: Automating Oracle9i Dynamic SGA Performance [Oracle In-Focus series]）》，作者：Donald K. Burleson，出版商：Rampant TechPress（2003年8月1日），ISBN：0972751327。
数据库的构建正如其它应用一样，你需要确定数据库对文件系统／卷治理器、HBA和RAID的I/O模式，同时牢记性能需求和成本问题。由于数据库很复杂，调节起来有些难度，不过现在有很多工具供你查看数据，帮助你理解潜在的I/O问题。
