第二章 进程管理

数据库系统要启动许多功能模块，接收、处理用户请求，将处理结果返回用户。这些功能模块协同工作，共同完成用户数据的管理和维护。了解这些功能模块的作用及相互关系，是管理员控制数据库系统运行的基础。

数据库系统有自己的进程管理和调度，不同的数据库系统其进程使用和功能划分也不尽相同。本章对数据库系统各功能模块的作用及处理方式进行了讲解，然后对常用数据库系统的进程管理进行了介绍，并就有关的配置参数进行了说明。用户可基于对这些知识的掌握，配置符合自己要求的系统运行环境。

2.1 用户请求的处理过程

在了解数据库系统各进程模块的功能之前，我们首先要明白系统有那些进程，这些进程又是如何协同处理的。这可以通过系统对用户请求的处理过程来简单说明，其处理过程可见图2-1。

客户端应用程序在能够访问数据库中的数据之前，必须要建立和数据库系统的连接，这是通过图2-1中的第1到第3步完成的。

（1）监听进程接收到来自客户端应用程序的连接请求。

（2）监听进程选定一个代理进程，将连接请求交给该代理进程处理。

（3）代理进程建立和客户端应用程序的连接。

在建立和数据库系统的连接后，用户就可以通过客户端应用程序发出处理请求。代理进程在处理前，需要优化器进程对SQL语句进行语法分析和优化处理。

（4）代理进程接收到客户端应用程序的请求，将请求交给优化器进程处理。

（5）优化器进程分析、优化SQL语句，生成最终的执行计划，返回代理进程。

代理进程开始处理请求。在处理时，要求所操作数据处于内存中。如果需要处理大批量的数据（例如：通过表扫描查询数据），异步预取进程被激活，将代理进程随后需要的数据事先读入内存，这样可以保证代理进程进一步处理数据时，这些数据已经处于内存中，避免代理进程再次的、直接的I/O处理，从而提高了请求的处理效率。

（6）代理进程发出I/O请求，将当前所需数据读入内存。

（7）异步预取进程被激活，将随后需要的数据事先读入内存。

在代理进程、异步预取进程读数据到内存中时，系统发现内存中没有空闲的、可替代的空间。也就是说，内存中的所有空间都写满了数据，这些数据已经被更新过。在代理进程、异步预取进程能够读数据到内存中之前，需要将内存中已更新的数据必须写入磁盘，以释放空间。

（8）页清除进程被激活，将内存中已更新数据写入磁盘。

数据库系统使用前写日志原则，在内存中的更新数据被写入磁盘之前，和这些更新相关的日志信息需要首先从内存写入磁盘。

（9）页清除进程发信号给日志写进程，日志写进程完成内存中日志信息到日志文件的写操作。

在日志写进程完成后，页清除进程继续处理，内存中被修改的数据写入磁盘，内存空间得到释放。

在得到可用的内存空间后，代理进程、异步预取进程将所需数据读入内存。然后代理进程开始处理数据。

在代理进程完成处理之前，死锁检测进程、检查点进程时间间隔到。

（10）死锁检测进程时间间隔到。死锁检测进程查看代理进程拥有的资源，检查是否由于资源竞争而引起多个代理进程之间的死锁。如果发现死锁，就采取相关算法，解除死锁。

（11）检查点进程时间间隔到。检查点进程阻断所有的代理进程，将内存中的日志信息、已更新的数据全部写入磁盘，在日志文件中记入检查点信息。

代理进程完成请求处理，提交事务，释放相关资源。

（12）代理进程将结果返回客户端应用程序。

以上展示了系统对一个客户端用户请求的处理过程，其目的在于说明数据库系统拥有那些进程以及它们如何工作。在实际的用户请求处理过程中，一般不会按照这个顺序执行。例如：代理进程在处理请求时，内存中已经存在要执行SQL语句的执行计划，不再需要分析、优化；所需数据已经读入内存，不需要磁盘的I/O操作；异步预取进程读数据到内存时，内存中存在满足需要的空闲空间，不需要页清除进程进行内存空间的释放；代理进程在处理过程中，死锁检查进程和检查点进程没有被激活，等等。

2.2 数据库系统的常用进程

从系统对用户请求的处理过程，我们可以看出数据库系统应该具备以下的功能模块：监听进程、代理进程、异步预取进程、页清除进程、日志写进程、检查点进程、优化器进程、死锁检测进程。对多线程的数据库系统，这些功能模块是通过线程的方式实现的。数据库管理员应当对这些功能模块的作用及处理过程有一个详细的了解，在此基础上才能够有目的的控制数据库系统的运行。

2.2.1 监听进程

监听进程不间断地运行，接收用户的连接请求，然后交由代理进程处理。

客户端应用程序要操作数据库中的数据，必须要首先建立和数据库系统的连接。数据库系统支持TCP/IP、IPX/SPX以及共享内存、流管道、命名管道等多种通讯协议，运行在远程机器上的客户端应用程序，使用TCP/IP、IPX/SPX等网络协议建立和数据库系统的连接；对于和数据库系统在同一台机器上的客户端应用程序，使用共享内存、流管道、命名管道等连接方式是比较好的选择。

在配置通讯连接时，需要为数据库系统使用的每一种协议设置唯一的连接服务端口。每一种协议的监听进程在启动后，就不间断地监视该协议的连接服务端口，检查是否有到来的用户连接请求。

在使用网络协议进行通讯时，客户端应用程序使用以下的操作过程（如图2-2所示），建立和数据库系统的连接。

（1）客户端应用程序向数据库系统已知协议的连接服务端口，发送连接请求。

（2）监听进程检查到用户的连接请求后，检查当前系统中是否有空闲的代理进程。如果没有找到空闲的代理进程，就启动一个新的代理进程，并为它分配一个未使用的服务端口。在确认了代理进程之后，用户的连接请求就交由代理进程来处理。监听进程就继续进行监听，检查是否有新的连接请求。

（3）代理进程根据监听进程传递的用户连接请求信息，向客户端发送连接确认，同时说明自己的连接服务端口。

（4）客户端应用程序在收到代理进程的连接确认后，使用代理进程的连接服务端口向代理进程发送连接确认。

通过以上的连接处理过程，客户端应用程序就和数据库系统中的一个代理进程建立了连接，就可以通过代理进程访问数据库。

2.2.2 代理进程

代理进程可以看作是客户端应用程序在数据库系统中的代理人，它接收、处理用户请求，然后将结果返回客户端。

客户端应用程序要通过代理进程访问数据库系统中的数据，首先应建立和代理进程的连接，具体的连接过程见前面的监听进程。代理进程对用户请求的处理过程，可以参看第2.1一节。

在一般情况下，代理进程和客户端应用程序一一对应。一个客户端应用程序需要一个代理进程，来处理自己的用户请求；一个代理进程只为一个客户端应用程序提供服务，接收它的服务请求。只要客户端应用程序存在，服务器端的代理进程就一直运行，并互相保持着连接。在客户端应用程序正常退出或者异常中断后，服务器上的代理进程要么被系统终止，释放系统资源；要么就处于空闲状态，可以为其它客户端应用程序提供连接、请求处理服务。

在数据库系统的并行处理环境下，一个客户端应用程序就可能对应多个代理进程。在这种情况下，接收用户请求的代理进程称为协调代理进程。协调代理进程接收到用户请求后，将任务分成多个子任务，分别交给其它的代理进程进行处理，这些代理进程称为子代理进程。子代理进程在完成处理后，将结果返回协调代理进程，由协调代理进程合并所有的处理结果，然后返回给客户端应用程序。数据库系统的这种并行处理方式，缩短了用户请求的处理时间，特别适合于决策支持系统中的大批量数据查询。对它的处理过程以及相关配置，本书不做进一步的介绍。

此外，在交互式的联机事务处理环境中，代理进程大部分时间处于空闲状态，一直在等待客户端应用程序的处理请求。因此为了提高代理进程的利用率，降低系统资源的消耗，使系统支持更多的用户连接数，可以设置数据库系统，使一个代理进程为多个客户端应用程序所共享，同时为它们提供服务。在这种共享代理进程的数据库系统设置中，客户端应用程序和代理进程之间的连接会稍有不同。

2.2.3 异步预取进程

异步预取进程负责将代理进程随后要处理的数据事先读入到内存中，避免代理进程处理时等待数据的读入，从而提高用户请求的处理速度。只有在系统需要数据的预先读取时，才会激活异步预取进程。

代理进程在处理事务时，要求被操作的数据处于内存中。如果内存中不存在所需的数据，代理进程就必须等待，直到所需数据读入内存，然后才继续处理。这种等待会严重影响用户请求的响应时间。为了降低代理进程的I/O等待，数据库系统引入了异步预取进程，预先将代理进程要处理的数据读入内存。

并不是所有的代理进程在处理时都需要进行预取。要进行事先的数据读取，需要满足以下两个条件：

（1）对大数据量进行操作

（2）系统能够预见随后要处理的数据

对一个或者多个包含很多记录的表，进行诸如：表扫描、索引扫描、排序、合并等操作，异步预取操作就不可避免。优化器在分析、优化SQL语句后，如果发现需要进行预取操作，就会激活异步预取进程。

异步预取进程对数据的读取是渐进的。如果已读入内存、还没有被使用数据的数量，达到数据库系统设定的上限后，异步预取进程就停止操作；如果低于设定的下限值后，异步预取进程又重新被激活。这种处理方式，一方面可以保证代理进程要处理的数据事先被读入内存，另一方面又可以避免太多的数据读入占用大量可用内存空间，影响到其它事务的处理。

2.2.4 页清除进程

页清除进程负责将内存缓冲区中已经被更新的数据页写入磁盘，在系统需要将这些已更新数据写入磁盘时被激活。系统通过页清除进程，使已发生的更新做永久性的保存，同时释放被占用的内存空间。

数据库系统要处理大量的事务，在事务执行完成、被提交后，已经发生更新的数据仍旧存放在内存缓冲区中，并不会立即被写入磁盘。这主要是基于以下的考虑：

（1）最近被访问的数据，很大可能会再次被访问。

（2）减少磁盘的I/O读写，提高系统性能，提高用户请求的响应速度。

然而这些脏数据又不能无限期地积累、存放在内存中，主要是因为：

（1）内存空间是有限的。新的事务处理需要使用空间，存放要处理的数据。

（2）内存中的脏数据页没有写入磁盘，就没有得到永久性的确认。一旦系统崩溃，所有这些更新将全部丢失。

因此，内存中的脏数据页在达到一定的限制后，需要写入磁盘，使这些更新得到永久确认，进而释放内存空间。这些工作就是由页清除进程完成的。页清除进程并不是一直处于活动状态，下列操作或者事件会激活页清除进程的处理：

（1）检查点操作发生时。检查点操作执行时，要将内存中所有更新写入磁盘，这时检查点进程发信号激活页清除进程，由页清除进程将内存中的所有更新写入磁盘。

（2）内存中已被更新的数据量达到系统设定的阀值。数据库系统不断监测内存中数据的更新，一旦内存中脏数据页的数量达到预先设定的阀值，就激活页清除进程，由页清除进程将内存中的更新写入磁盘。

（3）没有足够的空闲空间存放数据。代理进程在处理事务时，首先检查要处理数据是否在内存中。如果要处理数据不在内存中，就要将这些数据读入内存。这时代理进程会搜索内存空间，寻找可用的内存页。在没有找到足够可用空间的情况下，就发信号激活页清除进程，将内存中的更新写入磁盘，从而释放被占用的空间。

任何数据库系统都采取前写日志的方法，即被更新数据从内存写入磁盘之前，和这些更新有关的日志信息必须已经写入磁盘。因此，页清除进程在写已更新数据到磁盘之前，要检查相关的日志信息。如果这些日志信息仍旧存放在内存缓冲区中，就发信号、激活日志写进程，然后等待。在日志写进程完成处理后，页清除进程才会继续处理。

在有大量数据更新的系统运行环境中，可以根据需要，启动多个页清除进程，来加快数据往磁盘上的写速度。

2.2.5 日志写进程

日志写进程负责将内存缓冲区中的事务日志信息写入磁盘，在系统需要写日志信息到磁盘时被激活。

数据库系统以事务的方式操作数据库中的数据，用户请求以一个个的事务形式被提交。事务中的所有操作要么都执行，要么都不执行。事务中的任何更新操作都会产生相关的日志信息，以便于事务的回退、系统的恢复。有关事务、数据库日志的详细信息，可参看第6、7两章。

事务产生的日志信息最初存放在内存缓冲区中，然后由日志写进程写入磁盘。在数据库系统中，下列操作或者事件会激活日志写进程：

（1）事务或者一组事务被提交。

（2）检查点进程执行。

（3）页清除进程将脏数据写入磁盘，和脏数据有关的日志仍旧在内存中。

（4）内存中日志缓冲区满或者使用率达到已设定的百分比。

（5）日志文件切换。当前使用的日志文件已写满，系统开始使用下一个日志文件。

在现有的数据库系统中，日志写进程可以采用以下两种方式，执行日志信息的磁盘写操作：

（1）事务提交前必须将日志信息写入磁盘

这种方式，要求一个事务的所有操作在执行完成后，和事务相关的所有日志信息必须写入磁盘，事务才能正常完成，客户端应用程序才会收到返回信息。这种方式保证了所有已提交事务的日志信息都已经保存在可永久存储的设备上。这样，一旦系统出现故障，可以使用日志信息重做所有已经提交的事务，不会丢失事务的处理。

在交互式的联机事务处理环境中，数据库系统要同时处理很多的事务，每一个事务都必须等待其日志信息写入磁盘之后，才能提交。由于不停地对磁盘进行I/O操作，这不但影响了系统性能，而且降低了用户处理的响应时间。另外，在交互式处理环境中，事务一般比较小，产生的日志信息也较少，而内存中的数据是以页为单位向磁盘中写（UNIX平台：页尺寸为4K ；WINDOWS平台：页尺寸为2K），这样每一页中将会有很多剩余空间，从而造成磁盘存储空间的浪费。

（2）事务提交前不要求将日志信息写入磁盘

使用这种方式，一个事务在所有操作执行完成后就进行提交，客户端应用程序就会收到返回信息，和事务相关的所有日志信息仍旧存放在内存缓冲区中。数据库系统不断检查已经提交的事务数目，如果达到设定的数值，或者存放日志信息的内存空间使用率达到已设定的百分比，日志写进程就开始将日志信息写入磁盘。

这种日志处理方式，在交互式的联机事务处理环境中，避免了不停地对磁盘进行I/O操作，既提高了系统性能、用户处理的响应时间，又可以节省磁盘空间。但美中不足的是，一旦系统崩溃，存放在内存缓冲区、还没有写到磁盘中的事务日志就要丢失，从而就造成和这些日志相关、已提交事务的丢失，系统不会自动进行恢复。在这种情况下，系统维护人员必须和业务处理人员一同进行人工检查，发现并重新执行那些丢失的事务。

由于日志写进程顺序地访问磁盘，而且大多数情况下是由内存向磁盘上写入日志信息，这和数据库中其它数据的磁盘随机访问，有着明显的区别。因此将日志信息和数据库的其它数据分开存放在不同的磁盘上，避免两种访问方式之间的互相影响，将有助于提高系统的性能。这一点，对采用事务提交前必须将日志信息写入磁盘的数据库应用系统，尤其有用。

2.2.6 检查点进程

检查点进程定期执行，将内存中所有已经被更新的数据及日志信息写入磁盘，在日志文件中记录检查点信息。

数据库系统并发地为许多用户提供数据访问处理，当前被操作的数据有很大的可能还要继续被处理，因此数据被更新后，仍旧保留在内存中，并不会立即写入磁盘。

如果没有检查点操作，一旦系统由于断电等原因崩溃，数据库系统无法确切地知道那些更新已经写入磁盘，做了永久性确认；那些更新还没有写入磁盘，需要重新执行或者回退。这时数据库系统的恢复需要使用系统运行以来的所有日志文件，整个恢复过程复杂而漫长。

有了检查点进程，在执行检查点操作时，会在日志文件中写入检查点信息，给系统打上一个时间戳，表明在这一时刻，以往所有的更新得到了永久性确认。在数据库系统恢复时，只要从日志文件中最后一个检查点开始就可以了。

检查点操作将内存中所有更新写入磁盘，这些更新所对应事务有的已经提交，有的还没有完成。在数据库系统恢复时，需要根据日志记录，重新执行已经提交的事务，回退尚未完成的事务。有关系统恢复的详细信息，可以参看第8章。

系统在执行检查点操作时，所有的事务处理被暂时中止。直到检查点操作完成后，事务的处理才继续进行。因此需要仔细规划检查点进程的执行间隔，避免给数据库系统带来大的影响。

如果执行间隔设置得太小，数据库系统就可能存在以下问题：

（1）数据库系统频繁地中断用户请求处理。

（2）频繁地引起磁盘读写。由于对磁盘的读写，需要磁头的来回移动，这种机械运动导致磁盘的读写速度比内存的读写速度低几个数量级，必然要影响到系统性能。

如果执行间隔设置得太大，下列问题就需要进行考虑：

（1）检查点操作的执行时间可能很长。在执行检查点操作时，可能有大量更新需要写入磁盘，需要较长的时间。此时，系统中现有的事务可能由于中断时间过长，引起超时而中止，用户的适时响应也会受到严重的影响。

（2）一旦数据库系统崩溃，需要较长的时间进行恢复，进而影响到系统的可用性。

在现有的数据库系统中，通过系统的配置参数，来决定检查点操作的执行间隔。除此之外，数据库系统的一些特定动作，如：日志文件的切换、数据库的备份、数据库系统的正常关闭等等，也会触发检查点操作。

对检查点操作的系统配置，大体上来说，可以归结为以下两种设置方式：

（1）设置固定的时间间隔

数据库系统以固定的时间间隔，执行检查点操作。在设定的时间间隔到来后，不管内存中是否有更新的数据，检查点操作都会被执行。这种设置方式，在数据库系统中存在大量更新时，固定的时间间隔会使检查点操作的时间变长，进而可能影响到系统的正常运行。

（2）以内存中已更新数据量来决定是否激活检查点操作

数据库系统不断地检查内存中已经发生的更新，当已更新的数据量达到预先设置的限制时，就激活检查点进程，执行检查点操作。这种设置方式，在系统有大量更新时，检查点操作会很频繁；在系统处理相对空闲时，检查点操作发生的频度就降低，从而可以有效地避免过长的检查点处理时间。然而系统对内存中已更新数据量的不断监测，需要消耗一定的系统资源。

2.2.7 优化器进程

确切地说，优化器进程应被称为语法分析和优化进程。它负责SQL语句的语法分析和优化，生成SQL语句费用最低的执行计划。

SQL语言是数据库系统通用的访问接口。用户通过SQL语句更新、读取数据库中的数据，不需要知道数据在数据库中如何存放。数据库系统的这种特性实现了应用程序和数据之间的物理和逻辑独立性。

由于用户不了解数据的物理存放、数据的逻辑结构，因此SQL语句的执行方式最终要由数据库系统来决定，这就是优化器进程的工作。对任一个SQL语句，优化器首先需要进行语法分析，判定该SQL语句是否存在语法错误，决定发出该SQL语句的用户是否有执行权限。此外，一个SQL语句可能有很多种的处理方式，优化器需要从中找出最优、最合理的方式，作为该SQL语句的最终执行计划。

优化器是基于执行费用来选择SQL语句的最终执行计划。所谓执行费用，并不仅仅是指SQL语句执行时间的长短，它是对处理SQL语句所使用的CPU时间、需要的内存空间、执行的I/O操作以及处理时间长短等各方面因素的综合评价。

优化器在分析SQL语句时，首先找出SQL语句所有可能的执行计划，然后逐一进行费用评估，最终确定出费用最低的执行计划。

对SQL语句处理所需费用的评估，不可能将所有的执行计划都实际上执行一遍，记录所用时间和系统资源。优化器基于数据库对象现有的统计信息，来大体估算SQL语句所需的执行费用。对一个表来说，可以使用的统计信息包括：表中的字段数、记录的长度、表中的记录数、表上是否有索引以及索引所使用的字段、字段上数值的分布等等。数据库对象上统计信息的准确与否，直接决定了优化器选择的执行计划是否合理。

数据库管理员应当定期维护数据库对象上的统计信息。如果对数据库对象执行了大批量的更新操作，现有的统计信息已经失去意义，管理员就应当立即考虑重新收集数据库对象的统计信息。

优化器的处理虽然由系统自动运行，用户无从干预，但是用户可以在提交的SQL语句中嵌入一些指示（directives）来影响优化器的选择。另外，数据库系统的一些配置参数，也可以设定优化器的处理方式。

有关优化器的更多处理信息，可以参看第5章。

2.2.8 死锁检测进程

死锁检测进程定期执行，负责监测、处理数据库系统中出现的死锁。在设定的时间间隔到达后，死锁检测进程就被激活。

如果发现死锁，死锁检测进程能够采取以下手段，解除死锁：

（1）选择死锁中的任意一个事务，进行回退。

（2）查看死锁中事务，找出消耗系统资源最少的事务，进行回退。

（3）查看死锁中事务，找出剩余工作量最多的事务，进行回退。

数据库管理员应当密切注意数据库系统中是否有死锁的发生。一旦有死锁的存在，就应当查找原因，想办法避免死锁的发生。有关死锁处理的更多信息，可以参看第6.3.9一节。

2.2.9 其它进程

除了前面提到的各功能模块之外，数据库系统要正常运行，还需要具备以下常用功能模块：

（1）崩溃恢复进程。在数据库系统崩溃后重新启动，要执行系统的崩溃恢复。系统的崩溃恢复需要使用日志文件中的日志信息，前滚已经提交的事务，回退尚未完成的事务。

（2）资源回收进程。在系统运行过程中，系统的各种进程可能由于各种原因而异常中止，它们所拥有的资源应当及时回收。例如：对正在进行事务处理而异常中止的代理进程来说，系统应当回退代理进程正在执行的事务，释放锁以及其它资源，收回代理进程本身所使用的内存结构，从而使其它代理进程能够使用这些资源。

（3）系统审计进程。对系统中的数据访问进行审计，跟踪系统中发生的数据更新，记录用户的访问处理等。管理员通过审计发现系统中不合理的授权，找出系统中存在的不安全因素。

（4）日志归档进程。自动对数据库系统中已经写满的日志文件进行归档，使这些日志文件可以再次被使用。

（5）备份和恢复进程。数据库管理员需要定期备份数据库，在系统出现故障后进行数据的恢复。

以上只是列出了数据库系统部分最常用的功能模块，至于数据库系统在运行时会用到那些功能模块，这和应用系统要求、数据库系统的相关配置有关。我们这里不再进行详细地阐述。

2.3 进程之间的相互关系

死锁检测进程的执行，由数据库系统中设置的运行间隔决定，与其它的进程模块之间没有关联。除死锁检测进程之外，其它的进程模块彼此互相影响（如图2-3所示）。这主要体现为：

（1）监听进程将客户端应用程序的连接请求，交给代理进程处理。

（2）优化器进程为代理进程分析和优化SQL语句。如果需要大数据量的处理，就激活异步预取进程。

（3）代理进程找不到可用内存时，激活页清除进程，将内存中的脏数据写入磁盘，从而释放内存空间。

（4）页清除进程执行时，发现和脏数据页相关日志仍旧存放在内存中，就激活日志写进程。

（5）检查点操作执行时，激活页清除进程和日志写进程，将内存中的脏数据以及相关日志信息写入磁盘。

2.4 进程的调度管理

现代计算机系统通常采用多道并发处理。在这样的系统中，每一个用户作业都以进程的形式参与系统的并发执行。进程是程序在一个数据集合上运行的过程，是操作系统进行资源分配和调度的一个独立单位。

1. 进程的状态及转换

一般来说，进程在它的整个生命期中，可以处于以下基本状态：

（1）就绪。进程具备运行条件，但尚未获得CPU资源。

（2）运行。进程正在使用CPU资源。

（3）等待。由于等待某一个事件，进程不能使用CPU资源。

一个进程在其执行期间不断地在这三个状态之间转换，以“走走停停”的方式向前推进。整个状态的转换过程可见图2-4。

（1）用户提交任务处理。如果系统没有可用的CPU资源，就将该进程放入就绪队列，进行等待。

（2）如果存在CPU资源，操作系统就按照调度算法，从就绪队列中调度一个进程到CPU上运行，从而该进程就从就绪状态转变为运行状态。与此同时，原来正在运行的进程，可能完成所有操作而正常结束，也可能由于分配的时间片用完而被迫退出CPU资源，从运行状态转变为就绪状态。

（3）进程在运行过程中，可能会等待某一个事件，例如：等待分配某一资源，等待I/O操作的完成等等。在这种情况下，进程由于无法继续执行，就主动退出CPU资源，然后使自己处于等待状态，从而引起状态的变化。

（4）如果进程所等待的事件发生了变化，例如：一次I/O操作完成，于是进程就退出等待状态，进入就绪状态。

2. 进程的调度算法

可能有多个进程同时处于就绪状态，等待执行。进程的调度算法，决定了哪一个进程可以获得CPU资源。在操作系统中，有以下这些常用的进程调度算法：

（1）先来先服务算法。对处于就绪状态的进程，按照进程的提交顺序进行调度处理。

（2）轮转法。CPU的处理时间被分成固定大小的时间片。一个进程在被调度选中之后，用完了系统规定的时间片，但又未完成要求的任务，则它自行释放CPU资源而排到就绪队列的末尾，等待下一次调度。同时当前就绪队列的第一个进程获得CPU资源。

（3）优先权法。给进入系统的进程设定一个优先级，表示该进程所享有的调度优先权。对处于就绪状态的进程，优先级高的进程首先获得CPU资源。

在实际的操作系统中，一般是将几个调度算法结合起来使用。如：基于优先级的先来先服务调度算法，就是优先级高的进程首先获得CPU资源，而具有相同优先级的进程，则按照先来先服务算法，进行调度。

3. 数据库系统的进程调度

数据库系统需要启动许多个不同功能的进程。它的进程调度是根据进程间的相互关系，基于操作系统的进程调度管理，从而实现进程之间的协同处理，完成用户数据的管理和维护。

2.5 进程配置的一般原则

对数据库系统的进程管理，数据库管理员就是根据自身需要，通过调整系统配置参数，影响数据库系统的运行。在具体的系统维护过程中，管理员可以按照以下原则对数据库系统的相关功能模块进行设置：

（1）根据应用系统中访问数据库系统的用户数目，决定系统要启动的代理进程数目。代理进程的数目以满足系统的用户连接、并略有冗余为宜，太多的代理进程数将消耗不必要的系统资源。

（2）在交互式的应用系统环境中，如果系统中有大量的用户连接，可以考虑使用共享的代理进程，以减少系统资源的消耗。对INFORMIX、SYBASE这种多线程的系统，可以不用考虑这一点。

（3）在不同的数据库系统中，对一个监听进程能够服务的客户端应用程序的数目，有不同的说法。一般来说，一个监听进程能够支持200个左右的客户端应用程序，数据库管理员可以根据这个大概值，决定应用系统中需要启动的监听进程数目。

（4）如果系统中频繁出现诸如：表扫描、排序等大数据量操作，可以考虑：增加异步预取进程的数目，提高内存中未使用数据页的上限值。但前提是这些大数据量操作是必需的，应尽可能避免由于不当的SQL语句等非正常原因而引起的表扫描、排序操作。

（5）在设置检查点操作的执行间隔时，最初可以使用系统缺省值，然后根据系统的运行情况进行调整。

（6）页清除进程对内存中脏数据的磁盘写操作，应能够保证：代理进程在申请可用内存时，总能找到足够的空闲空间。如果系统中出现代理进程对可用内存的等待，就需要增加页清除进程的数目，调整内存中脏数据页的阀值，甚至可以降低检查点的执行间隔。

（7）对于死锁很少出现、甚至不会发生的应用系统，可以增大死锁检测的时间间隔，从而减少死锁检测的执行次数，避免不必要的系统开销。如果系统中出现死锁，管理员应当找出原因，想办法进行解决。

（8）数据库管理员应当定期维护数据库对象上的统计信息。应当根据应用系统的需要，决定优化器的优化级别以及在数据库对象上收集那些统计信息。

2.6 常用数据库系统的进程管理

在了解系统各功能模块的作用及处理过程之后，管理员对特定数据库系统的维护和调整，需要知道那些系统配置参数和各功能模块有关。这样才能去改变系统配置，进而影响系统运行。

对常用数据库系统：DB2、ORACLE、INFORMIX、SYBASE来说，虽然每个数据库系统都具备我们以上所讲功能模块，但其具体实现并没有严格地按照这些功能模块进行划分，而且每个数据库系统也会根据需要，建立一些自身独有的功能模块。下面我们就针对每一个数据库系统，列出其关键的功能模块及其相关配置参数，并加以简单说明以帮助数据库管理员对系统的管理。

2.6.1 DB2数据库系统

DB2数据库系统采用多进程体系结构，所有的功能模块是使用进程来实现的，进程被称为引擎可调度单元（engine dispatchable unit，EDU）。数据库系统的配置参数可以在实例、数据库两个级别上设置。

1. 监听进程

DB2系统支持TCP/IP、APPC、NetBIOS、PIPE通信协议。在配置数据库系统时，通过环境变量DB2COMM设定系统要使用的通信协议。下列实例配置参数和监听进程有关：

SVCENAME：设定通讯协议使用的端口号。

2. 代理进程

DB2系统中的代理进程分为两类：协调代理进程和子代理进程。协调代理进程接收用户请求，在处理完成后，将结果返回给用户。如果DB2系统启用了分区间或者分区内的并行处理，协调代理进程可能根据需要，将一个事务处理分成多个子任务，交由多个子代理进程并行处理，在合并了子代理进程的结果后返回给用户。

代理进程在实例启动时被启动，存放在代理池（agent pool）中，这时处于空闲状态。随着访问数据库的用户增多，代理池中不再有空闲的代理进程，这时DB2系统将重新启动新的代理进程，只要系统中已启动代理进程的总数不超过最大值就可以了。如果访问数据库的用户减少，代理池中的空闲代理进程会越来越多。在空闲代理进程的数目大于设定值后，系统就自动停止多余的空闲代理进程。

下列实例配置参数和代理进程有关：

MAX_CONNECTIONS：设定最大数目的用户连接数。

MAXAGENTS：设定系统可启动代理进程的最大数目，包括协调代理进程和子代理进程。

MAX_COORDAGENTS：设定系统可启动协调代理进程的最大数目。

NUM_INITAGENTS：设定在实例启动时，启动的代理进程数。

NUM_POOLAGENTS：设定代理进程池中空闲代理进程的最大数目。

在多数应用系统中，实例配置参数MAX_CONNECTIONS = MAX_COORDAGENTS，这时客户端应用程序和协调代理进程一一对应。在交互式的应用系统环境中，可以设定MAX_CONNECTIONS > MAX_COORDAGENTS，这时系统就启动了连接集中器（connection concentrator）功能，一个协调代理进程可以为多个用户连接服务，从而减少系统资源的消耗，增加系统支持的用户连接数。

3. 异步预取进程

异步预取进程在DB2系统中被称为I/O服务器，下列数据库配置参数和异步预取进程有关：

NUM_IOSERVERS：设定数据库启动的I/O服务器的数目。

DFT_PREFETCH_SZ：设定缺省的预取页数。在创建表空间时，可以设定该表空间所使用的预读取页数。如果没有设定，就使用该配置参数的值进行预读取。

SEQDETECT：设定顺序读检测标志。如果该配置参数被设置，数据库就不断地监视I/O操作，一旦发现正在顺序读取页，就激活I/O的预读取操作。否则，数据库仅当在表排序、表扫描、索引扫描时才会执行预取操作。

4. 页清除进程

下列数据库配置参数和页清除进程有关：

NUM_IOCLEANERS：设定系统启动的页清除进程数。

CHNGPGS_THRESH：设定内存中已更新数据页的百分比。如果内存中的脏数据页达到或者超过该参数值，进程被激活。页清除进程在执行时，首先构建内存中脏数据页的列表，在将这些页全部写入磁盘之后再次变为不活动状态。

5. 日志写进程

DB2系统的一个实例可以包含多个数据库，每个数据库使用的写日志信息方式，与下列数据库配置参数有关：

MINCOMMIT：设定系统提交的事务数。在达到此设定后，日志写进程被激活，将日志缓冲区中的日志信息写入磁盘。如果设置MINCOMMIT = 1，DB2系统的这个数据库就采用事务提交前必须将日志写入磁盘的机制。对系统性能要求高、需要快速响应的应用系统，可以设置其数据库的配置参数MINCOMMIT > 1，这样日志写进程将多个事务的日志信息一起写入磁盘，减少了磁盘的I/O操作，提高了系统性能。

6. 检查点进程

DB2系统监测数据的更新，根据已更新数据的数量，来决定何时启动检查点操作。下列数据库配置参数和检查点进程有关：

SOFTMAX：设定数据库崩溃后恢复所需要的日志文件数目。数据库系统根据此参数，决定执行多少更新后就触发检查点进程。

7. 优化器进程

DB2系统的优化器功能相当复杂，为了得到SQL查询语句最优的执行计划，除了根据数据库对象结构、数据分布外，还结合计算机中CPU的个数和处理速度、可用排序内存空间、通讯带宽等相关系统资源，最终确定SQL查询语句的执行计划。下列实例和数据库配置参数和优化器进程有关：

CPUSPEED：设定CPU处理器的速度。

COMM_BANDWIDTH：设定数据库分区服务器之间的通讯带宽。

SORTHEAP：设定用于排序的内存页的最大数目

AVG_APPLS：设定系统正常运行状况下活动应用程序的平均数目。优化器使用此参数来估计SQL语句在运行时将有多少内存空间可以使用。

DFT_DEGREE：设定缺省情况下优化器是否对查询语句进行并行处理。

DFT_QUERYOPT：设定缺省情况下系统使用的查询优化级别。

MAX_QUERYDEGREE：设定SQL语句可以使用的最大查询并行度。

除此之外，对有关SQL编译器、性能等环境变量的设置，也会对优化器的处理产生影响。

8. 死锁检测进程

下面的数据库配置参数和死锁检测进程有关：

DLCHKTIME：设定死锁检查的时间间隔。

2.6.2 ORACLE数据库系统

ORACLE数据库系统采用多进程体系结构，所有的功能模块是使用进程来实现的。除前面已经讲到的进程之外，ORACLE系统还有一些比较关键的的进程，如：SMON、PMON等。

1. 监听进程

ORACLE系统的监听进程在系统之外运行，因此严格来说，监听进程并不属于ORACLE系统。由于这种实现方式，监听进程和ORACLE系统实例之间拥有多对多的关系：

（1）一个监听进程可以为多个ORACLE系统服务。同一台服务器上的多个ORACLE系统实例可以使用同一个端口，监听进程使用用户请求中的实例名称，来决定将用户请求发送给那一个ORACEL系统实例进行处理。

（2）可以为一个ORACLE系统实例设置多个监听端口，启动多个监听进程同时为该实例提供连接服务。

命令行工具lsnrctl，用来启动、关闭以及监测监听进程。对监听进程的配置，可以使用图形化工具netca，也可以直接修改配置文件。和监听进程有关的配置信息存放在以下三个文件中：

（1）listener.ora：存放一个或多个监听进程的定义

（2）sqlnet.ora：决定通讯连接所有服务名的解析方式

（3）tnsnames.ora：在使用本地（local）方式进行服务名的解析时，存放服务所使用协议、端口等信息。

2. 代理进程

在ORACLE系统中，代理进程称为服务器进程（server process），它可以是专用的，也可以是共享的。

在专用的服务器进程（dedicated server process）环境中，一个服务器进程只为一个客户端应用程序服务，服务器进程和客户端应用程序一一对应，它和第2.2.2一节讲到的代理进程大体上一致。

在共享的服务器进程（shared server process）环境中，一个服务器进程能够为多个客户端应用程序服务。在这种环境中，服务器进程和客户端应用程序之间并没有直接的联系，系统需要启动一个新的进程：分发进程（dispacher process）。

分发进程作为客户端应用程序在数据库系统中的代理人，建立和客户端应用程序的连接，并接收用户请求。然而，分发进程不会去处理用户请求，在收到用户请求后，放入自己的请求队列。系统中任何处于空闲状态的服务器进程，会不断地去检查分发进程的请求队列。如果发现需要处理的用户请求，就取出该请求并处理，然后将结果放入分发进程的响应队列，最后由分发进程将结果返回客户端应用程序。一个分发进程能够为多个客户端应用程序服务，分发进程和客户端应用程序之间是一对多的关系。

下列配置参数和服务器进程的配置有关，在专用的服务器进程环境中，只需要配置PROCESSES和SESSIONS参数，其余参数均设为0即可。

PROCESSES：设定系统进程的最大数目，包括ORACLE系统本身启动的后台进程。

SESSIONS：设定用户会话的最大数目。由于每一个用户连接需要一个会话，因此该参数决定了系统中的并发用户数目。

CIRCUITS：设定系统使用的VIRTUAL CIRCUITS的数目。在共享的服务器进程环境下，应设定该参数等于参数SESSIONS。

DISPATCHERS：设定实例启动时，启动的分发进程数目。

MAX_DISPATCHERS：设定实例中可以启动的分发进程的最大数目。

SHARED_SERVERS：设定实例启动时，启动的共享服务器进程的数目。

MAX_SHARED_SERVERS：设定实例中可以启动的共享服务器进程的最大数目。

SHARED_SERVERS_SESSIONS：设定系统的所有用户会话中，有多少可以在共享的服务器进程环境下使用。通过该参数，可以在共享的服务器进程环境中，建立专用的服务器进程环境。

3. 异步预取进程

ORACLE系统没有异步预取功能。代理进程在处理用户请求时，所需数据完全由代理进程从磁盘中读入。

4. 页清除进程

ORACLE系统的页清除进程被称为数据库书写器（DBWn）。下列参数和数据库书写器的配置有关；

DB_WRITER_PROCESSES：设定实例启动时，启动的数据库书写器的数目。

内存中已更新数据页达到总数据缓冲区的40%时，数据库书写器就被激活，将脏数据写入磁盘。该百分比为系统的缺省设置，不允许用户修改。

5. 日志写进程

ORACLE系统采用事务提交前必须将日志写入磁盘的机制，日志写进程称为日志书写器（LOG WRITER，LGWR）。除了事务提交、数据库书写器将内存中的脏数据写入磁盘之外，下列事件也将触发日志书写器的磁盘写操作：

（1）重做日志内存缓冲区中的三分之一已经被使用

（2）写入重做日志缓冲区中的日志信息已经超过1M字节

（3）每间隔三秒钟

6. 检查点进程

ORACLE系统监测数据的更新，根据已更新数据的数量，来决定何时启动检查点操作。在执行检查点操作时，除了要在日志文件中写入检查点信息，还要使用检查点信息修改控制文件以及数据文件的文件头。正是这个特性，使得ORACLE数据库系统可以在数据文件的级别上进行备份和恢复，当然系统性能受到影响是不可避免的。下列参数和检查点进程的配置有关：

FAST_START_MTTR_TARGET：设定系统崩溃恢复时需要花费的时间。数据库系统根据此参数，决定执行多少更新后就触发检查点进程。

7. 优化器进程

在ORACLE系统中，除了常用的基于费用的优化方式外，优化器还可以使用基于规则的优化方式。下列参数和优化器进程的配置有关：

OPTIMIZER_MODE：设定优化器使用的优化方式。

OPTIMIZER_MAX_PERMUTATIONS：设定连接查询中数据表的置换次数。

OPTIMIZER_INDEX_COST_ADJ：设定优化器对于索引访问的费用估计方式。

OPTIMIZER_INDEX_CACHING：设定索引中数据被装入内存的百分比。优化器使用该参数估计嵌套循环连接的费用。

OPTIMIZER_FEATURES_ENABLE：设定系统使用的优化器版本。

OPTIMIZER_DYNAMIC_SAMPLING：设定数据库对象的统计信息不可使用时，优化器进行动态地采样。

8. 死锁监测进程

ORACLE系统采用独特的并发处理结构，因此它的锁管理方式不同于其它的数据库系统，在系统正常运行过程中一般不会出现锁的问题。死锁监测由ORACLE系统自动进行管理，用户不需要进行配置。

9. 系统监控进程（system monitor，SMON）

ORACLE的系统监控进程在系统启动时，检查数据库系统是否处于一致状态。如果数据库系统处于不一致状态，就执行系统的崩溃恢复。

除此之外，在系统正常运行过程中，系统监控进程还要执行以下的处理：

（1）每3秒钟一次合并数据文件中的自由空间

（2）从临时表空间中回收不再使用的临时段

系统监控进程由ORACLE系统自动进行管理，用户不需要进行配置。

10. 进程监控进程（process monitor，PMON）

ORACLE的进程监控进程，用来管理系统中的其它进程，监测它们的运行状况。如果发现失败的代理进程，就回收由这些代理进程使用的相关资源；如果发现失效的系统后台进程，就重新启动这些后台进程。

进程监控进程由ORACLE系统自动进行管理，用户不需要进行配置。

2.6.3 INFORMIX数据库系统

INFORMIX数据库系统采用多进程、多线程体系结构，进程被称为虚拟处理器（virtual processor，VP）。根据功能划分，INFORMIX系统可以启动以下几种类型的虚拟处理器：CPU、PIO、LIO、AIO、SHM、TLI、SOC、ADM、ADT、JVP等。

CPU虚拟处理器是INFORMIX系统最关键的进程，数据库系统中几乎所有的功能，例如：监听、服务、检查点等，都可以使用CPU虚拟处理器中的线程来实现。INFORMIX系统能够启动的CPU虚拟处理器的数目不能超过计算机中物理CPU的个数。

PIO、LIO、AIO虚拟处理器服务磁盘的I/O操作。如果使用操作系统文件创建数据库，那么PIO、LIO、AIO虚拟处理器中的线程分别负责物理日志、逻辑日志、用户数据的读写；如果使用裸设备创建数据库，那么由CPU虚拟处理器中的线程负责物理日志、逻辑日志、用户数据的读写。在UNIX平台的应用系统中，一般是使用裸设备来创建INFORMIX数据库系统，因此PIO、LIO、AIO虚拟处理器各自启动一个就足够了。

根据系统使用的通讯协议，SHM、TLI、SOC虚拟处理器被启动，负责系统的通讯管理。这些虚拟处理器的功能也可以在CPU虚拟处理器中完成，因此对INFORMIX系统来说，这些虚拟处理器并不是必须的。

ADM虚拟处理器负责数据库系统的管理工作，如：用户会话失败后，回收会话所拥有的资源等。在INFORMIX资料中，并没有该虚拟处理器的详细描述，也不需要用户进行配置。

ADT虚拟处理器负责数据库系统的审计处理。如果数据库系统的审计功能被使用，该虚拟处理器被自动启动。

JVP虚拟处理器负责数据库系统中JAVA应用环境的处理。如果数据库系统使用了JAVA函数和程序，该虚拟处理器被自动启动。

对虚拟处理器的管理，可以使用VPCLASS配置参数。通过该参数，可以设定系统要启动虚拟处理器的种类、个数以及相关特性等。

1. 监听线程

INFORMIX系统支持TCP/IP、IPX/SPX、IPC、PIPE通讯协议，系统所使用的通讯协议、端口存放在配置文件sqlhosts中。下列配置参数和监听线程有关：

NETTYPE：设定系统启动的监听线程的数目、最大用户连接数，以及使用的虚拟处理器的种类和数目。

2. 代理线程

在INFORMIX系统中，系统可以启动的代理线程数目由最大的用户连接数决定，没有系统配置参数可供用户调整。同时，如果在系统中设置了查询的并行处理功能，那么可启动的代理线程数目还会增加。

3. 异步预取线程

下列配置参数和异步预取线程有关：

RA_PAGES：设定每次预读的数据页数。

RA_THRESHOLD：设定内存中未处理数据页数的最小值。内存中未处理数据页数等于或者低于这个参数值时，就开始下一次的数据预读。

4. 页清除线程

在INFORMIX系统中，数据缓冲区被分成多个LRU队列进行管理，页清除线程分别将这些LRU队列的脏数据写入磁盘。下列配置参数和页清除线程有关：

LRUS：设定系统启动时创建的LRU队列数。配置参数BUFFERS的值除以这个值，就可以得出每个LRU队列管理的缓冲区数目。

CLEANERS：设定系统启动的页清除线程的个数。

LRU_MAX_DIRTY：设定LRU队列中脏数据页的最大百分比。在一个LRU队列中的脏数据，等于或者超过这个参数值后，页清除线程就开始将该LRU队列中的脏数据写入磁盘。

LRU_MIN_DIRTY：设定LRU队列中脏数据页的最小百分比。在一个LRU队列中的脏数据，等于或者小于这个参数值后，页清除线程就停止该LRU队列脏数据的磁盘写操作。

INFORMIX系统建议的LRUS参数值，是基于计算机系统可用的CPU数目。对单CPU的计算机系统，可以设置LRUS参数的初始值为4；对多CPU的计算机，可以设置LRUS参数的初始值为max(4,(number of CPU VP))。一般来说，根据数据库系统使用的硬盘数目，决定参数CLEANERS的值，一个硬盘需要一个页清除线程。但也应当考虑LRU 队列的长度以及检查点的频率。另外参数CLEANERS的值不应当低于LRUS的值。

5. 日志写线程

INFORMIX系统使用了两种日志文件：逻辑日志文件和物理日志文件。我们常说的数据库日志文件是指逻辑日志文件，只有逻辑日志文件保存了数据库的更新记录。在INFORMIX系统的正常事务处理过程中，数据页在被更新之前，要存入物理日志文件中。物理日志文件是用来存放数据页被改变之前的内容，这样如果事务需要回退，直接使用物理日志文件中的数据页覆盖原来的数据页就可以了。

对逻辑日志文件和物理日志文件的读写，INFORMIX系统使用了不同的线程，自动完成，没有系统配置参数可供用户调整。

INFORMIX系统的单个实例下可以创建多个数据库，每一个数据库有多种日志处理模式。如果数据库使用非缓冲日志模式或者ANSI兼容日志模式，则系统就对该数据库采用事务提交前必须将日志写入磁盘的机制；如果数据库使用缓冲日志模式，则系统就对该数据库采用事务提交前不要求将日志信息写入磁盘的机制。

6. 检查点线程

INFORMIX系统使用了两种形式的检查点操作：FULL和FUZZY。FULL检查点操作将内存中所有的改变写入磁盘，保证了数据物理上的一致性。

FUZZY检查点操作只是将内存中一些特定的改变写入磁盘，如：表的修改、索引的建立、用户定义类型以及大对象的增加、删除和修改等，在系统存在大量的更新操作时，这种检查点操作降低了系统I/O的压力。INFORMIX系统的检查点线程在正常情况下执行的都是FUZZY操作。

INFORMIX系统使用固定的时间间隔，执行检查点操作。下列配置参数和检查点线程有关：

CKPTINTVL：设定检查点操作的时间间隔。

7. 优化器线程

下列参数和优化器线程有关：

OPTCOMPIND：设定多个表的连接时，优化器如何生成查询的执行计划。

OPT_GOAL：设定优化器的优化方式。

除此之外，用户还可以设定IFX_DIRECTIVES环境变量。优化器根据此设置，决定是否使用嵌入在SQL语句的优化指示。

8. 死锁检测线程

在INFORMIX系统中，死锁检测由系统自动完成，没有系统配置参数可供用户调整。

2.6.4 SYBASE数据库系统

SYBASE数据库系统采用多线程体系结构，所有的功能模块都是使用线程来实现的，启动、管理、调用线程功能模块的进程被称为引擎（engine）。数据库服务器能够启动的引擎数目由计算机的实际CPU数目决定，即最大的引擎数目不能超过物理的CPU数目。在数据库系统启动后，使用dbcc engine命令，可以联机地激活或者关闭引擎。可以使用下列配置参数管理引擎和线程：

NUMBER OF ENGINES AT STARTUP：设定数据库系统启动时，启动的引擎数目。

MAX ONLINE ENGINE：设定数据库系统可以启动的最大引擎数目。

TIME SLICE：设定线程中任务可以运行的毫秒数。

CPU GRACE TIME：设定线程中任务的运行时间达到配置参数TIME SLICE的设置后，在被数据库系统强制暂停之前，任务还可以运行的最大时间。

除了启动的引擎数目之外，数据库系统使用其它参数，实现线程的调度管理，一般不需要改变。

1. 监听线程

在SYBASE数据库系统中，监听线程使用的网络协议、地址、端口等信息存放在interfaces接口文件中。下列配置参数和监听线程有关：

MAX NUMBER NETWORK LISTENERS：设定数据库系统启动的监听线程的最大数目。

2. 代理线程

如果在SYBASE数据库系统中设置了并行处理，根据并行度，每个代理线程会将任务分配给其它的代理子线程。代理子线程在SYBASE系统中被称为工作线程。下列配置参数和代理线程有关：

NUMBER OF USER CONNECTIONS：设定数据库系统可以建立的用户连接数目。该参数也同时决定了数据库系统可以启动的代理线程的数目。

NUMBER OF WORKER PROCESSES：设定数据库系统可以启动的工作线程数目。

3. 异步预取线程

在SYBASE系统中，内存空间中的数据缓冲区，可以被划分为多个高速缓存（cache），每一个高速缓存又可以细分为多个池（pool）。下列配置参数和异步预取线程有关：

GLOBAL ASYNC PREFETCH LIMIT：设定高速缓存、池预取数据可使用的内存空间百分比。该参数在整个数据库系统范围内起作用，可以根据需要，使用命令为单个的高速缓存、池设定相应的预取数据属性。

在需要使用数据的预读取时，异步预取线程根据特定高速缓存、池的属性设置，来决定使用该高速缓存、池的数据库对象要预取的数据量。如果高速缓存、池的预取属性没有被设置，就使用数据库系统的参数设置。

确省情况下，数据库对象的预读取功能被设置。如果用户使用sp_cachestrategy命令，改变了一个数据库对象的预读取设置，则对该数据库对象的数据操作，系统不会使用预读取功能。

4. 页清除线程

下列配置参数和页清除线程有关：

HOUSEKEEPER FREE WRITE PERCENT：设定写入磁盘的脏数据的百分比。系统在CPU处于空闲状态时，根据此百分比和总的脏数据的数量，决定将多少已更新数据写入磁盘。

5. 日志写线程

SYBASE系统的单个实例下包含多个数据库，所有的数据库使用相同的日志信息写方式。在缺省情况下，数据库采用事务提交前必须将日志写入磁盘的机制，代理线程生成的事务日志存放在自己的私有内存空间中，由代理线程写入磁盘；如果在SYBASE系统的内存结构中建立日志缓冲区，那么所有数据库采用事务提交前不要求将日志信息写入磁盘的机制，事务在所有操作完成后就提交，代理线程将日志信息写入日志缓冲区，最后由日志写线程统一写入磁盘。

6. 检查点线程

SYBASE系统的检查点线程，大约每分钟被激活一次，顺序检查每个数据库中已发生的数据更新。如果某个数据库中已更新数据的数量，达到系统的参数设置，就执行该数据库的检查点操作。对数据库执行检查点操作，检查点线程将检查该数据库的truncate log on chkpt属性。如果该属性被设置，检查点线程就截断数据库的日志。下列配置参数和检查点线程有关：

RECOVERY INTERVAL IN MINUTES：设置单个数据库的崩溃恢复需要花费的时间。检查点线程根据此参数，决定是否触发该数据库的检查点操作。

7. 优化器线程

下列配置参数和优化器线程有关：

ENABLE SORT-MERGE JOINS AND JTC：设定在整个系统范围内，优化器可以使用排序合并连接和连接传递闭包。

ALLOW BACKWARD SCANS：设定优化器在决定SQL语句的执行计划时，是否可以反方向地扫描索引。

8. 死锁检测线程

下列配置参数和死锁检测线程有关：

DEADLOCK CHECKING PERIOD：设定死锁检测的时间间隔。

2.7 本章小结

数据库系统有自己的进程管理和调度，应当具备以下的功能模块：监听进程、代理进程、异步预取进程、页清除进程、日志写进程、检查点进程、优化器进程、死锁检测进程等。对INFORMIX、SYBASE系统来说，这些功能模块是通过线程来实现的。

监听进程接收客户端应用程序的连接请求，并选择进行服务的代理进程。应根据需要服务的客户端应用程序数目，决定系统需要启动的监听进程数目。

代理进程作为客户端应用程序在数据库系统中的代理人，接收、处理用户请求，并将结果返回客户端。一般情况下代理进程和客户端应用程序一一对应。

异步预取进程负责将代理进程随后要处理的数据事先读入内存，避免出现代理进程的数据等待。它对数据的读取是渐进的，如果系统中频繁出现大数据量操作，可以考虑增加异步预取进程的数目，提高内存中未使用数据页的上限值。

页清除进程负责将内存缓冲区中已经被更新的脏数据页写入磁盘，使已发生的更新做永久性的保存。页清除进程对磁盘的写速度应能够保证：代理进程在申请可用内存时，总能找到足够的空闲空间。

日志写进程负责将内存缓冲区中的事务日志信息写入磁盘，数据库采用的日志写方式要根据应用系统的具体需要进行确定。

检查点进程执行时，暂停所有事务处理，将内存中所有已更新数据及日志信息写入磁盘，在日志文件中记录检查点信息。数据库管理员根据需要，设定检查点操作的执行间隔。

优化器进程负责SQL语句的语法分析和优化，生成SQL语句费用最低的执行计划。应当定期维护数据库对象上的统计信息。

死锁检测进程定期执行，负责监测、处理数据库系统中出现的死锁。如果出现死锁，就采取措施解除死锁。对于死锁很少出现、甚至不会发生的应用系统，可以增大死锁检测的时间间隔。

常见的数据库系统：DB2、ORACLE、INFORMIX、SYBASE，其功能模块的使用和管理不尽相同。基于对系统各功能模块作用及处理过程的了解，数据库管理员通过调整相关配置参数，来控制系统的运行。