关于一次db2数据库导入功能低效问题处理历程

环境：数据库db2 9.7v 操作系统:linux（redhat6.0）

最近生产环境的上的一个前端导入功能客户反应说很慢，一开始客户那边反应怀疑是不是死锁和并发性导致，所以一开始就去查看db2diag.log日志找-911的错误

但是没有找到(如果一开始日志文件很大打不开，你可以重命名以下，之后数据库会生产一个新的log)，于是又更改了db2数据库的注册变量环境配置，具体命令如下:
第一步:
使用命令db2 list db directory查看DB2上有那些数据库,连接数据库。
db2set -all -用于查看环境变量的配置
查看下面的三个变量是否开启，一般默认是不开启的。
第二步:
之后通过如下命令设置开启(具体语法可以使用db2set ?查看):
DBI1300N db2set 显示、设置或除去 DB2 概要文件变量。
db2set [variable=[value]]
[-g|-i instance [db-partition-number]]
[-all]
[-null]
[-r [instance] [node-number]]
[-n DAS node[-u user[-p password]]]
[-l|-lr]
[-v]
[-ul|-ur]
[-?|-h]

说明：
命令选项是：
-g 访问全局概要文件变量。
-i 指定要使用的实例概要文件，而不是当前的或缺省的实例概要文件。
-n 指定远程 DB2 管理服务器节点名。
-u 指定用于管理服务器连接的用户标识。
-ul 访问用户概要文件变量
-ur 刷新用户概要文件变量
-p 指定用于管理服务器连接的密码。
-r 复位给定实例的概要文件注册表。如果未提供任何实例，那么将使用缺
省/当前实例。
-l 列示所有实例概要文件。
-lr 列示所有受支持的注册表变量。
-v 详细方式。
-? 显示命令帮助消息。
-h 与 -? 选项相同。
-all 显示出现的所有本地环境变量，如以下各项中所定义：
* 环境，用 [e] 表示
* 用户级注册表，用 [u] 表示
* 节点级注册表，用 [n] 表示
* 实例级注册表，用 [i] 表示，和
* 全局级注册表，用 [g] 表示
-null 在指定的注册表级别将变量值设置为空（null），以防止查找在变量值
搜索顺序中定义的下一个注册表级别中的值。
注意：
* 不带变量名的 db2set 将显示定义的所有变量。
* db2set <变量> 将显示 <变量> 的值。
* db2set <变量>= (无内容) 将删除 <变量>。
* db2set <变量>=<值> 将修改 <变量> 的值。
* db2set <变量> -null 将 <变量> 的值设置为 NULL。
* db2set <变量> -all 将显示所有定义的 <变量> 的值。
* db2set -ur 将刷新当前的用户概要文件。
* db2set <变量> -ul 将显示在用户级别的定义的 <变量>。
* db2set -all 将显示所有注册表级别中的所有定义的变量。
开启命令:
db2set DB2_EVALUNCOMMITTED=ON - i 这个参数将在记录锁之前进行谓词检查，尽量减少锁的时间；
db2set DB2_SKIPINSERTED=ON - i 这个参数将新insert且没有提交的数据跳过；例如，SELECT/UPDATE语句不会发现这条记录；
db2set DB2_SKIPDELETED=ON - i 这个参数将新delete且没有提交的数据跳过；例如，SELECT/UPDATE语句不等待这条记录的提交，并且认为他已经被删除了。
关闭命令:
db2set DB2_SKIPDELETED=
如果不加-i可能会覆盖掉db2comm=tcpip导致其他客户端机器连接不上数据库，具体到java前端就会报500错误(500错误有多种，具体查看你们自己前端服务器写的启动日志)
如果发生重新设置回来即可，这些设置需要重启db2数据库,命令如下:
db2 force application all
db2stop
db2start
第三步:重启成功后发现前端导入数据还是很慢(比原先快了那么一丢丢，开启这些命令也会导致一些问题,具体要看公司业务)。
到这时候看没有死锁，跟并发性设置关系也不大，然后准备抓取数据库快照分析下。

第一步：查看开启使用数据库快照来抓取数据库的信息
通过命令db2 get monitor switches查看快照开启信息，如下命令是开启(开启会影响数据库性能，时间自定,用完之后记得关闭,on改为off即可)
第二步:
db2 update monitor switches using lock on
第三步:
db2 get snapshot for locks on dbname > /pas/log.out(可把locks改为all,这样就可以查看更多信息,locks只看锁),log.out文件部分内容

Application handle = 2888
Application ID = 199.9.39.11.5634.150915090917
Sequence number = 06373
Application name = db2jcc_application
CONNECT Authorization ID = PAS
Application status = UOW Executing--正在执行
Status change time = Not Collected
Application code page = 1208
Locks held = 9
Total wait time (ms) = 0

List Of Locks(有这个表示在上面的连接下锁了那些表)
Lock Name = 0x010031010F0054010000000052
Lock Attributes = 0x00000000
Release Flags = 0x40000000
Lock Count = 1
Hold Count = 0
Lock Object Name = 22282255
Object Type = Row --行锁
Tablespace Name = TBS_SPA --表空间名
Table Schema = SPA
Table Name = tablenam1 --表名
Mode = X --锁类型

Application handle = 434
Application ID = 199.9.39.11.377.1509141
Sequence number = 01949
Application name = db2jcc_application
CONNECT Authorization ID = PAS
Application status = UOW Waiting--在等待的连接
Status change time = Not Collected
Application code page = 1208
Locks held = 0
Total wait time (ms) = 0
之后发现了很多连接处于等待状态(锁表太久跟sql语句有直接关联？？初步怀疑sql语句)，而且有好些表处于行锁x以及表锁ix上，于是就想通过设置锁等待时间以及LOCKLIST和MAXLOCKS来处理。具体如下步骤：
第一步：
db2 -v update monitor switches using lock on
db2 -v terminate
第二步:
然后收集数据库快照(把信息输入到pas下面的log.out文件里)：
db2 -v get snapshot for database on dbname | grep –i lock >/pas/log.out
在快照输出中，检查下列各项：
Locks held currently = 21224
Lock waits = 24683
Time database waited on locks (ms) = 32875
Lock list memory in use (Bytes) = 87224
Deadlocks detected = 89
Lock escalations = 8
Exclusive lock escalations = 12
Agents currently waiting on locks = 0
Lock Timeouts = 0
Internal rollbacks due to deadlock = 0
如果“Lock list memory in use (Bytes)”超过定义的LOCKLIST大小的50%，那么就增加LOCKLIST数据库配置参数中的4KB页的数量。
如果发生了“Lock escalations>0”或“Exclusive lock escalations>0”，
则应该或者增大LOCKLIST或者MAXLOCKS，抑或同时增大两者。
查看“Locks held currently”、“Lock waits”、“Time database waited on locks (ms)”、
“Agents currently waiting on locks”和“Deadlocks detected”中是否存在高值，如果有的话，
就可能是差于最优访问计划、事务时间较长或者应用程序并发问题的症状。
LOCKLIST和MAXLOCKS的值和设置参考下面的文档：
http://wenku.baidu.com/link?url=jw7BMdUHtcISvFq_kWhyC_GxMrsCXh8PTaZgzcL7c3X2xOXLKyU99dxxrz9OWnXT6-d8BF9jTptCdMIgHAu7Z-RbAGr4g0DnYGFv2ew0z57
走到了这一步之后发现还是行不通，导入数据依然要些时间，看来导入跟数据库设置关系不大，应该是sql语句的问题。
于是就导入一条数据，然后监视
第一步:
通过db2top -d 数据库名 -u 用户名 -p 密码命令来监视运行的sql.
第二步:
通过db2top命令查找运行时间最长以及耗费资源最多的sql。
具体用法就不提了输入命令后上面有提示，之后找到了运行最久最耗时的sql进行了优化就快多了。

处理也就到此结束，之所以一开始没有使用db2top监视一方面是由于客户反映问题的方向，另一方面是由于这个功能其他客户也用的是一样的代码，

没曾想有人改过代码。。。。。。。

PS后记：

修改表的自增字段的起始值

db2 alter table t1 alter id restart with 11

再重组下

reorg table t1

如果表的id是自增可以避免自增的字段是9,10的主键冲突，这个在项目中高并发经常遇到，主要是写日志的表。

关于一次db2数据库导入功能低效问题处理历程

猜你喜欢