DB2 日常维护技巧，第 1 部分

级别： 初级

程永 ([e-mail]), 高级信息工程师, IBM
王雪梅 ([e-mail]), 高级数据库工程师, 自由撰稿人


2008 年 11 月 27 日

本文主要介绍数据库管理员（DBA）在日常维护中遇上一些比较紧急的情况如何处理，如何形成自己的应急方案，以及在日常维护中需要注意哪些技巧。“ DB2 日常维护技巧，第 1 部分”主要包括删除活动日志文件后如何处理、数据库事务日志已满如何处理、没有正确设置数据库代码页如何处理等。
删除活动日志文件后如何处理

1、恢复日志文件

数据库的日志文件主要是用来保存数据库更改的记录。数据库的日志管理方式有两种：循环日志模式和归档日志模式。循环日志模式是缺省模式（logarchmeth1 和 l ogarchmeth2 数据库配置参数被设置成 OFF），在这种方式下，有几个限制，分别为：

只能脱机数据库备份，不能联机数据库备份。
不能进行增量备份，也不能进行差异备份。
不能进行表空间级别备份，只支持数据库级别备份。
不能进行前滚恢复
在循环日志模式下，日志文件会被循环使用。日志仅保留到当前事务完成时为止。正常情况下，数据库仅使用主日志文件（由 LOGPRIMARY 数据库参数控制）来记录数据库的更改，只有当主日志文件使用完的情况（事务都在进行中，没法释放出新的资源给新的事务使用）下，才会按需新开辅助日志文件，当新开的辅助日志文件使用完成后，就会关闭掉。主日志文件在第一次 ACTIVATE DATABASE 命令运行后或第一次数据库连接后在内存中分配。辅助日志文件只有当主日志文件满时才会新开。循环日志模式具体如图 1 所示：


图 1. 循环日志模式


崩溃恢复期间，使用活动日志来防止故障（系统电源或应用程序错误）使数据库处于不一致的状态。活动日志位于数据库日志路径目录中。

在归档日志模式下，就没有上面循环日志模式下的限制，可以进行脱机数据库备份，也可以进行联机数据库备份，可以进行表空间备份，可以前滚恢复数据库，可以进行增量备份、差异备份等。已经归档的日志记录是用来前滚恢复的，而崩溃恢复则不需要使用这些已经归档的日志记录。在归档日志模式下，平时数据库也仅使用主日志文件（由 LOGPRIMARY 数据库参数控制）来记录数据库的更改，只有当主日志文件使用完的情况（事务都在进行中，没法释放出新的资源给新的事务使用）下，才会按需新开辅助日志文件，当新开的辅助日志文件使用完成后，就会关闭掉。主日志文件在第一次 ACTIVATE DATABASE 命令运行后或第一次数据库连接后在内存中分配，并且当某一个主日志文件使用完毕后（这个日志中所有的事务都已经处理完毕，一个事务可以跨多个日志文件），其是通过改名的方式把日志文件由在线活动日志变成脱机活动日志，而内存中已经打开的主日志文件并不关闭而是改成新的日志文件名。在归档日志模式下，活动日志不再是循环使用，而是用完的日志文件将变成脱机方式，并且由数据库管理器进行归档。归档日志模式具体如图 2 所示：


图 2. 归档日志模式


2、如何处理

DB2 的活动日志文件（指的是数据库参数 Log Path 目录中存储的日志文件）不能被删除。一旦 DB2 的活动日志文件被删除，或者所在的存储设备出现问题，则不可避免地造成 DB2 数据库系统宕机。日志文件路径由数据库配置参数 Log Path 控制。如果要修改，使用数据库配置参数 NEWLOGPATH 。

如果删除了 DB2 数据库的活动日志文件，则不可避免地造成 DB2 数据库系统宕机。如果你有现有 DB2 数据库的备份，建议由备份恢复数据库。请在执行恢复之前，确认：

数据库备份可用
数据库备份如果是 Online 的，则相关的日志文件要存在
如果可能，先保存当前的错误环境；或者将当前的环境进行文件系统的备份
如果没有数据库备份，但是你使用了 DB2 到 DB2 的复制功能，把当前数据库准实时复制到了另外一个数据库，可以从另外一个数据库把数据倒回来。

如果既没有数据库备份也没有使用 DB2 的复制功能建立备份库，而这个时候你有 PPA 服务，请找 IBM 800 的工程师提请实验室重置日志控制文件，然后重建数据库，具体如下：

致电 8008101818 － 5200，提供 ICN（IBM Customer Number） 或 PPA Number ，对于生产系统宕机，PPA 是提供 24 × 7 服务。
停止实例。
准备 db2level 输出和日志控制文件 SQLOGCTL.LFH 文件（DPF 下每个实例都要提供）。
将重置过的日志控制文件放回原处（注意 FTP 时选择正确的方式 BIN) 。
启动数据库，连接数据库，确认重置的控制文件可用（DPF 相关操作更复杂）。
停止实例，确保实例是由 db2stop 非 db2stop force 停止的。
用 db2dart 工具检查数据库对象的完整性，db2dart 检查没有问题并不代表数据库对象一定是一致的。
重建数据库。
使用这种方式重建数据库，仍会有数据丢失，这点需要注意。数据库的重建时间视数据库大小而定，需要有 2 倍于数据库实际大小的存储空间导数据。如果没有 PPA 服务，则只能使用 db2dart 命令导出裸数据，重建数据库，而数据库里的 LOB 字段，将全部舍弃无法恢复。






回页首




交易日志存储空间满如何处理

在归档日志模式下，如果没有使用自动归档方式或者自动归档配置出现故障（比如磁带机出现故障，存储管理软件出现故障等等），则存储的日志文件会不断增多，有可能造成日志所在的文件系统空间满。 当这种情况发生时，会根据参数 BLK_LOG_DSK_FUL 的配置而有不同的现象：

如果该参数启用，则 DB2 数据库可继续读操作，但是写操作会挂起。
如果该参数没有启用，则 DB2 数据库会停止工作。
两种情况下，都需要到日志所在的文件系统添加了空间后整个数据库才会恢复正常。

BLK_LOG_DSK_FUL 数据配置参数主要就是为了防止当活动日志所在的当前目录满了（不能继续创建新的日志文件）时 DB2 马上停止工作。如果启用了此参数（如上面所述的情况 1），也就是将 BLK_LOG_DSK_FUL 数据配置参数设置成 YES，当活动日志所在目录不能创建新的文件时，遇到日志磁盘已满错误的应用程序将挂起，从而使您可解决该错误并允许事务完成。

日志所在的文件系统空间已满以后应采取如下措施。将旧日志文件，注意不要是活动日志文件，移至另一个文件系统或扩充文件系统，建议在创建数据库之初就创建一个第三方路径用来存放归档日志文件，存储管理软件从第三方路径拿走归档日志文件，当存储管理软件出现问题时，也可以手工从第三方路径里拿走归档日志文件，不建议直接从活动日志目录中拿走文件，如果实在没有办法，比如从活动日志目录拿走文件，建议从最旧的部分在执行完 archive log 命令后挪走而不是删除。正确的处理方法是，增加活动日志目录所在文件系统的存储空间，并立即配置或修复自动归档功能。 一定要注意不要删除活动日志文件，如果删除了活动日志文件，就会使 DB2 系统宕机，具体说明可以参照本章第四节详细描述。如果管理员手工归档，需要注意 “ 首个活动日志文件即 First Active Log ”数据库配置参数在某些情况下是不准的，在归档的日志文件的时候记得要多留一些日志文件 。

当 BLK_LOG_DSK_FUL 数据配置参数设置为 NO 的时候（也就是上面说的情况 2），当活动日志所在目录不能创建新的日志文件时，接收日志磁盘已满错误的事务将会失败并回滚。






回页首




数据库事务日志已满如何处理

1、数据库事务日志的最大大小

数据库事务日志的最大大小由数据库的三个配置参数决定，分别是“主日志文件的数目”（LOGPRIMARY）、“辅助日志文件的数目”（LOGSECOND）和“日志文件大小（4KB）”（LOGFILSIZ）。数据库事务日志的最大大小的计算公式如清单 01-32 所示：


清单 1. 数据库事务日志的最大大小的计算公式
数据库事务日志的最大大小 = （ LOGPRIMARY + LOGSECOND ）* LOGFILSIZ * 4KB


LOGSECOND 在这个公式中不能设为 “ -1 ” ，“ -1 ”代表你在请求一个无限的活动日志空间，数据库也不会报数据库事务日志已满错误，如果空间不足则会报日志磁盘已满错误，具体如本章第五节所述。下面我们具体看一下这三个参数：

主日志文件的数目 LOGPRIMARY
此数据库配置参数用来指定要预分配的主日志文件个数。主日志文件建立分配给恢复日志文件的固定存储器数量。在循环日志管理模式下，数据库事务将按顺序重复使用主日志，也就是当一个主日志已满时，顺序使用下一个主日志，如果主日志已满，则按需一次分配一个辅助日志，辅助日志在使用完后，将被释放。如果你发现数据库会经常分配辅助日志文件，则可能需要通过增大日志文件大小或增大主日志文件的数目来提高系统性能。
辅助日志文件的数目 LOGSECOND
此数据库配置参数用来指定按需分配的辅助日志文件个数。尽量不要把此参数的值设置成“ -1 ” ，“ -1 ”代表你在请求一个无限的活动日志空间，数据库也不会报数据库事务日志已满错误，如果空间不足则会报日志磁盘已满错误。
日志文件大小 LOGFILSIZ
此数据库配置参数用来指定日志文件的大小。
2、数据库事务日志已满错误

数据库事务日志已满错误是指当前事务无法写入到活动日志中（此时主日志文件和辅助日志文件已经全部用完或者没有足够当前事务写入的空间），需要注意的是，这个错误和日志磁盘空间已满是两个概念，如果想查看日志磁盘已满错误，请参照本章第五节。数据库事务日志已满不是由于磁盘空间满引起的，而是由于没有落实的事务总体过大，超过了数据库事务日志所能容纳的最大大小所造成的。

一般系统上线之初（如果是分阶段上线，则是每次上线之初），由于经常要导大量的数据，容易出现这个问题，当出现这个问题时，直接的办法是找到引起这个错误的当前事务，终止掉这个事务即可，后续在操作时找到当前执行的事务中比较大的事务，尽量落实或回滚该事务。

一般情况下，建议大家在系统上线之初进行导数时，尽量使用 LOAD 实用程序（如果是归档日志模式，建议使用带 NONRECOVERABLE 选项的 LOAD 实用程序，否则装入完成后数据库或装入的表所在的表空间会被置于备份暂挂状态，需要做一次全备才能解除备份暂挂状态），LOAD 实用程序在装入数据时不记日志。

如果使用 IMPORT 实用程序，建议使用 COMMITCOUNT 选项。无论是循环日志模式还是归档日志模式，使用 IMPORT 实用程序导入大量数据时，都有可能报数据库事务日志已满（也就是当前导入操作产生的事务过大，使得当前活动日志满了，包括所有的主日志和辅助日志都用完了），所以为了避免数据库日志已满错误，提高并发性，可以使用 COMMITCOUNT 选项，对要导入的数据分阶段提交。比如可以将 COMMITCOUNT 参数设置为“自动”，指示 import 实用程序 内部决定何时进行落实。此外，也可以将 COMMITCOUNT 选项设置为特定数字，指示 import 实用程序 在导入指定记录数后即进行落实。

尽量避免在上线之初直接使用“ INSERT INTO … SELECT .. FROM .. ”语句，导入一个很大的事务的方式进行导数，这样会使事务非常大。另外，还可以在系统上线之初把主日志文件的数目（LOGPRIMARY）、辅助日志文件的数目（LOGSECOND）和日志文件大小（4KB）（LOGFILSIZ）三个参数调大，等系统正式上线稳定后，再调回合适的值。

如果是在正式上线后的系统，经常出现这个问题，就需要查找原因，具体的原因可能有：

数据库并发连接比较多
这种情况下，就要考虑适当增加主日志文件的数目（LOGPRIMARY）和日志文件大小（4KB）（LOGFILSIZ）。
有人通过第三方软件或其他工具直接连接到了生产库
在这样的情况下，就要监控数据库，看其是否经常写一些大的语句对数据库进行增删改的操作，如果是的话，建议增加数据库的控制，尽量不要让不相关的人员连接生产库（如果其他人有需要，尽量开放备份库给他们使用，而不要开放生产库，生产库尽量只给业务系统正常使用），如果你使用的是 DB2 V9.5 版本，则可以使用工作负载管理 WLM 对数据库的资源进行调配。如果使用的是 DB2 V9.5 之前的版本，则可以在数据库服务器上通过配置操作系统的方式，限制一些 IP 的访问。
当出现这样的错误时，不要尝试使用 DB2STOP FORCE 命令来强制停掉数据库，建议大家使用 FORCE APPLICATION 命令停掉引起这个错误的应用程序或者停掉所有的应用程序。也不建议大家使用 KILL 命令来杀掉任何 DB2 相关的进程。






回页首




没有正确设置数据库代码页

由于数据库的代码页在数据库创建之后是无法修改的，所以在创建数据库时一定要选择正确的代码页。当应用程序和数据库使用的代码页不相同时，则在处理中文等情况下需要进行字符转换，因为在应用程序和数据库代码页直接映射数据需要其他开销，会使数据库性能受到影响。在某些情况下，不合适的数据库代码页会造成 JDBC、ODBC 等访问中文字段被截断（包括控制中心），这种情况需要重建数据库以修改数据库代码页。从全局规划来说，如果应用需要访问多个数据库，那么这多个数据库的代码页应该是一致的。

按照需要，设置正确的代码页。数据库代码页可以在创建数据库时指定：

CREATE DB 中可以显式指定数据库代码页。
在 DB2 V9.5 之前的版本中，CREATE DB 中未指定数据库代码页则取环境变量 db2codepage, db2country ；如果 db2codepage, db2country 没有指定，则取 Locale 。
在 DB2 V9.5 中，如果 CREATE DB 中没有指定数据库代码页，默认值将是 UTF-8 。
当你遇到这样的问题时（在创建数据库时指定了不正确的代码页），需要先将数据库中的数据导出，然后重建数据库，再将数据导入。如果有疑问，建议拨打 IBM 技术支持中心的电话：8008101818 。