导读:对于一个应用程序的性能来说,其中数据库的性能是一个重要因素。由于应用程序及其相关的数据总会随着时间的推移而发生变化,因此必须不断地对数据库进行调优从而使其保持最佳水准。然而,花在调优上的努力应该在一个合理的范围之内。调优应该有一个度,超过了这个度的一切努力只能产生负面影响。如果应用程序的性能还不能令人满意,那么就应该考虑其他的变通办法,比如将该应用程序移到更快的平台上。下文就以讲解DB2数据库初始调优和设计方面为例为大家讲解数据库的调优。
本文中提到的命令和语法是基于 DB2 UDB V7 的,如果您使用的是 DB2 UDB V8,可能会稍有差异。
数据库设计方面的考虑
数据库调优始于设计阶段。假设硬件的选择是基于其他方面的考虑的,那么第一个要决定的就是存储架构。DB2 所使用的驱动器越多、越快,则潜在的性能将越好。对于表空间(tablespaces )和其他对象(日志,备份文件,等等)的位置应该小心仔细地加以规划。尤其重要的是,要尽量保证日志和备份处在不同的驱动器上,这样做不但是为了性能,也是为了便于恢复。
表空间设计是整个数据库设计中的一个重要部分。通过创建不止一个的用户表空间可以增强性能。在下面三种情况下,使用多个表空间就很有用:
控制 I/O,如果这些表空间可以位于不同的驱动器上的话。
使用不同的页面大小(pagesize)。
控制缓冲池。
在大多数情况下,隔离的表空间是为索引和大型对象而创建的。以相同的页面大小创建多于一个的表空间并没有什么好处。
比起系统管理的表空间来,数据库管理(Database-managed)的表空间(尤其是在原始设备上)能够提供更好的性能。在决定页面大小时要记住,DB2 在一页上最多只能放 255 行,剩余的空间将不被使用。例如,如果平均行长度是 50 字节,那么一页最多使用的空间是 50*255=12750 字节。如果将该表放在页面大小为 16K 或者 32K 的表空间中,那么有些页就会被浪费。反之,如果有些表有更长的行,或者有很多的列,(具体的限制参见 SQL 参考手册中 CREATE TABLE 语句),那么页面大小就需要大于 4K。如果要以一种连续的方式(例如,群集表)来访问数据,那么采用更大的页面大小可以获得更好的性能,相反,如果对数据的访问采用的是随机方式,那么最好使用尽可能小的页面大小。
每个表空间都与具有相同页面大小的一个缓冲池相关联(一个缓冲池可以与不止一个的表空间相关联)。在使用多个缓冲池的时候要谨慎。由于可用的存储是有限的,为某个缓冲池分配过多的空间势必减少其他缓冲池的宽度,从而导致整体性能的降低。缓冲池调优最好是在检测数据库性能和基准的基础上进行。DB2 善于动态地管理可用空间,因此,在大多数情况下使用最少数量的缓冲池可以得到较好的性能。
长期以来,表设计的重要性就在于标准化。无冗余数据占据着最少的空间,并且具有最好的完整性。然而,无冗余数据并不能提供最好的性能。为了消除一点点的冗余,需要创建额外的表,这使得查询时需要额外地结合这额外创建的表,从而增加查询的复杂性。在平衡这两方面的需求时,需要有正确的判断。通常,通过生成冗余数据可以增加性能,但是这要采取一种受约束的方式,即冗余数据所采取的形式必须是索引和汇总表。如果要经常访问汇总数据,那么后者可以明显增加性能。对刷新频率的评估应该以信息需要保持的新鲜程度为依据。
索引是性能调优中最重要的方面之一。通常,对表的访问都是基于一些标准的。根据组成这些标准的一些列构建索引,可以动态地减少查询相关的开销。对于在线维护的不稳定的表应该创建少量的索引(一个或两个),而对于大型的历史性的表,由于需要通过多种方式进行查询,则需要创建很多的索引。一条索引中的列数应该尽量地少,除非很多查询都可以通过一个“index only”搜索来完成。为了这个目的, INCLUDE 选项允许将其他字段附加到索引上,其开销则小于完全索引方式。可以选择一个表的某一索引作为群集索引,或者在 REORGANIZE 命令中指定该索引。表数据将保持由该索引指定的顺序。当大量的查询基于该索引访问大量的行时,这种做法很有用。索引通常被放在它们自己的表空间中,拥有它们自己的缓冲池,以防止数据页数量很多时会将索引页挤出。