我认为解决问题的关键在于分清问题的种类,并清楚每种问 题的解决办法。另外很多的数据库的问题都是由于错误的操作,错误的配置引起的,所以本文在解释怎么样处理问题时也会给出一些好的建议,来避免产生问题。本 文重点介绍实用的方法。
对问题的分类有很多种方法,在本文中我我采用了两种分类方案。
第一种方案是是否有错误码。即发生错误时是否同时返回了错误码,错误码既包括执行命令的返回码,也包扩应用程序的返回码。
有返回码的错误解决方案是,在db2 CLP中运行db2 ? SQLXXXX,然后根据对该问题的解释采取相应的解决方案。对没有错误码的问题,如数据库hang,CPU使用率过高等问题,解决问题的经验将非常重要,在本文中会有详细的说明。
根据错误码解决问题举例(在下文中,再出现需要用这种方法解决问题时将不再重复):
如在连接数据库时发生错误
db2 connect to sample
SQL0332N There is no available conversion for the source code page "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 by the database 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是否已经设置,然后要检查dbm cfg的SVCENAME,该变量可以直接设置成端口号,或者设置成服务名,该服务名要在services文件中设置成对应的端口号。要检查该端口号是否 已经被其他服务占用。在启动数据库后,可以运行netstat –an |grep,来查看该端口处于的状态。
TCP 0.0.0.0:50000 0.0.0.0:0 LISTENING
还有一种情况,当连接数据库时,数据库处于backup pending状态,无法连接。这是只要对数据库做一个备份就可以了。
Tip:通常导致数据库处于备份赞挂的原因
当一个数据库从循环日志改成归档日志时,数据库要求进行一次脱机备份,在重新启动数据库后,数据库就处于备份赞挂的状态
对于一个使用线形日志的数据库,当做load时,表空间会处于备份赞挂的状态,为了避免这种情况,load命令需要使用copy yes,或者nonrecoverable参数。
2.数据库损坏
数据库最严重的问题莫过于数据库损坏,那么当数据库损坏时,最好的办法是从备份恢复数据库。
如果无法从备份恢复,可以根据损坏的原因尝试相应的解决方案。
由于存储问题导致部分数据文件损坏,但是数据库还可以连接,这种情况可以采用导出数据库的表结果和数据的方法来恢复数据库。当然对损坏的表,导出是无法完成的,这是可以使用db2dart的导出数据功能来导出这些损坏的表的数据。
如果数据库损坏到已经无法连接的程度,那么除了从备份恢复,唯一的办法是使用db2dart来导出所有的数据了。
Tip:怎么样使用db2dart来导出数据
运行命令
db2dart /DDEL
#Table object 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 sort on statement 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 write to file ‘/tmp/dlmon’ replace
原文链接: http://blog.csdn.net/jaminwm/article/details/4219880