第一章 数据库系统的基本概念

数据库管理系统（Database Management System，DBMS）很重要。对它的任何操作失误和管理不当，都可能引起灾难性的后果。然而数据库系统并不复杂，从CPU、内存、I/O的角度来看，它不外乎就是使用这些资源，为用户提供数据存储和维护机制，方便用户对数据的访问和管理。用户对数据库系统的配置，也就是让它合理地使用这些资源，加快数据的处理速度。

本章简单介绍了数据库技术的发展历程、数据库系统的基本概念，就实例、并发、并行、裸设备等相关系统概念进行解释和说明。然后，本章着重介绍常用数据库系统的体系结构以及它们的特点，并在最后为数据库系统的性能调整提供可行的方法指导。

1.1 数据库系统的发展概述

数据库管理系统已经成为数据存储和管理的重要手段，没有使用数据库的应用系统是不可想象的。它是随着人们对现实世界认知的深入，伴随着计算机技术的进步而出现的，并将在此基础上进一步发展和壮大。

1.1.1 数据管理发展的三个阶段

数据是反映客观世界的事实，可以输入到计算机中进行存储和管理。人们可以对数据进行加工处理，从而获取有用的信息。对数据的存储和管理，主要是围绕提高数据独立性、降低数据冗余度、提高数据共享性、提高数据的安全和完整性等方面来进行改进，让使用者能够有效地管理和使用数据资源。数据的存储和管理经历了三个阶段：人工管理阶段、文件系统阶段和数据库系统阶段。

在计算机出现的初期，用户自己完全负责数据的组织、存储结构、存储方法、输入输出等数据管理工作；每个用户使用自己的数据，数据完全面向特定的应用程序；程序和数据完全结合在一块，程序随着数据结构的改变而改变。这种数据的存储和管理方法，导致了数据和程序紧密结合、数据的利用率不高、数据不易管理、数据一致性很难维护等问题。

到了文件系统阶段，由文件系统提供数据的统一访问控制，负责数据存储、读写等管理工作，向应用程序提供操作接口。但是文件系统只是解脱了程序员对物理设备存取的负担，它并不理解数据的语义，只负责存储；数据的语义信息只能由程序来解释，也就是说，数据收集以后怎么组织，以及数据取出来之后按什么含义解释，只有全权管理它的程序知道；一个应用程序若想共享另一个应用程序生成的数据，必须同另一个应用程序沟通，了解数据的语义与组织方式，因而文件系统的出现并没有改变数据与程序紧密结合的状况，数据逻辑结构改变则必须修改应用程序，数据的独立性和共享性仍旧很差。

为了进一步提高数据的物理和逻辑独立性，减少数据的冗余，提高数据的利用率，于是数据库管理系统应运而生。数据库系统采用了三级模式结构（外模式、模式和内模式），外模式是数据库用户看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。模式是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。内模式是数据物理结构和存储结构的描述，是数据在数据库内部的表示方式。对于每一个外模式，在数据库系统中定义一个外模式／模式映象，即外模式与模式之间的对应关系。当模式改变时，由数据库管理员对各个外模式／模式的映象作相应改变，可以使外模式保持不变，从而应用程序不必修改，保证了数据的逻辑独立性。模式和内模式在数据库系统中是唯一的，它们之间的映象定义了数据全局逻辑结构与存储结构之间的对应关系。当数据库的存储结构改变了，由数据库管理员对模式／内模式映象作相应改变，可以使模式保持不变，从而保证了数据的物理独立性。

数据库技术的使用，使得我们修改应用程序而可以不更改后台数据，更改数据结构而不影响应用程序，极大地提高了应用系统的灵活性。同时数据库中的数据可以为许多用户和应用程序所访问，数据的冗余度降低了，利用率提高了。

然而数据库技术远非完美，它还不能将数据和应用程序彻底地分割开来。我们在设计应用系统时，所能做的是根据这些原则，尽可能地降低数据和应用程序的耦合度，而这也已经成为应用系统设计好坏的一个衡量标准。

1.1.2 数据库技术发展的三个阶段

为了把现实世界中的具体事物转换成计算机能够处理的数据，必须要使用某种手段来抽象和描述这些数据，这就是数据模型。数据模型是对现实世界中各种事物或者实体特征的数字化模拟和抽象，用以表示现实世界中的实体和实体之间的联系，是之能够存放到计算机中，并通过计算机软件进行处理。

在数据库技术的发展过程中，按照数据模型和时间的先后，可以把数据库技术的发展和演化划分为以下几类：层次数据库系统、网状数据库系统、关系数据库系统。

在现实世界中，许多实体之间的联系呈现一种自然的层次关系，如：行政机构、家族关系等。因此层次数据模型可以自然地表达数据间具有层次规律的分类关系、概括关系、部分关系等。层次数据库系统使用层次数据模型，出现于上个世纪六十年代末期，以IBM公司的IMS系统为代表。

由于层次数据模型只支持实体之间的1 : 1、1 : N联系，实体之间的M : N联系，需要数据记录的多处存放，数据冗余量大。另外，对任何数据记录的访问，都需要从根结点开始进行扫描，处理时间长。这些缺点使层次数据库系统没有得到广泛使用。

现实世界中事物之间的联系大多数是网状的，因此网状数据模型更具有普遍性，层次模型可以看作是网状模型的一个特例。网状数据库系统使用网状数据模型，出现于上个世纪七十年代早期，以美国CODASYL组织的DBTG标准为基础。网状数据模型能直接地描述现实世界，但由于结构复杂，数据库设计和应用程序之间的实现比较困难，从而限制了它的进一步发展。

关系数据库系统使用关系数据模型，从上个世纪八十年代以来，得到长足发展，至今仍长盛不衰。我们常见的数据库系统，如：DB2、ORACLE、INFORMIX、SYBASE等，都是关系数据库系统。

关系数据模型使用关系表表示实体和实体之间的联系。在关系数据模型中，每个实体、实体之间的联系都用一个关系表表示，关系表从结构上看就是一张二维表格，表中的每条记录都表示一个实体对象或者一个联系。在关系表中，通过外部关键字直接表达实体之间一对一、一对多、多对多的联系，不需要任何转换或者中间环节。

和层次数据模型、网状数据模型相比，关系数据模型面向记录集合，有较高的数据独立性，概念单一、结构简单，可以直接处理多对多的联系，因此得到了广泛的应用。

1.2 数据库系统基本概念

本书基于关系数据库系统，主要讲解常用系统：DB2、ORACLE、INFORMIX、SYBASE的管理和配置。在开始进一步的讲解之前，我们有必要对一些相关概念进行阐述，以加深我们对数据库系统的理解。

1.2.1 什么是数据库管理系统

通俗地来说，数据库就是存放数据的仓库，用来存放人们日常生活、工作中各种各样的数据。对这些数据，人们希望在需要时可以快速、方便地获取。由于这种要求，数据不能杂乱无章、毫无目的的存放在数据库中，而应当被编码、分类、有规划地存放。有关数据的定义和管理信息也放置在数据库中，被称为数据字典。

日常生活中和数据库很类似的一个例子是图书馆。图书馆可以看作是图书的仓库，在这里图书代替了数据。图书被分类、编码，有规则地摆放在一排排的书架上。为了便于图书的查找，需要按照作者、出版社、日期等信息建立图书的索引。

数据库既然是数据的仓库，我们就需要一套软件对它进行管理。该软件应当至少具备以下的功能：

（1）数据定义：定义数据库中存放什么样的数据、数据采用什么样的格式。

（2）数据维护：在定义了数据格式之后，可以向数据库中插入数据，也可以删除或者更新已插入的数据。

（3）数据查询：用户可以根据需要，随时从数据库中获取数据。

为了数据的安全，该软件还应当能够定义用户，并给不同的用户授权；为了保证数据不被破坏，还应当能够对数据进行备份和恢复等等。

基于以上的讨论，我们可以将数据库管理系统看作由一个互相关联的数据集合和一组用以访问这些数据的程序组成，这个数据的集合通常被称作数据库。

1.2.2 数据库系统与操作系统的关系

操作系统是最贴近硬件的系统软件，我们可以将它的管理工作划分为以下五大功能：

（1）进程管理。又可以称为处理机管理。实质上是对处理机执行“时间”的管理，即如何将CPU真正合理地分配给每个任务。在多道程序环境下，现代操作系统中处理机的分配和运行都是以“进程”为基本单位，因而对处理机的管理可归结为对进程的管理。

（2）内存管理。任何程序必须调入内存之后才能运行。在多道程序设计中，对内存的管理主要涉及内存空间的充分利用技术，以及多道、多重处理和内存的分配、保护、扩充等。

（3）存储管理。就是以不同类型的文件、目录和文件夹的形式储存数据，方便用户检索，实现用户之间的数据共享，同时又要保证数据的安全和可靠。

（4）作业管理。用户可以以交互方式、批处理方式向计算机提交自己的处理请求，作业管理负责这些请求的调度和管理。

（5）设备管理。其实质是对硬件设备的管理。现在的计算机配备了许多外部设备，通过设备管理，用户无需了解设备的细节，要使用什么设备，只要向操作系统发命令就可以了。

数据库系统运行在操作系统平台之上。除设备管理之外，数据库系统具有自己的进程管理、内存管理、存储管理、作业管理。这些功能的实现都是基于底层操作系统的功能调用，和操作系统的各功能模块密切相关。所不同的是，它们着重于对数据库中数据的管理和维护，以方便用户访问和操作这些数据。

数据库系统和操作系统密切相关。操作系统的任何硬件、软件失败，都可能影响数据库系统的正常运行；而发生在数据库系统中的处理故障，也会在操作系统中有所体现。因此，对数据库系统的管理和维护，离不开操作系统的管理和维护。

1.2.3 数据库系统的体系结构

数据库系统尽管重要，但并不复杂，用户不要对它心存畏惧。从CPU、内存、I/O的角度来看，数据库系统就是使用这些资源，为用户提供数据存储和维护机制，方便用户对数据的访问和管理。

从CPU资源的使用来看，数据库系统提供了许多功能模块。这些功能模块可以让用户定义或者更改自己的数据格式；可以接收用户请求，决定请求的处理方式，以及在请求处理完成后将结果返回给用户；可以实现数据的备份和恢复等等。这些功能模块可以进程、也可以线程的方式实现，不同数据库系统会选用不同的方式。所有这些功能模块需要协同处理，共同完成对用户数据的管理工作。这就是数据库系统的进程管理，我们将在第2章中讲述。

从内存资源的使用来看，数据库系统需要一块内存空间，存放需要处理的用户数据；为了获取用户数据格式以及判断用户是否有执行权限，需要一块内存空间存放数据字典信息；为了防止数据更新的丢失，处理前系统要给数据加锁，需要一块内存空间存放锁的信息，等等。所有这些内存空间，为系统对数据的处理提供了一个工作场所。除此之外，各功能模块的运行也需要堆栈、存放执行代码等的内存空间。不同数据库系统对内存的使用也各不相同，但大体上存在相似的结构。对所有这些内存空间的管理，就是数据库系统的内存管理，我们将在第3章讲述。

从I/O资源的使用来看，数据库系统对用户数据的管理和维护，需要不断地将数据读入内存进行处理、在更新完成后写入磁盘。数据在磁盘上按照一定的格式存放，用户需要决定数据的组织和存放方式，以及确定何时对数据进行整理。这是数据库系统存储管理需要完成的工作，我们将在第4章中讲述。

因此，从数据库系统对CPU、内存、I/O系统资源的使用来看，我们可以将数据库系统的体系结构划分为：进程管理、内存管理、存储管理。本书也就是从这个角度来看待数据库系统，让用户能够从整体上快速、深入地掌握数据库系统。有关常用数据库系统的体系结构，可以参看第1.4一节。

由于数据库系统对CPU、内存、I/O系统资源的使用，用户对它的管理和配置也就是让这些资源相互协调、合理运用，不能在某一个资源上面存在瓶颈。这也是数据库系统性能调整的主要目标，有关数据库系统性能调整，可以参看第1.6一节。

1.3 数据库系统相关概念

1.3.1 实例

数据库系统由一个互相关联的数据的集合和一组用以访问这些数据的程序组成，这个概念只是对数据库系统作了一个静态的、简单的描述。如果要对具体的、实际运行的数据库系统进行说明，就需要一个新的概念：实例。

1. 什么是实例

许多资料都曾讲到实例，但都没有给出明确的解释。其实，我们可以将实例看作是数据库系统的一个具体化，就是用户根据自己的要求，对系统进行裁剪和配置，创建数据库使用的存储空间，从而建立适合自己需要的一个数据库系统运行环境。

我们知道，在计算机上安装了数据库系统软件之后，还不能够使用。用户还需要完成以下的工作：

（1）选择并分配存放数据的磁盘空间。

（2）配置运行环境，如：选择语言、字符集、可启动的进程数、可使用的内存空间、使用的网络协议及相关配置，等等。

在以上操作正确完成之后，数据库系统才可以启动。而该过程的处理，就是用户根据自身要求，创建一个具体的数据库系统运行环境，也就是创建一个实例。

由于不同用户、不同应用程序需要访问和管理不同的数据，其运行环境也不尽相同。因此在同一台计算机上，其他用户也可以根据自身需要，创建另外的实例。这些实例和实例之间互不影响。

一个系统实例包括：对运行环境进行设置的各种配置信息、存放数据的磁盘空间等。在实例启动之后，根据配置信息启动的进程、分配的内存空间也属于这个实例。

2. 实例和数据库系统的关系

实例是数据库系统的具体化。它和数据库系统之间的关系，就如同面向对象技术中的对象和类。

对象和类是面向对象技术中的两个最基本的概念。对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。而具有相同或相似性质的对象的抽象就是类。因此，对象的抽象是类，类的具体化就是对象。

具体到我们的现实生活，人可以看作一个类，具有五官、四肢等特征，是从世界上所有人抽象出来的一个概念；而对于特定的一个人，如：张三，属于人这个类中的一个对象，具有人这个类的所有特征，但同时张三这个人已经被具体化，拥有区别于人这个类中其他对象的特征。我们提到张三，就不会想到李四。

同样的道理，数据库系统可以看作一个类，是一个抽象的概念；而实例则是数据库系统这个类被具体化的对象，一个实例和另一个实例之间互相区别。

3. 实例和数据库的关系

实例是具体化了的数据库系统，包含了存放数据的数据库。在实例和数据库之间，可以建立两种关系，见图1-1和图1-2。

（1）单实例多数据库

在一个实例下，可以建立多个数据库，这些数据库只能属于这个实例。不同的数据库存放不同的用户数据，共享同一个实例的运行环境。

（2）多实例单数据库

一个实例只能管理一个数据库，而一个数据库可以有多个运行环境，即多个实例。用户可以通过多个运行环境，访问同一个数据库中的数据。

每一个实例可以单独运行在一台机器上。由于I/O操作往往是系统的瓶颈，这种由多个节点访问相同数据的做法，自然会降低系统的性能。

1.3.2 进程和线程

进程是一个具有独立功能的程序在计算机上动态执行的过程，简单地说，进程就是指程序的一次执行过程。线程属于进程，是进程中执行运算的最小单位，一个进程的所有线程都共享该进程的内存地址空间。

现代计算机系统采用多道程序设计，系统中同时存在多个进程，执行多个任务，从而实现资源共享，提高CPU利用率。一个进程在等待资源或者其运行时间达到设定的时间片之后，就放弃资源进行切换，使其它进程能够获取资源而执行。对放弃资源、停止执行的进程，系统需要保存它的当前运行环境，以使该进程在重新获取资源后，能够从这一点继续往下执行。

由于进程之间的切换需要较多的系统资源，而且进程之间的通讯效率也受到限制，因此为了减少系统开销、提高通信效率，在计算机系统中引入了线程的概念。线程使用进程的资源，不会从系统中获取新的资源，因此线程之间的切换很快。另外，同一进程中的各个线程可以通过直接读取数据段来进行通讯。

进程和线程之间，存在以下的关系：

（1）一个线程只能属于一个进程，而一个进程可以包含多个线程。

（2）系统将资源分配给进程，不同的进程有不同的地址空间。同一个进程的所有线程共享该进程的所有资源。

（3）线程在运行过程中，需要协作同步。同一个进程的线程可通过直接读写数据段进行通信，不同进程的线程之间要利用消息通讯的办法实现同步。

1.3.3 并发和并行

并发（concurrent）和并行（parallel）这两个概念，在数据库系统的资料中经常出现，然而有关它们的定义和区别却没有明确的说法。这里，我们根据这两个概念在资料中的使用，对它们的不同做一个说明。

并发是指多个任务的同时执行，任务与任务之间没有联系。由于数据库系统要同时为许多用户提供服务，每个用户都可以发出自己的访问请求，一个请求就是一个任务。在一个时间点，数据库系统可能要同时处理多个任务。因此，数据库系统一定要具备并发处理能力。

并行是指将一个任务划分为多个子任务，这些子任务同时执行。在所有子任务处理完成后，将它们的结果进行合并，就得到该任务的最终处理结果。在数据库系统中，如果要执行一个大的数据查询，为了提高速度、降低响应时间，用户可以通过系统配置或者在命令中，要求对该大数据量查询进行并行处理，将该查询划分成多个子查询。这些子查询同时执行，最后系统将所有子查询的处理结果进行合并，作为该查询处理的最终结果。现有的大型数据库系统都支持并行处理。

需要说明的是，并发和并行与数据库系统采用多进程还是多线程体系结构无关。对采用多进程结构的数据库系统，所有的任务、子任务通过进程来处理；而对采用多线程结构的数据库系统，这些工作是由线程来完成。

数据库系统的并发控制，涉及到任务的调度、数据的一致性及可靠性等，我们将在第6章进行介绍。而数据库系统的并行处理，主要涉及任务的处理速度、系统性能等方面，本书将不做讨论。

1.3.4 表空间和裸设备

空间是一块逻辑磁盘空间，用来存放数据库中的数据，可以建立在裸设备、操作系统文件、目录（只能在DB2数据库系统中使用）上。在创建数据库对象时，我们可以指定表空间，使对象中的数据只能存储在这个表空间中，从而可以有效地控制数据的存放位置。如果不指定表空间，系统就自动为它设定一个表空间，该表空间一般就是缺省表空间。有关表空间的进一步描述，可以参看第4章。

裸设备是一块物理磁盘空间，用户不能直接访问。对它的数据读写，需要通过操作系统底层调用。和操作系统文件相比，对裸设备的管理和维护不是很方便。然而也正是由于这一点，使用裸设备会更加安全、可靠，数据库系统不会轻易遭到破坏。在WINDOWS平台上，裸设备就是没有被格式化的磁盘分区。

如果表空间使用操作系统文件创建，在读取数据时，数据库系统要将数据读取请求交给操作系统，由操作系统将文件中的数据首先读入自己的内存缓冲区，然后再交给数据库系统处理，也就是从操作系统的内存缓冲区移动到数据库系统使用的内存缓冲区。在写数据到磁盘时，数据库系统首先将数据交给操作系统，也即从数据库系统的内存缓冲区移动到操作系统的内存缓冲区，最后由操作系统完成磁盘的写操作。

如果表空间建立在裸设备上，数据库系统对磁盘中数据的读取，就绕过操作系统，使用操作系统底层调用，直接存取磁盘。和操作系统文件相比，对裸设备的数据读取不需要操作系统的内存数据缓冲，因此加快了I/O处理速度。

1.4 常用数据库系统的体系结构

DB2、ORACLE、INFORMIX、SYBASE是我们常用的关系数据库系统。在WINDOWS平台下，它们都采用多线程体系结构，所有的功能模块通过线程来实现的。在UNIX平台下，它们的体系结构会有所不同。本书基于UNIX平台，我们下面就各系统在UNIX平台上的体系结构进行讲解。

1.4.1 DB2系统

DB2数据库系统使用单实例多数据库模式，采用多进程体系结构，所有的功能模块使用进程来实现的。整个系统的体系结构见图1-3（图中只画出整个实例的一个数据库）。

一个DB2系统实例需要启动的进程包括：（1）代理、监听进程等，这些进程在数据库管理器运行时启动；（2）异步预取、页清除、检查点、日志写进程等，这些进程在数据库运行时启动。需要为实例分配的内存空间包括：数据库管理器共享内存（在数据库管理器运行时分配）、进程专用内存（在代理、监听、异步预取、页清除等进程启动时分配）、数据库全局内存（在数据库运行时分配）。一个数据库的存储结构包括：配置文件、历史文件、容器、日志文件等，这些存储空间在数据库创建时建立，可以在运行过程中给数据库增加容器。

在一个DB2系统的实例中，可以创建多个数据库。数据库和数据库之间互相隔离，互不影响，这主要体现在：

（1）每个数据库有单独的进程，如：异步预取、页清除等，执行本数据库的相关操作。

（2）每个数据库有单独的内存结构（数据库全局内存），存放本数据库运行过程中要处理的数据及控制信息。

（3）每个数据库单独保存和维护自己的数据字典、用户数据，所有的存储资源，如：表空间、容器等，不能在多个数据库之间共享。

（4）每个数据库有单独的配置文件，可以根据需要对本数据库进行设置，使本数据库具有不同于其它数据库的运行特性。

（5）每个数据库有单独的日志文件，存放本数据库中事务所产生的所有日志信息。

由于以上原因，DB2系统还存在一个数据库管理器，用来管理和监控所有数据库及整个实例的运行。在每一次启动数据库系统实例时，首先要启动数据库管理器。数据库管理器的启动，将获取以下资源：

（1）启动监听、代理、监控进程等。监听进程接受客户端的访问请求，然后交给代理进程处理；监控进程监测所有数据库的运行状况并记录相关信息。

（2）获取内存空间。为要启动的进程分配专用内存空间，创建数据库管理器使用的共享内存。

在数据库管理器正常启动后，可以使用以下两种方式启动数据库：

（1）手工启动。使用命令，激活要启动的数据库。在数据库不再被使用后，仍旧需要使用命令关闭数据库。

（2）自动启动。在第一次接收到用户对数据库的连接请求后，系统就自动激活对应的数据库。在数据库的所有连接都断开之后，系统就自动关闭数据库。

在数据库的启动过程中，需要为数据库启动相关进程、分配共享内存空间，然后将相关数据字典信息读入内存。由于这些原因，为避免第一次访问数据库时的较慢响应，可以在数据库管理器正常启动后，手工启动数据库。

整个DB2系统的配置参数可以在数据库管理器、数据库两个级别上设置，数据库管理器的配置在整个实例上起作用。

数据库中用来存放数据的表空间，建立在容器上，容器可以是目录、操作系统文件、裸设备。

此外，DB2系统还有一个管理服务器，用来方便客户端管理软件对数据库服务器的访问，运行定时执行的程序脚本。该DB2系统部件是可选的，我们这里不再深入讲述。

1.4.2 ORACLE系统

在有些ORACLE系统资料中，只是将启动的进程、分配的内存空间合称为实例，这种说法应该不是很确切。

ORACLE系统实例也是数据库系统的具体化，是用户根据自身需要建立的一个运行环境，并通过这个运行环境来管理和维护数据库中的数据。在这一点上，ORACLE系统的实例和其它数据库系统的实例完全一样。仅仅所不同的是，在并行运行环境下，多个ORACLE系统实例可以同时管理同一个数据库中的数据。因此，除了启动的进程、分配的内存空间之外，我们说ORACLE系统实例还包括设置运行环境的各种配置信息、存放数据的数据库等，只不过这个数据库被共享使用，可以归属到多个实例中去。

ORACLE数据库系统使用多实例单数据库模式，访问和管理同一个数据库的不同实例可以运行在不同的节点计算机上。系统采用多进程体系结构，所有的功能模块是使用进程来实现的。整个系统的体系结构见图1-4（图中只画出数据库的一个实例）。

一个ORACLE系统实例需要启动的进程包括：进程监控进程（PMON）、系统监控进程（SMON）、数据库书写器进程（DBWR）、日志书写器进程（LGWR）、检查点进程等，需要为实例分配的内存空间包括：程序全局区、系统全局区（共享池、缓冲区高速缓存、重做日志缓冲区等）。一个数据库的存储结构包括：参数文件、密码文件、数据文件、日志文件等，这些存储空间在数据库创建时建立，可以在运行过程中给数据库增加数据文件。

ORACLE系统实例的启动，可以分为以下两个步骤：

（1）启动进程、分配内存空间。在这个启动过程中，系统根据配置信息，启动实例需要的各种进程，如：进程监控进程等；分配实例需要的进程专用内存（程序全局区）、共享内存（系统全局区）。

（2）打开数据库。在这个过程中，系统会检查数据库的控制信息、数据的一致性。只有所有状态都正常，数据库才能被打开，用户才能进行数据的访问。

数据库中用来存放数据的表空间，建立在数据文件上，数据文件可以是操作系统文件、裸设备。

1.4.3 INFORMIX系统

INFORMIX数据库系统使用单实例多数据库模式，采用多进程、多线程系统结构。由于进程相对于数据库系统就好比CPU相对于计算机一样，因此在INFORMIX系统中，进程被称为虚拟处理器（virtual processor，VP）。之所以称为虚拟处理器，表明它并不是物理上的处理器。整个系统的体系结构见图1-5。

一个INFORMIX系统实例需要启动的进程包括：CPU、AIO、LIO、PIO、ADM、SCO等，需要为实例分配的内存空间包括：常驻部分（缓冲池、锁表、逻辑日志缓冲区、物理日志缓冲区）、虚拟部分（字典高速缓冲、线程会话信息、SQL语句缓冲区）、虚拟扩展部分、通讯部分、VP专用部分。数据库的存储结构包括：配置文件、大块、归档日志文件等，这些存储空间在实例创建时建立，可以在运行过程中给数据库增加大块。

在INFORMIX系统的一个实例中，存在多个数据库，分为系统数据库和用户数据库。系统数据库在实例初始化时自动创建，存放实例级别上的监控信息、数据字典信息，用户能够访问而不能修改这些数据。一个实例需要创建的系统数据库有：sysmaster和sysutils。用户数据库由用户根据需要创建，存放用户数据以及和该数据库有关的数据字典信息。

INFORMIX系统实例的数据库和数据库之间，关系比较紧密，这主要体现在：

（1）共用实例进程、线程模块。实例的进程和线程可以访问和处理所有数据库中的数据，用户对数据库的访问就通过这些进程和线程完成。实例的进程和线程在实例运行时被启动。

（2）共用系统内存空间。用户要处理数据库中的数据，首先要将它们读入内存，存放在为实例分配的系统内存空间中。实例的系统内存空间为所有数据库所使用，在实例运行时被分配。

（3）共用存储空间。实例中用来存放数据的表空间，可以为所有数据库使用。一个数据库可以跨越多个表空间，而一个表空间也可以存放多个数据库的数据。

（4）共用数据库日志文件。在实例中被处理事务所产生的所有日志信息，存放在共同的日志文件中，这些事务所处理数据可以来自任何数据库。

在启动实例时，系统根据配置信息，启动实例需要的各种进程（如：CPU、AIO等），分配共享内存空间（如：常驻部分、虚拟部分等），并同时打开所有数据库。另外，实例的表空间，建立在大块（chunk）上，大块可以是操作系统文件、裸设备。

1.4.4 SYBASE系统

SYBASE数据库系统使用单实例多数据库模式，系统采用多线程体系结构，所有的功能模块都是使用线程来实现的，启动这些线程的进程被称为引擎（engine）。整个系统的体系结构见图1-6。

一个SYBASE系统实例需要启动的进程就是引擎，需要为实例分配的共享内存空间包括：内核和服务器结构（堆栈缓冲、控制信息缓冲、数据字典高速缓存、锁表高速缓存）、数据高速缓存、过程高速缓存、可执行代码区。数据库的存储结构包括：配置文件、设备、归档日志文件等，这些存储空间在数据库创建时建立，可以在运行过程中给数据库增加设备。

在SYBASE系统的一个实例中，存在多个数据库，分为系统数据库和用户数据库。用户数据库由用户根据需要创建，存放用户数据以及和该数据库有关的数据字典信息。系统数据库在实例初始化时自动创建，包括：master、sybsystemprocs、model、tempdb等，不同的系统数据库有不同的作用。

（1）master数据库存放所有数据库以及实例的管理和控制信息，在遭到破坏后整个实例就无法启动。

（2）sybsystemprocs存放SYBASE系统提供的执行过程，用户通过对这些过程的执行，来管理数据库系统。

（3）model数据库是一个数据库模板，所有新建数据库均按照这个模板创建。可以对model数据库进行设置，使所有新建数据库自动获得某些属性，这样就可以避免对单个数据库的设置操作。

（4）tempdb数据库是系统运行过程中，临时表、临时工作区的可用磁盘空间。一些大的查询、更新处理需要这些空间存放处理过程中产生的中间结果。

其它的系统数据库，如：sybsecurity、sybsystemdb、sybdiag、dbccdb等，并不是系统运行所必需的，这里不做介绍。

用户能够访问、修改系统数据库中的数据，这是其它数据库系统所不具备的。这种管理方式虽说增加了用户管理的灵活性，但不正确的使用也可能造成整个系统实例的破坏。

尽管每一个数据库都单独存放自己的日志信息，但一个实例的数据库和数据库之间，关系仍旧比较紧密，这主要体现在：

（1）共用实例线程模块。实例的线程可以访问和处理所有数据库中的数据，用户对数据库的访问就通过这些线程完成。实例的进程和线程在实例运行时被启动。

（2）共用实例内存空间。用户要处理数据库中的数据，首先要将它们读入内存，存放在为实例分配的系统内存空间中。实例的系统内存空间为所有数据库所使用，在实例启动时被分配。

（3）共用存储空间。实例中用来存放数据的表空间可以为所有数据库使用。一个数据库可以跨越多个表空间，而一个表空间也可以存放多个数据库中的数据。

在启动实例时，系统根据配置信息，启动引擎及各种线程，分配共享内存空间（如：过程高速缓存、内核和服务器结构等），并同时打开所有数据库。

在SYBASE系统中，表空间被称为设备，用户可以使用操作系统文件、裸设备来建立数据库设备。

1.5 常用数据库系统的特点

尽管常用关系数据库系统：DB2、ORACLE、INFORMIX、SYBASE，在操作、使用、维护等方面存在着很大的差异，但它们在数据库技术的相关理论上是一致的。因此用户在深入了解一种系统之后，就可以很快地掌握另外几种系统。

不同的系统各有其特色。用户往往根据自身对不同系统的偏爱、熟悉程度，来选择要使用的数据库系统。然而，了解各系统的特点，对我们更好地管理和维护系统，还是有很大的帮助。

1. DB2数据库系统

I/O操作一般是系统的运行瓶颈，DB2系统的I/O处理有自己独特的一面。不管表空间使用目录、操作系统文件还是裸设备作为容器，系统都会把表空间中的数据均匀地分布到每一个容器中。如果表空间的容器被放置在不同的磁盘上，将有效地提高I/O的并行处理能力，从而提高系统的I/O处理速度。

对DB2系统的并行处理环境，大多是一个节点运行在一台主机上，每一个节点拥有数据库的一部分数据。系统在处理事务时，会将事务划分为多个子事务，分别在每一个节点上执行，最后将所有子事务的处理结果合并后返回客户。

DB2系统的优化器功能强大，CPU频率、网络通信流量等都是优化器在优化SQL语句时要考虑的因素，强大的优化功能自然要消耗大量的时间、系统资源。为避免这些消耗对系统运行性能的影响，DB2系统要求事先为应用程序中所有静态SQL语句进行绑定，生成执行计划后存放在数据字典中，这样就不用在运行过程中对这些SQL语句进行分析、优化。在数据库结构调整、重新收集了统计信息之后，就需要重新对这些SQL语句进行绑定，因而系统的管理和配置繁琐、复杂。

2. ORACLE数据库系统

从系统的具体实现过程来看，ORACLE系统更强调系统的可靠性、稳定性。例如：由专门的进程负责系统、事务的失败处理，强制在事务结束之前将日志写入磁盘，在每一个数据文件的头部写入检查点信息等等。这些处理方法也使系统的备份、恢复操作更加灵活、方便。由于任何系统都会存在缺陷，我们说ORACLE系统可靠、稳定，只是从它的具体实现过程来看，并不是说它不会出现系统宕机、无法启动等故障。

ORACLE系统可靠、稳定的实现是以牺牲性能作为代价。如果不能很好地规划和调整，系统运行就很大可能会出现性能上的问题。

对ORACLE系统的并行处理环境，大多是一个实例运行在一台主机上，多个实例共享磁盘阵列上的数据库。在一个实例中更新数据，其它实例就不能对相同数据进行更新处理。由于I/O操作往往是系统的运行瓶颈，多个实例对同一数据库中数据的竞争性访问，必然会进一步加大I/O处理的压力，进而降低整个应用系统的性能。

3. INFORMIX数据库系统

操作简单、管理方便是INFORMIX系统的特点。INFORMIX系统易于安装、配置，对它的管理，只需要使用一些简单的命令就可以完成，便于用户掌握和使用。然而它的系统可靠性一直是用户担心的问题。早期的INFORMIX系统版本，仅仅表空间所拥有数据文件的操作权限被改变，就可能造成整个数据库系统的损坏。另外，较少的系统性能、故障分析及跟踪工具，使用户很难对系统中出现的故障进行定位。

4. SYBASE数据库系统

SYBASE数据库系统的安全管理是它的一大特色。任何要访问数据库的用户，必须要在数据库中获得一个帐号、并进行授权，操作系统中的用户帐号是无法访问数据库的。其他的一些用户访问跟踪、数据库对象使用权限链，都很好地增强了系统的安全性。安全管理是SYBASE系统值得炫耀的地方，在它的系统管理资料中，使用了很大的篇幅进行安全管理方面的讲解。

相对于其他的数据库系统，SYBASE系统允许用户直接修改数据字典，这种处理方式增加了系统管理、维护的灵活性，但同时又可能造成数据库系统的意外损坏。尽管SYBASE系统的锁管理实现了死锁检测与恢复、锁超时机制，但许多使用SYBASE系统的用户都曾遇到过由死锁而引起的系统挂起故障。

5. 各数据库系统的比较

总体上来说，DB2、ORACLE系统采用多进程结构，要消耗更多的系统资源。在系统有足够资源的情况下，具有更大的管理、数据处理能力，适合于大数据量处理的应用系统；INFORMIX、SYBASE系统采用多线程结构，需要较少的系统资源，管理和操作简单，但对数据的处理能力有所降低，适合于中等规模的数据处理系统。

1.6 数据库系统的性能调整

每个用户都希望自己的数据库系统有很好的性能，能够非常快速地响应自己的处理请求。跟踪、监控数据库系统的性能状况，采取相关措施，提高系统的处理速度，是数据库管理员的工作职责。

数据库系统在启动时，需要启动进程，获取内存资源。它对用户请求的处理，就是从磁盘读取数据到内存，在内存中完成数据的更新、查询以及汇总处理，然后将已更新数据写入磁盘。从整个处理过程来看，数据库系统使用了以下三个方面的资源：CPU时间、内存空间、I/O存取。如果系统对所有用户请求的处理，在这些资源方面不存在等待和竞争，就不会存在系统性能的问题。

用户对数据库系统性能的调整和配置，就是让系统在CPU、内存、I/O等资源的使用上，相互协调、合理运用，不会在某一个资源上面存在瓶颈。对系统的性能调整，用户既不要感到害怕，不知道该从那里入手；也不要认为系统的性能调整很简单，只需要改变几个配置参数、执行几个简单的命令，就能够大幅度地提高系统的运行性能。

数据库系统的性能调整，最关键是要定位问题的所在，也即找出影响系统性能的关键因素。由于多方面的因素会影响到系统性能，而只有对最关键因素的调整，才能起到提高系统性能的目的。

数据库系统性能调整的具体操作和实现，是有规律和方法可以遵循的。要调整性能，可以从两个方面进行：系统配置调整和应用系统调整。

1. 系统配置调整

系统配置调整就是使用各种系统工具，不间断地跟踪、分析，发现系统运行过程中的资源使用瓶颈，通过改变系统的各种配置参数以及数据的存储方式和位置，改变系统资源使用，进而达到改善系统性能的目的。

要有效地改变系统的配置，决定合理的数据存储方式和位置，用户需要深入了解数据库系统的进程管理、内存空间的结构和使用、数据的存储管理，我们将在第2、3、4章，对这些方面进行介绍。

任何计算机系统的硬件资源都是有限的，不可能无限地满足所有用户处理的需要。要评价数据库系统性能的好坏，在于它对资源的使用是否协调，是否存在资源利用上的瓶颈。用户对数据库系统配置进行调整，就是要达到这一目标。

2. 应用系统调整

应用系统调整就是从应用程序出发，采取：调整数据库中表的结构、创建新的索引或者改变现有索引结构、改变SQL语句写法等手段，达到改善系统性能的目的。

在程序设计、开发上存在缺陷的应用系统，其对数据库系统性能的影响，最终也体现在系统对CPU、内存、I/O的资源使用上。通过应用程序调整，可以降低数据库系统对资源的使用，减少资源瓶颈的发生。

我们这里所说的应用系统调整，是指应用系统在投入使用后，数据库管理员可以采取的操作手段。这要求数据库管理员对优化器的处理过程、SQL语句的编写、事务的管理和并发控制等有深入地了解。有关这些方面的内容，我们将在第5、6章进行介绍。

需要说明的是，对应用系统的调整，最好在系统最初设计、开发时就考虑，这样可以获得事半功倍的效果。在系统投入运行之后再调整，将存在很大的局限性。毕竟这时要改变表的结构、SQL语句的写法，不是一件容易的事情。

很多程序设计、开发人员往往只关心应用系统的功能实现，而忽略对数据库系统性能的考虑。然而，一个设计、开发得很糟糕的应用系统，希望通过运行过程中数据库管理员的全力调整和维护，使数据库系统有一个良好的性能状况是办不到的。因此，在应用系统的设计、开发过程中，有数据库管理员的参与是非常有必要的。

3. 性能调整步骤

数据库系统的性能调整，是一个反复、不断执行的过程，不能指望通过一次调整，就能够使数据库系统永久地处于良好的性能状况。

由于数据库系统建立在操作系统之上，因此对它的性能调整离不开操作系统的性能调整。操作系统的性能调整过程，类似于数据库系统的性能调整过程，这里不再赘述。

此外，我们需要明白的是，任何一台计算机系统的硬件资源都是有限的，它的事务处理能力有一个极限值。在达到或者接近这个极限值之后，任何的性能调整都无济于事。因此在这种情况下，我们不能指望通过调整增加系统性能，对系统硬件资源进行扩充是唯一可以采用的手段。

在调整数据库系统性能时，我们大体上可以采取以下的步骤（见图1-7）：

（1）性能数据收集

要调整性能，首先要明确数据库系统性能低下的原因。这要通过对性能数据的分析而获得，不能凭空想象。收集性能数据，是数据库系统性能调整的第一步。我们可以使用数据库系统提供的各种工具收集数据，也可以从系统的各种信息文件中获取。

（2）数据分析和问题定位

性能数据的分析是一件繁琐而枯燥的工作，要从一大堆纷乱复杂的数据中，找出影响数据库系统性能的主要原因，不是一件容易的事情。这需要数据库管理员丰富的工作经验，对数据库系统的深入了解，以及对发现问题、解决问题的耐心和工作热情。

（3）调整策略的制定和执行

在确定了数据库系统性能低下的缘由之后，接下来的工作就是从系统配置、应用系统调整这两个方面入手，确定调整策略和手段，然后进行具体的实施。

（4）调整结果的验证

在调整操作实施之后，我们需要检验调整操作是否起作用，是否达到预期的效果。我们当然希望一次调整就能满足要求，但实际情况往往不是这样。有可能这次制定的调整措施存在偏差，调整操作没有起到作用；也有可能前面对系统性能低下的原因定位有误，调整操作反而进一步降低了系统性能。另外一种常见情况是，此次调整发生了作用，解决了前面找出的性能低下原因，但被掩盖、同样会引起性能问题的其他原因又浮现出来。例如：如果最初发现数据库系统性能低下的原因在于内存资源不足，在改变系统的内存参数配置，使数据库系统能够获得更多的内存资源后，内存资源不再是系统的性能瓶颈，但这时发现I/O处理成为制约系统性能提高的关键因素，我们就需要考虑对I/O的调整。

（5）性能调整的结束和开始

如果本次调整没有达到要求，就需要重复以上的过程。即使本次调整解决了性能低下的问题，但随着时间的推移，数据库系统会再次出现性能问题，这时就需要开始另外一次的性能调整。因此数据库系统的性能调整，要反复、不断地进行，数据库管理员要在日常工作中不间断地跟踪数据库系统的性能状态。

1.7 本章小结

数据的存储和管理经历了三个阶段：人工管理阶段、文件系统阶段和数据库系统阶段。而数据库技术的发展和演化，又经历了：层次数据库系统、网状数据库系统、关系数据库系统。现如今，关系数据库系统得到了广泛应用。

数据库管理系统由一个互相关联的数据的集合和一组用以访问这些数据的程序组成，这个数据的集合通常称作数据库。数据库系统有自己的进程管理、内存管理、存储管理、作业管理，和操作系统密切相关。对数据库系统的管理和维护，离不开操作系统的管理和维护。

实例是数据库系统的具体化，是满足用户需要的一个系统运行环境，包括设置运行环境的各种配置信息、存放数据的磁盘空间，以及实例启动之后根据配置信息启动的进程、分配的内存空间等。在实例和数据库之间，可以建立两种关系：单实例多数据库、多实例单数据库。

进程是指程序的一次执行过程。线程属于进程，是进程中执行运算的最小单位，一个进程的所有线程都共享该进程的内存地址空间。

并发是指多个任务之间的同时执行，而并行是指将一个任务划分为多个子任务，这些子任务同时执行。

裸设备是一块物理磁盘空间，用户不能直接访问。与操作系统文件相比，使用裸设备，能够提高I/O读写速度。

DB2数据库系统使用单实例多数据库模式，系统采用多进程体系结构。

ORACLE数据库系统使用多实例单数据库模式，系统采用多进程体系结构。

INFORMIX数据库系统使用单实例多数据库模式，系统采用多进程、多线程系统结构。

SYBASE数据库系统使用单实例多数据库模式，系统采用多线程体系结构。

数据库系统的性能调整，是一个反复、不断执行的过程，对它的性能调整离不开操作系统的性能调整。数据库管理员要在日常工作中不间断地跟踪数据库系统的性能状态。