将 DB2 UDB 应用程序迁移到分区数据库中
来源:百度文库 编辑:神马文学网 时间:2024/06/13 12:21:46
Bill Wilkins, Partner Enablement, IBM Information Management
2004 年 7 月 01 日
通过使用分区数据库,可以最大化 DB2 UDB for Linux、Unix 和 Windows 的可伸缩性(scalability)和容量(capacity)。本文讨论了什么是 DB2 分区,对使用这种功能的好处与代价作了一个概述,并且帮助您决定是否使用分区数据库(partitioned database),以及如何迁移到一个分区数据库中。本文的重点是应用程序的迁移,但是我们也会讨论对于分区数据库的设计、配置和操作等方面的考虑。
用 DB2 SQL Reference中的话说,“ 分区关系数据库是这样一种关系数据库——其中的数据是跨多个分区(又称作节点)管理的。这种跨分区的数据分离对大多数 SQL 语句的用户来说是透明的。"
不管是在一台服务器内,还是跨越多台服务器,要对一个 DB2 Enterprise Server Edition (ESE) 数据库进行分区,需要具备 Database Partitioning Feature (DPF) 功能。DPF 实际上是一种许可(license),并不要求在 ESE 上安装任何附加的产品。
在 DB2 Version 8 之前,对分区的支持是通过 DB2 Enterprise-Extended Edition (EEE) 提供的,这是一种可安装的产品。
本文基于带有 Fixpak 5 的 DB2 V8.1 for Linux、Unix and Windows。将来,在 DPF 方面还会有所改变,其中有些改变已经被宣布出来,这在后面会讨论到。
如果您对于 DPF 的基础知识还不熟悉,那么应该阅读 DB2 Information Center 关于分区的资料(请参阅参考资料);或者阅读 developerWorks 文章"对具有数据库分区功能的 DB2 UDB for Linux, UNIX and Windows Version 8 的生动介绍",最好是一起阅读。
本文假设您理解 DB2 分区数据库环境的基本架构,但还是让我们先快速浏览一下 DPF 背后的一些关键概念。
通过向 DB2 实例添加一些系统,并在每个系统上安装 DB2,就可以将该实例指定为分区的(partitioned)。添加系统的过程对于 Unix(或 Linux)和 Windows 来说各不相同,但是最后得到的都是一个文件,即 db2nodes.cfg,该文件列出了实例上的一些系统,以及每个系统上的一个或多个分区。术语 节点(node)有时候会产生混淆。这个术语通常指的是在分区实例(partitioned instance)中的一个系统,但有时候又指一个分区本身。例如,在磁盘上一个数据库的目录结构中,可以看到名为 NODE0000、NODE0001 等等的一些目录。每个这样的目录都包含一些文件,这些文件属于由后缀(0,1,等等)指定的那个分区。
当在分区实例中创建一个数据库时,在 Create Database 命令执行时所在的分区中还将创建一些编目表(catalog table),之后,那个分区就被称作 编目分区(catalog partition)。 数据库分区组(database partition group)(也称 节点组(nodegroup))实际上是一个分区列表以及一个相关的 分区图(partitioning map),分区图是一个包含 4096 个条目的数组,每个条目的值对应于数据库分区组中的某一个分区号。每个数据库分区组在任何地方都可以包括实例中从一个分区到所有分区的任意个分区。
当创建一个新数据库时,就定义了 3 个数据库分区组,其中最重要的数据库分区组是 IBMDEFAULTGROUP,该分区组包括了实例中的所有分区。用于编目表的数据库分区组是 IBMCATGROUP,该分区组只包含编目分区。用于用户数据的缺省表空间 USERSPACE1 是在 IBMDEFAULTGROUP 中创建的,因而跨越了所有分区。
如果在一个其数据库分区组只有一个分区的表空间中创建一个表,那么表中所有的行都将存储在那个分区中,就像在未分区(nonpartitioned)的数据库中一样。在本文中,我们把这样的表称作 未分区表(nonpartitioned table)。如果一个表是在其数据库分区组有多个分区的表空间中创建的,那么表中的行将分散在这些分区上。并且每一行都完整地存储在某一个分区中。我们称这种表为 分区表(partitioned table),并称使用这种表的应用程序为 分区应用程序(partitioned application)。
分区键(partitioning key)是指由一个或多个列组成的列集,每个分区表都必须定义(显式地或缺省地)一个分区键。对于这样的表,在决定将一个新行插入到哪一个分区时,可将该行的分区键值散列(hash)到分区图中的一个条目上,该条目就包含了要使用的分区号。
对于使用 DPF 情况下的数据库设计,关键的性能目标是 并置(collocation)。在并置的情况下,表的连接是在一个或多个分区中进行的,这与 定向(directed)连接或 广播(broadcast)连接不同,在后面这两种连接中,分别涉及发送到特定分区的行和发送到所有分区的行。在后面我们会对此加以讨论。
实现并置的一种方法是定义一个特殊的小表,定义时将其指定为 replicated,意即在每个分区中都将维护该表的一个完整拷贝,这样的话,在进行连接时就不必在分区间发送该表中的行。DPF 是一种 无共享(shared-nothing)环境,也就是说,分区之间不共享资源。每个分区都有其自己的数据子集,分区上的索引只能有对应于该分区中的行的条目。每个分区有自己的缓冲池、数据库配置参数设置、日志文件、管理器等等。如果将分区添加到某个已填充的分区数据库中,则可以对每个数据库分区组中的数据进行 再分配(redistribute),以使每个表分布在所有分区上的行数尽量均匀。
当一个应用程序连接到一个分区数据库时,它便被连接到某个特定的分区(可以由应用程序选择),那么这个分区就称作 协调分区(coordinator partition)。该应用程序的 协调代理(coordinator agent)运行在那个分区上,满足该应用程序的请求,在合适的时候访问数据库中的任意分区或者所有分区。
回页首
关于为什么要使用分区数据库,这里有三个主要原因:
通过利用附加系统的硬件资源,增加数据容量,或者改善吞吐量或响应时间。
为了充分利用 32-位系统上的内存。
为了规避 DB2 对未分区表(以及分区表情况下的每个分区)中字节数和行数的限制。
DPF 主要带来的是利用硬件的能力,而且特定于 DPF 的功能为这种对硬件的利用提供了支持和优化,且不必添加独特的要求更改应用程序的功能。
这是使用 DPF 的最常见的原因。有些应用程序工作负载会给本来就很大的单个系统强加太多的负担,使其不能以可接受的性能处理这些负载。例如,单个系统的 CPU 或内存容量可能不够,而即使升级该系统也仍然不够,或者升级的代价太昂贵。或者,数据量很大,以致在运行期间超出了系统的 I/O 能力,从而使得性能十分糟糕。
如果使用一个分区实例,向该实例添加新系统和分区,并对数据进行再分配以利用新的分区,那么 DB2 就可以利用额外的硬件资源。通过良好的数据库设计以及 DPF 的无共享方法,就可以大大改善性能和可伸缩性。这些改善在形式上可能是多种多样的,但是使人感兴趣的共同点就是增加了 OLTP 应用程序的吞吐量,而对响应时间也没有负面影响,并且减少了 DSS 查询的时间(或者说提供了不用增加时间就能处理更多查询的能力)。
让我们看一个例子,这是 DPF 的一个典型的最佳案例(best-case)场景。假设在系统 S1 上的一个单分区数据库中,表 T1 有 100M 行。我们运行 select count(*) from T1 ,该语句历时 N 秒钟后完成。然后,我们添加三个额外的系统(跟 S1 一样)到这个实例,每个系统上有一个分区,再将 T1 的数据库分区组在所有分区上进行再分配。如果再次运行同样的 SELECT 语句,就可以使用 4 个系统的 CPU、内存和磁盘 I/O 资源,而不是一个系统的资源,这时应该只需运行 (N * 0.25) 秒。
32-位操作系统可以为单个进程或线程提供最大 4GB 内存的虚拟可寻址能力(virtual addressability)。由于每个 DB2 代理(作为一个进程或线程运行)需要访问它所连接到的数据库的 Database Global Memory,而 Database Global Memory 受32-位寻址能力的限制,因此可使用的最大内存是大约 1GB 到 3.3GB(取决于平台)的样子。DB2 缓冲池来自 Database Global Memory,缓冲池的大小通常是决定数据库性能的一个最大的配置因素,因此,Database Global Memory 大小的限制将大大制约性能。
记住,DB2 分区本质上是独立的数据库,有其自己的内存分配,每个分区都有其自己的 Database Global Memory,因而也使用额外内存。例如,假设有一个具有 8GB 内存的系统,如果在此系统上再添加一个分区(有时候也称 逻辑分区),那么就可以利用两倍的内存,从而提供更好的性能。注意,您可以将这个原因与前面提到的那个原因相结合,作为使用 DPF 的理由:即,您可以让多个系统中的每一个系统都具有多个分区,从而更好地利用内存。
DB2 对于一个表和常规的 DMS 表空间在每个分区中可以拥有的数据量有一个限制。该限制是基于表的(或者,更确切地说是表空间的)页宽的,如下所示:
4K 页宽 8K 页宽 16K 页宽 32K 页宽
每个分区上的最大表大小(按 GB 计): 64 128 256 512
每个分区上的最大常规 DMS 表空间大小(按 GB 计): 64 128 256 512
另一个限制是每个表在每个分区上最多只能有 40 亿行,这反映了前面那个表的内容以及每页 255 行的限制。这些限制以及其他 DB2 限制都文档化在 SQL Reference的 Appendix A, "SQL Limits" 中。
回页首
现在您知道使用分区数据库的好处了,让我们讨论如何判断是否该使用分区数据库。当您读完本节,对应用程序当前和预计将来的行为进行一些分析,那么对于是否值得进行分区这个问题就相当清楚了。在某些情况下,可能需要按照进行迁移中的内容使用应用程序的一个子集进行某种原型化。
考虑以上三大原因(在为什么使用分区数据库?这一节中)中是否有任何原因在目前是成立的,或者在不久的将来成立。这要求对运行在未分区数据库上的应用程序有个基本的理解。如果应用程序当前根本不会在 DB2 上运行,那么我们建议首先让该应用程序在未分区的情况下运行,研究在使用了合理大小的数据库时该应用程序的性能。现在,让我们看看这 3 个原因。
这里的讨论是针对当前而言的,但是还应记得考虑将来可能发生的变化,例如数据量的增加。利用多个系统:
要评估这种可能性,需要研究当前的性能,并判断限制在哪里。如果系统的容量足以让 CPU、I/O 和内存使用起来良好,那么再去添加额外的系统所能带来的好处就很少。即使有些资源已经快要耗尽,那也可以通过升级系统来解决,而无需添加更多的系统。为了评估将来的需要,应理解一些关键任务的耗时的计算方法,并尽量估计数据库的扩大对这些任务的影响。随着表或数据库的增长(假设没有进行调优),有些操作(例如表扫描和数据库备份)的耗时的增长非常接近线性,并且可以认为,通过使用多个系统并通过分治(divide and conquer)的方法,几乎可以线性地减少耗时。而在另一个极端,对于像使用主键的 SELECT 语句这样的任务,表的大小的影响非常小,因此对于这些任务不大需要使用多个系统。
在单个 32-位系统上对内存的利用:
为了让 DPF 通过支持在一个 32-位系统上使用多个分区而有所帮助,必须满足一些需求: 必须有一个带有至少 2GB 内存的系统,但是通常需要 4GB 或更多内存。内存越多,DPF 就越可能有帮助。
性能必须受到 I/O 或大型排序的很大约束。通过转而使用多个分区,让各分区有其自己的缓冲池,就可以利用更多的内存。然而,如果在系统运行时 CPU 的利用率几乎是 100%,并且很少发生 I/O 等待,那么使用更多的缓冲池空间没有任何好处,因为 I/O 量的减少是微不足道的;而且,添加分区到一个 CPU 限制的(CPU-bound)系统更可能损害性能,而不是有助于性能。如果大型排序是要关心的问题,则使用多个分区有助于诸如 Create Index 之类的任务,这种任务需在每个分区中并行地排序。另一方面,有些查询并不需要在多个分区上并行排序,在这种情况下,使用单独一个(而不是多个)更大的排序堆(sort heap)展开到各分区上,就足够管用了。
即使 I/O 量很大,如果大多数 I/O 都是对 LOB 或 LONG 数据的直接读写(没有在缓冲池中进行缓冲)的话,使用多个缓冲池也不会减少 I/O。
如果日志写操作是一个瓶颈,并且分区的日志文件是写到不同的磁盘上,那么使用多个分区就有帮助。
如果转而使用 64 位的数据库服务器,就可以利用所有的系统内存。然而,这种方法在互操作性方面存在一些问题(V7 客户机不能连接到 64 位的 V8 服务器,有些第三方的软件也可能不支持 V8),因此这种方法对于某些客户环境来说可能不可行。但是,仍然可以考虑用 64 位数据库服务器作为在单个系统或一些分离的系统上使用分区数据库的替代方案。
规避限制:
对每个表运行 "runstats on table." (或 "reorgchk update statistics on table all" )。接着运行像
2004 年 7 月 01 日
通过使用分区数据库,可以最大化 DB2 UDB for Linux、Unix 和 Windows 的可伸缩性(scalability)和容量(capacity)。本文讨论了什么是 DB2 分区,对使用这种功能的好处与代价作了一个概述,并且帮助您决定是否使用分区数据库(partitioned database),以及如何迁移到一个分区数据库中。本文的重点是应用程序的迁移,但是我们也会讨论对于分区数据库的设计、配置和操作等方面的考虑。
用 DB2 SQL Reference中的话说,“ 分区关系数据库是这样一种关系数据库——其中的数据是跨多个分区(又称作节点)管理的。这种跨分区的数据分离对大多数 SQL 语句的用户来说是透明的。"
不管是在一台服务器内,还是跨越多台服务器,要对一个 DB2 Enterprise Server Edition (ESE) 数据库进行分区,需要具备 Database Partitioning Feature (DPF) 功能。DPF 实际上是一种许可(license),并不要求在 ESE 上安装任何附加的产品。
在 DB2 Version 8 之前,对分区的支持是通过 DB2 Enterprise-Extended Edition (EEE) 提供的,这是一种可安装的产品。
本文基于带有 Fixpak 5 的 DB2 V8.1 for Linux、Unix and Windows。将来,在 DPF 方面还会有所改变,其中有些改变已经被宣布出来,这在后面会讨论到。
如果您对于 DPF 的基础知识还不熟悉,那么应该阅读 DB2 Information Center 关于分区的资料(请参阅参考资料);或者阅读 developerWorks 文章"对具有数据库分区功能的 DB2 UDB for Linux, UNIX and Windows Version 8 的生动介绍",最好是一起阅读。
本文假设您理解 DB2 分区数据库环境的基本架构,但还是让我们先快速浏览一下 DPF 背后的一些关键概念。
通过向 DB2 实例添加一些系统,并在每个系统上安装 DB2,就可以将该实例指定为分区的(partitioned)。添加系统的过程对于 Unix(或 Linux)和 Windows 来说各不相同,但是最后得到的都是一个文件,即 db2nodes.cfg,该文件列出了实例上的一些系统,以及每个系统上的一个或多个分区。术语 节点(node)有时候会产生混淆。这个术语通常指的是在分区实例(partitioned instance)中的一个系统,但有时候又指一个分区本身。例如,在磁盘上一个数据库的目录结构中,可以看到名为 NODE0000、NODE0001 等等的一些目录。每个这样的目录都包含一些文件,这些文件属于由后缀(0,1,等等)指定的那个分区。
当在分区实例中创建一个数据库时,在 Create Database 命令执行时所在的分区中还将创建一些编目表(catalog table),之后,那个分区就被称作 编目分区(catalog partition)。 数据库分区组(database partition group)(也称 节点组(nodegroup))实际上是一个分区列表以及一个相关的 分区图(partitioning map),分区图是一个包含 4096 个条目的数组,每个条目的值对应于数据库分区组中的某一个分区号。每个数据库分区组在任何地方都可以包括实例中从一个分区到所有分区的任意个分区。
当创建一个新数据库时,就定义了 3 个数据库分区组,其中最重要的数据库分区组是 IBMDEFAULTGROUP,该分区组包括了实例中的所有分区。用于编目表的数据库分区组是 IBMCATGROUP,该分区组只包含编目分区。用于用户数据的缺省表空间 USERSPACE1 是在 IBMDEFAULTGROUP 中创建的,因而跨越了所有分区。
如果在一个其数据库分区组只有一个分区的表空间中创建一个表,那么表中所有的行都将存储在那个分区中,就像在未分区(nonpartitioned)的数据库中一样。在本文中,我们把这样的表称作 未分区表(nonpartitioned table)。如果一个表是在其数据库分区组有多个分区的表空间中创建的,那么表中的行将分散在这些分区上。并且每一行都完整地存储在某一个分区中。我们称这种表为 分区表(partitioned table),并称使用这种表的应用程序为 分区应用程序(partitioned application)。
分区键(partitioning key)是指由一个或多个列组成的列集,每个分区表都必须定义(显式地或缺省地)一个分区键。对于这样的表,在决定将一个新行插入到哪一个分区时,可将该行的分区键值散列(hash)到分区图中的一个条目上,该条目就包含了要使用的分区号。
对于使用 DPF 情况下的数据库设计,关键的性能目标是 并置(collocation)。在并置的情况下,表的连接是在一个或多个分区中进行的,这与 定向(directed)连接或 广播(broadcast)连接不同,在后面这两种连接中,分别涉及发送到特定分区的行和发送到所有分区的行。在后面我们会对此加以讨论。
实现并置的一种方法是定义一个特殊的小表,定义时将其指定为 replicated,意即在每个分区中都将维护该表的一个完整拷贝,这样的话,在进行连接时就不必在分区间发送该表中的行。DPF 是一种 无共享(shared-nothing)环境,也就是说,分区之间不共享资源。每个分区都有其自己的数据子集,分区上的索引只能有对应于该分区中的行的条目。每个分区有自己的缓冲池、数据库配置参数设置、日志文件、管理器等等。如果将分区添加到某个已填充的分区数据库中,则可以对每个数据库分区组中的数据进行 再分配(redistribute),以使每个表分布在所有分区上的行数尽量均匀。
当一个应用程序连接到一个分区数据库时,它便被连接到某个特定的分区(可以由应用程序选择),那么这个分区就称作 协调分区(coordinator partition)。该应用程序的 协调代理(coordinator agent)运行在那个分区上,满足该应用程序的请求,在合适的时候访问数据库中的任意分区或者所有分区。
回页首
关于为什么要使用分区数据库,这里有三个主要原因:
通过利用附加系统的硬件资源,增加数据容量,或者改善吞吐量或响应时间。
为了充分利用 32-位系统上的内存。
为了规避 DB2 对未分区表(以及分区表情况下的每个分区)中字节数和行数的限制。
DPF 主要带来的是利用硬件的能力,而且特定于 DPF 的功能为这种对硬件的利用提供了支持和优化,且不必添加独特的要求更改应用程序的功能。
这是使用 DPF 的最常见的原因。有些应用程序工作负载会给本来就很大的单个系统强加太多的负担,使其不能以可接受的性能处理这些负载。例如,单个系统的 CPU 或内存容量可能不够,而即使升级该系统也仍然不够,或者升级的代价太昂贵。或者,数据量很大,以致在运行期间超出了系统的 I/O 能力,从而使得性能十分糟糕。
如果使用一个分区实例,向该实例添加新系统和分区,并对数据进行再分配以利用新的分区,那么 DB2 就可以利用额外的硬件资源。通过良好的数据库设计以及 DPF 的无共享方法,就可以大大改善性能和可伸缩性。这些改善在形式上可能是多种多样的,但是使人感兴趣的共同点就是增加了 OLTP 应用程序的吞吐量,而对响应时间也没有负面影响,并且减少了 DSS 查询的时间(或者说提供了不用增加时间就能处理更多查询的能力)。
让我们看一个例子,这是 DPF 的一个典型的最佳案例(best-case)场景。假设在系统 S1 上的一个单分区数据库中,表 T1 有 100M 行。我们运行 select count(*) from T1 ,该语句历时 N 秒钟后完成。然后,我们添加三个额外的系统(跟 S1 一样)到这个实例,每个系统上有一个分区,再将 T1 的数据库分区组在所有分区上进行再分配。如果再次运行同样的 SELECT 语句,就可以使用 4 个系统的 CPU、内存和磁盘 I/O 资源,而不是一个系统的资源,这时应该只需运行 (N * 0.25) 秒。
32-位操作系统可以为单个进程或线程提供最大 4GB 内存的虚拟可寻址能力(virtual addressability)。由于每个 DB2 代理(作为一个进程或线程运行)需要访问它所连接到的数据库的 Database Global Memory,而 Database Global Memory 受32-位寻址能力的限制,因此可使用的最大内存是大约 1GB 到 3.3GB(取决于平台)的样子。DB2 缓冲池来自 Database Global Memory,缓冲池的大小通常是决定数据库性能的一个最大的配置因素,因此,Database Global Memory 大小的限制将大大制约性能。
记住,DB2 分区本质上是独立的数据库,有其自己的内存分配,每个分区都有其自己的 Database Global Memory,因而也使用额外内存。例如,假设有一个具有 8GB 内存的系统,如果在此系统上再添加一个分区(有时候也称 逻辑分区),那么就可以利用两倍的内存,从而提供更好的性能。注意,您可以将这个原因与前面提到的那个原因相结合,作为使用 DPF 的理由:即,您可以让多个系统中的每一个系统都具有多个分区,从而更好地利用内存。
DB2 对于一个表和常规的 DMS 表空间在每个分区中可以拥有的数据量有一个限制。该限制是基于表的(或者,更确切地说是表空间的)页宽的,如下所示:
4K 页宽 8K 页宽 16K 页宽 32K 页宽
每个分区上的最大表大小(按 GB 计): 64 128 256 512
每个分区上的最大常规 DMS 表空间大小(按 GB 计): 64 128 256 512
另一个限制是每个表在每个分区上最多只能有 40 亿行,这反映了前面那个表的内容以及每页 255 行的限制。这些限制以及其他 DB2 限制都文档化在 SQL Reference的 Appendix A, "SQL Limits" 中。
回页首
现在您知道使用分区数据库的好处了,让我们讨论如何判断是否该使用分区数据库。当您读完本节,对应用程序当前和预计将来的行为进行一些分析,那么对于是否值得进行分区这个问题就相当清楚了。在某些情况下,可能需要按照进行迁移中的内容使用应用程序的一个子集进行某种原型化。
考虑以上三大原因(在为什么使用分区数据库?这一节中)中是否有任何原因在目前是成立的,或者在不久的将来成立。这要求对运行在未分区数据库上的应用程序有个基本的理解。如果应用程序当前根本不会在 DB2 上运行,那么我们建议首先让该应用程序在未分区的情况下运行,研究在使用了合理大小的数据库时该应用程序的性能。现在,让我们看看这 3 个原因。
这里的讨论是针对当前而言的,但是还应记得考虑将来可能发生的变化,例如数据量的增加。利用多个系统:
要评估这种可能性,需要研究当前的性能,并判断限制在哪里。如果系统的容量足以让 CPU、I/O 和内存使用起来良好,那么再去添加额外的系统所能带来的好处就很少。即使有些资源已经快要耗尽,那也可以通过升级系统来解决,而无需添加更多的系统。为了评估将来的需要,应理解一些关键任务的耗时的计算方法,并尽量估计数据库的扩大对这些任务的影响。随着表或数据库的增长(假设没有进行调优),有些操作(例如表扫描和数据库备份)的耗时的增长非常接近线性,并且可以认为,通过使用多个系统并通过分治(divide and conquer)的方法,几乎可以线性地减少耗时。而在另一个极端,对于像使用主键的 SELECT 语句这样的任务,表的大小的影响非常小,因此对于这些任务不大需要使用多个系统。
在单个 32-位系统上对内存的利用:
为了让 DPF 通过支持在一个 32-位系统上使用多个分区而有所帮助,必须满足一些需求: 必须有一个带有至少 2GB 内存的系统,但是通常需要 4GB 或更多内存。内存越多,DPF 就越可能有帮助。
性能必须受到 I/O 或大型排序的很大约束。通过转而使用多个分区,让各分区有其自己的缓冲池,就可以利用更多的内存。然而,如果在系统运行时 CPU 的利用率几乎是 100%,并且很少发生 I/O 等待,那么使用更多的缓冲池空间没有任何好处,因为 I/O 量的减少是微不足道的;而且,添加分区到一个 CPU 限制的(CPU-bound)系统更可能损害性能,而不是有助于性能。如果大型排序是要关心的问题,则使用多个分区有助于诸如 Create Index 之类的任务,这种任务需在每个分区中并行地排序。另一方面,有些查询并不需要在多个分区上并行排序,在这种情况下,使用单独一个(而不是多个)更大的排序堆(sort heap)展开到各分区上,就足够管用了。
即使 I/O 量很大,如果大多数 I/O 都是对 LOB 或 LONG 数据的直接读写(没有在缓冲池中进行缓冲)的话,使用多个缓冲池也不会减少 I/O。
如果日志写操作是一个瓶颈,并且分区的日志文件是写到不同的磁盘上,那么使用多个分区就有帮助。
如果转而使用 64 位的数据库服务器,就可以利用所有的系统内存。然而,这种方法在互操作性方面存在一些问题(V7 客户机不能连接到 64 位的 V8 服务器,有些第三方的软件也可能不支持 V8),因此这种方法对于某些客户环境来说可能不可行。但是,仍然可以考虑用 64 位数据库服务器作为在单个系统或一些分离的系统上使用分区数据库的替代方案。
规避限制:
对每个表运行 "runstats on table