如何快速定位问题：
1）如果系统的CPU利用很高，IO很少，那么数据库的排序较多
2）如果系统的IO繁忙，CPU很多是wait，那么说明数据库有过多的IO
3）如果系统CPU，IO都很空闲，那么说明可以是有 锁 的问题
4）如果系统IO，CPU都非常忙，说明有执行代价非常高的sql在执行

快速找到执行成本较高的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

如何优化sql语句:
DB2提供了很好的工具来做sql语句优化。首先要对找到的sql语句进行分析，看是否是该语句引起了性能问题。
可以使用db2expln来查看sql语句的访问计划和执行成本。
\#首先将找到的sql语句写到一个文本文件中以;结尾，然后运行
\#db2expln –d dbname -f sqlfile -g -o sql.explain查看 sql.explain可以看到这个sql语句的执行成本。
\#如果确认该语句有问题，可以使用db2advis来通过建索引的方法来优化该语句.db2advis -d -i sqlfile如果通过创建索引无法优化该语句，一般只能从 业务 角度优化。

如果发生锁的问题如何处理:
发生锁的问题，一般有两种情况，一是锁等待，二是 死锁 。
\#首先检查数据库配置参数locktimeout，该参数一定不能设为-1，因为会引起某些应用无限期的等待。
\#其次可以通过快照来确定数据库发生的问题是哪一种。
\#db2 get snapshot for db on
\#查看输出中的下列内容：
\#Deadlocks detected = 0
\#Lock Timeouts = 0
\#如果发生了死锁，可以通过创建死锁监视器来分析产生死锁的原因，命令如下：
\#mkdir /tmp/dlmon
\#db2 connect to dbname
\#db2 create event monitor dlmon for deadlocks with detail write to file ‘/tmp/dlmon’ replace
\#db2 set event monitor dlmon state 1等有死锁发生后
\#db2 set event monitor dlmon state 0
\#db2evmon –d /tmp/dlmon >/tmp/dlmon.out
\# 分析/tmp/dlmon.out文件就可以找到造成死锁的信息，结合应用就可以找到造成死锁的原因了。

一般来说看三个指标，一个是IO WAIT%，一个是磁盘BUSY%，一个是磁盘IO溢出率，要是有异常现象，就要看数据库了，用db2top来看到底哪个应用ID长时间占用过高的IO，然后用db2 get snapshot for application agentid 应用ID来看这个事务此时的状态包括SQL语句。
另外还有一种办法，直接开db2 event monitor来监视statement，这样这段时间的所有SQL都可以被抓下来分析，看是否存在全表扫描的情况，要是存在，直接增加索引即可。

绝大多数sql语句的io wait time比较高。

如果 perfmon 显示有一个或多个磁盘的磁盘时间在 80% 以上，或资源监视器显示有一个或多个磁盘上的活动时间在 80% 以上，那么这通常意味着系统中存在一个 I/O 瓶颈。可以从 perfmon 或资源监视器确定具有很高利用率的一个或多个磁盘。一旦确定了大量使用的磁盘，就可以找出放置在磁盘上的内容。
是否有任何 DB2 表空间容器放置在磁盘上？
db2 list tablespace containers for
对数据库中的所有表空间重复此命令。
或者，DB2 日志文件是否被放置在大量使用的磁盘上？
db2 get db cfg for
搜索 newlogpath 数据库配置参数。
或者，这些磁盘是否包含实用程序文件，比如备份目标或加载文件？查看已执行的备份/负载命令。根据大量使用的磁盘上的内容，解决方案也会有所不同。