新闻中心
联系我们
Contact us
Contact us
- 总部电话010-51727811
- 客服热线400 779 6696
- 更多联系信息
DBA与存储工程师的技术鸿沟（一）
时间：2013-03-11 09:18 来源：飞客数据恢复 作者：飞客数据恢复工程师
前言
决定应该赋予数据库什么样的存储和 配置，已经成为一项杂乱无章的工作，这种现象我见得多了。数据库工程师一般都是数据库的专家，而对于存储配置的低层细节几乎一无所知。另外存储管理员和工 程师也往往不知道数据库如何利用下层的存储，以及数据库、索引文件、记录文件，当然还有文件系统和卷管理器的需求和最佳配置又是什么。
这往往造成了存储资源利用率低，增加了整体成本，导致性能降低甚至可能无法满足你的需求，此外预算也总是很紧张，而管理上又要求有效地利用可获得的预算。本文将解决数据库管理员和存储工程师在解决架构问题而进行协作时的一些问题。
数据库与存储架构配置
组件
大部分数据库的端到端存储架构所需硬件和软件如下：
数据库
控制文件(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%，性能也超过了当时客户的要求。