DB2 缓冲池调优Bufferpools

缓冲池命中率

这个比率说明了为页面请求提供服务时，数据库管理器不需从磁盘装入页（即该页已经在缓冲池中）就能处理页请求的时间百分比。

计算：

BPHR = (1 - ((缓冲池数据物理读 + 缓冲池索引物理读) /

(缓冲池数据逻辑读 + 缓冲池索引逻辑读) ) ) * 100%

索引命中率

这个比率表明了可以在缓冲池中找到的页面能够满足的对索引页的所有读请求所占的百分比。

计算：

IHR = (1 - (缓冲池索引物理读 / 缓冲池索引逻辑读) ) ) * 100%

数据命中率

这个比率说明了可以在缓冲池中找到的页面能够满足的对数据页的所有读请求所占的百分比。

计算：

DHR = (1 - (缓冲池数据物理读 / 缓冲池数据逻辑读) ) ) * 100%

结论

缓冲池命中率大于 80% 被认为是理想的。对于 OLTP 系统来说，该值的理想情况是尽可能接近于 100% （索引命中率更是如此）。

要提高缓冲池的命中率，可以增加缓冲池的大小，也可以考虑分配多个缓冲池，可以为每个经常访问的具有自己的表空间的大型表使用一个缓冲池，也可以为一组小型表使用一个缓冲池。

1、使用命令 db2 get dbm cfg |find "SVCENAME" 查找到TCP/IP 服务名

2、到系统配置文件里找到service name 对应的 port number
windows：查看 c:\windows\system32\drivers\etc\services                                                

aix：         查看 /etc/services

如下：

DB2_DB2              60000/tcp
DB2_DB2_1          60001/tcp
DB2_DB2_2          60002/tcp
DB2_DB2_END      60003/tcp

db2c_DB2             50000/tcp

3、使用 netstat -an 命令查找tcp/ip 服务的端口

 
4、修改端口号
   直接修改services文件中当前服务名对应的端口号
如：db2c_DB2 50000/tcp
然后重启数据库即OK  db2stop  db2start

5、另外附上一个关于linux系统下的查找方法（摘抄帖子）：

In JDBC configurations for WPA, you have to specify the port that DB2 is listening on. I usually look for /etc/services or try one of 50000/50001 and it usually works. In SUSE Linux, both the solutions did not work and there was another process (Multithreaded routing toolkit aka mrt) was listening on port 50000.

So how do we find out the DB2 port in a reliable way? Read on...
Step 1: Set the DB2 environment.
$ . ~db2inst1/sqllib/db2profile

Step 2: Find the service name for DB2 instance. It basically involves running "db2 get dbm cfg" command and finding a line containing SVCENAME. 
$ svc=`db2 get dbm cfg | grep SVCENAME | cut -d= -f2 | awk '{print $1}'`

Step 3: Find the service name that you got from Step 2 in /etc/services or %SYSTEMROOT%\system32\drivers\etc\services. That is the port DB2 is listening on. $ grep $svc /etc/services

Hope you find this useful.

用sqoop做测试，发现端口号50000被占用了，所以就更改了一下DB2的端口号。

第一步，登录DB2数据库的实例用户，我这里是db2inst1

db2 get dbm cfg|grep SVCENAME

可以看到对应的SVCENAME的名称是什么。

这里容易出现一个问题。按照网上有人说的，会将SVCENAME改为端口号，那个是错误的。一定要将这个名称和services中的名称统一。

第二步，退回到root用户，

vim /etc/services，找到对应的SVCENAME的名称所对应的端口号。

我这里直接编辑成50001

第三步，先关数据库，再开就可以了。

db2stop

db2start

实际上没有复杂的步骤，只是好多人写的比较的乱，还不加解释说明，所以坑了些。

可以通过db2 get dbm cfg，查询数据库管理器配置参数，就可以查到端口号或端口名。

示例：

$ db2 get dbm cfg | grep -i svcTCP/IP Service name (SVCENAME) = 50000

50000就是端口号了。

如果查到的是端口名，可以通过网络服务配置文件来找到对应关系。

示例：

$ db2 get dbm cfg | grep -i svc

TCP/IP Service name (SVCENAME) = db2c_DB2

这时，就需要查找db2c_DB2对应的端口号了。

$ cat /etc/services | grep db2c_DB2

db2c_DB2 60000/tcp

这个60000就是端口号了。

如果DB2是装在windows的server上，那么就需要查找这个配置文件了，C:\WINDOWS\system32\drivers\etc\services格式：db2c_DB2 50000/tcp

如果下：Table_A表和Table_B表，要求查询出在Table_A表中不在Table_B表中的记录。

CREATE TABLE [dbo].[Table_A](  [ID] [nchar](10) NULL,  [Name] [nchar](10) NULL ) ON [PRIMARY]  GO  ID          Name 001        张三         002        李四         003        王五                   CREATE TABLE [dbo].[Table_B](  [ID] [nchar](10) NULL,  [Name] [nchar](10) NULL ) ON [PRIMARY]  GO  ID        Name NULL     张三         002       李四         NULL     王五 

很容大家第一时间相当的写法是：

SELECT  * FROM    dbo.Table_A AS a WHERE   a.ID NOT IN ( SELECT    b.ID                       FROM      dbo.Table_B AS b)

然而查询出来并没有达到预期的

ID    Name
001  张三        
003  王五          

原因很简单：由于NULL不能进行如何的“操作”

–如果null参与算术运算，则该算术表达式的值为null。（例如：+，-，*，/ 加减乘除）

–如果null参与比较运算，则结果可视为false。（例如：>=,<=,<>  大于，小于，不等于）

–如果null参与聚集运算，则聚集函数都置为null。除count(*)之外。

--如果在not in子查询中有null值的时候,则不会返回数据。  （最简单的解释请参考下面的评论说明）     

--正确写法                       SELECT  * FROM    dbo.Table_A AS a WHERE   a.ID NOT IN ( SELECT    b.ID                       FROM      dbo.Table_B AS b                       WHERE     b.ID IS NOT NULL ) --排除NULL值参与运算符比较                        --建议修改为关联查询方法                                             --正确写法1              SELECT  * FROM    dbo.Table_A AS a WHERE   NOT EXISTS ( SELECT *                      FROM   dbo.Table_B AS b                      WHERE  a.ID = b.ID ) --正确写法2                      SELECT  * FROM    dbo.Table_A AS a         LEFT OUTER JOIN dbo.Table_B AS b ON a.ID = b.ID WHERE   b.ID IS NULL

在DB2中，null和‘’是完全不同的两个东西。

NULL是一个不确定值它不能通过列值过滤，只能通过IS NULL 或者IS NOT NULL方式过滤

而‘’可以用in，=，<>,>,<来比较判断。

此外，若一个属性的值为null，则select显示时，会以-代替，而‘’则直接什么都不显示

我们的项目中使用到了IBM的DB2数据库，系统开发语言是C++，操作数据库是直接在C++中编写ESQL（嵌入式SQL）语句。在使用中发现，只要有文件名前8位相同，就造成部分文件中的代码失效。

原因：
------------------
db2默认情况下使用*.sqC的名字生成*.bnd，又以*.bnd的文件名部分在数据库中做绑定，建一个同名的package。而db2的package的名字是有八字节长度限制的，造成前八位文件名相同的C++代码，总会后面的覆盖前面的。

知道原因就好办事了。

解决：
------------------
取原始文件名的md5摘要前N位，拼成bnd文件的名字，再以此文件去目标数据库做绑定，这样package就不会前后覆盖了。

makefile中实际的做法：
------------------------

%.C : %.sqC
  db2 connect to $(dbName) user $(dbUser) using $(dbPassword);\
  db2 prep $*.sqC bindfile;\
  cp $*.bnd ${shell echo $* |md5sum -|cut -c1-8}_$*.bnd;\
  db2 bind ${shell echo $* |md5sum -|cut -c1-8}_$*.bnd;\
  db2 connect reset; \
  db2 terminate;

　　在这篇专栏文章中，我将讨论如何创建分区表，解释分区表的定义如何决定各个记录的存储位置。

　　范围分区表

　　数据分区也称为范围（当前 DB2 只支持范围分区方案），一个数据分区包含一个行子集，这些行存储在与表中其他行集不同的地方。不同的数据分区可以驻留在不同的表空间中，也可以驻留在相同的表空间中。CREATE TABLE 语句的 PARTITION BY 子句中提供的信息决定表数据的分区方式。这个可选子句的语法取决于是希望让 DB2 在指定的表数据范围内均匀地生成每个分区范围，还是要手工控制每个范围的边界。对于给定的表数据范围自动生成分区的语法是：

PARTITION　BY　<RANGE>　
　([ColumnName]　<NULLS　LAST　|　NULLS　FIRST>　,...)　
　(　
　STARTING　<FROM>　[Start　|　MINVALUE　|　MAXVALUE]　|　
　　STARTING　<FROM>　([Start　|　MINVALUE　|　MAXVALUE]　,...)　
　<INCLUSIVE　|　EXCLUSIVE>　
　ENDING　<AT>　[End　|　MINVALUE　|　MAXVALUE]　|　
　　ENDING　<AT>　([End　|　MINVALUE　|　MAXVALUE]　,...)　
　<INCLUSIVE　|　EXCLUSIVE>　
　EVERY　<(>[Constant]　<DurationLabel>　<)>　
　,...)　

　　手工指定分区的语法是：

PARTITION　BY　<RANGE>　　
　　([ColumnName]　<NULLS　LAST　|　NULLS　FIRST>　,...)　
　　(　
　　<PARTITION　[PartitionName]>　
　STARTING　<FROM>　[Start　|　MINVALUE　|　MAXVALUE]　|　
　　STARTING　<FROM>　([Start　|　MINVALUE　|　MAXVALUE]　,...)　
　<INCLUSIVE　|　EXCLUSIVE>　
　ENDING　<AT>　[End　|　MINVALUE　|　MAXVALUE]　|　
　　ENDING　<AT>　([End　|　MINVALUE　|　MAXVALUE]　,...)　
　<INCLUSIVE　|　EXCLUSIVE>　
　　<IN　[TSName]>　
　　<INDEX　IN　[IndexTSName]>　
　　<LONG　IN　[LongTSName]>　

　　其中：

　　ColumnName：用名称指定一个或多个列（最多 16 列），这些列的值用来决定数据行应该存储在哪个数据分区中。（指定的列组成表的分区键 — 参见边栏 “选择表分区键”。）数据类型为 LONG VARCHAR、LONG VARGRAPHIC、BLOB、CLOB、DBCLOB、XML、基于这些数据类型的 distinct 类型和结构化数据类型的列都不能作为数据分区键的组成部分。

　　PartitionName：指定分配给要创建的数据分区的惟一名称。

　　Start：指定每个数据分区的范围下限。

　　End：指定每个数据分区的范围上限。

　　Constant：在使用语法的自动生成形式时，指定每个数据分区范围的宽度。从 STARTING FROM 值开始创建数据分区，数据分区的范围内包含指定数量的值。支持这种语法的条件是分区键由单一列组成，这一列的数据类型是数字、日期、时间或时间戳。

　　DurationLabel：如果分区键列的数据类型是日期、时间或时间戳，这个参数指定与 Constant 值相关的时间单位。这个参数的有效值是：YEAR、YEARS、MONTH、MONTHS、DAY、DAYS、HOUR、HOURS、MINUTE、MINUTES、SECOND、SECONDS、MICROSECOND 和 MICROSECONDS。

　　TSName：指定存储每个数据分区的表空间。

　　IndexTSName：指定存储每个数据分区的分区索引的表空间。

　　LongTSName：指定存储长列的值的表空间。

　　注意：尖括号 (< >) 中的参数是可选的；方括号 ([ ]) 中的参数或选项是必需的，必须提供它们；逗号后面跟着省略号 (...) 表示前面的参数可以重复出现多次。

　　因此，如果希望创建一个名为 SALES 的分区表，把每个季度的数据存储在单独的分区中，每个分区驻留在不同的表空间中，那么可以执行以下 CREATE TABLE 语句：

CREATE　TABLE　sales　
　(sales_date　　DATE,　
　sales_amt　　　NUMERIC(5,2))　
　IN　tbsp0,　tbsp1,　tbsp2,　tbsp3　
　PARTITION　BY　RANGE　(sales_date)　
　　(STARTING　'1/1/2010'　ENDING　'12/31/2010'　
　　EVERY　3　MONTHS)　

　　图 1 说明生成的表是什么样的。

图 1. 一个简单分区表中存储的数据

　　另一方面，如果希望创建一个名为 INVENTORY 的分区表，把物品编号在 1 到 100 之间的行存储在一个表空间中的一个分区中，把编号在 101 到 200 之间的行存储在另一个表空间中的另一个分区中，以此类推，那么可以执行下面的 SQL 语句：

CREATE　TABLE　inventory　
　　(item_no　INT,　
　　desc　VARCHAR(20))　
PARTITION　BY　(item_no　NULLS　FIRST)　
(PARTITION　PRODUCE　STARTING　MINVALUE　ENDING　100　IN　tbsp0,　
PARTITION　DAIRY　　STARTING　　　　101　ENDING　200　IN　tbsp1,　
PARTITION　BAKERY　　STARTING　　　　201　ENDING　300　IN　tbsp2,　
PARTITION　MEAT　　　STARTING　　　　301　ENDING　400　IN　tbsp3)　

　　选择表分区键

　　选择有效的表分区键列对于发挥表分区的优势非常重要。最有效的表分区键列是有利于分区消除的列。例如，如果通常按日期查询表中的记录，那么应该用日期或时间列进行表分区。

　　同样，如果希望随着时间的推移把表数据的一部分删除或存档，应该根据期望的记录存档方式进行表分区。例如，如果希望把三年前的所有数据都存档，应该按周、月或季度进行表分区，这样就可以分别在每周、每月或每季度末删除一个老分区。

　　对于这个示例，ITEM_NO 值在 1 到 100 之间的行将存储在名为 PRODUCE 的分区中（这个分区的数据写到表空间 TBSP0 中），ITEM_NO 值在 101 到 200 之间的行将存储在名为 DAIRY 的分区中（这个分区的数据写到表空间 TBSP1 中），依次类推；ITEM_NO 值为 NULL 的行将存储在 PRODUCE 分区中。

　　一定要注意，当指定 NULLS FIRST 选项时，第一个分区必须从 MINVALUE 开始。（同样，如果使用 NULLS LAST 选项，最后一个分区必须结束于 MAXVALUE。）否则，在插入分区键列为 NULL 值的记录时，会产生 “data out of bounds” 错误。另外，每个分区的数据、索引和长列数据可以放在不同的表空间中。如果不为索引或长列指定表空间，分区索引和长列数据会存储在与数据相同的表空间中。

　　在默认情况下，范围包含边界本身。要想防止在某一分区中存储特定的记录，可以用 EXCLUSIVE 选项创建范围。例如：

CREATE　TABLE　sales　
　(sales_date　DATE,　
　sales_amt　NUMERIC(5,2))　
IN　tbsp0,　tbsp1,　tbsp2,　tbsp3　
PARTITION　BY　RANGE　(sales_date)　
(STARTING　'1/1/2010'　ENDING　'3/31/2010'　EXCLUSIVE,　　
STARTING　'3/31/2010'　ENDING　'6/30/2010'　EXCLUSIVE,　　
STARTING　'6/30/2010'　ENDING　'9/30/2010'　EXCLUSIVE,　　
STARTING　'9/30/2010'　ENDING　'12/31/2010')　

　　在这个示例中，销售日期为 3/31/2010 的记录不会存储在表空间 TBSP0 中，而是存储在表空间 TBSP1 中。

　　当在分区表中插入行时，会根据键值及其所处的范围自动地把它放到适当的数据分区中。如果键值不处于表的任何范围内，插入操作就会失败并产生一个错误。

　　轻松地移入和移出数据

　　使用分区表的另一个优点是，可以轻松地在表中添加新数据（作为新的数据分区），同时可以轻松地删除并存档老数据。在下一篇专栏文章中，我将讲解添加（移入）和删除（移出）数据分区的过程。还要讨论 DB2 9.7 中的改进如何大大加快移入和移出数据分区的速度，减少这些操作产生的干扰。

d:/>db2 ? sql0911n


SQL0911N因为死锁或超时，所以当前事务已回滚。原因码为
          "<原因码>"。

解释:

当前工作单元涉及到未解决的对使用对象的争用，因此不得不回滚。

原因码如下：


 2 由于死锁而导致事务已回滚。

 68 由于锁定超时而导致事务已回滚。

 72 因为存在与事务中所涉及的 DB2 Data Links Manager
有关的错误，所以事务已回滚。

注释: 必须再次输入与工作单元相关的更改。

应用程序已回滚至上一次 COMMIT。

用户响应:

为了帮助避免死锁或锁定超时，对长时间运行的应用程序或有可能遇到死锁
的应用程序频繁发出 COMMIT 操作（如果有可能的话）。

联合系统用户：死锁可能发生在联合服务器或数据源上。没有检测跨越数据
源并潜在地跨越联合系统的死锁的机制。有可能标识使请求失败的数据源（
参阅 Problem Determination Guide 以确定哪一个数据源使 SQL
语句的处理失败）。

当处理 SQL 语句的某些组合时，通常会发生死锁或者预期会发生死锁。建议
您设计应用程序来尽可能避免死锁。

 sqlcode :  -911

 sqlstate :  40001


d:/>

今天看了一篇文章，觉得不管怎么强调sortheap的重要性都不为过。理由我后面肯定会写详细的，这里写记录下，占个位置：

----2007.07.10.00。13（没想到是10号还以为9号呢 ，9号刚过）

========================

感觉学的不是很好，没有达到目标，但还是把这2天学的写上吧 。

 1.sortheap在数据库配置说明上是这样的：定义要用于专用排序的专用内存页的最大数目，或者要用于共享排序的共享内存页的最大数目。现在这个项目并没有启动分区并行性，所以此参数只是表示要用于专用排序的专用内存页的最大数目。不知道是我没理解好，还是db2没有说好，其实这个参数还有个很重要的作用：数据库在执行散列连接sql的时候也用到此内存区域。db2  对2个表进行连接的时候，只有3种类型：嵌套，合并，散列。其中散列连接用的最多（我在执行复杂sql的时候是这样的，简单的没有测试过大家可以测试下）。进行散列连接的时候，数据库会把其中一个表的内容复制到sortheap对应的内存中，如果sortheap对应的内存不够大，就会吧余下的数据库复制到临时表空间中。然后进行连接比较。可以想想操作内存和操作硬盘的差别吧，所以我们应尽量大的设置sortheap，使他不溢出到硬盘中，或者很少溢出。（关于上面3中嵌套，合并，散列连接类型，可以看下面的附件，附件中有很详细的说明）

2.  查看是否溢出的方法：

大家执行下面的命令： db2 gen snapshot for db on 数据库名 （这个命令不需要打开db2的快照开关，db2有些默认的快照信息）。在输出的信息中查找下面的信息：

已分配的专用排序堆总数          = 0
已分配的共享排序堆总数                    = 0
共享排序堆高水位标记                      = 0
总计排序                          = 34600
总计排序时间（毫秒）              = 35491
排序溢出                            = 2384
活动排序数                                 = 0

和

散列连接数                        = 38808
散列循环数                        = 0
散列连接溢出数                    = 534
小散列连接溢出数                  = 1

 排序溢出 /总计排序   可以得到溢出比例  （如果溢出比例大于 3 个百分点，那么在应用程序 SQL 中会出现严重的或意外的排序问题。因为正是溢出的存在表明发生了大的排序，所以理想的情况是发现没有排序溢出或至少其百分比小于一个百分点。
如果出现过多的排序溢出，那么“应急”解决方案是增加SORTHEAP的大小。然而，这样做只是掩盖了真实的性能问题。相反，您应该确定引起排序的 SQL 并更改该 SQL、索引或群集来避免或减少排序开销。如果溢出比例大于 5 （作为一种经验之谈），那么每个事务的排序数可能很大。虽然某些应用程序事务执行许多小的组合排序（它们不会溢出并且执行时间很短），但是它消耗了过多的 CPU。当SortsPerTX很大时，按我的经验，这些机器通常会受到 CPU 的限制。确定引起排序的 SQL 并改进存取方案（通过索引、群集或更改 SQL）对提高事务吞吐率是极为重要的。）

散列连接数   就是在执行sql的时候进行散列连接的数目。这里只说下散列循环数 的意义，其他参数的意义在下面的附件中都有很详细的说明：  我在测试的时候，把sortheap设置为16个页，然后执行复杂的sql，散列循环数有值，而且很高。一般看到散列循环数有值就要注意，他说明你的sortheap或者SHEAPTHRES（实例级参数）太低了。现在的测试情况就说明sortheap太低了。另外一种情况SHEAPTHRES太低的原因： SHEAPTHRES已经分配给前面的代理进程了，再有代理进程申请sortheap的时候，SHEAPTHRES已经达到上限了，这个时候db2就会给申请sortheap的进程很小的值，此时代理进程进行散列连接的时候就需要把很多数据放到硬盘上，这个时候就会导致散列循环数值很高，这个时候大家可以增加 SHEAPTHRES进行观察。

3.查看排序溢出的sql方法： 首先打开快照监视器：  db2 update monitor switches using sort on statements on ;

然后过段时间（1分钟就可以了）执行 get snapshot for all on 数据库名；

在输出的信息中查找：语句排序溢出                    = 1   ，看对应的sql就知道了，对sql的执行计划分析下就明白了。

记得在测试完要关闭 快照开关： db2 update monitor switches using sort off statements off;

序言

本文的目的就是通过详细的实例来阐述如何在DB2 UDB 中监控死锁的发生。在DB2 UDB中有两种类型的监控器：快照监控器和事件监控器。快照顾名思义就是数据库连续状态下的一个切面，通过快照监控器，你可以很方便地查看当前连接的应用程序，当前等待的锁，当前的死锁，以及正在执行的SQL语句，同时你可以查看缓冲区，表和表空间的用法。如果保存历史数据，并且能够做出比较，对于分析数据库的并发性能有很大的帮助。

但是我们并不能预测什么时候发生死锁，所以如果有一个后台程序能够一直监控数据库的活动，记录下所有的死锁事件，这对于数据库管理员来说是非常重要的。DB2 UDB提供了事件监控器。通过不遗漏地获得一段时间内所有的数据库事件（在本文中只关心其中的死锁事件），事件监控器提供了一种可以分析历史数据（本文的重点），预测将来趋势的可能。DB2 UDB同时提供了DB2 Performance Expert (DB2/PE) 或者类似的程序用来生成分析报表，不过这已经超出了本文的范畴。

回页首

常用术语

锁是控制应用程序并发的数据库软件机制，锁用来防止以下情况的发生：

1． 丢失以前更新

2． 不可重复读取

3． 访问未提交数据

锁的模式包括共享锁和排他锁，共享锁允许其他程序读取已经被其他共享锁占用的资源，所以也叫读锁，排他锁意味着在释放资源以前其他的应用程序无法访问同一资源，所以也叫写锁。此外，DB2 UDB 还提供了不同的锁级别，不同的应用程序可能会要求访问不同范围的数据，锁级别有利于充分利用系统资源，提高系统性能。若一个应用程序请求一个锁，而该锁被另外一个应用程序所使用且不能共享，DB2 UDB 就会挂起前一个应用程序。锁升级就是当LOCKLIST (LOCKLIST代表锁能够占用的内存空间) 耗尽或者一个应用程序所拥有的锁大于MAXLOCKS*LOCKLIST的时候（MAXLOCKS 代表应用程序所拥有的锁占所空间的百分比），DB2 UDB 就试图把几个行级别的锁合并为一个表级别的锁，从而释放锁空间。虽然锁升级本身并不耗费多少时间，但是锁住整个表通常会大大地降低并发性能。

当应用程序处于挂起状态超过了一段规定的时间后，DB2 UDB就会自动中止这个应用程序，同时会向SQLCA发送描述性的错误信息。当两个或者更多的应用程序都持有另外一个应用程序所需资源上的锁，没有这些资源，那些应用程序都无法继续完成其工作的时候，就会发生死锁。

在DLCHKTIME超时之后，DB2 UDB会中止发生死锁的某个应用程序（通常为所做工作最少的那个应用程序），这会释放这个应用程序所持有的所有的锁，并允许别的应用程序继续工作，DB2 UDB 将向被终止的应用程序的SQLCA发送描述性的错误信息。LOCKTIMEOUT 指定一个应用程序被允许的锁等待的时间，这将避免全局的死锁从而导致整个应用崩溃。如果LOCKTIMEOUT 的值为-1，应用程序会等待直到该锁被释放或者发生一个死锁。

回页首

事件监控器

事件监控器用来收集当一个数据库事件发生时所关联的应用程序的信息。这里的事件指，连接，死锁，声明和事务。你可以定义你想监控的事件类型的监控器。比如说，一个死锁监控器就是用来监控死锁的发生。

在DB2 UDB 中存在两种和死锁有关的事件类型：

• DEADLOCKS
  记录简单的应用程序信息。
• DEADLOCKS WITH DETAILS
  记录所有复杂的信息，包括应用程序、执行语句声明以及死锁的详细信息。但是使用这种事件监控器会因为需要得到大量额外的信息而降低系统的性能。

回页首

如何监控死锁

为了详细说明事件监控器在死锁监控中的用途，我引入了一个简单的死锁场景来触发一个死锁，在随后的章节，我会告诉读者如何分析监控结果以及根据结果来避免死锁的发生。

这里我们需要至少三个应用程序来调用DB2 CLI，一个用来监控死锁的发生，另外两个用来产生死锁。我们可以使用DB2 UDB 安装时附带的SAMPLE数据库。

1． 首先建立一个死锁事件监控器

db2 connect to sample
db2 "create event monitor dlmon for tables, deadlocks with 
details write to file 'C:\dlmon'"
mkdir C:\dlmon
db2 "set event monitor dlmon state 1"

2． 用另外两个应用程序来产生一个死锁

db2 connect to sample
db2 +c "insert into employee values('000350', 'Truman',
 'I', 'Jiang', 'B00', '5892',
'1999-02-21', 'Engineer', 19, 'M',
 '1978-06-17', 60000, 2000, 6000)"

现在应用程序A就拥有了一个EMPLOYEE表的行级别的排他锁

（注: +c 代表不自动提交SQL语句，DB2 中 autocommit 是缺省设置，也可以通过 db2 update command options using c off 关闭该缺省选项。）

db2 connect to sample
db2 +c "insert into project values('AD3300', 'Dead Lock Monitor', 'B00', '000350', 7.00, 
'1982-07-21', '1983-02-03', 'AD3111')"

现在应用程序B就拥有了一个PROJECT表的行级别的排他锁

db2 +c "select projname from project"

应用程序A需要PROJECT表上所有行的共享锁，但是因为PROJECT表正在被应用程序B以排他锁的形式独占，这时候应用程序1就进入一个锁等待的状态。

db2 +c "select firstnme from employee"

应用程序B也进入一个锁等待的状态。此时就出现了一个死锁状态。

3． 两个本身处于锁等待并且占有资源的应用程序互相等待另外一方所持有的资源，这时候Session A和Session B就出现了死锁状态，这种状态一直会延续直到死锁检查器（超出DLCHKTIME时间以后）检查出一个死锁并且回滚其中的一个事务。

SQLN0991N 因为死锁或者超时，当前事务已经被回滚。原因码为 "2". SQLSTATE=40001
这时候死锁事件监控器就会记录这个死锁，同时应用程序A可以完成他的工作。

PROJNAME
----------------------------------------
……
20 条记录已选择

db2 connect reset

db2 connect reset

4． 通过 db2evmon 工具可以获得死锁信息的日志，并且把日志文件导入到本地机器的文件系统当中。在下面一节，我们将详细分析导出的日志文件。

Session Monitor
db2 connect reset
db2evmon -path c:\dlmon > c:\dlmon\dllog1.txt

回页首

分析监控结果

本节我们开始详细分析上一节产生的监控结果，从监控导出的日志文件中，我们可以分析出死锁发生的时间，级别，模式以及产生死锁的SQL语句，从而据此来进一步地修正可能由程序并发设计或者数据库设计所导致的缺陷。

	
--------------------------------------------------------------------------
                            EVENT LOG HEADER
  Event Monitor name: DLMON
  Server Product ID: SQL08022
……
  Server instance name: DB2
--------------------------------------------------------------------------
--------------------------------------------------------------------------
  Database Name: SAMPLE  
  Database Path: C:\DB2\NODE0000\SQL00001\
	……
--------------------------------------------------------------------------
3) Deadlock Event ...
  Deadlock ID:   1
	……
4) Connection Header Event ...
  Appl Handle: 949
	……
5) Deadlocked Connection ...
  Deadlock ID:   1
  Participant no.: 2
  Participant no. holding the lock: 1
  Appl Id: G9B56A72.HE13.01B406083205
  Appl Seq number: 0001
  Appl Id of connection holding the lock: G9B56A72.HD13.02CE06083152
	……
  Deadlock detection time: 2006-01-06 16:34:27.327582
  Table of lock waited on      : EMPLOYEE
	(A锁发生的表)
  Schema of lock waited on     : JT      
  Tablespace of lock waited on : USERSPACE1
  Type of lock: Row
	（A锁级别为行锁）
  Mode of lock: X   - Exclusive
	（A锁模式为排他锁）
  Mode application requested on lock: NS - Share (and Next Key Share)
	（在A排他锁上要求B共享锁，发生死锁）
	……
Text     : select name from employee
（产生B共享锁的SQL语句）
  List of Locks:
	（当前所有锁的列表）
		……
      Lock Name                   : 0x020005000D0000000000000052
      Lock Attributes             : 0x00000008
      Release Flags               : 0x40000000
      Lock Count                  : 1
      Hold Count                  : 0
      Lock Object Name            : 13
      Object Type                 : Row
      Tablespace Name             : USERSPACE1
      Table Schema                : JT      
      Table Name                  : PROJECT
      Mode                        : X   - Exclusive
		  （在PROJECT表上有一个排他锁）
……
      Lock Name                   : 0x02000300000000000000000054
      Lock Attributes             : 0x00000000
      Release Flags               : 0x00000001
      Lock Count                  : 1
      Hold Count                  : 0
      Lock Object Name            : 3
      Object Type                 : Table
      Tablespace Name             : USERSPACE1
      Table Schema                : JT      
      Table Name                  : EMPLOYEE
      Mode                        : IS  - Intent Share
		（在EMPLOYEE表上有一个共享锁）
  Locks Held: 6
  Locks in List: 6
……
9) Table Event ...
  Table schema: JT      
  Table name: EMPLOYEE
  Record is the result of a flush: FALSE
  Table type: User
  Data object pages: 1
……
  Rows read: 35
  Rows written: 1
	……
  Tablespace id: 2
  Table event timestamp: 2006-01-06 16:37:28.972501
	（记录EMPLOYEE表上发生的事件）
	

我们可以分析一下dllog1.txt 文件，来准确定位死锁发生的原因，看看5）Deadlocked Connection: 我们可以看出死锁发生的表是EMPLOYEE，同时我们也可以判断出这是一个对于已被排他锁占有的资源申请共享锁所导致的死锁。更加重要的是我们得到了产生死锁的SQL语句，从上面我们可以推断出一定存在别的应用程序在以独占锁的方式占用EMPLOYEE表，这很有可能就是对于EMPLOYEE表的插入或者更新动作造成的。

而这最有可能就是插入或者更新事务时间过长所导致的，导致事务时间过长的原因大体有两种，一是来自于并发程序的设计和编写，二是来自于数据库的设计和数据库参数的调整。

本节我们通过仔细地分析事件监控器的结果来推断出导致死锁发生的原因，从而采取有效的措施去避免死锁的发生。这些措施包括调整数据库参数，或者修改应用程序的代码，或者修改SQL语句甚至是数据库的设计来提高代码和SQL语句执行的效率。

回页首

避免死锁的方法

越早地考虑数据库设计中的并发性问题，就越可以提高代码执行的效率，降低程序开发和维护的成本，这里我们提出了一些避免死锁，提高应用程序并发性的方法。

• 设置隔离级别，根据应用程序的业务逻辑和数据完整性需求来决定合适的隔离级别，包括：RR，RS，CS，UR。该决定需要对应用程序需求和相关的业务规则具有基本理解
• 尽量避免锁升级，正确调整参数LOCKLIST, MAXLOCKS
• SQL0911N返回码68（LOCKTIMEOUT参数）的原因是锁等待超时，而SQL0911返回码2（DLCHKTIME参数）的原因则是因为死锁被强制回滚，避免这两种错误的方法就是合理设计数据库和建立合理的索引
• 尽快提交事务，不要在事务中加入不必要的执行时间过长的代码，比如大的代码循环和远程调用，或者一些没有用处的SELECT语句
• 应用程序的框架实现保证一旦发现SQL错误，立刻执行回滚事务，释放锁。
• 如果多个应用程序访问同一资源，最好以相同的次序访问。这样，即使前一个访问资源的应用程序会延迟其他应用程序的访问，也不会导致死锁的发生
• 设定外键索引，如果想删除父表中的行，就需要扫描多个子表中的多行数据，这样就需要占用多个子表的锁，我们可以通过在外键上建立索引来减少扫描子表的行数，否则若不建立索引，如果从父表中删除一行的时候，就需要扫描整个子表

   两阶段提交(2PC Two Phase Commit)

    两阶段提交把事务提交分成两个阶段：

• 第一阶段，事务处理器向数据库服务器发出"准备提交"请求，数据库收到请求后执行相同的数据修改和日志记录等处理，不同的是处理完成后只是把事务的状态改成"可以提交",然后把结果返回给事务处理器。
• 事务处理器收到回应后进入第二阶段，如果在第一阶段内的危险期中发生了故障，事务处理器收不到回应，则认为事务失败，回撤事务。数据库服务器收不到第二阶段的确认提交请求，把"可以提交"的事务回撤.
• 两阶段的第二阶段中事务处理器向数据库服务器发出"确认提交"请求，数据库服务器把事务的"可以提交"状态改为"提交完成"状态，然后返回应答。

   从严格意义上说，两阶段提交并没有完全解决网络通讯危险期的问题，但因为第二阶段的处理很简单，只是修改了事务的状态，与第一阶段相比其处理时间极短，所以危险期极短，发生事务提交故障的可能性几乎不存在。 

                              ——数据库技术和“事务处理”专家

1998年度的图灵奖授予了声誉卓著的数据库专家詹姆斯·格雷(James Gray)或称吉姆·格雷(JimGray，Jim是James的昵称)。这是图灵奖诞生32年的历史上，继数据库技术的先驱查尔斯·巴赫曼(Charles W．Bachman，1973)和关系数据库之父埃德加·科德(Edgar F．Codd，1981)之后，第3位因在推动数据库技术的发展中做出重大贡献而获此殊荣的学者。

    格雷生于1944年，在著名的美国加州大学伯克利分校计算机科学系获得博士学位。其博士论文是有关优先文法语法分析理论的。学成以后，他先后在贝尔实验室、IBM、Tandem、DEC等公司工作，研究方向转向数据库领域。

    在IBM期间，他参与和主持过IMS、System R、SQL／DS、DB2等项目的开发，其中除System R仅作为研究原型，没有成为产品外，其他几个都成为IBM在数据库市场上有影响力的产品。

    在Tandem期间，格雷对该公司的主要数据库产品ENCOMPASS进行了改进与扩充，并参与了系统字典、并行排序、分布式SQL、Nonstop SQL等项目的研制工作。

    在DEC，他仍然主要负责数据库产品的技术。格雷进入数据库领域时，关系数据库的基本理论已经成熟，但各大公司在关系数据库管理系统(RDBMS)的实现和产品开发中，都遇到了一系列技术问题，主要是在数据库的规模愈来愈大，数据库的结构愈来愈复杂，又有愈来愈多的用户共享数据库的情况下，如何保障数据的完整性(Integrity)、安全性(Security)、并行性(Concurrency)，以及一旦出现故障后，数据库如何实现从故障中恢复(Recovery)。这些问题如果不能圆满解决，无论哪个公司的数据库产品都无法进入实用，最终不能被用户所接受。正是在解决这些重大的技术问题，使DBMS成熟并顺利进入市场的过程中，格雷以他的聪明才智发挥了十分关键的作用。

目前，各DBMS解决上述问题的主要技术手段和方法如下：

1．把对数据库的操作划分为称之为“事务”(或“事务元”，transaction)的一个个原子单位。事务是事务处理(transaction processing)的基本执行单位，即一个事务中的操作要么全部被执行，要么全部都不执行，即实行所谓all or none的原则。一个事务一般以一个“开始”语句(begin)开始，先从数据库中取出一些数据，然后进行所需的处理，最后以“提交”语句(commit)结束。如事务中发生异常，则用“异常终止”语句(abort)或“回退”语句(rollback)撤销本事务执行过程中对数据库已做的所有更新(即所谓undo)，将数据库恢复到事务开始时的正确状态，以保障数据的完整性、一致性。

    2．用户在对数据库发出操作请求时，系统对有关的不同粒度(granularity)的数据元素(字段、记录以至整个文件)“加锁”(10cking)，加锁的数据将被暂时禁止其他用户访问(我们这里仅是一种简化的解释，实际上，根据用户对数据请求的不同性质，加锁的数据如何对待另一用户的请求，呈现复杂的情况，例如，如果加锁的数据将被修改，那是绝对禁止其他用户访问的；而如果加锁的数据只用于读出，则其他用户的读出请求还将是允许的。这由所谓“锁相容性矩阵”——lock compatibility matrix管理和控制)。操作完成后“解锁”(unlocking)。这一机制用以既保持事务之间的“并发性”，又保证数据的“完整性”。

    3．建立系统运行日志(10g)，记载各事务的始点、终点以及在事务中被更新过的页面的改前和改后状况(before image和afterimage)，以便在系统出现散障使数据库遭到破坏时，能根据定期或不定期为数据库所作的备份(backup)加上日志中的信息将数据库恢复到系统故障前的正确状态，同时又能保留最后一次备份以来对数据库所作的修改。

    4。对数据库的任何更新分两阶段提交(two-phase commit)。这是基于一个事务可能同时涉及两个不同的数据库系统而必需的，这在分布式系统中尤为重要。

    上述及其他各种方法可总称为“事务处理技术”(transaction processing technique)。格雷在事务处理技术上的创造性思维和开拓性工作，使他成为该技术领域公认的权威。他的研究成果反映在他发表的一系列论文和研究报告之中，最后结晶为一部厚厚的专著Transaction Processing：Concepts and Techniques(Morgan Kaufmann Publishers，1993，另一作者为德国斯图加特大学的A．Reuter教授)。事务处理技术虽然诞生于数据库研究，但对于分布式系统，client／server结构中的数据管理与通信，对于容错和高可靠性系统，同样具有重要的意义。

    格雷的另一部著作是The Benchmark Handbook：for Database and Transaction Processing Systems，第1版于1991年，第2版于1993年出版，也是Morgan Kaufmann出版社出版的。格雷还是该出版社“数据管理系统丛书”的主编。

    格雷在数据库学术界十分活跃。国际上定期或不定期举行的一些重要的数据库学术会议如VLDB、SIGMOD上，都能见到他的身影，听到他的声音。除了在公司从事研究开发外，他还兼职在母校伯克利、斯坦福大学、布达佩斯大学从事过教学和讲学活动。1992年，VLDB杂志(The VLDB Journal)创刊，他出任主编。

    格雷是ACM于1988年授予IBM的System R以软件系统奖的6位得奖人之一，其他5人是Donald Chamberlin、Raymond Lorie、Gianfranco Putzolu、Patricia Selinger和Irving Traiger。正是由于格雷在数据库技术方面的声誉，软件业中的“巨无霸”微软公司在1993年决定进入大型关系数据库市场时，才不惜用种种手段把格雷从DEC公司挖过来。因格雷不喜欢微软总部所在的多雨的西雅图，愿意留在阳光灿烂的旧金山，微软特地在旧金山开辟第二个微软研究院海湾区研究中心BARC(Bay Area Research Center)，安排格雷任该研究院主管。格雷果然不负所望，领导一个研制小组开发出了MS SQL Server 7．0，成为微软历史上一个里程碑式的版本，而且也成为当今关系数据库市场上的佼佼者。

    格雷是在1999年5月4日于亚特兰大举行的ACM全国会议上接受图灵奖的。格雷发表了“信息技术今后的目标”的演说(What Next?一A dozen remaining IT problems)，纵论了信息技术发展中有关的几个方向性问题。后来，该文经修改后在SIGMOD的会上以What Next?一A dozen IT Research Goals为题再次发表。格雷的演说在对计算技术的发展作总结性回顾时认为，英国数学家巴贝奇(Charles Babage，1791—1871)在19世纪所梦想和追求的计算机今天已经基本实现；美国数学家布什(Vannevar Bush，1890—1974，曾任罗斯福总统的科学顾问)20世纪40年代所设想的“梅米克斯”MEMEX即“记忆延伸器”(MEMory EXtender)当前已接近实现；而图灵所提出的智能机器离实现还有一段距离，目前的计算机还难以通过“图灵测试”。为了完全实现上述3位科学巨人的理想，格雷呼吁美国政府要重视支持对IT技术的长期研究，认为其重要意义不亚于200年前杰弗逊(Thomas Jefferson，1743—1826，“独立宣言”的起草者，美国第三任总统，1801—1809在位)决定用1 500万美元从法国政府手中买回路易斯安娜领地(Louisiana Territory，这是位于密西西比河和洛矶山脉之间，北至加拿大，南达墨西哥湾的大块土地，面积达2 070 000km²)这一被称为Louisiana Purchase的著名历史事件，然后又派出以刘易斯上尉(Captain Meriwether Lewis)和克拉克(William Clark)为首的“发现军团(Corps for Discovery)到西部探险直至太平洋海岸，为最终形成美国如今的版图奠定了基础。格雷认为，一个好的IT长期目标应具有以下5个关键性：

    1．可理解性  目标应能简单表述并被人理解。

    2．有挑战性  如何达到目标不是很明显的。

    3．用途广泛  不只对计算机科学家有用，而是对大多数人有用。

  4．可测试性  以便检查项目进展并知道目标是否已经达到。

    5．渐进性  中间有若干里程碑，以检查项目进展并鼓舞研究人员干下去。

    在以上论点支持下，格雷提出的几个IT技术的长期研究目标如下：

    1．规模可伸缩性(scalability)。

    2．通过图灵测试。

    3．语音到文本的转换(Speech to Text)。

    4．文本到语音的转换(Text to Speech)。

    5．机器视觉，能像人一样识别物体和运动。

    6.个人的“梅米克斯”，可记录人所看到和听到的一切，需要时快速检索出来。

    7．世界的“梅米克斯”，即建立文本、音乐、图像、艺术、电影的“全集”(corpus)，可回答有关的任何提问，像人类专家那样快而好地做索引，做文摘。

    8．虚拟现实(格雷用了TelePresenee这个词，参见对1969年图灵奖获得者明斯基的介绍)。

    9．无故障系统(Trouble-Free Systems)。

    10．安全系统(Secure Systems)。

    11．高可用系统(AlwaysUp)。

    12．自动程序设计(Automatic Programming)。

  格雷的图灵奖演说全文已由笔者译出，摘要刊于《中国计算机报》2000年6月，有兴趣的读者可以一阅。

    目前，格雷本人正在从事Scalability这一长期目标的研究，他是微软“规模可伸缩的服务器研究小组”(Scalable Servers Research Group)的高级研究员，该项目已有若干研究成果在网上公布。

    格雷的电子信箱为：

    gray @ microsoft．com

他的因特网个人主页为：

http：//www．research．microsoft．com/research／barc／gray

(引用自:http://202.207.0.245:9001/jisuanjifazhanshi/tuling/33.htm)

　　---雇员表(EMPLOYE)

以下是代码片段：     CREATE TABLE EMPLOYE ( 　　EMPLOYEID INTEGER NOT NULL,---员工号 　　NAME VARCHAR(20) NOT NULL,---姓名 　　SALARY DOUBLE---薪水 　　); 　　INSERT INTO EMPLOYE (EMPLOYEID,NAME,SALARY) VALUES 　　(1,'张三',1000), 　　(2,'李四',2000), 　　(3,'王五',3000), 　　(4,'赵六',4000), 　　(5,'高七',5000);

　　--经理表(MANAGER)

以下是代码片段：     CREATE TABLE MANAGER ( 　　EMPLOYEID INTEGER NOT NULL,---经理号 　　NAME VARCHAR(20) NOT NULL,---姓名 　　SALARY DOUBLE---薪水 　　); 　　INSERT INTO MANAGER (MANAGERID,NAME,SALARY) VALUES 　　(3,'王五',5000), 　　(4,'赵六',6000);

　　---雇员表(EMPLOYE)

以下是代码片段：     CREATE TABLE EMPLOYE ( 　　EMPLOYEID INTEGER NOT NULL,---员工号 　　NAME VARCHAR(20) NOT NULL,---姓名 　　SALARY DOUBLE---薪水 　　); 　　INSERT INTO EMPLOYE (EMPLOYEID,NAME,SALARY) VALUES 　　(1,'张三',1000), 　　(2,'李四',2000), 　　(3,'王五',3000), 　　(4,'赵六',4000), 　　(5,'高七',5000);

　　--经理表(MANAGER)

以下是代码片段：     CREATE TABLE MANAGER ( 　　EMPLOYEID INTEGER NOT NULL,---经理号 　　NAME VARCHAR(20) NOT NULL,---姓名 　　SALARY DOUBLE---薪水 　　); 　　INSERT INTO MANAGER (MANAGERID,NAME,SALARY) VALUES 　　(3,'王五',5000), 　　(4,'赵六',6000);

　　--更新存在的

以下是代码片段：     UPDATE EMPLOYE AS EM SET SALARY=(SELECT SALARY FROM MANAGER WHERE MANAGERID=EM.EMPLOYEID) 　　WHERE EMPLOYEID IN ( 　　SELECT MANAGERID FROM MANAGER 　　);

　　---插入不存在的

以下是代码片段：     INSERT INTO EMPLOYE (EMPLOYEID,NAME,SALARY) 　　SELECT MANAGERID,NAME,SALARY FROM MANAGER WHERE MANAGERID NOT IN ( 　　SELECT EMPLOYEID FROM EMPLOYE 　　);

　　--更新存在的

以下是代码片段：     UPDATE EMPLOYE AS EM SET SALARY=(SELECT SALARY FROM MANAGER WHERE MANAGERID=EM.EMPLOYEID) 　　WHERE EMPLOYEID IN ( 　　SELECT MANAGERID FROM MANAGER 　　);

　　---插入不存在的

以下是代码片段：     INSERT INTO EMPLOYE (EMPLOYEID,NAME,SALARY) 　　SELECT MANAGERID,NAME,SALARY FROM MANAGER WHERE MANAGERID NOT IN ( 　　SELECT EMPLOYEID FROM EMPLOYE 　　);

　　上面的处理是可以的，但是我们还可以有更简单的方法，就是用Merge语句，如下所示：

以下是代码片段：     MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED THEN UPDATE SET EM.SALARY=MA.SALARY 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY); 　　MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED THEN UPDATE SET EM.SALARY=MA.SALARY 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY);

以下是代码片段：     MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY); 　　MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY);

　　不仔细的朋友可能没有看出上面两条语句的区别，哈哈，请仔细对比一下这两条语句。上面的语句中多了ELSE IGNORE语句，它的意思正如它英文的意思，其它情况忽略不处理。如果你认为理论上应该不存在EM.SALARY>MA.SALARY的数据，如果有，说明有问题，你想抛个异常，怎么办？如下：

以下是代码片段：     MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN MATCHED AND EM.SALARY>MA.SALARY THEN SIGNAL SQLSTATE '70001' SET MESSAGE_TEXT = 'EM.SALARY>MA.SALARY' 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY) 　　ELSE IGNORE; 　　MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN MATCHED AND EM.SALARY>MA.SALARY THEN SIGNAL SQLSTATE '70001' SET MESSAGE_TEXT = 'EM.SALARY>MA.SALARY' 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY) 　　ELSE IGNORE;

　　对于EM.SALARY>MA.SALARY的情况，如果你不想抛异常，而是删除EMPLOYE中的数据，怎么办？如下：

以下是代码片段：     MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN MATCHED AND EM.SALARY>MA.SALARY THEN DELETE 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY) 　　ELSE IGNORE; 　　MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN MATCHED AND EM.SALARY>MA.SALARY THEN DELETE 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY) 　　ELSE IGNORE;

　　以上简单介绍了Merge语句的使用，它的应用不只是上面介绍的情况，其实它可以应用在很多其他语句不好处理情况，这需要你去发现，记住熟能生巧

下面是相应的输出：
DB2 Universal Database Version 7.2, 5622-044 (c) Copyright IBM Corp. 1991, 2001
Licensed Material - Program Property of IBM
IBM DATABASE 2 SQL Explain Tool

Processing package DB2INST1.P0203450.
******************** PACKAGE *********************

Package Name = DB2INST1.P0203450
--------Prep Date = 2002/12/17
--------Prep Time = 16:02:04

--------Bind Timestamp = 2002-12-17-16.02.04.373971

--------Isolation Level ---------= Cursor Stability
--------Blocking---------------- = Block Unambiguous Cursors
--------Query Optimization Class = 5

--------Partition Parallel ------= No
--------Intra-Partition Parallel = No

--------Function Path----------- = "SYSIBM", "SYSFUN", "DB2INST1"

Processing Section 1.
-------------------- SECTION ----------------------
......
-------------------- SECTION ----------------------
Section = 2

SQL Statement:

update STAFF set NAME = 'test'
where ID = 350

Estimated Cost = 75
Estimated Cardinality = 2

Access Table Name = DB2INST1.STAFF ID = 2,3
| #Columns = 2
| Relation Scan
| | Prefetch: Eligible
| Lock Intents
| | Table: Intent Exclusive
| | Row : Update
| Sargable Predicate(s)
| | #Predicates = 1
Update: Table Name = DB2INST1.STAFF ID = 2,3

End of section

Optimizer Plan:

------UPDATE
------( -2)
------/-- \
-TBSCAN --Table:
--( 3) --DB2INST1
---| -----STAFF
Table:
DB2INST1
STAFF
......

可以用下面命令找出数据库中存在的程序包：
db2 "select pkgschema, pkgname from syscat.packages"
上面例子中的程序包DB2INST1.P0203450是一个存储过程。

-------------------

设置当前模式：

set current path = oais(模式名)

查看当前的模式：

db2 values(current path)

设置为默认的、缺省的：

set current path = system path

----------------------------------------

详细的列表信息请查看：
see IBM publib site for Database tuning overview.

db2 "select * from Linux_CPU" 总是提示表未定义.后来发现表名大小写问题,应该在db2提示符下运行 select * from "Linux_CPU"或者db2 "select * from \"Linux_CPU\""才正确,.晚上在IBM网站上查到详细说明.

如何定义和使用含小写字符的 DB2 表名？

这种方案是否可行

配置类型

数据库管理器

适用于

• 具有本地和远程客户机的数据库服务器
• 具有本地客户机的数据库服务器
• 具有本地和远程客户机的分区数据库服务器

参数类型

可配置

缺省值 [范围]

UNIX 32 位平台

20 000 [ 250 -- 2 097 152 ]

Windows 平台

10 000 [ 250 -- 2 097 152 ]

64 位平台

20 000 [ 250 -- 2 147 483 647 ]

计量单位

页（4 KB）

专用排序和共享排序使用两个不同内存资源中的内存。共享排序内存区的大小是根据 sheapthres 的值，在第一次与数据库连接时静态地预先确定的。专用排序内存区的大小不受限制。

sheapthres 参数对于专用和共享的排序用法是不同的：

• 对于专用排序，此参数是在一个实例内对任何给定时间专用排序可占用的总内存量的 软 限制。当一个实例的总专用排序内存占用达到了此限制时，为附加入站的专用排序请求分配的内存将显著减少。
• 对于共享排序，此参数是在一个数据库内对任何给定时间共享排序占用的总内存量的硬限制。当达到此限制时，将不允许其它共享排序内存请求（直到总共享排序内存的占用降低至 sheapthres 指定的限制以下为止）。（在某些情况下，配置共享排序最大值的另一种方法是使用 sheapthres_shr 数据库配置参数。）

使用排序堆的操作的示例包括：排序、散列连接、动态位图（用于索引 AND 运算和星型连接）和表位于内存中的操作。

显式定义阈值可防止数据库管理器对大量排序使用过量内存。

当从非分区数据库移至分区数据库环境时，不应增大此参数的值。一旦在单个数据库分区环境中调整了数据库和数据库管理器配置参数，在大多数情况下，相同的值在分区数据库环境将同样合适。

作为数据库管理器配置参数的“排序堆阈值”参数应用于整个 DB2 实例。将该参数设置为不同节点或分区上的不同值的唯一方法是创建多个 DB2 实例。这将需要通过不同数据库分区组管理不同的 DB2 数据库。这样安排将无法发挥分区数据库环境的许多优点。

建议： 理想情况下，应将此参数设置为您在数据库管理器实例中拥有的最大 sortheap 参数的一个合理倍数。此参数 至少 应是该实例中为任何数据库定义的最大 sortheap 的两倍。

如果您正执行专用排序并且您的系统不受内存约束，则可使用下列步骤来计算此参数的理想值：

1. 计算每个数据库的典型排序堆的使用：

   （对该数据库运行的并发代理程序的典型数目）
       * （sortheap，为该数据库定义的） 

2. 对以上结果求和，该值提供可在实例中所有数据库的典型环境中使用的总排序堆。

应使用基准程序技术来调整此参数以找到在排序性能和内存使用之间的相应平衡。

可以使用数据库系统监视器并借助后阈值排序（ post_threshold_sorts ）监视元素来跟踪排序活动。

sortheap － 排序堆大小 配置参数

配置类型

数据库

参数类型

可联机配置

传播类

语句边界

缺省值 [范围]

32 位平台

256 [ 16 - 524 288 ] 2 2

64 位平台 2

256 [ 16 - 4 194 303 ] 2

计量单位

页（4 KB）

分配时

需要执行排序时

释放时

当排序完成时

此参数定义要用于专用排序的专用内存页的最大数目或要用于共享排序的共享内存页的最大数目。如果排序为专用排序，则此参数将影响代理程序专用内存。如果排序为共享排序，则此参数将影响数据库共享内存。每个排序都有一个独立的排序堆，该排序堆是由数据库管理器按照需要分配的。此排序堆是将数据排序的区域。如果由优化器定向，则将使用优化器提供的信息分配一个比此参数指定的排序堆小的排序堆。

建议： 当使用排序堆时，应该考虑下列事项：

• 适当的索引可使排序堆的使用减至最小程度。
• 散列连接缓冲区和动态位图（用于索引 AND 计算和星型连接）使用排序堆内存。在使用这些技术时，增大此参数的大小。
• 当需要进行频繁的大型排序时，增大此参数的大小。
• 当增大此参数的值时，应该检查是否还需要调整数据库管理器配置文件中的 sheapthres 参数。
• 排序堆大小由优化器在确定存取路径时使用。在更改此参数后，应考虑重新绑定应用程序（使用 REBIND 命令）。

 Which of the following settings would allow 20 sorts with a maximum of 10MB each to run currently on a 64-bit instance?
A. Set the DB SHEAPTHERS to 50000 and DB SORTHEAP to 2500
B. Set the DBM SHEAPTHERES to 50000 and DB SORTHEAP to 2500
 C. Set the DBM SHEAPTHERS to 50000 and DBM SORTHEAP to 2500
D. Set the DBM SHEAPTHERS_SHR to 50000 and DBM SHEAPTHRES to 2500

　　如果你使用图形界面的配置向导，你需要回答一系列问题，这些问题相当于AUTOCONFIGURE命令中的参数(如表1所示)。首先让我们看一AUTOCONFIGURE的命令格式:

　　>>-AUTOCONFIGURE--+---------------------------------------+----->
　　| .----------------------------. |
　　| V | |
　　'-USING----input-keyword--param-value-+-'
　　>--APPLY--+-DB ONLY----+---------------------------------------><
　　+-DB AND DBM-+
　　'-NONE-------'

　　表 1显示了选项关键字和取值范围。

　　表 1 关键字和取值范围

　　关键字

　　
 取值范围  默认值 解释
mem_percent  1-100  80  设定DB2使用内存的多少。如果还有其他应用程序使用，请选择小于100的数值

　　
 
workload_type  simple, mixed,

　　
 complex mixed  指定工作负荷类型，simple（简单）类型主要指IO访问比较集中，对于大多数OLTP系统，选择simple类型。Complex类型主要是对CPU占用较多的复杂查询系统，如OLAP系统。如果你的系统介于两者之间，选择mixed类型。
num_stmts

　　
 1-1 000 000  10  系统中每一个事务包含的SQL语句数
tpm  1-200 000  60  每分钟进行的交易数。

　　
 
admin_priority

　　
 performance, recovery, both both  选择你的管理策略，可以是更好的性能，或者是更快的数据库恢复时间。
is_populated

　　
 yes, no  yes  数据库已经存在数据
num_local_apps

　　
 0-5 000  0  本地连接数
num_remote_apps  0-5 000  10

　　
 远程连接数
isolation  RR, RS, CS, UR  RR

　　
 应用程序的隔离级别
bp_resizeable

　　
 yes, no yes  缓冲池是否可调整大小

　　APPLY DB ONLY

　　在当前数据库管理器的配置参数下，显示推荐的数据库和缓冲池的参数，并应用与数据库和缓冲池。

　　APPLY DB AND DBM

　　显示并应用推荐的数据库管理器参数、数据库参数和缓冲池参数。

　　APPLY NONE

　　仅仅显示推荐值，但不更改配置参数。

　　使用该命令配置数据库，关键要选择合适的参数(参见表1选择你的参数选项)。下面我们通过一个例子来说明如何使用AUTOCONFIGURE命令配置数据库。假设我们在一个分区的数据库环境中，只有一个数据库实例db2inst1和数据仓库TESTDW，并且已经装载了数据。 我们使用下面的命令对该数据库调整参数:

　　db2_all “db2 connect to testdw; db2 autoconfigure using mem_percent 80 workload_type complex num_stmts 10 tpm 20 admin_priority both num_local_apps 5 num_remote_apps 50 isolation cs apply db and dbm; db2 connect reset;”

　　你也可以创建一个脚本autoconfigure.db2，存放在DB2 实例的共享目录下，假设为/home/db2inst1, 内容如下:

　　connect to testdw;

　　autoconfigure using mem_percent 80 workload_type complex num_stmts 10 tpm 20 admin_priority both num_local_apps 5 num_remote_apps 50 isolation cs apply db and dbm;

　　connect reset;

　　然后使用db2_all命令在所有的数据库分区上执行这条命令，我们假设改脚本的存放目录为/home/db2inst1/autoconfigure.db2:

　　db2_all “”db2 -tvf /home/db2inst1/autoconfigure.db2 >>autoconfigure##.log”

　　执行完毕后，你可以通过autoconfigure*.log来察看该命令在每一个数据库分区上的执行情况。然后重新启动DB2实例，让这些参数生效。运行一些基准测试的查询语句，测试DB2 配置向导的配置结果。

　　你也可以使用配置向导图形界面来配置你的数据库。你可以通过在控制中心中选中你的数据库，然后点右键，选择“配置向导”来启动配置向导。如果你需要使用图形界面配置分区数据库，记得要将结果保存为任务，并将配置结果导出到一个脚本文件中，如/home/db2inst1/autoconfigure.db2。这样你就可以使用db2_all命令来执行该脚本配置所有的数据库分区了:

　　db2_all “”db2 -tvf /home/db2inst1/autoconfigure.db2 >>autoconfigure##.log”

　　如果你对DB2非常熟悉，你可以对DB2自动配置产生的配置文件做适当的修改。总之，DB2配置向导是一个非常简单易用的工具，能够大大减少DBA的工作量。

原文来自：雨枫技术教程网 http://www.fengfly.com
原文网址：http://www.fengfly.com/plus/view-30426-1.html

　　db2batch 是一种基准测试工具，它以一组 SQL 和/或 XQuery 语句作为输入，动态地准备语句和描述语句，并返回一个结果集。取决于 db2batch 命令中所使用的选项，结果集可以返回这些语句的执行时间、关于内存使用情况(例如缓冲池)的数据库管理器快照和缓存信息。

　　可以在一个 flat 文件或标准输入中指定要运行基准测试的语句。在输入文件中可以设置很多控制选项。指定这些选项的语法是：--#SET control_option value 。下面是包含控制选项的一个输入文件的例子。要获得控制选项的完整列表，请参考 Information Center。

-- db2batch.sql -- ------------ --#SET PERF_DETAIL 3 --#SET ROWS_OUT 5 -- This query lists employees, the name of their department -- and the number of activities to which they are assigned for -- employees who are assigned to more than one activity less than -- full-time. --#COMMENT Query 1 select lastname, firstnme, deptname, count(*) as num_act from employee, department, emp_act where employee.workdept = department.deptno and employee.empno = emp_act.empno and emp_act.emptime < 1 group by lastname, firstnme, deptname having count(*) > 2; --#SET PERF_DETAIL 1 --#SET ROWS_OUT 5 --#COMMENT Query 2 select lastname, firstnme, deptname, count(*) as num_act from employee, department, emp_act where employee.workdept = department.deptno and employee.empno = emp_act.empno and emp_act.emptime < 1 group by lastname, firstnme, deptname having count(*) <= 2;

• 　　选项 PERF_DETAIL 3 意味着将返回关于花费的时间和数据库管理器、数据库及应用程序的快照这些性能方面的细节。
• 　　选项 ROWS_OUT 5 意味着无论查询返回的实际行数是多少，只从结果集中取 5 行。
• 　　COMMENT Query1 将语句命名为 Query1。

　　下面的命令在 SAMPLE 数据库上调用基准测试工具，输入文件为 db2batch.sql。

　　db2batch -d sample -f db2batch.sql

　　这个命令将返回查询的结果集(限 5 行)和查询所花费的时间及 CPU 时间。另外还返回数据库管理器、数据库和应用程序快照。由于输出很大，因此这里只显示 db2batch 命令的概要。

* Summary Table: Type      Number      Repetitions Total Time (s) Min Time (s)   ... --------- ----------- ----------- -------------- -------------- Statement           1           1       0.052655       0.052655 ... Statement           2           1       0.004518       0.004518 ... ...Max Time (s)   Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output    -------------- --------------- -------------- -------------- ------------- ...      0.052655        0.052655       0.052655              5             5 ...      0.004518        0.004518       0.004518              8             5                                               * Total Entries:              2               * Total Time:                 0.057173 seconds * Minimum Time:               0.004518 seconds * Maximum Time:               0.052655 seconds * Arithmetic Mean Time:       0.028587 seconds * Geometric Mean Time:        0.015424 seconds

　　db2batch 命令支持很多选项。这里只列出其中一些选项，让您对这个工具的威力有所了解。

• 　　-m parameter_file 用参数值指定用于绑定到 SQL 语句参数占位符的一个输入文件。
• 　　-r result_file 指定存放命令结果的输出文件。
• 　　-i short|long|complete 指定从哪个方面测量所花费的时间。short 测量运行每条语句所花费的时间。long 测量运行每条语句所花费的时间，包括语句之间的开销。complete 测量运行每条语句所花费的时间，分别报告准备、执行和取数据的时间。
• 　　-iso 指定语句使用的隔离级别。默认情况下，db2batch 使用 Repeatable Read 隔离级别。

CREATE TABLE EMPDATA
(
EMPNO INT NOT NULL,
SEX CHAR(1) NOT NULL
CONSTRAINT SEXOK
CHECK (SEX IN ('M','F'))
NOT ENFORCED
ENABLE QUERY OPTIMIZATION,
SALARY INT NOT NULL,
CONSTRAINT SALARYOK
CHECK (SALARY BETWEEN 0 AND 100000)
NOT ENFORCED
ENABLE QUERY OPTIMIZATION
)

本例包含两个更改列约束行为的语句。第一个选项是 NOT ENFORCED，它建议 DB2 在插入或更新数据时不强制检查本列。第二个选项是 ENABLE QUERY OPTIMIZATION，DB2 在对该表运行 SELECT 语句时使用它。指定该值时，DB2 将在优化 SQL 时使用约束中的信息。

NOT ENFORCED 选项

若表包含 NOT ENFORCED 选项，INSERT 语句的行为可能会变得很古怪。对 EMPDATA 表运行以下 SQL 语句时，不会产生任何错误：

INSERT INTO EMPDATA VALUES
(1, 'M', 54200),
(2, 'F', 28000),
(3, 'M', 21240),
(4, 'F', 89222),
(5, 'Q', 34444),
(6, 'K',132333)

编号是 5 的员工的性别显然有问题（Q），编号 6 的员工不但性别有问题，同时工资也超出了 SALARY 列的限制。在这两种情况下，DB2 依然允许插入，因为约束是 NOT ENFORCED。这指出了信息约束的一个薄弱之处。您必须确定所插入或载入的数据符合在 DB2 中放置的定义。

ENABLE QUERY OPTIMIZATION 选项

在上一屏运行的插入之后，如果再对 EMPDATA 表执行 SELECT 语句，其结果很可能会令您更加迷惑：

SELECT * FROM EMPDATA
WHERE SEX = 'Q';

EMPNO SEX SALARY
----------- --- -----------

0 record(s) selected.

DB2 向查询返回了错误的答案。表中发现了 “Q” 值，但该列上的约束告诉 DB2 有效值仅包括 “M” 和 “F”。ENABLE QUERY OPTIMIZATION 关键字还允许 DB2 在优化 SQL 语句时使用这一约束信息。若这并非您所希望的行为，那么您就需要使用 ALTER 命令来更改约束：

ALTER TABLE EMPDATA
ALTER CHECK SEXOK DISABLE QUERY OPTIMIZATION

现在，再重新执行之前的查询。结果如下所示：

SELECT * FROM EMPDATA
WHERE SEX = 'Q';

EMPNO SEX SALARY
----------- --- -----------
5 Q 34444

1 record(s) selected.