使用 db2pd 进行监视和故障诊断
db2解决死锁的方法
db2解决死锁的方法DB2是一种常见的关系型数据库管理系统，它被广泛应用于企业级应用程序中。
然而，随着应用程序的复杂性增加和并发访问的增加，死锁问题也变得越来越常见。
在本文中，我们将探讨一些使用DB2解决死锁问题的方法。
1. 死锁的定义和原因死锁是指两个或多个事务彼此等待对方持有的资源，从而导致所有事务无法继续执行的状态。
死锁通常发生在并发访问数据库时，其中一个事务正在使用某个资源，而另一个事务需要访问相同的资源。
死锁的发生原因可以归结为四个条件：互斥（资源只能被一个事务使用）、持有并等待（一个事务持有资源并等待另一个事务的资源）、不可剥夺（资源不能被其他事务抢占）、循环等待（多个事务形成循环等待资源）。
2. 使用锁机制避免死锁在DB2中，可以使用锁机制来避免死锁的发生。
锁是一种机制，用于协调并发事务对共享资源的访问。
DB2提供了两种类型的锁：共享锁和排他锁。
共享锁允许多个事务同时读取资源，但不允许写入资源；排他锁只允许一个事务同时读取或写入资源。
为了避免死锁，可以采取以下策略：- 在事务开始时，尽量将锁的范围缩小到最小，只锁定必要的资源。
- 在事务执行期间，尽量减少锁的持有时间，执行完操作后尽快释放锁。
- 避免循环等待，即事务在请求资源时按照统一的顺序进行，避免形成死锁的循环等待。
3. 设置适当的隔离级别DB2提供了多种隔离级别，用于控制事务之间的相互影响。
不同的隔离级别对并发访问的控制程度不同。
在选择隔离级别时，需要权衡事务的一致性和性能。
在避免死锁的角度考虑，可以选择较低的隔离级别，如读取已提交（Read Committed）。
较低的隔离级别可以减少锁的竞争，从而降低死锁的风险。
但同时，较低的隔离级别也可能导致数据不一致的问题，需要根据具体业务需求进行权衡。
4. 监控和诊断死锁DB2提供了一些工具和功能，用于监控和诊断死锁问题。
可以通过以下方式来实现：- 使用DB2的系统监控工具，如db2pd命令和db2top工具，可以实时查看数据库的锁和死锁情况。
DB2故障处理的解决办法
解决问题的关键在于分清问题的种类，并清楚每种问题的解决办法。
另外很多的数据库的问题都是由于错误的操作，错误的配置引起的，所以本文在解释怎么样处理问题时也会给出一些好的建议，来避免产生问题。
本文重点介绍实用的方法。
对问题的分类有很多种方法，在本文中我我采用了两种分类方案。
第一种方案是是否有错误码。
即发生错误时是否同时返回了错误码，错误码既包括执行命令的返回码，也包扩应用程序的返回码。
有返回码的错误解决方案是，在db2 CLP中运行db2?SQLXXXX，然后根据对该问题的解释采取相应的解决方案。
对没有错误码的问题，如数据库hang，CPU使用率过高等问题，解决问题的经验将非常重要，在本文中会有详细的说明。
根据错误码解决问题举例（在下文中，再出现需要用这种方法解决问题时将不再重复）：如在连接数据库时发生错误db2 connect to sampleSQL0332N There is no available conversion for the source codepage"1386" tothe 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=1386db2 terminatedb2 connect to sample就可以成功连接了。
db2 实践+性能调优和问题诊断最佳实践+第+2+部分
developerWorks 中国 > Information Management >DB2 最佳实践: 性能调优和问题诊断最佳实践，第 2 部分有条不紊地进行性能调优和故障诊断级别：初级developerWorks 中国网站编辑团队, 编辑, IBM2009 年 3 月 12 日本系列介绍了 DB2 系统性能的最优方法，分两部分。
第 1 部分首先介绍为了达到良好性能，我们如何从软硬件配置方面来保障，紧接着讨论了在多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。
第 2 部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。
概述就算是配置最仔细的系统也终究会发现它仍然需要一定的性能调优，并且这时我们已经搜集了的运行监控数据，将来非常便于搜集。
保持一种系统的方法来调优和进行故障诊断对我们非常重要。
当发生了一个问题，为了解决这个问题，很容易随意的进行调整。
然而，当我们这么做了，事实上定位到问题的可能性非常低，甚至让问题更糟糕。
性能调优的一些基本原则：1.有备而来，去了解系统一切正常的情况下性能怎么样。
搜集运行监视信息来跟踪一段时间内系统行为的变化。
2.了解整个场景，不要局限于你从 DB2 上看到的 – 也要搜集并分析来自于操作系统、存储、应用程序甚至来自用户的数据。
了解系统本身将有助于你解释监控数据。
3.只调整能解释你看到的症状的参数，如果连发动机都无法启动就不要更换轮胎。
不要试图通过降低 CPU 来解决磁盘的瓶颈。
4.一次只改一个参数，在更改其它参数之前先观察效果。
你可能遇到的问题类型性能问题往往分为两大类：影响了整个系统的问题和只影响了部分系统的问题。
比如某一特定应用或 SQL 语句，在研究的过程中－种类型的问题可能转化为另外一种类型的问题，或者相反。
例如造成整个系统性能降低可能是一个单独的语句，或者是整个系统的问题只是在一个特定的区域被发现。
下面我们从整个系统的问题开始。
db2pd命令捕获死锁信息
本文通过一个实例讲解了在DB2版本9以后，如何使用db2pd命令捕获死锁信息死锁经常会存在于我们的应用系统中，如何捕获死锁信息并解决死锁问题，是一个比较复杂的问题。
DB2提供了死锁事件监控器来获取死锁信息，可以非常方便地获取死锁信息。
从DB2版本8.2.2开始，DB2也可以使用db2pd命令和db2cos脚本来获取死锁信息，提供了一种新的途径来获取死锁信息。
从DB2版本9开始，我们可以使用db2pd -catch 命令来捕获错误信息，然后调用一个sqllib/db2cos 的脚本收集出错时的现场信息。
该命令的使用语法如下：Usage:-catch clear | status | <errorCode> [<action>] [count=<count>]Sets catchFlag to catch error or warning.Error Codes:<sqlCode>[,<reasonCode>] / sqlcode=<sqlCode>[,<reasonCode>]ZRC (hex or integer)ECF (hex or integer)"deadlock" or "locktimeout"Actions:[db2cos] (default) Run sqllib/db2cos callout script[lockname=<lockname>] Lockname for catching specific lock(lockname=000200030000001F0000000052)[locktype=<locktype>] Locktype for catching specific lock(locktype=R or locktype=52)下面我们通过一个实例来讲解如何使用db2pd -catch命令获取死锁信息。
DB2监控总结
列出所有对数据库的连接。
针对连接数达到最大，可以用命令db2 get snapshot for dbm 查看High water mark for agents registered此项的数字，
db2 list application show detail查看连接
db2 get snapshot for all on labdb >snap.out //扑捉所有快照
捕获单个快照的监控数据
Db2 get snapshot for dynamic sql on table> snap.out
grep -n "Number of executions" snap.out | grep -v "= 0" | sort -k 5,5rn | more
SELECT * FROM TABLE( SNAPSHOT_CONTAINER( 'SAMPLE', -1 )) as SNAPSHOT_CONTAINER
--To capture a snapshot of the ranges for a table space map:
--Buffer pool: To capture a snapshot of buffer pool information:
SELECT * FROM TABLE( SNAPSHOT_BP( 'SAMPLE', -1 )) as SNAPSHOT_BP
--Table space:To capture a snapshot of table space information:
DB2 最佳实践-性能调优和问题诊断最佳实践
DB2 最佳实践: 性能调优和问题诊断最佳实践，第1 部分性能调优从配置和监控开始2009 年 3 月12 日本系列介绍了DB2 系统性能的最优方法，分两部分。
第一部分首先介绍为了达到良好性能，我们如何从软硬件配置方面来保障，紧接着讨论了在多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。
第 2 部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。
内容提要大多数DB2 系统都经过了性能的演变。
首先，不论出于硬件还是软件的观点，该系统首先要能被配置。
在多数情况下，这将成为系统在实施后如何运行的基础。
其次，系统一经发布，勤勉的数据库管理员（DBA）将监控系统的性能，来监测任何可能的开发问题。
如果发现任何问题，我们就进入下一个阶段- 故障诊断阶段。
每个阶段都是基于上一阶段，如果没有适当的准备，我们极有可能需要处理比较困难的问题。
本文介绍了DB2 系统性能的最优方法。
我首先涉及到一些有助于我们确保良好软硬件性能的重要原则。
然后我们讨论多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。
最后，尽管我们做了最好的准备，性能问题仍然可以降临到我们身上，我们讨论如何逐步地处理它们，并有条不紊的进行。
回页首简介任何形式的性能问题都将严重影响并降低一个系统对你组织的价值、削弱业务能力、服务中断、以及增加管理开销。
所有这些都会提升总的拥有成本。
缺乏对系统配置的基本原则，监视和性能故障诊断可能导致不同程度的性能低下，并且降低对于组织的价值。
因此，在前期花些时间去考虑基本的配置指导方针和建立健全的系统监控这样的做法，将使你对处理许多可能出现的典型性能问题，有充分的准备。
并使数据服务器得以高性能运行，以提高投资回报率。
回页首第一步：从配置上实现性能良好像InfoSphere 平衡的仓库（BW）这类的DB2 部署类型，或者那些在SAP 系统之内的系统，配置都是高度确定的。
在BW 案例中，像CPU 个数、内存对 CPU 的比率、硬盘的个数和配置这样的硬件因素，以及在预先指定版本的基础上，详尽的测试，以确定最优配置。
Lab 1-4 db2pd对锁的监控
db2pd对锁的监控（30分钟）目的：掌握db2pd对于锁信息监控的使用技巧1．打开3个db2cmd窗口，并分别连接到sample数据库2．在第一个窗口中输入3．在第二个窗口中输入此时，这条命令会等待。
下面我们用db2pd来分析这种等待的情况。
4．在第三个窗口中输入db2pd -db sample -locks wait showlocksdb2pd报告了有两个交易(TranHdl: Transaction Handler)产生了锁等待，其中一个交易(TranHdl=6)的锁状态(Mode)为G，表示该锁已被授予(Granted)，另外一个交易(TranHdl=2)的锁为等待(W, Waiting)。
5．为了查出在那张表上产生了锁等待，我们在第三个窗口中输入db2 "SELECT TABSCHEMA, TABNAME FROM SYSCAT.TABLES WHERE TBSPACEID = 2 AND TABLEID = 6"由此，我们查出在EMPLOYEE这张表上产生了锁等待。
由此，我们完成了从事务到应用的对应，我们发现事务2,6分别属于应用30, 34，而且这两个应用都处于Write的状态。
因此，我们确定是写操作产生了锁等待。
7．我们需要近一步查出产生锁等待的应用程序的程序名，我们在第三个窗口中输入db2pd -agents由此，我们也找出了是哪两个客户端进程(Process ID)产生了锁等待。
8．能否近一步看出是什么样的SQL语句产生了锁？首先通过以下语句获得应用程序的更多信息，其中L-Anch ID表示上次执行的SQL，C-Anch ID表示当前执行的SQL：db2pd -db sample -applications9．得到上述信息后，我们再通过下述语句，就可以找出产生锁等待的SQL语句了db2pd -db sample -dynamic结果如下图所示：。
使用 db2pd 进行监视和故障诊断
使用 db2pd 进行监视和故障诊断因为 db2pd 工具可从 DB2® 内存集合迅速返回即时信息，所以该工具可用于故障诊断。
该工具不需要获得任何锁存器或使用任何引擎资源就可以收集信息。
因此，在 db2pd 收集信息时，有可能（并且预计）会检索到正在更改的信息；这样，数据可能不是十分准确。
如果遇到正在更改的内存指针，可使用信号处理程序来防止 db2pd 异常终止。
这可能会导致输出中出现诸如以下的消息：“正在更改的数据结构已强制终止命令”。
虽然如此，该工具对于故障诊断却非常有用。
在不锁存的情况下收集信息有两个好处：检索速度更快并且不会争用引擎资源。
如果要在出现特定 SQLCODE、ZRC 代码或 ECF 代码时捕获关于数据库管理系统的信息，那么可以使用 db2pdcfg -catch 命令完成此操作。
捕获到错误时，将启动 db2cos（调出脚本）。
db2cos 文件可以自动改变，以便运行解决问题所需的任何 db2pd 命令、操作系统命令或任何其他命令。
在 UNIX® 和Linux™ 上，模板文件 db2cos 位于 sqllib/bin 中。
在 Windows® 操作系统上，db2cos 位于 $DB2PATH in 目录中。
以下是使用 db2pd 快速故障诊断的一组示例。
场景 1：诊断锁定等待使用 db2pd -db <database name> -locks -transactions -applications -dynamic 命令来获取下列结果：锁定：Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att ReleaseFlg0x07800000202E5238 3 00020002000000040000000052 Row ..X G 3 1 0 0x00000x400000000x07800000202E4668 2 00020002000000040000000052 Row ..X W* 2 1 0 0x00000x40000000对于使用 -db 数据库名称选项指定的数据库，开头的结果会显示该数据库的锁定。
关于DB2数据库问题故障分析
----创建用户临时表空间
db2 "create USER temporary tablespace ORCLSP_USER_TMP pagesize 8k managed by system using ('/home/db2inst1/temp')"
----创建BUFFER
db2 "create bufferpool ker pagesize 8k '/home/db2inst1/' "
DB20000I The SQL command completed successfully.
-----创建系统临时表空间并指定BUFFER
db2 "create system temporary tablespace temp pagesize 8k bufferpool zy"
------断点恢复
1、首先备份sample1数据库，查看归档日志的路径，看看最后归档的时间。（一般最后最后归档的时间的那个是坏的，前一个因该可以用例2011-06-08-01.21.25.000000。）
2、将sample1数据库的活动日志文件拷贝到一个新的目录下（例/home/db2inst1/archivelogs/db2inst1/ORCL）。
[db2inst1@localhost $]$ db2move orcl import -u db2inst1 -p db2inst1 >db2moveout.log
说明：实施数据迁移的前提是1、某个非关键业务的表发生错误，导致数据库不能正常操作。
2、凭个人经验"-901"一般是除坏表外其它表数据能导出来，可实现迁移。而"-1224"，数据库损坏严重，一般导到坏表时，数据库就自动断开连接了，其它表基本上导不出来，不能进行迁移。
db2pd简介及使用方法
1.打开 db2pd – Monitor and Troubleshoot DB Command，如图 3 所示。
图 3. DB2 Information Center 中关于 db2pd 工具的信息调用 db2pd 工具有两种方式。
可以用交互模式调用 db2pd 工具，或者直接在操作系统命令提示符下运行。
要是用交互模式执行该工具，可以在操作系统命令提示符下输入 db2pd –interactive 或者直接输入 db2pd，这样将看到 db2pd 命令提示符db2pd>，可以输入命令选项。
使用–help 选项可以获得帮助信息。
退出 db2pd 命令提示符只需要输入 quit 或者 q。
图 4 中的例子说明了如何使用交互模式显示当前的代理。
图 4. 用交互模式调用 db2pd在操作系统命令提示符下调用该工具可以输入带有命令选项的 db2pd 命令。
下面的例子（图 5）使用 -agents 选项显示了所有的活动代理。
图 5. 在操作系统命令提示符下调用 db2pd此外，还可以通过将选项保存在文件中或者在 DB2PDOPT 环境变量中设置选项来控制该命令。
下面的例子（图 6）说明可以将 -agents 选项保存在一个（在该例中）名叫file.out的文件中，然后使用 db2pd –command file.out 执行选项。
图 6. 将 db2pd 选项保存在文件中如果要使用 DB2PDOPT 环境变量，可以将 DB2PDOPT 设成需要的选项然后像下面这样调用 db2pd：图 7. 在 DB2PDOPT 环境变量中设置 db2pd 选项更好的是，可以指定–repeat 参数重复该命令。
比方说，下面的命令每 2 秒钟显示一次 DB2 内存信息，共 5 次：db2pd –mempools –repeat 2 5此外，通过 file= 参数还可以将特定 db2pd 命令选项的结果保存到文件中。
file 和 repeat 参数可以结合使用：回页首监控的例子下面这些例子说明了如何用 db2pd 工具监控您的数据库环境。
DB2(常用工具)具体实用
题目：1、熟练使用db2look工具导出数据库结构2、使用db2pd监控表空间、锁的使用情况3、使用db2mtrk 检查数据库内存的分配情况4、练习使用db2top工具5、使用db2batch测试SQL语句的性能解答：1、熟练使用db2look工具导出数据库结构[myinst@ye ~]$ db2look -d mydb3 -l -e -o mydb3.dll-- No userid was specified, db2look tries to use Environment variable USER-- USER is: MYINST-- Creating DDL for table(s)-- Output is sent to file: mydb3.dll-- Binding package automatically ...-- Bind is successful-- Binding package automatically ...-- Bind is successful2、使用db2pd监控表空间、锁的使用情况#db2pd监控表空间[myinst@ye ~]$ db2pd -db mydb3 -tablespaceDatabase Member 0 -- Database MYDB3 -- Active -- Up 0 days 00:29:31 -- Date2015-08-24-11.36.10.344000Tablespace Configuration:Address Id Type Content PageSz ExtentSz Auto Prefetch BufID BufIDDisk FSC NumCntrs MaxStripe LastConsecPg RSE Name0x00007F9AC71E0080 0 DMS Regular 32768 4 Yes 4 1 1 Off 1 0 3 Yes SYSCATSPACE0x00007F9AC71ED220 1 SMS SysTmp 32768 32 Yes 32 1 1 On 1 0 31 No TEMPSPACE10x00007F9AC71FA3C0 2 DMS Large 32768 32 Yes 32 1 1 Off 1 0 31 Yes USERSPACE10x00007F9AC7207560 3 DMS Large 32768 4 Yes 4 1 1 Off 1 0 3 Yes SYSTOOLSPACE0x00007F9AC7214700 4 DMS Large 32768 32 Yes 32 2 2 Off 1 0 31 Yes MYSPACE3Tablespace Statistics:Address Id TotalPgs UsablePgs UsedPgs PndFreePgs FreePgs HWMMax HWM State MinRecTime NQuiescers PathsDropped TrackmodState0x00007F9AC71E0080 0 7168 7164 6880 0 284 68806880 0x00000000 0 0 No n/a0x00007F9AC71ED220 1 1 1 1 0 0 - - 0x00000000 0 0 No n/a0x00007F9AC71FA3C0 2 1024 992 96 0 896 9696 0x00000000 0 0 No n/a0x00007F9AC7207560 3 1024 1020 80 0 940 8080 0x00000000 0 0 No n/a0x00007F9AC7214700 4 1024 992 352 0 640 352352 0x00000000 1439886641 0 No n/aTablespace Autoresize Statistics:Address Id AS AR InitSize IncSize IIP MaxSize LastResize LRF0x00007F9AC71E0080 0 Yes Yes 33554432 -1 No None None No0x00007F9AC71ED220 1 Yes No 0 0 No 0 None No0x00007F9AC71FA3C0 2 Yes Yes 33554432 -1 No None None No0x00007F9AC7207560 3 Yes Yes 33554432 -1 No None None No0x00007F9AC7214700 4 Yes Yes 33554432 -1 No None None NoTablespace Storage Statistics:Address Id DataTag Rebalance SGID SourceSGID0x00007F9AC71E0080 0 0 No 0 -0x00007F9AC71ED220 1 0 No 0 -0x00007F9AC71FA3C0 2 -1 No 0 -0x00007F9AC7207560 3 -1 No 0 -0x00007F9AC7214700 4 -1 No 0 -Containers:Address TspId ContainNum Type TotalPgs UseablePgs PathID StripeSetContainer0x00007F9AC1270580 0 0 File 7168 7164 0 0/www/db2/db2test/myinst/NODE0000/MYDB3/T0000000/C0000000.CAT0x00007F9AC1270C60 1 0 Path 1 1 0 0/www/db2/db2test/myinst/NODE0000/MYDB3/T0000001/C0000000.TMP0x00007F9AC1268A20 2 0 File 1024 992 0 0/www/db2/db2test/myinst/NODE0000/MYDB3/T0000002/C0000000.LRG0x00007F9AC1269A00 3 0 File 1024 1020 0 0/www/db2/db2test/myinst/NODE0000/MYDB3/T0000003/C0000000.LRG0x00007F9AC126AA00 4 0 File 1024 992 0 0/www/db2/db2test/myinst/NODE0000/MYDB3/T0000004/C0000000.LRG#db2pd监控锁的使用情况[myinst@ye ~]$ db2pd -db mydb3 -lockDatabase Member 0 -- Database MYDB3 -- Active -- Up 0 days 00:23:26 -- Date2015-08-24-11.30.05.926325Locks:Address TranHdl Lockname Type Mode Sts Owner Dur HoldCount Att ReleaseFlg rrIID3、使用db2mtrk 检查数据库内存的分配情况#显示数据库的内存分配情况的详细信息[myinst@ye ~]$ db2mtrk -d -vTracking Memory on: 2015/08/24 at 12:12:36Memory for database: MYDB3Backup/Restore/Util Heap is of size 262144 bytesPackage Cache is of size 2293760 bytesOther Memory is of size 196608 bytesCatalog Cache Heap is of size 720896 bytesBuffer Pool Heap (2) is of size 34078720 bytesBuffer Pool Heap (1) is of size 75300864 bytesBuffer Pool Heap (System 32k buffer pool) is of size 1835008 bytesBuffer Pool Heap (System 16k buffer pool) is of size 1572864 bytesBuffer Pool Heap (System 8k buffer pool) is of size 1441792 bytesBuffer Pool Heap (System 4k buffer pool) is of size 1376256 bytesShared Sort Heap is of size 1310720 bytesLock Manager Heap is of size 53936128 bytesDatabase Heap is of size 107085824 bytesApplication Heap (15) is of size 65536 bytesApplication Heap (14) is of size 65536 bytesApplication Heap (13) is of size 65536 bytesApplication Heap (12) is of size 196608 bytesApplication Heap (11) is of size 65536 bytesApplication Heap (10) is of size 65536 bytesApplication Heap (9) is of size 131072 bytesApplication Heap (8) is of size 131072 bytesApplications Shared Heap is of size 917504 bytesTotal: 283115520 bytes#显示数据库的内存使用情况[myinst@ye ~]$ db2mtrk -dTracking Memory on: 2015/08/24 at 12:14:16Memory for database: MYDB3utilh pckcacheh other catcacheh bph (2) bph (1) 256.0K 2.2M 192.0K 704.0K 32.5M 71.8Mbph (S32K) bph (S16K) bph (S8K) bph (S4K) shsorth lockh 1.8M 1.5M 1.4M 1.3M 1.2M 51.4Mdbh apph (15) apph (14) apph (13) apph (12) apph (11) 102.1M 64.0K 64.0K 64.0K 192.0K 64.0Kapph (10) apph (9) apph (8) appshrh64.0K 128.0K 128.0K 896.0K#显示当前实例的内存使用情况[myinst@ye ~]$ db2mtrk -iTracking Memory on: 2015/08/24 at 12:15:10Memory for instanceother fcmbp monh51.2M 832.0K 512.0K#显示当前实例的内存使用的详细信息[myinst@ye ~]$ db2mtrk -i -vTracking Memory on: 2015/08/24 at 12:15:18Memory for instanceOther Memory is of size 53739520 bytesFCMBP Heap is of size 851968 bytesDatabase Monitor Heap is of size 524288 bytesTotal: 55115776 bytes4、练习使用db2top工具[myinst@ye ~]$ db2top -d mydb3按快捷键“d”，转至数据库屏幕按快捷键“D”，转至动态SQL 屏幕按快捷键“u”,显示活动的实用程序，并且跨数据库分区将它们聚集起来按快捷键“l”,转至会话屏幕按快捷键“t”,转至表空间屏幕5、使用db2batch测试SQL语句的性能[myinst@ye ~]$ cat sample.sqlselect * from mydb3.emp;[myinst@ye ~]$ db2batch -d mydb3 -f sample.sql* Timestamp: Mon Aug 24 2015 13:53:24 CST---------------------------------------------* SQL Statement Number 1:select * from mydb3.emp;** CLI error in preparing the SQL statement:(-204): [IBM][CLI Driver][DB2/LINUXX8664] SQL0204N "MYDB3.EMP" is an undefined name. SQLSTATE=42704* Elapsed Time is: 0.000000 seconds* Summary Table:Type Number Repetitions Total Time (s) Min Time (s) Max Time (s) Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output--------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- -------------Statement 1 1 0.000000 0.000000 0.000000 0.000000 0.000000 0 0* Total Entries: 1* Total Time: 0.000000 seconds* Minimum Time: 0.000000 seconds* Maximum Time: 0.000000 seconds* Arithmetic Mean Time: 0.000000 seconds* Geometric Mean Time: 0.000000 seconds---------------------------------------------* Timestamp: Mon Aug 24 2015 13:53:24 CST#获得更多信息[myinst@ye ~]$ db2batch -d mydb3 -f sample.sql -o r 0 p 2* Timestamp: Mon Aug 24 2015 13:54:30 CST---------------------------------------------* SQL Statement Number 1:select * from mydb3.emp;** CLI error in preparing the SQL statement:(-204): [IBM][CLI Driver][DB2/LINUXX8664] SQL0204N "MYDB3.EMP" is an undefined name. SQLSTATE=42704* Elapsed Time is: 0.000000 secondsMonitoring InformationInstance name = myinstNode name =Node type = Enterprise Server Edition with local and remote clientsSnapshot timestamp = 08/24/2015 13:54:30.306349Application SnapshotApplication handle = 229Application status = UOW WaitingStatus change time = 08/24/2015 13:54:30.301560Application code page = 1208Application country/region code = 1DUOW correlation token = *LOCAL.myinst.150824055430 Application name = db2batchApplication ID = *LOCAL.myinst.150824055430Sequence number = 00002TP Monitor client user ID =TP Monitor client workstation name = TP Monitor client application name = DB2BATCHTP Monitor client accounting string =CONNECT Authorization ID = MYINSTClient login ID = myinstConfiguration NNAME of client = Client database manager product ID = SQL10055Process ID of client application = 7007Platform of client application = LINUXAMD64Communication protocol of client = Local ClientDatabase name = MYDB3Database path = /www/db2/db2test/myinst/NODE0000/SQL00001/MEMBER0000/Client database alias = MYDB3Input database alias =The highest authority level granted =Direct DBADM authorityDirect SECADM authorityIndirect SYSADM authorityIndirect CREATETAB authorityIndirect BINDADD authorityIndirect CONNECT authorityIndirect IMPLICIT_SCHEMA authorityCoordinator member number = 0Coordinator agent process or thread ID = 56Agents associated with the application = 1Connection request start timestamp = 08/24/2015 13:54:30.292632Connect request completion timestamp = 08/24/2015 13:54:30.293070Application idle time = 0Inbound communication address = *LOCAL.myinstLast reset timestamp = 08/24/2015 13:54:30.300279Agents stolen = 0Agents waiting on locks = 0Maximum associated agents = 1Priority at which application agents work = 0Priority type = DynamicLocks held by application = 0Lock waits since connect = 0Time application waited on locks (ms) = 0 Deadlocks detected = 0 Lock escalations = 0 Exclusive lock escalations = 0 Number of Lock Timeouts since connected = 0 Total time UOW waited on locks (ms) = 0Total sorts = 0 Total sort time (ms) = 0 Total sort overflows = 0Buffer pool data logical reads = 0 Buffer pool data physical reads = 0 Buffer pool temporary data logical reads = 0 Buffer pool temporary data physical reads = 0 Buffer pool data writes = 0 Buffer pool index logical reads = 1 Buffer pool index physical reads = 0 Buffer pool temporary index logical reads = 0 Buffer pool temporary index physical reads = 0 Buffer pool index writes = 0 Buffer pool xda logical reads = 0 Buffer pool xda physical reads = 0 Buffer pool temporary xda logical reads = 0 Buffer pool temporary xda physical reads = 0 Buffer pool xda writes = 0 Total buffer pool read time (milliseconds) = 0Total buffer pool write time (milliseconds)= 0Time waited for prefetch (ms) = 0 Unread prefetch pages = 0 Direct reads = 0 Direct writes = 0 Direct read requests = 0 Direct write requests = 0 Direct reads elapsed time (ms) = 0 Direct write elapsed time (ms) = 0Number of SQL requests since last commit = 0 Commit statements = 1 Rollback statements = 0 Dynamic SQL statements attempted = 0 Static SQL statements attempted = 1 Failed statement operations = 0 Select SQL statements executed = 0Xquery statements executed = 0Update/Insert/Delete statements executed = 0DDL statements executed = 0Internal automatic rebinds = 0Internal rows deleted = 0Internal rows inserted = 0Internal rows updated = 0Internal commits = 0Internal rollbacks = 0Internal rollbacks due to deadlock = 0Binds/precompiles attempted = 0Rows deleted = 0Rows inserted = 0Rows updated = 0Rows selected = 0Rows read = 0Rows written = 0UOW log space used (Bytes) = 0Previous UOW completion timestamp = 08/24/2015 13:54:30.293070 Elapsed time of last completed uow (sec.ms)= 0.005268UOW start timestamp = 08/24/2015 13:54:30.296285 UOW stop timestamp = 08/24/2015 13:54:30.301553 UOW completion status = Committed - Commit StatementOpen remote cursors = 0Open remote cursors with blocking = 0Rejected Block Remote Cursor requests = 0Accepted Block Remote Cursor requests = 1Open local cursors = 0Open local cursors with blocking = 0Total User CPU Time used by agent (s) = 0.001037Total System CPU Time used by agent (s) = 0.000000Host execution elapsed time = 0.000845Package cache lookups = 1Package cache inserts = 0Application section lookups = 1Application section inserts = 0Catalog cache lookups = 1Catalog cache inserts = 0Catalog cache overflows = 0Catalog cache heap full = 0Catalog cache high water mark = 0Number of hash joins = 0Number of hash loops = 0Number of hash join overflows = 0Number of small hash join overflows = 0Statement type = Static SQL Statement Statement = Static CommitSection number = 0Application creator =Package name =Consistency Token =Cursor name =Statement member number = 0Statement start timestamp = 08/24/2015 13:54:30.301498 Statement stop timestamp = 08/24/2015 13:54:30.301553 Elapsed time of last completed stmt(sec.ms)= 0.000055Total Statement user CPU time = 0.000052Total Statement system CPU time = 0.000000SQL compiler cost estimate in timerons = 0SQL compiler cardinality estimate = 0Degree of parallelism requested = 1Number of agents working on statement = 1Number of subagents created for statement = 1Statement sorts = 0Total sort time = 0Sort overflows = 0Rows read = 0Rows written = 0Internal rows deleted = 0Internal rows updated = 0Internal rows inserted = 0Rows fetched = 0Buffer pool data logical reads = 0Buffer pool data physical reads = 0Buffer pool temporary data logical reads = 0Buffer pool temporary data physical reads = 0Buffer pool index logical reads = 0Buffer pool index physical reads = 0Buffer pool temporary index physical reads = 0Buffer pool xda logical reads = 0Buffer pool xda physical reads = 0Buffer pool temporary xda logical reads = 0Buffer pool temporary xda physical reads = 0Blocking cursor = NOAgent process/thread ID = 56Memory usage for application:Node number = 0Memory Pool Type = Other MemoryCurrent size (bytes) = 196608High water mark (bytes) = 327680Configured size (bytes) = 1868365824* Summary Table:Type Number Repetitions Total Time (s) Min Time (s) Max Time (s) Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output--------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- -------------Statement 1 1 0.000000 0.000000 0.000000 0.000000 0.000000 0 0* Total Entries: 1* Total Time: 0.000000 seconds* Minimum Time: 0.000000 seconds* Maximum Time: 0.000000 seconds* Arithmetic Mean Time: 0.000000 seconds* Geometric Mean Time: 0.000000 seconds---------------------------------------------* Timestamp: Mon Aug 24 2015 13:54:30 CST。
db2监控命令汇总
db2监控命令汇总db2 监控命令汇总1. 查看和更改与锁相关的主要配置参数。
db2 get db cfg在参数列表中寻找DLCHKTIME和LOCKTIMEOUT两个参数。
-DLCHKTIME 单位是毫秒，是DB2检查死锁的间隔时间，假设该值为10000ms，则意味着每隔10秒钟检查一下当前数据库中有无死锁存在，如有死锁，会选择回滚其中的某一个事务，让另外一个事务完成交易。
\-LOCKTIMEOUT单位是秒，是锁等待最长时间，超过该时间仍未获得锁，则返回错误。
2. 查看当前并发应用db2 list applications或db2 list applications show detail或 db2 list applications for database dbname [ show detail]3. 查看和更改快照参数如果在合理设置了DLCHKTIME和LOCKTIMEOUT参数仍然出现锁现象，可以查看快照或者创建事件监控器来分析原因。
要采用快照，首先要打开快照开关db2 get monitor switches输出中将包含以下参数:监控开关数据库管理器参数注释BUFFERPOOL DFT_MON_BUFPOOL 缓冲区的读写情况和发生时间LOCK DFT_MON_LOCK 锁持有，锁等待，以及死锁的发生情况SORT DFT_MON_SORT Heap的使用情况，排序性能STATEMENT DFT_MON_STMT 语句起始时间，语句内容TABLE DFT_MON_TABLE Measure of activity (rows read/written)UOW DFT_MON_UOW Start/end times, completion statusTIMESTAMP DFT_MON_TIMESTAMP Timestamps为了观察快照中的锁和执行语句情况，一般把LOCK和STATEMENT选项设为ON，也可以酌情把其他开关打开，示例如下: db2 update monitor switches using lock on statement on4. 查看快照信息-查看数据库管理器级别快照信息db2 get snapshot for dbm-查看数据库级别快照信息db2 get snapshot for database on dbname-查看应用级别快照信息db2 get snapshot for application agentid appl-handler注:appl-handler可以从list applicaitions的输出中得到-查看表级别快照信息db2 get snapshot for tables on dbname注:需要把tables快照开关设为ON才会有作用-查看锁快照信息db2 get snapshot for locks on dbname 这条命令很有用，可以查看具体有哪些锁。
DB2故障处理的解决办法
解决问题的关键在于分清问题的种类，并清楚每种问题的解决办法。
另外很多的数据库的问题都是由于错误的操作，错误的配置引起的，所以本文在解释怎么样处理问题时也会给出一些好的建议，来避免产生问题。
本文重点介绍实用的方法。
对问题的分类有很多种方法，在本文中我我采用了两种分类方案。
第一种方案是是否有错误码。
即发生错误时是否同时返回了错误码，错误码既包括执行命令的返回码，也包扩应用程序的返回码。
有返回码的错误解决方案是，在db2 CLP中运行db2?SQLXXXX，然后根据对该问题的解释采取相应的解决方案。
对没有错误码的问题，如数据库hang，CPU使用率过高等问题，解决问题的经验将非常重要，在本文中会有详细的说明。
根据错误码解决问题举例（在下文中，再出现需要用这种方法解决问题时将不再重复）：如在连接数据库时发生错误db2 connect to sampleSQL0332N There is no available conversion for the source codepage"1386" tothe 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=1386db2 terminatedb2 connect to sample就可以成功连接了。
DB2数据库故障与性能瓶颈诊断思路
本文主要介绍了db2数据库在遇到故障及性能问题时运用什么方法去快速诊断定位问题，希望本文内容可以为从事db2的网友提供一些指导和参考。
1、在db2数据库主机遇到重大故障时我们可以通过db2support收集数据库诊断日志数据#在可以连接的时候#db2support . -d sample -c -g -s#不能连接的时候#db2support . -c -g -s2、bufferpool设置的太大连接数据库时导致系统宕机的解决方法：操作步骤：#db2set DB2_OVERRIDE_BPF=10000#db2 terminate#db2stop#db2start#db2 connect to db#连上db#db2 alter bufferpool buffer001 numblockpages#原来的块SIZE太大，我们这里禁用它#db2 force applications all#db2 connect to db#db2 alter bufferpool buffername immediate size 50000#将SIZE改小#db2set DB2_OVERRIDE_BPF= #设置为空，还原回去#db2 terminate#db2 force applications all#db2stop#db2start3、如何快速定位问题1）如果系统的CPU利用很高，IO很少，那么数据库的排序较多2）如果系统的IO繁忙，CPU很多是wait，那么说明数据库有过多的IO3）如果系统CPU，IO都很空闲，那么说明可以是有锁的问题4）如果系统IO，CPU都非常忙，说明有执行代价非常高的sql在执行4、快速找到执行成本较高的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语句。
数据库管理系统DB2监控与调优技巧
数据库管理系统DB2监控与调优技巧随着现代企业对数据存储和管理的重要性越来越高，数据库管理系统已经成为了现代企业不可或缺的一部分。
DB2是IBM的一款关系型数据库管理系统，被广泛应用于企业级应用中。
在使用DB2进行数据管理时，我们需要掌握一些监控和调优技巧来保证其高效性和可靠性。
一、DB2监控技巧1. 监视系统资源使用情况在使用DB2进行数据管理时，我们需要关注系统资源的使用情况以及性能瓶颈。
可以使用IBM提供的一些监控工具来监视系统资源的使用情况，例如db2top、db2pd等工具。
通过使用这些工具，我们可以快速了解系统资源使用情况，及时发现性能瓶颈并进行调整。
2. 监视数据库活动除了监视系统资源的使用情况外，我们还需要监视数据库的活动情况。
可以使用db2diag命令查看数据库操作日志，查看数据库的活动情况并及时处理可能存在的问题。
此外，可以使用db2pd命令查看数据库锁定、响应时间等信息，也可根据情况对数据库进行调整和优化。
3. 周期性维护在长时间的数据库运行过程中，可能会产生类似磁盘碎片等问题，导致系统资源使用效率下降。
因此，我们需要定期进行数据库维护工作，例如备份和还原数据库、重建索引、收缩日志等操作，以保证数据库的高效性和可靠性。
二、DB2调优技巧1. 参数调整在使用DB2进行数据管理时，我们需要根据业务需求来调整DB2的参数，以提高数据库的性能。
例如，我们可以调整DB2的缓存大小、线程数、日志文件大小等参数，以达到更好的性能表现。
2. 建立索引索引是数据库管理中非常重要的一部分，可以大大提高数据库的查询效率。
在使用DB2进行数据管理时，我们需要针对数据库中经常查询的列建立索引，以加快查询速度。
此外，我们还需要定期检查并优化索引的性能。
3. 批量提交在进行大量数据处理时，我们可以采用批量提交的方式，以减少数据库服务器的负担。
如果逐条提交数据，会导致数据库频繁切换工作状态，从而影响数据库性能。
数据库性能监控与故障排查方法
数据库性能监控与故障排查方法一、引言数据库在现代软件开发中扮演着重要的角色，它承载着大量的业务数据并提供高效的数据访问。
然而，随着业务的增长和规模的扩大，数据库性能问题和故障不可避免地出现。
本文将介绍数据库性能监控与故障排查的方法，以帮助管理员和开发人员更好地管理数据库系统。
二、数据库性能监控方法1. 监控指标选择数据库性能监控的第一步是选择适当的监控指标。
常见的监控指标包括数据库的连接数、查询响应时间、缓冲区的利用率、磁盘空间利用率等。
通过监控这些指标，可以及时发现数据库性能的异常情况，并采取相应的优化措施。
2. 监控工具选择选择合适的监控工具是保证监控效果的关键。
目前市面上有许多数据库监控工具可供选择，如Zabbix、Nagios等。
这些工具可以通过采集数据库的性能数据，并提供可视化的监控结果和报警功能，帮助管理员及时发现并解决性能问题。
3. 定期巡检除了实时监控，定期巡检也是保证数据库性能的重要手段。
通过定期巡检，可以查看数据库的配置参数是否合理，是否存在潜在的性能隐患。
同时，还可以对数据库的表结构、索引进行优化，提高查询性能。
4. 性能分析和调优数据库性能监控的目的不仅是发现问题，更重要的是对性能问题进行分析和调优。
通过分析数据库的查询计划、索引使用情况等，可以找出性能瓶颈的来源，并尝试改进查询语句、调整数据库参数等方式进行调优，提高数据库的性能。
三、数据库故障排查方法1. 日志分析数据库中的日志记录了系统运行过程中的各种操作和错误信息，是排查故障的重要依据。
通过仔细分析数据库的错误日志和事务日志，可以找出故障产生的原因，并采取相应的措施进行修复。
2. 监控报警监控工具通常会提供报警功能，当数据库出现异常情况时，可以通过邮件、短信等方式进行报警通知。
管理员可以根据报警信息及时发现数据库故障，并采取必要的措施来修复故障。
3. 备份与恢复数据库的备份是防范和应对故障的重要手段。
定期进行数据库的备份，并将备份数据存储在安全的地方，以便在出现故障时进行数据的恢复。
数据库性能监控与故障诊断的最佳实践指南
数据库性能监控与故障诊断的最佳实践指南随着数据量不断增长和应用程序复杂性的提高，数据库的性能监控和故障诊断变得越来越重要。
有效的数据库性能监控可以帮助系统管理员实时跟踪数据库的健康状况，及时发现和解决潜在的性能问题。
而故障诊断则可以帮助管理员快速定位并解决数据库故障，最大限度地减少停机时间。
以下是数据库性能监控和故障诊断的最佳实践指南，希望能帮助管理员更好地管理和保护数据库。
1. 设定合理且全面的监控指标：为了全面了解数据库性能，管理员需要明确哪些指标是需要监控的。
这些指标通常包括数据库连接数、并发事务数、查询响应时间、查询吞吐量等。
管理员可以通过数据库系统的监控工具或自定义脚本来定期收集这些指标，并将这些指标存储在数据库中以供查询和分析。
2. 实时监控数据库性能：及时监控数据库性能对于维护数据库的正常运行至关重要。
管理员可以使用专业的数据库性能监控工具来实时监控数据库的性能。
这些工具可以提供实时的可视化仪表盘，方便管理员随时了解数据库的状态，并根据需要调整相关参数或进行优化。
3. 设置告警机制：数据库告警机制可以帮助管理员快速了解到数据库性能的异常情况。
管理员可以根据业务需求，设置合理的告警阈值，并将告警信息发送至管理员的手机或邮箱。
当数据库出现性能问题时，管理员可以立即采取相应的措施，避免问题进一步扩大。
4. 进行性能分析：数据库性能分析是及时发现性能问题的关键步骤。
管理员可以使用数据库性能分析工具来监测和分析数据库的性能。
这些工具可以帮助管理员找出性能瓶颈，并提供相应的优化建议，帮助管理员提升数据库的性能。
5. 配置恰当的日志：日志是跟踪和诊断数据库故障的重要工具。
管理员需要确保数据库的日志功能正常工作，同时设置合适的日志级别。
定期检查数据库日志可以帮助管理员及时发现潜在的问题，并采取相应的措施进行修复。
6. 建立备份和恢复策略：备份和恢复策略是保护数据库免受数据丢失和故障的重要手段。
管理员应该定期备份数据库，并测试备份的可用性和可靠性。
db2pd命令捕获死锁信息
本文通过一个实例讲解了在DB2版本9以后，如何使用db2pd命令捕获死锁信息死锁经常会存在于我们的应用系统中，如何捕获死锁信息并解决死锁问题，是一个比较复杂的问题。
DB2提供了死锁事件监控器来获取死锁信息，可以非常方便地获取死锁信息。
从DB2版本8.2.2开始，DB2也可以使用db2pd命令和db2cos脚本来获取死锁信息，提供了一种新的途径来获取死锁信息。
从DB2版本9开始，我们可以使用db2pd -catch 命令来捕获错误信息，然后调用一个sqllib/db2cos 的脚本收集出错时的现场信息。
该命令的使用语法如下：Usage:-catch clear | status | <errorCode> [<action>] [count=<count>]Sets catchFlag to catch error or warning.Error Codes:<sqlCode>[,<reasonCode>] / sqlcode=<sqlCode>[,<reasonCode>]ZRC (hex or integer)ECF (hex or integer)"deadlock" or "locktimeout"Actions:[db2cos] (default) Run sqllib/db2cos callout script[lockname=<lockname>] Lockname for catching specific lock(lockname=000200030000001F0000000052)[locktype=<locktype>] Locktype for catching specific lock(locktype=R or locktype=52)下面我们通过一个实例来讲解如何使用db2pd -catch命令获取死锁信息。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
使用 db2pd 进行监视和故障诊断因为 db2pd 工具可从 DB2® 内存集合迅速返回即时信息，所以该工具可用于故障诊断。
该工具不需要获得任何锁存器或使用任何引擎资源就可以收集信息。
因此，在 db2pd 收集信息时，有可能（并且预计）会检索到正在更改的信息；这样，数据可能不是十分准确。
如果遇到正在更改的内存指针，可使用信号处理程序来防止 db2pd 异常终止。
这可能会导致输出中出现诸如以下的消息：“正在更改的数据结构已强制终止命令”。
虽然如此，该工具对于故障诊断却非常有用。
在不锁存的情况下收集信息有两个好处：检索速度更快并且不会争用引擎资源。
如果要在出现特定 SQLCODE、ZRC 代码或 ECF 代码时捕获关于数据库管理系统的信息，那么可以使用 db2pdcfg -catch 命令完成此操作。
捕获到错误时，将启动 db2cos（调出脚本）。
db2cos 文件可以自动改变，以便运行解决问题所需的任何 db2pd 命令、操作系统命令或任何其他命令。
在 UNIX® 和Linux™ 上，模板文件 db2cos 位于 sqllib/bin 中。
在 Windows® 操作系统上，db2cos 位于 $DB2PATH in 目录中。
以下是使用 db2pd 快速故障诊断的一组示例。
场景 1：诊断锁定等待使用 db2pd -db <database name> -locks -transactions -applications -dynamic 命令来获取下列结果：锁定：Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att ReleaseFlg0x07800000202E5238 3 00020002000000040000000052 Row ..X G 3 1 0 0x00000x400000000x07800000202E4668 2 00020002000000040000000052 Row ..X W* 2 1 0 0x00000x40000000对于使用 -db 数据库名称选项指定的数据库，开头的结果会显示该数据库的锁定。
您会发现 TranHdl 2 正在等待 TranHdl 3 挂起的锁定。
事务：Address AppHandl [nod-index] TranHdl Locks StateTflag Tflag2 Firstlsn Lastlsn LogSpace SpaceReserved TID AxRegCnt GXID0x0780000020251B80 11 [000-00011] 2 4 READ 0x00000000 0x000000000x000000000000 0x000000000000 0 0 0x0000000000B7 1 00x0780000020252900 12 [000-00012] 3 4 WRITE 0x00000000 0x000000000x000000FA000C 0x000000FA000C 113 154 0x0000000000B8 1 0您会发现 TranHdl 2 与 AppHandl 11 相关联，而 TranHdl 3 与 AppHandl 12 相关联。
应用程序：Address AppHandl [nod-index] NumAgents CoorPid Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid0x07800000006879E0 12 [000-00012] 1 1073336 UOW-Waiting 0 0 17 1 *LOCAL.burford.0603032256020x0780000000685E80 11 [000-00011] 1 1040570 UOW-Executing17 1 94 1 *LOCAL.burford.060303225601您会发现 AppHandl 12 最后运行动态语句 17, 1。
ApplHandl 11 是当前正在运行的动态语句17, 1，而最后运行的语句是 94, 1。
动态 SQL 语句：Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text0x07800000209FD800 17 1 1 1 2 2 update pdtest set c1 = 50x07800000209FCCC0 94 1 1 1 2 2 set lock mode to wait 1您会发现，文本列显示与锁定超时相关联的 SQL 语句。
场景 2：使用 -wlocks 选项捕获所有正在等待的锁定在下面的样本输出中，应用程序 1（AppHandl 47）正在执行插入操作，而应用程序 2（AppHandl 46）正在选择该表。
venus@boson:/home/venus =>db2pd -wlocks -db pdtest数据库分区 0 -- 数据库 PDTEST -- 活动 -- 正常运行 0 天 00:01:22正在等待的锁定：AppHandl [nod-index] TranHdl Lockname Type Mode Conv Sts CoorEDU AppName AuthID AppID47 [000-00047] 8 00020004000000000840000652Row ..X G 5160 db2bp VENUS *LOCAL.venus.0712********46 [000-00046] 2 00020004000000000840000652Row .NS W 5913 db2bp VENUS *LOCAL.venus.0712********场景 3：使用 -apinfo 选项捕获关于锁定所有者和锁定等待者的详细运行时信息下面的样本输出是在与上面的场景 2 相同的条件下捕获的。
venus@boson:/home/venus =>db2pd -apinfo 47 -db pdtest数据库分区 0 -- 数据库 PDTEST -- 活动 -- 正常运行 0 天 00:01:30应用程序：地址： 0x0780000001676480AppHandl [nod-index]： 47 [000-00047]应用程序 PID ： 876558应用程序节点名： bosonIP 地址：不适用连接开始时间： (1197063450)Fri Dec 7 16:37:30 2007客户机用户标识： venus系统授权标识： VENUS协调程序 EDU 标识： 5160协调程序分区： 0代理程序数： 1锁定超时值： 4294967294 秒锁定升级：否工作负载标识： 1工作负载出现标识： 2可信上下文：不适用连接信任类型：不可信继承的角色：不适用应用程序状态： UOW 正在等待应用程序名称： db2bp应用程序标识： *LOCAL.venus.0712********当前 UOW 的不活动语句列表：UOW 标识： 2活动标识： 1程序包模式： NULLID程序包名称： SQLC2G13程序包版本：节号： 203SQL 类型：动态隔离： CS语句类型： DML 以及 Insert/Update/Delete语句： insert into pdtest values 99venus@boson:/home/venus =>db2pd -apinfo 46 -db pdtest数据库分区 0 -- 数据库 PDTEST -- 活动 -- 正常运行 0 天 00:01:39应用程序：地址： 0x0780000000D77A60AppHandl [nod-index]： 46 [000-00046]应用程序 PID： 881102应用程序节点名： bosonIP 地址：不适用连接开始时间： (1197063418)Fri Dec 7 16:36:58 2007客户机用户标识： venus系统授权标识： VENUS协调程序 EDU 标识： 5913协调程序分区： 0代理程序数： 1锁定超时值： 4294967294 秒锁定升级：否工作负载标识： 1工作负载出现标识： 1可信上下文：不适用连接信任类型：不可信继承的角色：不适用应用程序状态：锁定等待应用程序名称： db2bp应用程序标识： *LOCAL.venus.0712********活动语句列表：*UOW 标识： 3活动标识： 1程序包模式： NULLID程序包名称： SQLC2G13程序包版本：节号： 201SQL 类型：动态隔离： CS语句类型： DML 和 Select（可阻塞）语句： select * from pdtest场景 4：在考虑锁定问题时使用调出脚本查找 db2cos 输出文件。
该文件的位置由数据库管理器配置参数 DIAGPATH 控制。
输出文件的内容将随您在 db2cos 文件中输入的命令不同而不同。
当 db2cos 文件包含 db2pd -db sample -locks 命令时，提供的输出示例如下所示：捕获到锁定超时Thu Feb 17 01:40:04 EST 2006实例 DB2 数据库：SAMPLE分区号：0PID：940TID：2136函数：sqlplnfd组件：锁管理器探测点：999时间戳记：2006-02-17-01.40.04.106000AppID：*LOCAL.DB2...AppHdl：...数据库分区 0 -- 数据库 SAMPLE -- 活动 -- 正常运行 0 天 00:06:53锁定：Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att Rlse0x402C6B30 3 00020003000000040000000052 Row ..X W* 3 1 0 0 0x40仅查找“W*”，因为这是经历超时的锁定。
当锁定转换为更高级的方式时，也会发生锁定超时。
在这种情况下，您只会在输出中见到“C*”，而不会见到“W*”。
但是，在此特定情况下发生了锁定等待。
可使用db2cos 文件中的其他db2pd 命令提供的输出将结果映射至事务、应用程序、代理程序甚至是 SQL 语句。
可以缩小输出范围或使用其他命令来收集需要的信息。
例如，可以更改 db2pd 命令选项以使用 -locks wait 选项，后一个选项仅打印具有等待状态的锁定。
如果需要 -app 和 -agent 选项，也可以输入它们。