DB2数据库设计的重要性不言而喻，对于I/O存储设计方面的注意事项，
可归总为以下诸点：
1）良好数据库存储设计的目标
• 事先预知I/O和系统性能
• 均衡使用可用I/O带宽和能力，避免“热点”
• 便于动态管理，例如添加新的存储
• 便于判断问题
• 通过冗余实现高可用性
2）数据库存储设计指导思想——简单
在数据库存储设计的无数选择中，简单是系统架构师和 DBA 的秘密武器。
简单，有时候就来自于对一个特定的表或表空间没有选择最优 I/O 特性，总有这么一种可能，一个富有经验的 DBA 拥有高超的存储技能并可以没有时间限制的去为一个非常重要的表或者索引配置一个存储。然而这样做的问题是，就算能达到设计的最佳性能，为了维护原始对象，这也经常造成对一个系统的管理变得更加复杂。
好的数据库存储设计的要点是，在一个动态系统上，实现所有目标应该是最初的系统设计的一部分，并应该在数据库运行过程中长期进行。这篇文档简单的最佳实践描述达到了这些目标并且几乎没有性能损失。
3）设计归总
在考虑I/O存储设计时，需要考虑的问题，首先是I/O 吞吐量，包括每秒I/O数 (IOPS)，以及每秒兆字节数 (MPS)。还有就是存储容量。最后还要考虑单独用于日志的磁盘（非共享）。基于以上考虑，我们得出如下经验法则：
1. 请确保你的数据均匀地分布在所有的物理磁盘中。你还应该确保镜像位于不同的磁盘和适配器上。如果你使用了SAN或者其他类型的存储阵列，那么你应该尝试在创建阵列时使它们具有相同的大小和类型。你还应该在创建它们时，为每个阵列使用一个LUN，然后将所有的逻辑卷分散到你的卷组中所有的物理卷。
2. 物理设备使用高速适配器连接磁盘驱动器，具有大的Cache。
但是你必须确保该总线本身不会成为一个瓶颈。要防止这种情况发生，请确保将适配器分散到多个总线。同时，不要将过多的物理磁盘或者 LUN连接到任何一个适配器，因为这样做也会对性能产生极大的影响。你配置的适配器越多越好，特别是在大量磁盘的利用率都很高的情况下。
同时，监控存储Cache的命中率，确保Cache size的设置应该与业务特点(OLTP还是OLAP业务类型)和数据页(data page)的大小设置合理。
3. 每个非DPF的数据库服务器和每个DPF分区都有专用LUN和文件系统
对于每个非DPF DB2数据库服务器和每个DPF数据库分区，专用 LUN是一个不错的选择。一个单独的文件系统应该被创建在每个这样的LUN上并且应该只被一个单独的非DPF DB2 数据库服务器或者DPF数据库分区使用。专用LUN和每个LUN的文件系统保持了存储的简单独立并有助于问题诊断。对于DPF系统，这也是非常适用的。
4. 把DB2事务日志和数据分开，数据库索引表空间容器和数据表空间容器也应该位于不同的物理磁盘。
为了最好的可用性，把事务日志和DB2数据分或表空间分开，分别放在不同的磁盘和在不同的LUN上。应该为每个DB2分区上的事务日志提供专门的磁盘。
日志磁盘数目对数据磁盘数目的比例完全取决于工作负载，一个比较好的调整标准是15%到25%的磁盘给日志，75%到85%的磁盘给数据。
5. 在文件系统（DIO/CIO）和裸设备之间权衡。
在文件系统中，操作系统为了提高读写效率，会为文件系统开辟一块 Buffer 用于读写数据的缓存。这样，数据库中的数据会被缓存两次。为了避免操作系统的这次缓存，我们可以采用裸设备作为数据文件的存储设备。裸设备，也称为裸分区 (Raw Partiton)，是一个没有被加载 (Mount) 到操作系统的文件系统上的磁盘分区，它通过字符设备驱动来访问。裸设备的 I/O 读写不由操作系统控制，而是由应用程序(如数据库)直接控制。
裸设备的优点：由于屏蔽了文件系统缓冲器而进行直接读写，从而具有更好的性能。对硬盘的直接读写就意味着取消了硬盘与文件系统的同步需求。这一点对于纯 OLTP 系统非常有用，因为在这种系统中，读写的随机性非常大以至于一旦数据被读写之后，它们在今后较长的一段时间内不会得到再次使用。
除了 OLTP，裸设备还能够从以下几个方面改善DSS(决策支持系统)应用程序的性能： 一、排序：对于 DSS 环境中大量存在的排序需求，裸设备所提供的直接写功能也非常有用，因为对临时表空间的写动作速度更快。 二、顺序访问：裸设备非常适合于顺序 I/O 动作。同样地，DSS 中常见的顺序 I/O( 表 / 索引的全表扫描 ) 使得裸设备更加适用于这种应用程序。三、直接读写，不需要经过操作系统级的缓存。节约了内存资源，在一定程度上避免了内存的竞争。四、避免了操作系统的 cache 预读功能，减少了I/O。五、采用裸设备避免了文件系统的开销。比如维护 I-node、空闲块等。
裸设备的缺点：裸设备的空间大小管理不灵活。在放置裸设备的时候，需要预先规划好裸设备上的空间使用。还应当保留一部分裸设备以应付突发情况。这也是对空间的浪费。 除此之外，裸设备还需要操作系统 root 用户干预，因为裸设备的创建、更改权限、扩展大小等都需要 root 用户完成，增加了管理的成本。
文件系统的优点：文件系统易于管理和维护，如文件的基本管理以及安全和备份等。
文件系统的缺点：性能比不上裸设备。
CIO/DIO
直接 I/O(DIO) 由于可以绕过在文件系统级别进行高速缓存，从而改进内存性能。此过程可减少 CPU 开销并使得更多的内存可用于数据库实例。并发 I/O(CIO) 具有 DIO 的优点，并且还可以消除串行化写访问权。与使用文件系统缓冲 I/O 相比，在具有大量事务处理工作负载和回滚时 CIO/DIO 机制可增大吞吐量。
DIO 和 CIO 在 HP-UX、Solaris、Linux 和 Windows 操作系统最新版本上都受支持。
关键字 NO FILE SYSTEM CACHING 和 FILE SYSTEM CACHING 是 CREATE 和 ALTER TABLESPACESQL语句的一部分，允许你指定将对每个表空间使用 DIO 还是 CIO 。当 NO FILE SYSTEM CACHING 有效时，只要可能，数据库管理器都会尝试使用“并发 I/O ”。在不支持 CIO 的情况下，将取而代之使用 DIO 。
在以往很多的经验法则中，都是建议直接使用裸设备，因为这样可以避免操作系统的层的缓存，以提高效率。
但在新版本的DB2中，直接I/O和并行I/O已经几乎完全消除了为了性能需要使用裸设备的需求。文件系统提供了比裸设备要更好地管理能力，像一个文件系统可以作为一个容器被多个表空间使用。
因此现在在两种技术中，一般比较推荐使用DIO和CIO，如果使用裸设备，对DBA的硬件系统技术和经验有比较高的要求。
1）良好数据库存储设计的目标
• 事先预知I/O和系统性能
• 均衡使用可用I/O带宽和能力，避免“热点”
• 便于动态管理，例如添加新的存储
• 便于判断问题
• 通过冗余实现高可用性
2）数据库存储设计指导思想——简单
在数据库存储设计的无数选择中，简单是系统架构师和 DBA 的秘密武器。
简单，有时候就来自于对一个特定的表或表空间没有选择最优 I/O 特性，总有这么一种可能，一个富有经验的 DBA 拥有高超的存储技能并可以没有时间限制的去为一个非常重要的表或者索引配置一个存储。然而这样做的问题是，就算能达到设计的最佳性能，为了维护原始对象，这也经常造成对一个系统的管理变得更加复杂。
好的数据库存储设计的要点是，在一个动态系统上，实现所有目标应该是最初的系统设计的一部分，并应该在数据库运行过程中长期进行。这篇文档简单的最佳实践描述达到了这些目标并且几乎没有性能损失。
3）设计归总
在考虑I/O存储设计时，需要考虑的问题，首先是I/O 吞吐量，包括每秒I/O数 (IOPS)，以及每秒兆字节数 (MPS)。还有就是存储容量。最后还要考虑单独用于日志的磁盘（非共享）。基于以上考虑，我们得出如下经验法则：
1. 请确保你的数据均匀地分布在所有的物理磁盘中。你还应该确保镜像位于不同的磁盘和适配器上。如果你使用了SAN或者其他类型的存储阵列，那么你应该尝试在创建阵列时使它们具有相同的大小和类型。你还应该在创建它们时，为每个阵列使用一个LUN，然后将所有的逻辑卷分散到你的卷组中所有的物理卷。
2. 物理设备使用高速适配器连接磁盘驱动器，具有大的Cache。
但是你必须确保该总线本身不会成为一个瓶颈。要防止这种情况发生，请确保将适配器分散到多个总线。同时，不要将过多的物理磁盘或者 LUN连接到任何一个适配器，因为这样做也会对性能产生极大的影响。你配置的适配器越多越好，特别是在大量磁盘的利用率都很高的情况下。
同时，监控存储Cache的命中率，确保Cache size的设置应该与业务特点(OLTP还是OLAP业务类型)和数据页(data page)的大小设置合理。
3. 每个非DPF的数据库服务器和每个DPF分区都有专用LUN和文件系统
对于每个非DPF DB2数据库服务器和每个DPF数据库分区，专用 LUN是一个不错的选择。一个单独的文件系统应该被创建在每个这样的LUN上并且应该只被一个单独的非DPF DB2 数据库服务器或者DPF数据库分区使用。专用LUN和每个LUN的文件系统保持了存储的简单独立并有助于问题诊断。对于DPF系统，这也是非常适用的。
4. 把DB2事务日志和数据分开，数据库索引表空间容器和数据表空间容器也应该位于不同的物理磁盘。
为了最好的可用性，把事务日志和DB2数据分或表空间分开，分别放在不同的磁盘和在不同的LUN上。应该为每个DB2分区上的事务日志提供专门的磁盘。
日志磁盘数目对数据磁盘数目的比例完全取决于工作负载，一个比较好的调整标准是15%到25%的磁盘给日志，75%到85%的磁盘给数据。
5. 在文件系统（DIO/CIO）和裸设备之间权衡。
在文件系统中，操作系统为了提高读写效率，会为文件系统开辟一块 Buffer 用于读写数据的缓存。这样，数据库中的数据会被缓存两次。为了避免操作系统的这次缓存，我们可以采用裸设备作为数据文件的存储设备。裸设备，也称为裸分区 (Raw Partiton)，是一个没有被加载 (Mount) 到操作系统的文件系统上的磁盘分区，它通过字符设备驱动来访问。裸设备的 I/O 读写不由操作系统控制，而是由应用程序(如数据库)直接控制。
裸设备的优点：由于屏蔽了文件系统缓冲器而进行直接读写，从而具有更好的性能。对硬盘的直接读写就意味着取消了硬盘与文件系统的同步需求。这一点对于纯 OLTP 系统非常有用，因为在这种系统中，读写的随机性非常大以至于一旦数据被读写之后，它们在今后较长的一段时间内不会得到再次使用。
除了 OLTP，裸设备还能够从以下几个方面改善DSS(决策支持系统)应用程序的性能： 一、排序：对于 DSS 环境中大量存在的排序需求，裸设备所提供的直接写功能也非常有用，因为对临时表空间的写动作速度更快。 二、顺序访问：裸设备非常适合于顺序 I/O 动作。同样地，DSS 中常见的顺序 I/O( 表 / 索引的全表扫描 ) 使得裸设备更加适用于这种应用程序。三、直接读写，不需要经过操作系统级的缓存。节约了内存资源，在一定程度上避免了内存的竞争。四、避免了操作系统的 cache 预读功能，减少了I/O。五、采用裸设备避免了文件系统的开销。比如维护 I-node、空闲块等。
裸设备的缺点：裸设备的空间大小管理不灵活。在放置裸设备的时候，需要预先规划好裸设备上的空间使用。还应当保留一部分裸设备以应付突发情况。这也是对空间的浪费。 除此之外，裸设备还需要操作系统 root 用户干预，因为裸设备的创建、更改权限、扩展大小等都需要 root 用户完成，增加了管理的成本。
文件系统的优点：文件系统易于管理和维护，如文件的基本管理以及安全和备份等。
文件系统的缺点：性能比不上裸设备。
CIO/DIO
直接 I/O(DIO) 由于可以绕过在文件系统级别进行高速缓存，从而改进内存性能。此过程可减少 CPU 开销并使得更多的内存可用于数据库实例。并发 I/O(CIO) 具有 DIO 的优点，并且还可以消除串行化写访问权。与使用文件系统缓冲 I/O 相比，在具有大量事务处理工作负载和回滚时 CIO/DIO 机制可增大吞吐量。
DIO 和 CIO 在 HP-UX、Solaris、Linux 和 Windows 操作系统最新版本上都受支持。
关键字 NO FILE SYSTEM CACHING 和 FILE SYSTEM CACHING 是 CREATE 和 ALTER TABLESPACESQL语句的一部分，允许你指定将对每个表空间使用 DIO 还是 CIO 。当 NO FILE SYSTEM CACHING 有效时，只要可能，数据库管理器都会尝试使用“并发 I/O ”。在不支持 CIO 的情况下，将取而代之使用 DIO 。
在以往很多的经验法则中，都是建议直接使用裸设备，因为这样可以避免操作系统的层的缓存，以提高效率。
但在新版本的DB2中，直接I/O和并行I/O已经几乎完全消除了为了性能需要使用裸设备的需求。文件系统提供了比裸设备要更好地管理能力，像一个文件系统可以作为一个容器被多个表空间使用。
因此现在在两种技术中，一般比较推荐使用DIO和CIO，如果使用裸设备，对DBA的硬件系统技术和经验有比较高的要求。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25714550/viewspace-756951/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/25714550/viewspace-756951/
787
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
