DB2数据库目录结构及其作用

DB2数据库目录结构及其作用

我创建的数据库存储在什么地方

从DB2的架构上来看，DB2 中的数据库的层次位于实例之下。实例实际上就是一个逻辑的数据库管理器，它提供了一个相对独立的运行环境。数据库必须要被创建在某个实例之下，因此，在创建数据库之前，必须要先创建实例。每当一个新的实例被创建，DB2都会在DB2安装目录sqllib 下生成一个目录，其目录名称与实例名称相同，该目录下的文件用于对该实例进行管理和控制。另外，在使用CREATE DATABSE创建数据库之后，系统还将会生成一系列子目录，具体的目录结构如图1所示。

图1：数据库缺省目录结构

在图1中，"驱动器/目录"的具体值可以在CREATE DATABASE 命令中指定（对于Windows 平台，用户只能指定要创建数据库的驱动器；而对于Unix/Linux 平台，用户可以指定在哪个目录下创建数据库），如果没有在创建数据库的时候指定路径，系统将会在数据库管理器配置参数DFTDBPATH 指定的缺省路径下来创建相应目录。第一层子目录的目录名与实例名称相同，属于该实例的数据将会被存储在该目录下。第二层子目录指定了该数据库所属的数据库分区。在DB2 V8中，数据库分区取代了以前版本中的节点的概念。一个数据库分区是数据库的一个子集，拥

有自己的配置文件、数据、索引和日志。在多分区数据库环境下，一个数据库可以被划分为多个分区，不同的分区可以驻留在不同的物理机器上，从而提高整个数据库系统的处理能力。在这种环境下，每个分区都有自己的编号，这个编号会体现在数据库的目录结构中。比如，如果该分区的编号为3，则该层目录名称应为NODE0003。对于单分区数据库环境，该目录名固定为NODE0000。

接下来名称形如"SQL0000n"的目录对应着该实例下的相应数据库。数据库中的数据就存放在该目录下。在该实例下创建的第一个数据库对应的目录为SQL00001，第二个为SQL00002，依此类推。如果因为数据库被删除而导致编号不连续，在新创建数据库的时候，系统会优先使用最小的编号。要想察看某个数据库具体对应的目录，可以先通过LIST DATABASE DIRECTORY 察看数据库所驻留的驱动器/路径，然后再通过LIST DATABASE DIRECTORY ON <驱动器/路径>命令来察看对数据库所在的目录。

此外，还有一个名为SQLDBDIR 的目录，该目录中存储着与本地数据库目录相关的文件。本地数据库目录中驻留在每个存储着数据库的驱动器或者路径中，用于存取子目录下的本地数据库。该目录中存储的每个条目中包含着数据库名称、数据库别名以及数据库类型和数据库的位置信息。要想察看本地数据库目录的内容，可以通过下列命令：

LIST DB DIRECTORY ON <驱动器/路径>

数据库内部结构

不同的数据库中可能有不同的存储设定，因此子目录可能会有些差异。很多初学者在安装了DB2后都会创建一个样本数据库，我们就以这个数据库为例介绍一下数据库内部的结构，请参见图2。

图2. 数据库内部目录结构

下面我们对这些目录和文件加以分析：

DB2EVENT 目录

这个目录是DB2 事件监视器的缺省结果输出目录。事件监视器用于记录特定事件发生时数据库的活动，记录的结果可以被保存在表、命名管道或者文件中。当使用文件来记录监控结果时，需要指明输出文件的路径名称。如果使用的是绝对路径，则文件会输出到相应路径下，如果使用的是相对路径，则文件会被输出到对应数据库目录下的DB2EVENT 目录中。要察看监控结果的话，可以使用事件分析器这样的图形化工具，或者DB2EVMON 这样的文本工具。

db2rhist.asc 和db2rhist.bak 文件

db2rhist.asc文件也就是在备份和恢复过程中会用到的DB2 恢复历史文件。该文件随着数据库的建立而建立，当对数据库进行了备份、恢复以及LOAD 等操作时，该文件中都会记录相应信息。这些信息在进行恢复操作将起到至关重要的作用。该文件是如此重要，以至于为了防止该文件损坏，DB2 同时生成了一个db2rhist.bak 作为该文件的备份，而且，DB2 的restore 命令还允许从备份映像中单独恢复该文件。用户可以使用LIST HISTORY 命令来察看该文件的内容，也可以使用UPDATE HISTORY 命令和PRUNE HISTORY 命令来修改该文件，但不应当使用文本编辑器来直接处理。

SQLBP.1 和SQLBP.2 文件

这两个文件中包含数据库中缓冲池的信息，用于对缓冲池进行管理。SQLBP.2 和SQLBP.1 的内容完全相同，可以起到备份的作用。

SQLDBCON 文件

每个数据库都有自己的配置参数，这些配置信息都被存放在SQLDBCON 文件中，由于该文件是二进制格式，因此不能使用文本编辑器编辑，而应该使用GET DB CFG 以及UPDATE DB CFG 命令来察看和修改。

SQLINSLK 和SQLTMPLK 文件

这两个文件都是用来保证该数据库只能被数据库管理器的一个实例来使用。

SQLOGCTL.LFH 文件

这个文件就是日志控制文件，里面记录着日志文件的状态，特别是包含了一个叫作LOGHEAD的变量，该变量定义了当前第一个活动日志，该日志也是崩溃恢复的起点。在进行崩溃恢复的时候，DB2会利用该变量的值来决定使用哪些日志来进行崩溃恢复。LOGHEAD对于归档日志也有很重要的意义，该变量的值是归档日志文件和活动日志文件的分割点，文件名序号小于LOGHEAD的值的日志文件都可以被归档到其他位置。要察看改变量的值，可以使用GET DB CFG 命令。

SQLOGDIR 目录

这个目录是数据库缺省的日志文件存放目录。不过，由于日志文件是数据库恢复策略中的决定性因素，因此要尽量保证日志文件的可用性。如果使用缺省设置，数据库的日志和数据都存放在同一位置，一旦发生介质错误，有可能造成日志文件和数据同时丢失，导致数据库无法恢复。因此，对于关键性应用，建议更改数据库配置参数NEWLOGPATH 来修改日志文件的存储位置。

SQLOGMIR.LFH 文件

该文件与SQLOGCTL.LFH 文件的作用类似，不过专门适用于启用了镜像日志的DB2 环境。

SQLSPCS.1 和SQLSPCS.2 文件

这两个文件中包含了数据库中表空间的定义以及表空间的当前状态。如果这两个文件被损坏，数据库连接操作将会失败。

以上介绍的文件和目录都是用于管理和控制数据库的，而数据库中的数据都是被存储在表空间中。在创建数据库时，系统必须预先创建三个表空间-系统目录表空间、系统临时表空间以及缺省用户表空间，如果不特别指定，这三个表空间都会是SMS 表空间，由于SMS 表空间的容器类型只能是目录，因此DB2 会生成下列三个目录：

SQLT0000.0 目录

这个目录是系统目录表空间SYSCATSPACE 所使用的容器。用于存储系统目录表。系统目录表由一组以SYSIBM 为模式的表组成，是一个数据库的数据字典。系统目录表里面包含了三类信息。一类是数据库中所有数据库对象的定义信息；一类是数据库中的统计信息，在对应用程序进行优化时需要使用这些统计信息计算存取计划。此外，还有一类是数据库级别的授权信息。如果系统目录表空间处于异常，数据库连接操作将会失败。

SQLT0001.0 目录

这个目录是系统临时表空间TEMPSPACE1 所使用的容器，用于存储数据库系统在操作过程中生成的临时数据，比如排序、多表连接等操作时所形成的临时表。每个数据库中必须至少存在一个系统临时表空间。

SQLT0002.0 目录

这个目录是缺省用户表空间USERSPACE1 所使用的容器，用于存放用户创建的表。用户也可以在数据库创建后创建自己的用户表空间。

要说明的是，我们上面介绍的三个表空间都是通过缺省方式创建的，在实际应用中，用户可以在创建数据库的时候指明这三个表空间的类型以及容器。那样的话，看到的目录结构会有些不一样，但功能上是相同的。

走进SMS 表空间

DMS 表空间的容器类型是文件或者设备，其内部有独特的映射机制来控制存储空间的分配。而SMS 表空间则不同，表中数据的分配会非常有规律地体现在文件结构中。很容易分辨，由于本文介绍的是DB2 中不同文件的作用，因此我们会着重探讨SMS 表空间下数据的分配。下面我们来看一看样本数据库中缺省用户表空间下的文件。

图3：缺省用户表空间下的文件

由于在创建样本数据库时，系统已经创建了一些用户表，因此我们可以在SQLT0000.2目录下看到很多文件。在每个SMS 表空间容器中，都会有一个名为SQLTAG.NAM 的文件，DB2 会通过这个文件来验证数据的一致性。此外，由于一个容器只能属于一个表空间，因此DB2 还会通过该文件阻止其他表空间对该容器进行重复使用。除了该文件以外，我们可以看出其他的文件的文件名称都形如SQLnnnnn.。其中nnnnn 由一组数字组成，可以用来判定数据是属于哪个表的， 可以用来判定具体的数据类型。在表空间中，每个表都有自己唯一的ID，表名称和ID 之间的对应关系可以通过系统目录视图SYSCAT.TABLES 和SYSCAT.TABLESPACES很方便地得到。首先，我们先要得到表空间名称和表空间ID 的对应关系。

SELECT TBSPACE, TBSPACEID FROM SYSCAT.TABLESPACES

通过上面语句的查询结果可以得出USERSPACE1 的表空间ID 为2，然后再通过下面的命令得出USERSPACE1 中表名称和表ID的对应关系。

SELECT TABNAME, TABLEID FROM SYSCAT.TABLES WHERE TBSPACEID =2

假定我们看到样本数据库中表EMP_PHOTO的ID 为8，则文件名称形如SQL00008. 的文件都与EMP_PHOTO 相关联。如果文件的扩展名为.DAT，则说明该文件中包含的是EMP_PHOTO 表中的常规（REGULAR）数据，也就是除了LONG VARCHAR、LONG V ARGRAPHIC、CLOB,BLOB 以及DBCLOB之外的数据，每个数据行中这类数据的大小不能超过一个数据页；如果文件的扩展名为.LF，则说明该文件中包含的是表中的LONG VARCHAR 或者LONG VARGRAPHIC 数据，由于EMP_PHOTO 表中不存在这类数据，因此不存在SQL00008.LF 文件；如果文件的扩展名为.LB，则说明该文件中包含的是EMP_PHOTO 表中的BLOB、CLOB 和DBCLOB 数据；如果文件的扩展名为.LBA，则说明该文件中包含的是EMP_PHOTO 表中BLOB、CLOB 和DBCLOB 数据的空间分配信息，该文件与.LB 文件是成对出现的；如果文件的扩展名为.INX，则说明该文件中包含的是EMP_PHOTO 表上建立的索引数据。除此之外，如果创建了多维群集(MDC) 或者对表进行了重组，则还

可能会出现其他一些扩展名，我们这里就不再介绍了。

DB2 实例目录中的重要文件

在前面我们已经提到过，在创建一个实例以后，DB2 还会在sqllib 目录下生成一个目录，其目录名称与实例名称相同。该目录下包含了很多与控制该实例运行的重要文件。当删除一个实例的时候，DB2 实际上只是删除该目录，而不是真正删除实例中的所有数据。因此重新创建实例后，还可以通过编目命令使原来实例下的数据库重新投入使用。该实例下的文件如图 4 所示：