db2 file and directory

很多刚刚接触 DB2 的朋友，可能会发现 DB2 中有着形形色色的文件，但并不了解这些文件所起的作用。本文将对 DB2 中的重要的文件进行介绍。这些文件有些用于数据的存储，有些则用于 DB2 系统的管理和配置。
必要性
其实，在数据库技术发展的早期阶段，科学家们所致力于解决的最大问题就是数据的独立性，即将数据库的逻辑操作与物理操作分离，使得数据库用户只需要指明要存取的信息，而不需要知道要存取的信息所存储的位置就可以对数据进行操作。上个世纪 70 年代，IBM 公司的科学家 Edgar Codd 发明的关系模型彻底解决了这一问题，使得数据库开发人员从单调的数据操作物理细节中解放出来，可以将注意力转移到特定应用程序上下文中数据的逻辑操作上。
虽然说用户可以在不了解 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 文件
这两个文件中包含了数据库中表空间的定义以及表空间的当前状态。如果这两个文件被损坏，数据库连接操作将会失败。

谢谢，db2diag.log文件可以删除吗？

[quote]原帖由 [i]fck[/i] 于 2007-7-17 14:28 发表 [url=http://www.loveunix.net/discuz/redirect.php?goto=findpost&pid=691422&ptid=74803][img]http://www.loveunix.net/discuz/images/common/back.gif[/img][/url]
谢谢，db2diag.log文件可以删除吗？ [/quote]

可以删。不过最好是清空，而不是删除。

db2diag.log可以archive备份出来的

ok,多谢！