DB2性能调整

学习收起

辛苦了，写得很好收起

数据库目录和文件

当创建一个数据库时，关于该数据库的信息（包括缺省信息）会存储在目录层次结构中。

此分层目录结构的创建位置取决于您在 CREATE DATABASE 命令中提供的信息。如果在创建数据库时未指定目录路径或驱动器的位置，那么将使用缺省位置。建议您明确指出希望在何处创建数据库。

在 CREATE DATABASE 命令中指定为数据库路径的目录中，将创建一个使用实例名的子目录。这个子目录确保在同一目录下的不同实例中创建的数据库不会使用相同的路径。在实例名子目录下面，将创建一个名为 NODE0000 的子目录。这个子目录可以区分逻辑分区数据库环境中的数据库分区。在节点名目录下面，将创建一个名为 SQL00001 的子目录。此子目录的名称使用了数据库标记并表示正在创建的数据库。SQL00001 包含与创建的第一个数据库以及随后创建的具有更高编号（SQL00002 等）的数据库相关联的对象。这些子目录可以区分在 CREATE DATABASE 命令中指定的目录下的实例中创建的数据库。

显示的目录结构为如下所示：your_database_path⁄your_instance⁄NODE0000⁄SQL00001⁄。

数据库目录中包含下列作为 CREATE DATABASE 命令的一部分进行创建的文件。 SQLBP.1 和 SQLBP.2 文件中都包含缓冲池信息。这两个文件互为副本以实现备份。 SQLSPCS.1 和 SQLSPCS.2 文件中都包含表空间信息。这两个文件互为副本以实现备份。 SQLSGF.1 和 SQLSGF.2 文件中都包含与数据库的自动存储器相关的存储路径信息。这两个文件互为副本以实现备份。 SQLDBCONF 文件中包含数据库配置信息。切勿编辑此文件。 注： SQLDBCON 文件用于先前发行版，它包含可以在 SQLDBCONF 被破坏时使用的类似信息。
要更改配置参数，请使用 UPDATE DATABASE CONFIGURATION 和 RESET DATABASE CONFIGURATION 命令。 DB2RHIST.ASC 历史记录文件及其备份 DB2RHIST.BAK 中包含关于备份、复原、表装入、表重组、表空间改变和其他数据库更改的历史记录信息。

DB2TSCHG.HIS 文件中包含日志文件级别的表空间更改的历史记录。对于每个日志文件，DB2TSCHG.HIS 中包含有助于确定日志文件影响哪些表空间的信息。表空间恢复使用此文件中的信息来确定在进行表空间恢复期间要处理哪些日志文件。可以在文本编辑器中检查这两个历史记录文件中的内容。

日志控制文件 SQLOGCTL.LFH.1 及其镜像副本 SQLOGCTL.LFH.2 和 SQLOGMIR.LFH 中包含有关活动日志的信息。

恢复处理过程使用这些文件中的信息来确定要在日志中后退多远来开始恢复。SQLOGDIR 子目录中包含实际的日志文件。

注： 您应确保不要将日志子目录映射到用于存储数据的磁盘。这样，在磁盘发生问题时，只会影响到数据或日志，而不会同时影响这两者。由于日志文件与数据库容器不会争用同一磁盘磁头的移动，因此这可提供很多性能方面的好处。要更改日志子目录的位置，请更改 newlogpath 数据库配置参数。
SQLINSLK 文件用于确保一个数据库只能由数据库管理器的一个实例使用。

在创建数据库的同时，还创建了详细死锁事件监视器。详细死锁事件监视器文件存储在目录节点的数据库目录中。当事件监视器达到它要输出的最大文件数时，它将取消激活，并且将把一条消息写入通知日志中。这样可防止事件监视器消耗过多的磁盘空间。除去不再需要的输出文件将允许在下一次数据库激活时再次激活事件监视器。

非自动存储器数据库中的 SMS 数据库目录的其他信息在非自动存储器数据库中，SQLT* 子目录包含运作数据库所需的缺省“系统管理的空间”（SMS）表空间。将创建三个缺省表空间： SQLT0000.0 子目录中包含带有系统目录表的目录表空间。 SQLT0001.0 子目录中包含缺省临时表空间。 SQLT0002.0 子目录中包含缺省用户数据表空间。

每个子目录或容器中都会创建一个名为 SQLTAG.NAM 的文件。这个文件可以标记正在使用中的子目录，因此在以后创建其他表空间时，不会尝试使用这些子目录。

此外，名为 SQL*.DAT 的文件中还存储有关子目录或容器包含的每个表的信息。星号（*）将被唯一的一组数字取代，用来识别每个表。对于每个 SQL*.DAT 文件，可能有一个或多个下列文件，这取决于表类型、表的重组状态或者表是否存在索引、LOB 或 LONG 字段： SQL*.BKM（如果它是一个 MDC 表，那么它包含块分配信息） SQL*.LF（包含 LONG VARCHAR 或 LONG VARGRAPHIC 数据） SQL*.LB（包含 BLOB、CLOB 或 DBCLOB 数据） SQL*.XDA（包含 XML 数据） SQL*.LBA（包含有关 SQL*.LB 文件的分配和可用空间信息） SQL*.INX（包含索引表数据） SQL*.IN1（包含索引表数据） SQL*.DTR（包含用于重组 SQL*.DAT 文件的临时数据） SQL*.LFR（包含用于重组 SQL*.LF 文件的临时数据） SQL*.RLB（包含用于重组 SQL*.LB 文件的临时数据） SQL*.RBA（包含用于重组 SQL*.LBA 文件的临时数据）注： 继续支持 LONG VARCHAR 和 LONG VARGRAPHIC 数据类型，但不推荐使用这两种类型，将来的发行版中可能会将其除去。



数据库配置文件
为每个数据库创建数据库配置文件。在版本 8.2 之前，此文件称为 SQLDBCON，而在版本 8.2 和更高版本中则称为 SQLDBCONF。系统已为您创建此文件。 节点目录
数据库管理器在编目第一个数据库分区时会创建节点目录。 本地数据库目录
本地数据库目录文件存在于定义了数据库的每条路径（或 Windows® 操作系统的“驱动器”）中。对于可从该位置访问的每个数据库，此目录中都包含一个相应的条目。 系统数据库目录
对于数据库管理器的每个实例，都存在一个系统数据库目录文件，该文件对于针对此实例编目的每个数据库都包含一个条目。 创建节点配置文件
如果数据库要在分区数据库环境中运行，那么必须创建一个名为 db2nodes.cfg 的节点配置文件。更改节点和数据库配置文件
要更新数据库配置文件，请运行带有适当选项的 AUTOCONFIGURE 命令。
  数据库恢复日志
数据库恢复日志保存对一个数据库所做的所有更改（包括新表的添加或对现有表的更新）的记录。收起

磁盘存储器性能因素

构成系统的硬件可能会影响系统的性能。作为硬件影响性能的示例，考虑一些与磁盘存储器相关的蕴含内容。

磁盘存储器管理的四个方面影响性能：

存储器的划分

如何在索引和数据之间以及表空间之间划分有限的存储器容量，在很大程度上决定了每一种资源在不同情况下的运行方式。

浪费的存储器

浪费的存储器本身可能不影响使用它的系统的性能，但浪费的存储器是一种可用于在别处改善性能的资源。

磁盘 I/O 的分布

如何良好地平衡几个磁盘存储设备和控制器上对磁盘 I/O 的需求，会影响数据库管理器从磁盘中检索信息的速度。

缺乏可用存储器

达到可用存储器限制后，可能会降低整体性能。

收起

死锁

当两个应用程序彼此锁定对方所需的数据时就发生了死锁，这将导致两个应用程序都无法继续执行的情形。

例如，在下图中，有两个应用程序正在同时运行：应用程序 A 和应用程序 B。应用程序 A 的第一个步骤是更新表 1 的第一行，第二个步骤是更新表 2 的第二行。应用程序 B 首先更新表 2 的第二行，然后更新表 1 的第一行。在某个时间点 T1，应用程序 A 正在执行它的第一个步骤，锁定表 1 的第一行以更新此行。同时，应用程序 B 锁定表 2 的第二行以进行更新。在 T2，应用程序 A 尝试执行下一个步骤并请求锁定表 2 中的第二行以便进行更新。但是，同时应用程序 B 正在尝试锁定并更新表 1 中的第一行。由于应用程序 A 要等到它完成表 2 中第二行的更新后才释放对表 1 的第一行的锁定，而应用程序 B 要等待它锁定并更新表 1 的第一行后才释放对表 2 的第二行的锁定，这样就产生了死锁。应用程序会永远等待下去，直到“另一个”应用程序释放挂起数据上的锁定为止。

图 1. 应用程序之间的死锁

因为应用程序不会自动释放它们所需的数据的锁定，死锁检测器过程是中断死锁并允许应用程序进程继续所必需的。顾名思义，死锁检测器监视关于等待锁定的代理程序的信息，并在 dlchktime 配置参数所指定的时间间隔苏醒。

如果它发现死锁，那么死锁检测器任意选择一个已死锁的进程作为牺牲进程来回滚。牺牲进程被唤醒，并将 SQLCODE -911（SQLSTATE 40001）返回到调用应用程序，原因码为 2。数据库管理器自动回滚所选进程中未落实的事务。当回滚完成时，释放属于牺牲进程的锁定，而该死锁涉及的其他进程可以继续进行。

要确保良好的性能，为死锁检测器选择适当的时间间隔。过短的时间间隔导致不必要的开销，而太长的时间间隔使死锁将进程延迟一段不可接受的时间。例如，5 分钟的唤醒时间间隔使死锁几乎存在 5 分钟，这对于短事务处理来说看起来可是长时间。在解决死锁时的可能延迟与检测它们的开销两者之间进行平衡非常重要。

注： 在分区数据库环境中，dlchktime 配置参数时间间隔仅在目录节点上适用。如果在分区数据库环境中检测到大量的死锁，增大 dlchktime 参数的值以解决锁定等待和通信等待。 在分区数据库中，每个数据库分区将锁定图发送到包含系统目录视图的数据库分区。在此数据库分区上进行全局死锁检测。
当构造带有多个访问数据库的独立进程的应用程序以致很可能产生死锁时，出现另一个问题。例如，在一个应用程序中的数个进程访问同一个表，对该表进行读取及写入操作。如果这些进程执行只读 SQL 和 XQuery 查询，然后再对同一表执行 SQL 更新，那么由于各个进程间对同一数据潜在的争用使得死锁的机会增大。例如，如果两个进程读该表，然后更新该表，那么进程 A 试图获得对行的 X 锁定，而进程 B 对该行具有 S 锁定。为了避免发生这种死锁，访问具有修改意向的数据的应用程序应该执行下列其中一项操作： 执行选择操作时使用 FOR UPDATE OF 子句。此子句确保当进程 A 试图读取该数据时进行 U 锁定。将禁用行分块。 执行查询时使用 WITH RR USE AND KEEP UPDATE LOCKS 子句或 WITH RS USE AND KEEP UPDATE LOCKS 子句。任一子句都确保当进程 A 试图读取该数据时进行 U 锁定，并且允许行分块。

在创建数据库的同时，会创建详细死锁事件监视器。同其他监视器一样，这个事件监视器将造成一些开销。

要限制此事件监视器消耗的磁盘空间量，当它达到其输出文件的最大数目时，该事件监视器就取消激活，并且会有一条消息写入管理通知日志。将不再需要的输出文件除去即可在下次激活数据库时重新激活事件监视器。

如果不需要详细死锁事件监视器，那么可使用以下命令删除事件监视器：

   DROP EVENT MONITOR db2detaildeadlock

在应用程序访问昵称的联合系统环境中，由于数据源处发生死锁而可能无法获取应用程序请求的数据。当发生这种情况时，DB2® 依靠数据源的死锁处理工具。如果在多个数据源之间发生死锁，那么 DB2 依靠数据源超时机制解开死锁。

要记录有关死锁的更多信息，将数据库管理器配置参数 diaglevel 设置为 4。记录的信息包括已锁定的对象、锁定方式以及挂起有锁定的应用程序。还可能会记录当前动态 SQL 和 XQuery 语句或静态程序包名称。仅在 diaglevel 4 记录动态 SQL 和 XQuery 语句。

缺省死锁事件监视器

在创建数据库时，缺省情况下将创建并激活一个称为 DB2DETAILDEADLOCK 的死锁事件监视器。激活数据库时，会自动启动该死锁事件监视器。当此监视器处于活动状态时，首次发生死锁时就会收集诊断信息，并允许调查发生死锁的原因，而不需要再现当时的情况。信息将写入目标输出文件。

要限制此事件监视器消耗的磁盘空间量，当它达到其输出文件的最大数目时，该事件监视器就取消激活，并且会有一条消息写入管理通知日志。将不再需要的输出文件除去即可在下次激活数据库时重新激活事件监视器。

如果不想负担与详细死锁事件监视器相关联的开销，那么应该首先取消激活该事件监视器，然后使用下列命令删除该事件监视器：db2 set event monitor db2detaildeadlock state 0db2 drop event monitor db2detaildeadlock但是，如果要在发生死锁时收集诊断信息，那么应该保留此监视器。收起

DB2 进程技术模型

DB2® 进程技术模型的知识可以帮助您确定问题的性质，因为它会帮助您理解数据库管理器及与其相关联的组件如何交互作用。

所有 DB2 数据库服务器使用的进程技术模型使数据库服务器与客户机以及本地应用程序之间的通信更加容易。它还确保数据库应用程序独立于如数据库控制块和关键数据库文件之类的资源。

DB2 数据库服务器必须执行各种不同的任务，例如，处理数据库应用程序请求或确保日志记录已写入磁盘。通常，每项任务都由一个独立的引擎可调度单元（EDU）执行。在先前发行版中，Linux® 和 UNIX® 环境中的大多数 EDU 是使用独立的进程实现的，而 Windows® 中的大多数 EDU 是使用主 DB2 数据库服务器进程内的操作系统线程实现的。从版本 9.5 开始，Linux 和 UNIX 环境中的 DB2 数据库服务器现在也是线程化的，因此，目前 UNIX 和 Windows 上的 EDU 都是使用操作系统线程实现的。

在 DB2 数据库服务器中使用多线程体系结构有很多优点。由于同一进程内的所有线程可以共享一些操作系统资源，因此，新线程需要的内存和操作系统资源比进程要少。此外，在某些平台上，线程的上下文切换时间的成本比进程要低，这样可提高性能。但是，在所有平台上使用线程模型最重要的优点是使得更容易配置 DB2 数据库服务器，这是因为这样更容易根据需要分配较多 EDU，并且可以动态分配多个 EDU 要共享的内存（在基于进程的模型中，一个 EDU 看不到从另一个 EDU 分配的内存）。请参阅『简化的内存配置』和『代理程序和进程技术模型配置』章节，以了解有关这些增强功能的更多详细信息。

在先前发行版中，在 Linux 和 UNIX 系统上，ps 系统命令或 db2_local_ps 命令可用来列示所有活动的 DB2 EDU。从版本 9.5 开始，这些命令不再列示 db2sysc 进程内的任何 EDU 线程。作为一种替代方法，现在可使用带有 -edus 选项的 db2pd 命令来列示所有活动的 EDU 线程。此命令可用于 UNIX 和 Windows 系统。

对于正在访问的每个数据库，启动各种 EDU 以处理各种数据库任务，例如，预取、通信和日志记录。数据库代理程序是一类特殊的 EDU，创建它们是为了处理数据库的应用程序请求。

每个客户机应用程序连接都有一个协调代理程序在数据库上运行。协调代理程序代表应用程序工作，并根据需要使用专用内存、进程间通信（IPC）或远程通信协议与其他代理程序通信。

DB2 体系结构提供一个防火墙，以便应用程序在不同于 DB2 的地址空间中运行。防火墙将数据库和数据库管理器与应用程序、存储过程和用户定义的函数（UDF）隔开。防火墙维护数据库中数据的完整性，原因是它禁用应用程序编程错误覆盖数据库管理器的内部缓冲区或文件。防火墙还提高了可靠性，原因是应用程序错误不能使数据库管理器崩溃。

图 1. DB2 系统的进程技术模型

以下列表提供有关图中显示的对象的其他详细信息：

客户机程序

客户机程序以远程方式运行或作为数据库服务器在同一机器上运行。它们通过侦听器建立与数据库的首次联系。然后，会对它们指定协调代理程序（db2agent）。

侦听器客户机程序使用通信侦听器建立初始联系，侦听器是在 DB2 启动时启动的。每个已配置的通信协议都有一个侦听器，本地客户机程序使用进程间通信（IPC）侦听器（db2ipccm）。侦听器包括： db2ipccm，用于本地客户机连接 db2tcpcm，用于 TCP/IP 连接 db2tcpdm，用于 TCP/IP 发现工具请求

代理程序

会对来自客户机应用程序的所有连接请求（不管是本地的还是远程的）分配相应的协调代理程序（db2agent）。创建协调代理程序之后，它将代表应用程序执行所有数据库请求。

在启用了数据库分区功能部件（DPF）或启用了查询内并行性的环境中，协调代理程序会将数据库请求分发给子代理程序（分别为 db2agntp 和 db2agnts）。这些代理程序为应用程序执行请求。一旦创建了协调代理程序，它就会代表其应用程序处理所有数据库请求，方法是协调对数据库执行请求的子代理程序（db2agntp）。与应用程序关联但当前处于空闲状态的子代理程序用名称 db2agnta 标识。

协调代理程序可能： 连接至具有别名的数据库。例如，“db2agent (DATA1)”连接至数据库别名“DATA1”。 连接至实例。例如，“db2agent (user1)”连接至实例“user1”。

DB2 进程技术模型将实例化其他类型的代理程序以执行特定操作，如独立的协调代理程序或子协调代理程序。例如，独立的协调代理程序 db2agnti 用于运行事件监视器，而子协调代理程序 db2agnsc 用于在突然关闭后以并行方式执行数据库重新启动。

网关代理程序 (db2agentg) 是一个与远程数据库相关联的代理程序。它提供用于允许客户机访问主机数据库的间接连接。

空闲代理程序位于代理程序池中。这些代理程序可用于处理来自代表客户机程序运行的协调代理程序或来自代表现有协调代理程序运行的子代理程序的请求。在涉及大量应用程序工作负载的配置中具有大小合适的空闲代理程序池有助于提高性能，这是因为可以根据需要立即使用空闲代理程序，而不必为每个应用程序连接分配一个全新的代理程序，这涉及到创建线程以及分配并初始化内存和其他资源。从版本 9.5 开始，DB2 还可以在需要时动态管理空闲代理程序池的大小。

可将合用代理程序关联到远程数据库或本地数据库。在远程数据库上合用的代理程序称为合用网关代理程序 (db2agntgp)。在本地数据库上合用的代理程序称为合用数据库代理程序 (db2agentdp)。

db2fmp

设防方式进程。它负责在防火墙外执行受防护的存储过程和用户定义的函数。db2fmp 进程始终是独立的进程，但可能是多线程的，这取决于它执行的例程的类型。

db2vend

这是代表 EDU 执行供应商代码的进程，例如，执行用户出口程序以进行日志归档（仅适用于 UNIX）。

数据库 EDU

以下列表包括每个数据库使用的一些重要 EDU：

db2pfchr，用于缓冲池预取程序。 db2pclnr，用于缓冲池页清除程序。 db2loggr，用于处理日志文件以处理事务处理和恢复。 db2loggw，用于将日志记录写入日志文件。 db2logts，用于跟踪哪些表空间在哪些日志文件中具有日志记录。此信息记录在数据库目录中的 DB2TSCHG.HIS 文件中。它用于加快表空间前滚恢复的向前阶段的速度。 db2dlock，用于死锁检测。在多分区数据库环境中，使用称为 db2glock 的附加线程来协调从每个分区上的 db2dlock EDU 收集的信息。db2glock 仅在目录分区上运行。 db2stmm，用于自调整内存功能。 db2taskd，用于分发后台数据库任务。这些任务由称为 db2taskp 的线程执行。 db2hadrp，HADR 主服务器线程。 db2hadrs，HADR 备用服务器线程。 db2lfr，用于处理各个日志文件的日志文件阅读器。 db2shred 处理日志页中的各个日志记录。 db2redom，用于重做主进程。在恢复期间，处理重做日志记录并将日志记录指定给重做工作程序来进行处理。 db2redow，用于重做工作程序。在恢复期间，在重做主进程请求时处理重做日志记录。 db2logmgr，用于日志管理器。管理可恢复数据库的日志文件。 db2wlmd，用于自动收集工作负载管理统计信息。 按如下所示标识事件监视器线程： db2evm%1%2 (%3)，其中 %1 可以为： g - 全局文件事件监视器 l - 本地文件事件监视器 t - 表事件监视器 gp - 全局管道事件监视器 lp - 本地管道事件监视器其中 %2 可以为： i - 协调程序 p - 不是协调程序而 %3 是事件监视器名称
按如下所示标识备份和复原线程： db2bm.%1.%2 是备份和复原缓冲区操纵程序，而 db2med.%1.%2 是备份和复原介质控制器，其中 %1 - 控制备份或复原会话的代理程序的 EDU 标识 %2 - 用于区分属于特定备份或复原会话的线程（可能有许多个）的顺序值例如：db2bm.13579.2 标识具有 EDU 标识为 13579 的 db2agent 线程控制的第二个 db2bm 线程。
数据库服务器线程和进程必须存在系统控制器（在 UNIX 上为 db2sysc，而在 Windows 上为 db2syscs.exe），数据库服务器才能工作。另外，必须启动下列线程和进程，才能执行各种任务： db2resync，扫描全局再同步列表的再同步代理进程 db2wdog，在 UNIX 和 Linux 操作系统上处理异常终止的看守程序 db2fcms，快速通信管理器发送方守护程序 db2fcmr，快速通信管理器接收方守护程序 db2pdbc，并行系统控制器，用来处理来自远程节点的并行请求（仅在分区数据库环境中使用）。 db2cart，用于访问配置为启用 USEREXIT 的数据库时的归档日志文件 db2fmtlg，用于访问配置为启用 LOGRETAIN 但禁用 USEREXIT 的数据库时的格式化日志文件 db2panic，紧急代理程序，在某特定节点上达到代理程序的限制时处理紧急请求（仅在分区数据库环境中使用） db2fmd，故障监视器守护程序 db2disp，客户机连接集中器分派器 db2acd，用于主管运行状况监视器、自动维护实用程序和管理任务调度程序的自主计算守护程序。此进程以前称为 db2hmon。 db2licc，管理已安装的 DB2 许可证 db2thcln，在 EDU 终止时重新启动资源（仅适用于 UNIX） db2aiothr，管理数据库分区的异步 I/O 请求（仅适用于 UNIX） db2alarm，在 EDU 请求的计时器到期时通知 EDU（仅适用于 UNIX） db2sysc，用于处理关键 DB2 数据库服务器事件的主系统控制器 EDU收起

DB2 体系结构和进程概述

有关 DB2® 体系结构和进程的一般信息可以帮助您了解对特定主题提供的详细信息。

下图提供了对 IBM® DB2 版本 9.5 的体系结构和进程的一般概述。

图 1. 体系结构和进程概述

在客户机端，本地和/或远程应用程序都与 DB2 客户机库链接。本地客户机使用共享内存和信号进行通信；远程客户机使用一种协议（例如，命名管道（NPIPE）或 TCP/IP）进行通信。

在服务器端，活动由引擎可调度单元（EDU）控制。在本节中的所有图形中，EDU 显示为圆圈或许多组圆圈。在版本 9.5 中，EDU 在所有平台上都是作为线程来实现的。DB2 代理程序是最常见的 EDU 类型。这些代理程序代表应用程序执行大量 SQL 和 XQuery 处理。其他常见的 EDU 是预取程序和页清除程序。

可以指定一组子代理程序来处理客户机应用程序请求。如果服务器所在的机器具有多个处理器或是分区数据库的一部分，可以指定多个子代理程序。例如，在对称多处理技术（SMP）环境中，多个 SMP 子代理程序可以利用许多处理器。

所有代理程序和子代理程序都是使用特定入池算法来管理的，该算法将 EDU 的创建和破坏减至最少。

缓冲池是数据库服务器内存的一个区域，用户表数据、索引数据和目录数据的数据库页被临时地移至该区域，并可以在该处被修改。因为从内存访问数据可以比从磁盘访问数据快得多，所以缓冲池是数据库性能的重要因素。如果应用程序需要的多个数据存在于缓冲池，那么访问数据所需的时间比在磁盘上查找要少。

缓冲池以及预取程序和页清除程序 EDU 的配置控制如何迅速访问数据以及对应用程序是如何容易地可用。

预取程序在应用程序需要数据之前从磁盘检索该数据，并将其移到缓冲池中。例如，如果没有数据预取程序，那么需要扫描大量数据的应用程序将必须等待数据从磁盘移到缓冲池中。应用程序的代理程序将异步预读取请求发送至公共预取队列。当预取程序可用时，它们使用大块或散射读取输入操作来将请求的页从磁盘读入缓冲池，从而实现那些请求。如果具有多个磁盘来存储数据库数据，那么可以将数据条带分割到多个磁盘上。条带分割数据让预取程序同时使用多个磁盘来检索数据。 页清除程序将数据从缓冲池移回到磁盘中。页清除程序是独立于应用程序代理程序的后台 EDU。它们将查找已经修改的页，并将已更改的那些页写入磁盘。页清除程序确保缓冲池中有空间供预取程序正在检索的页使用。

如果没有独立的预取程序和页清除程序 EDU，那么应用程序代理程序将必须执行缓冲池与磁盘存储器之间的所有数据读取和写入操作。

收起

性能调整限制

调整仅能够对系统的效率进行一定程度的更改。考虑要投入多少时间和费用来改善系统性能，以及要投入多少额外的时间和费用来帮助系统的用户。

例如，如果系统遇到性能瓶颈，通常可以通过调整来提高性能。如果已接近系统的性能限制，而用户数大约增加 10%，那么响应时间可能远远不止增加 10%。在这种情况下，需要确定如何调整系统来抵消降低的性能。

但是，有一个临界点，超过这个临界点再进行调整就没有用了。达到该临界点时，应考虑在环境的限制下修改您的目标和期望值。要显著提高性能，可能需要添加更多磁盘存储器、更快的 CPU、更多 CPU、更多主存储器、更快的通信链路，或者它们的组合。

收起

用户可以提供的性能信息

需要对系统进行调整的首个征兆可能是用户提出的意见。如果您没有足够的时间来设定性能目标并通过一种完备的方式来监视和调整，可了解用户的意见以改善性能。通常可提出几个简单的问题，来确定从哪里开始查找问题。例如，可以询问用户：

“响应慢”达到何种程度？是比预期的慢 10% 还是慢数十倍？ 问题是何时发现的？它是最近出现的，还是一直都存在？ 其他的用户有相同问题吗？这些用户是一两个人还是整个一组？ 如果是一组用户遇到相同问题，他们是否与同一个局域网连接？ 这些问题似乎与特定事务或应用程序相关吗？ 注意到问题出现时有任何模式吗？例如，问题是否是在一天的特定时间发生，如午餐时间，或它持续的时间是长还是短？收起

开发性能提高进程

性能提高进程是一种可重复的长期方法，用于监视和调整性能的各个方面。您和您的性能小组可以根据监视的结果调整数据库服务器的配置，并可对使用数据库服务器的应用程序进行更改。

性能监视和调整决策必须以您对使用数据的应用程序类型的了解程度和数据访问的模式为依据。不同类型的应用程序具有不同的性能要求。

将下面的性能提高流程概述作为提高性能的准则。

要开发性能提高流程：

定义性能目标。 为系统中的主要约束建立性能指示器。 开发并执行性能监视方案。 连续分析监视结果以确定哪些资源需要调整。 每次进行一项调整。

即使您认为需要调整多个资源，或数个调整选项可用于您要调整的资源，也要一次进行一项调整，从而确保所做的调整工作可以产生所需的效果。在某些点，调整数据库服务器和应用程序并不能提高性能。因此，您需要升级硬件。

实际的性能调整要求综合考虑系统资源。例如，为了提高 I/O 性能，您可能会增大缓冲池的容量，但是，缓冲池的容量越大，所需的内存也就越多，这将会降低其他方面的性能。

收起