对DB2故障处理及最佳实践的浅析

http://tech.hexun.com/2009-05-31/118164173.html

http://database.51cto.com/art/201009/224700.htm

　　我认为解决问题的关键在于分清问题的种类，并清楚每种问题的解决办法。另外很多的数据库的问题都是由于错误的操作，错误的配置引起的，所以本文在解释怎么样处理问题时也会给出一些好的建议，来避免产生问题。本文重点介绍实用的方法。

　　对问题的分类有很多种方法，在本文中我我采用了两种分类方案。

　　第一种方案是是否有错误码。即发生错误时是否同时返回了错误码，错误码既包括执行命令的返回码，也包扩应用程序的返回码。

　　有返回码的错误解决方案是，在db2 CLP中运行db2?SQLXXXX，然后根据对该问题的解释采取相应的解决方案。对没有错误码的问题，如数据库hang，CPU使用率过高等问题，解决问题的经验将非常重要，在本文中会有详细的说明。

　　根据错误码解决问题举例（在下文中，再出现需要用这种方法解决问题时将不再重复）：

　　如在连接数据库时发生错误

　　db2 connect to sample

　　SQL0332N There is no available conversion for the source codepage"1386" to

　　the target code page "819". Reason Code "1". SQLSTATE=57017

　　错误码分为返回码（SQL0332N）和原因码（Reason Code "1"），针对不同的原因码有不同的解决方案

　　运行db2 ? sql0332

　　从输出种可以看到对于reason code 1的解释是

　　……

　　1 source and target code page combination is not supported bythedatabase manager.

　　……

　　所以可以通过设置代码页来解决这个问题

　　db2set db2codepage=1386

　　db2 terminate

　　db2 connect to sample

　　就可以成功连接了。

　　第二种分类方案是按照问题的范围和性质进行分类。分类如下：

　　1．数据库实例问题

　　2．数据库问题

　　3．数据库性能问题

　　4．应用开发与数据库有关的问题

　　下面对每一类问题进行详细说明。

　　一、数据库实例的问题

　　数据库实例问题可以分为两种情况

　　1．实例无法启动，运行db2start后，直接返回错误码，如SQL1042C。

　　如果根据错误码信息无法解决，可以尝试如下方案：

　　重新更新该实例，以root身份登录，

　　cd /usr/opt/db2_08_01/instance/

　　./db2iupdt

　　Tip：常见的产生实例无法启动的原因

　　数据库安装了新的补丁后没有运行db2iupdt

　　数据库文件的权限被改成了777，数据库文件的权限是有要求的，所以不能将所有的文件都改成777的权限

　　数据库实例文件被删除或损坏

　　主机名与db2nodes.cfg里记录的不一致

　　2．运行db2start时，hang在那里，既不报错，也无法启动实例

　　这种情况一般是由于实例没有正常的停止造成的，一般运行下列命令可以解决：

　　su -

　　db2_kill

　　ipclean

　　su – root

　　(将所有的与该实例有关的db2进程杀死kill -9 )

　　然后重新启动实例。

　　3．数据库实例崩溃问题

　　遇到实例崩溃的问题，首先查看db2diag.log，根据里面的信息来分析数据库宕机的原因。再看db2dump目录中是否有trap文件。可以根据这些信息来分析原因，一般这类问题都需要IBM工程师协助解决。

　　宕机的原因可以分为两类，一类是数据库的BUG，即数据库的缺陷引起的，一般如果遇到了数据库的缺陷，都有临时的解决方案，或者通过安装最新的补丁来解决，对某些问题IBM也提供临时的修订来解决（需要付费）。另一类是操作系统，误操作等非产品问题导致的，对非产品问题导致的宕机尽量要避免。

　　Tip：常见的数据库宕机原因

　　系统的交换空间（paging space）用尽

　　数据库的某个进程被kill

　　二、数据库问题

　　1．数据连接问题

　　无法连接数据库，常见的错误有代码页错误，通讯协议错误，数据库状态错误等。

　　对代码页类错误，可以通过设置db2codepage,db2country来解决，这两个变量需要用db2set设置成与数据库一致的值。

　　当发生通讯类错误时，首先要要检查环境变量DB2COMM=TCPIP是否已经设置，然后要检查dbmcfg的SVCENAME，该变量可以直接设置成端口号，或者设置成服务名，该服务名要在services文件中设置成对应的端口号。要检查该端口号是否已经被其他服务占用。在启动数据库后，可以运行netstat–angrep，来查看该端口处于的状态。

　　TCP 0.0.0.0:50000 0.0.0.0:0 LISTENING

　　还有一种情况，当连接数据库时，数据库处于backup pending状态，无法连接。这是只要对数据库做一个备份就可以了。

　　Tip：通常导致数据库处于备份赞挂的原因

　　当一个数据库从循环日志改成归档日志时，数据库要求进行一次脱机备份，在重新启动数据库后，数据库就处于备份赞挂的状态

　　对于一个使用线形日志的数据库，当做load时，表空间会处于备份赞挂的状态，为了避免这种情况，load命令需要使用copyyes，或者nonrecoverable参数。

　　2．数据库损坏

　　数据库最严重的问题莫过于数据库损坏，那么当数据库损坏时，最好的办法是从备份恢复数据库。

　　如果无法从备份恢复，可以根据损坏的原因尝试相应的解决方案。

　　由于存储问题导致部分数据文件损坏，但是数据库还可以连接，这种情况可以采用导出数据库的表结果和数据的方法来恢复数据库。当然对损坏的表，导出是无法完成的，这是可以使用db2dart的导出数据功能来导出这些损坏的表的数据。

　　如果数据库损坏到已经无法连接的程度，那么除了从备份恢复，唯一的办法是使用db2dart来导出所有的数据了。

　　Tip：怎么样使用db2dart来导出数据

　　运行命令

　　db2dart /DDEL

　　＃Table t data formatting start.

　　＃Please enter

　　＃Table ID or name, tablespace ID, first page, num of pages:

　　＃(suffic page number with "p" for pool relative)，

　　按照提示输入表名，表空间id，起始页数，需要导出的页数

　　3．数据库的活动日志被删除

　　这个问题经常会遇到。也属于数据库损坏的一种情况。并且数据库无法连接。

　　首先考虑是否有可以恢复的备份，如果有，可以从备份恢复，然后前滚到日志的末尾，可以完全恢复该数据库。如果没有可用的备份来恢复，可以通过IBM的技术支持中心来协助解决。如果想自己解决那只有使用db2dart工具了。

　　Tip：怎么样避免数据库的活动日志被删除

　　启用数据库的镜像日志功能

　　启用数据库的日志出口程序，这样可以避免手工来删除活动日志目录中的日志

　　当一定要手工删除活动日志目录中的归档日志时，使用命令

　　PRUNE LOGFILE PRIOR TO log-file-name，]

　　可以避免失误将活动日志删除

　　三、数据库性能问题

　　数据库的性能问题一般不属于故障，但是当性能问题变得很严重时，就变成了故障。

　　解决数据库的性能问题，可以从以下方面入手，检查数据库的配置，如缓冲池，排序堆等是否合理；检查数据库是否收集过统计信息，准确的统计信息对语句优化起着重要的左右；对sql语句进行优化；查看是否有系统资源瓶颈。

　　确认性能问题首先要从系统的资源消耗来分析，一般可以借助操作系统的工具，如aix的topas命令。数据库的性能问题一般的表现是应用变慢，甚至没有响应。

　　Tip：怎么样快速定位问题

　　如果系统的CPU利用很高，IO很少，那么数据库的排序较多

　　如果系统的IO繁忙，CPU很多是wait，那么说明数据库有过多的IO

　　如果系统CPU，IO都很空闲，那么说明可以是有锁的问题

　　如果系统IO，CPU都非常忙，说明有执行代价非常高的sql在执行

　　数据库一般有三类的性能问题，一是CPU占用过多，二是IO过于繁忙，三是有锁等待。

　　1．快速找到执行成本较高的sql

　　首先要打开监视器的开关

　　db2 update monitor switches using bufferpool on lock on sortonstatement on table on uow on

　　在系统最繁忙的时候，运行

　　db2 get snapshot for all applications > app.out

　　然后在该文件中查找处于Executing状态的应用，找到执行的对应的sql语句。

　　如果用这种方法找不到，可以收集sql的快照

　　db2 get snapshot for dynamic sql on > sql.out

　　这个快照记录了动态语句的快照信息，可以根据

　　Total execution time (sec.ms) = 0.000000

　　Total user cpu time (sec.ms) = 0.000000

　　Total system cpu time (sec.ms) = 0.000000

　　这些信息来找到最耗时的语句。

　　2．怎么样优化sql语句

　　DB2提供了很好的工具来做sql语句优化。首先要对找到的sql语句进行分析，看是否是该语句引起了性能问题。我们可以使用db2expln来查看sql语句的访问计划和执行成本。

　　首先将找到的sql语句写到一个文本文件中sql.in，以“；”结尾，然后运行

　　db2expln –d -f -z “;” –g –o sql.exp

　　查看sql.exp可以看到这个sql语句的执行成本。

　　如果确认该语句有问题，可以使用db2advis来通过建索引的方法来优化该语句

　　db2advis –d -i sql.in

　　如果通过创建索引无法优化该语句，一般只能从业务角度优化。

　　3．如果发生锁的问题怎么样处理

　　发生锁的问题，一般有两种情况，一是锁等待，二是死锁。首先检查数据库配置参数locktimeout，该参数一定不能设为－1，因为会引起某些应用无限期的等待。

　　可以通过快照来确定数据库发生的问题是哪一种。

　　db2 get snapshot for db on

　　查看输出中的下列内容：

　　Deadlocks detected = 0

　　Lock Timeouts = 0

　　如果发生了死锁，可以通过创建死锁监视器来分析产生死锁的原因，命令如下：

　　mkdir /tmp/dlmon

　　db2 connect to

　　db2 create event monitor dlmon for deadlocks with detail writetofile "/tmp/dlmon" replace