DB2故障处理的解决办法

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

解决问题的关键在于分清问题的种类,并清楚每种问题的解决办法。

另外很多的数据库的问题都是由于错误的操作,错误的配置引起的,所以本文在解释怎么样处理问题时也会给出一些好的建议,来避免产生问题。

本文重点介绍实用的方法。

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

第一种方案是是否有错误码。

即发生错误时是否同时返回了错误码,错误码既包括执行命令的返回码,也包扩应用程序的返回码。

有返回码的错误解决方案是,在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
编辑推荐
利用函数解决DB2中日期时间问题
DBase:DB2必须了解的常用命令及技巧
利用表空间的备份快速恢复IBM DB2数据库
出师表
两汉:诸葛亮
先帝创业未半而中道崩殂,今天下三分,益州疲弊,此诚危急存亡之秋也。

然侍卫之臣不懈于内,忠志之士忘身于外者,盖追先帝之殊遇,欲报之于陛下也。

诚宜开张圣听,以光先帝遗德,恢弘志士之气,不宜妄自菲薄,引喻失义,以塞忠谏之路也。

宫中府中,俱为一体;陟罚臧否,不宜异同。

若有作奸犯科及为忠善者,宜付有司论其刑赏,以昭陛下平明之理;不宜偏私,使内外异法也。

侍中、侍郎郭攸之、费祎、董允等,此皆良实,志虑忠纯,是以先帝简拔以遗陛下:愚以为宫中之事,事无大小,悉以咨之,然后施行,必能裨补阙漏,有所广益。

将军向宠,性行淑均,晓畅军事,试用于昔日,先帝称之曰“能”,是以众议举宠为督:愚以为营中之事,悉以咨之,必能使行阵和睦,优劣得所。

亲贤臣,远小人,此先汉所以兴隆也;亲小人,远贤臣,此后汉所以倾颓也。

先帝在时,每与臣论此事,未尝不叹息痛恨于桓、灵也。

侍中、尚书、长史、参军,此悉贞良死节之臣,愿陛下亲之、信之,则汉室之隆,可计日而待也。

臣本布衣,躬耕于南阳,苟全性命于乱世,不求闻达于诸侯。

先帝不以臣卑鄙,猥自枉屈,三顾臣于草庐之中,咨臣以当世之事,由是感激,遂许先帝以驱驰。

后值倾覆,受任于败军之际,奉命于危难之间,尔来二十有一年矣。

先帝知臣谨慎,故临崩寄臣以大事也。

受命以来,夙夜忧叹,恐托付不效,以伤先帝之明;故五月渡泸,深入不毛。

今南方已定,兵甲已足,当奖率三军,北定中原,庶竭驽钝,攘除奸凶,兴复汉室,还于旧都。

此臣所以报先帝而忠陛下之职分也。

至于斟酌损益,进尽忠言,则攸之、祎、允之任也。

愿陛下托臣以讨贼兴复之效,不效,则治臣之罪,以告先帝之灵。

若无兴德之言,则责攸之、祎、允等之慢,以彰其咎;陛下亦宜自谋,以咨诹善道,察纳雅言,深追先帝遗诏。

臣不胜受恩感激。

今当远离,临表涕零,不知所言。

相关文档
最新文档