下载文档原格式
db2解决死锁的方法DB2是一种常见的关系型数据库管理系统，它被广泛应用于企业级应用程序中。
然而，随着应用程序的复杂性增加和并发访问的增加，死锁问题也变得越来越常见。
在本文中，我们将探讨一些使用DB2解决死锁问题的方法。
1. 死锁的定义和原因死锁是指两个或多个事务彼此等待对方持有的资源，从而导致所有事务无法继续执行的状态。
死锁通常发生在并发访问数据库时，其中一个事务正在使用某个资源，而另一个事务需要访问相同的资源。
死锁的发生原因可以归结为四个条件：互斥（资源只能被一个事务使用）、持有并等待（一个事务持有资源并等待另一个事务的资源）、不可剥夺（资源不能被其他事务抢占）、循环等待（多个事务形成循环等待资源）。
2. 使用锁机制避免死锁在DB2中，可以使用锁机制来避免死锁的发生。
锁是一种机制，用于协调并发事务对共享资源的访问。
DB2提供了两种类型的锁：共享锁和排他锁。
共享锁允许多个事务同时读取资源，但不允许写入资源；排他锁只允许一个事务同时读取或写入资源。
为了避免死锁，可以采取以下策略：- 在事务开始时，尽量将锁的范围缩小到最小，只锁定必要的资源。
- 在事务执行期间，尽量减少锁的持有时间，执行完操作后尽快释放锁。
- 避免循环等待，即事务在请求资源时按照统一的顺序进行，避免形成死锁的循环等待。
3. 设置适当的隔离级别DB2提供了多种隔离级别，用于控制事务之间的相互影响。
不同的隔离级别对并发访问的控制程度不同。
在选择隔离级别时，需要权衡事务的一致性和性能。
在避免死锁的角度考虑，可以选择较低的隔离级别，如读取已提交（Read Committed）。
较低的隔离级别可以减少锁的竞争，从而降低死锁的风险。
但同时，较低的隔离级别也可能导致数据不一致的问题，需要根据具体业务需求进行权衡。
4. 监控和诊断死锁DB2提供了一些工具和功能，用于监控和诊断死锁问题。
可以通过以下方式来实现：- 使用DB2的系统监控工具，如db2pd命令和db2top工具，可以实时查看数据库的锁和死锁情况。
解决问题的关键在于分清问题的种类，并清楚每种问题的解决办法。
另外很多的数据库的问题都是由于错误的操作，错误的配置引起的，所以本文在解释怎么样处理问题时也会给出一些好的建议，来避免产生问题。
本文重点介绍实用的方法。
对问题的分类有很多种方法，在本文中我我采用了两种分类方案。
第一种方案是是否有错误码。
即发生错误时是否同时返回了错误码，错误码既包括执行命令的返回码，也包扩应用程序的返回码。
有返回码的错误解决方案是，在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就可以成功连接了。
developerWorks 中国 > Information Management >DB2 最佳实践: 性能调优和问题诊断最佳实践，第 2 部分有条不紊地进行性能调优和故障诊断级别：初级developerWorks 中国网站编辑团队, 编辑, IBM2009 年 3 月 12 日本系列介绍了 DB2 系统性能的最优方法，分两部分。
第 1 部分首先介绍为了达到良好性能，我们如何从软硬件配置方面来保障，紧接着讨论了在多种在操作和故障诊断的情况下，有助于我们了解系统性能的监控方法。
第 2 部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。
概述就算是配置最仔细的系统也终究会发现它仍然需要一定的性能调优，并且这时我们已经搜集了的运行监控数据，将来非常便于搜集。
保持一种系统的方法来调优和进行故障诊断对我们非常重要。
当发生了一个问题，为了解决这个问题，很容易随意的进行调整。
然而，当我们这么做了，事实上定位到问题的可能性非常低，甚至让问题更糟糕。
性能调优的一些基本原则：1.有备而来，去了解系统一切正常的情况下性能怎么样。
搜集运行监视信息来跟踪一段时间内系统行为的变化。
2.了解整个场景，不要局限于你从 DB2 上看到的 – 也要搜集并分析来自于操作系统、存储、应用程序甚至来自用户的数据。
了解系统本身将有助于你解释监控数据。
3.只调整能解释你看到的症状的参数，如果连发动机都无法启动就不要更换轮胎。
不要试图通过降低 CPU 来解决磁盘的瓶颈。
4.一次只改一个参数，在更改其它参数之前先观察效果。
你可能遇到的问题类型性能问题往往分为两大类：影响了整个系统的问题和只影响了部分系统的问题。
比如某一特定应用或 SQL 语句，在研究的过程中－种类型的问题可能转化为另外一种类型的问题，或者相反。
例如造成整个系统性能降低可能是一个单独的语句，或者是整个系统的问题只是在一个特定的区域被发现。
下面我们从整个系统的问题开始。
本文通过一个实例讲解了在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命令获取死锁信息。
数据库性能监控与故障诊断工具的性能评估随着互联网时代的到来，数据库在各行各业中扮演着重要的角色。
而对于数据库来说，性能是至关重要的因素之一。
为了确保数据库的高效运行，我们需要使用性能监控与故障诊断工具来进行性能评估。
本文将介绍数据库性能监控与故障诊断工具，并对几种常见的工具进行性能评估。
一、数据库性能监控工具的作用和原理数据库性能监控工具是用于监控数据库实例的性能指标和资源使用情况，并及时报警以提醒管理员发现和解决性能问题的工具。
它通过收集数据库服务器的性能指标、查询统计数据以及SQL执行的计划等信息，帮助管理员追踪和分析数据库的性能瓶颈，提供系统优化的依据。
数据库性能监控工具的原理基本上是通过在数据库服务器上运行一个守护进程，该进程周期性地采集数据库的性能数据，经过归纳和汇总后保存到监控数据库中。
监控数据库中的数据可以通过前端可视化界面展示给管理员，提供各种查询、报表、告警等功能。
二、几种常见的数据库性能监控工具1.Oracle Enterprise Manager: 是Oracle Database自带的监控工具，有完善的图形化界面。
能够监控数据库的性能指标、查询分析、诊断问题、自动化管理等。
2.Prometheus: 是一个开源的监控系统，被广泛应用于实时监控与告警。
对于数据库性能监控，可以使用Prometheus的Client Libraries收集数据库的性能数据并发送到Prometheus Server，再通过Grafana等可视化工具展示。
3.Nagios: 是一个开源的IT基础架构监控工具，可以监控网络设备、服务器、应用程序等。
通过配置插件，可以对数据库进行性能监控，并定制化报警。
三、数据库性能监控工具的性能评估指标数据库性能监控工具的性能评估通常包括以下几个方面的指标：1.实时性：能否及时收集数据库的性能数据并对其进行处理和展示。
实时监控可以使管理员了解数据库的当前状况，及时发现和解决潜在的性能问题。
本文通过一个实例讲解了在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命令获取死锁信息。
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 工具可从 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 数据库名称选项指定的数据库，开头的结果会显示该数据库的锁定。
db2pd 分析锁等待简介：当多个 DB2® 用户并发地访问一个数据库时，锁等待会导致响应变慢。
锁等待是临时性的，因而难以捕捉。
然而，当出现锁等待情形时，需要由数据库管理员负责确定锁等待的原因。
本文通过例子演示如何使用用于 DB2 for Linux®, UNIX®, and Windows® 的db2pd和db2pdcfg实用程序完成该任务。
用于锁监视的db2pd选项db2pd是用于监视各种 DB2 数据库活动以及故障排除的实用程序。
它是从 DB2 V8.2 开始随DB2 引擎发布的一个独立的实用程序，其外观和功能类似于 Informix onstat实用程序。
db2pd是从命令行以一种可选的交互模式执行的。
该实用程序运行得非常快，因为它不需要获取任何锁，并且在引擎资源以外运行（这意味着它甚至能在一个挂起的引擎上工作）。
通过快照监视还可以收集db2pd提供的很多监视器数据，但是db2pd和快照监视的输出格式却有很大不同。
这使 DBA 可以选择更符合用户需求的监视替代方法。
本文关注用于锁监视的db2pd选项。
有一篇由 Sam Poon 撰写的 developerWorks 文章（参见参考资料小节）对db2pd的监视功能作了更广泛的介绍。
下面的图展示了用于锁监视的db2pd选项：图 1. 用于锁监视的db2pd选项∙TranHdl：用于指定事务句柄，以便只监视由特定事务持有的锁。
∙showlocks：这个子选项将锁名称扩展成有意义的解释。
对于一个行锁，该选项显示以下信息：表空间 ID、表 ID、分区 ID、页和槽。
通过使用编目视图SYSCAT.TABLES上的一个查询，很容易将表空间 ID 和表 ID 映射到相应的表名：清单 1. 将表空间 ID、表 ID 映射到表模式、表名SELECT TABSCHEMA, TABNAMEFROM SYSCAT.TABLESWHERE TBSPACEID = tbspaceid AND TABLEID = tableid∙∙wait：如果指定wait子选项，则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 工具监控您的数据库环境。
题目：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的网友提供一些指导和参考。
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 使用db2pd 进行监视和故障诊断因为db2pd工具可从DB2® 内存集合迅速返回即时信息，所以该工具可用于故障诊断。
该工具不需要获得任何锁存器或使用任何引擎资源就可以收集信息。
因此，在db2pd收集信息时，有可能（并且预计）会检索到正在更改的信息；这样，数据可能不是十分准确。
如果遇到正在更改的内存指针，可使用信号处理程序来防止db2pd异常终止。
这可能会导致输出中出现诸如以下的消息：“正在更改的数据结构已强制终止命令”。
虽然如此，该工具对于故障诊断却非常有用。
在不锁存的情况下收集信息有两个好处：检索速度更快并且不会争用引擎资源。
如果要在出现特定SQLCODE、ZRC 代码或ECF 代码时捕获关于数据库管理系统的信息，那么可以使用db2pdcfg -catch命令完成此操作。
捕获到错误时，将启动db2cos（调出脚本）。
db2cos文件可以自动改变，以便运行解决问题所需的任何db2pd命令、操作系统命令或任何其他命令。
在UNIX® 和Linux® 上，模板文件db2cos位于sqllib/bin中。
在Windows® 操作系统上，db2cos位于$DB2PATH\bin目录中。
以下是使用db2pd快速故障诊断的一组示例。
场景1：诊断锁定等待使用db2pd -db <database name> -locks -transactions -applications -dynamic 命令来获取下列结果：对于使用 -db 数据库名称选项指定的数据库，开头的结果会显示该数据库的锁定。
您会发现TranHdl 2 正在等待TranHdl 3 挂起的锁定。
您会发现TranHdl 2 与AppHandl 11 相关联，而TranHdl 3 与AppHandl 12 相关联。
您会发现AppHandl 12 最后运行动态语句17, 1。
ApplHandl 11 是当前正在运行的动态语句17, 1，而最后运行的语句是94, 1。
您会发现，文本列显示与锁定超时相关联的SQL 语句。
场景2：使用-wlocks选项捕获所有正在等待的锁定在下面的样本输出中，应用程序1（AppHandl 47）正在执行插入操作，而应用程序2（AppHandl 46）正在选择该表。
场景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********ClientUserID： n/aClientWrkstnName： n/aClientApplName： n/aClientAccntng： n/a当前 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********ClientUserID： n/aClientWrkstnName： n/aClientApplName： n/aClientAccntng： n/a活动语句列表：*UOW 标识： 3活动标识： 1程序包模式： NULLID程序包名称： SQLC2G13程序包版本：节号： 201SQL 类型：动态隔离： CS语句类型： DML 和 Select（可阻塞）语句： select * from pdtest场景4：在考虑锁定问题时使用调出脚本查找db2cos输出文件。
该文件的位置由数据库管理器配置参数DIAGPATH 控制。
输出文件的内容将随您在db2cos文件中输入的命令不同而不同。
当db2cos文件包含db2pd -db sample -locks命令时，提供的输出示例如下所示：仅查找“W*”，因为这是经历超时的锁定。
当锁定转换为更高级的方式时，也会发生锁定超时。
在这种情况下，您只会在输出中见到“C*”，而不会见到“W*”。
但是，在此特定情况下发生了锁定等待。
可使用db2cos文件中的其他db2pd命令提供的输出将结果映射至事务、应用程序、代理程序甚至是SQL 语句。
可以缩小输出范围或使用其他命令来收集需要的信息。
例如，可以更改db2pd命令选项以使用-locks wait选项，后一个选项仅打印具有等待状态的锁定。
如果需要-app和-agent选项，也可以输入它们。
场景5：将应用程序映射至动态SQL 语句db2pd -applications命令报告动态SQL 语句的当前和最后一个锚点标识和语句唯一标识。
这允许直接从应用程序映射至动态SQL 语句。
场景6：监视内存使用情况。
尝试了解内存使用情况时，db2pd -memblock命令非常有用。
例如：接下来是已排序的“性能池”输出：最后一部分输出对整个DBMS 集的内存使用者进行排序：在UNIX 和Linux 上，还可以报告专用内存的内存块。
例如：场景7：确定哪个应用程序用完了表空间通过使用db2pd -tcbstats，可以标识对一个表执行插入操作的次数。
以下是用户定义的全局临时表TEMP1 的样本信息：然后，可以通过db2pd -tablespaces命令获取表空间3 的信息。
样本输出如下所示：您会注意到通过引用FreePgs 列填满的空间。
因为可用页数值下降，所以可用空间减少。
还应注意，FreePgs 加上UsedPgs 的值将等于UsablePgs 的值。
一旦了解这一点，就可以标识使用表TEMP1 的动态SQL 语句：最后，可以将它映射至db2pd -app输出以标识应用程序。
针对先前使用的db2pd中的动态SQL 语句的请求产生的锚点标识（AnchID）将与针对关联应用程序的请求一起使用。
应用程序结果显示最后一个锚点标识（L-AnchID）值与该锚点标识（AnchID）相同。
一次运行db2pd产生的结果将在下一次运行db2pd时使用。
db2pd -agent的输出将显示应用程序读取的行数（Rowsread 列）和写入的行数（Rowswrtn 列）。
这些值将显示应用程序已完成的部分及尚未完成的部分。
db2pd -agent请求中的AppHandl 和AgentPid 的值可映射回db2pd -app请求中的AppHandl 和CoorPiid 的对应值。
如果您怀疑内部临时表占满了表空间，那么这些步骤会稍有不同。
仍然可以使用db2pd-tcbstats来标识具有最大插入数目的表。
以下是隐式临时表的样本信息：在此示例中，使用命名约定“TEMP (TbspaceID, TableID)”的表中有大量插入。
这些是隐式临时表。
SchemaNm 列中的值的命名约定为AppHandl 的值与SchemaNm 的值并置，这使得它能够标识正在工作的应用程序。
然后，可以将这些信息映射至db2pd -tablespaces产生的输出，以查看表空间 1 的已使用空间。
在表空间统计信息中记下已使用的页数与可用页数之间的关系。
然后，可以使用命令db2pd -app标识应用程序句柄30 和31（因为它们出现在-tcbstats输出中）：最后，使用db2pd -dyn命令将它映射至动态SQL：场景8：监视恢复命令db2pd -recovery显示了几个可用于验证是否正在进行恢复的计数器。
当前日志和当前LSN 提供了日志位置。
已完成的工作计算目前已完成的字节数。
场景9：确定事务正在使用的资源量命令db2pd -transactions提供了锁定数、第一个日志序号（LSN）、最后一个LSN、已使用的日志空间和保留空间。
这对于了解事务行为很有用。
场景10：监视日志使用情况命令db2pd -logs对于监视数据库的日志使用情况很有用。
通过观察已写入的页面输出，可以确定是否正在使用日志。
使用此输出可以确定两个问题：1.如果归档存在问题，那么“归档状态”将设置为值“失败”，表示最近的日志归档失败。
或者，如果正在发生的归档失败导致根本无法归档日志，那么将设置“首次失败”。
2.如果日志归档速度非常慢，那么“下一个要归档的日志”值将小于“当前日志编号”值。
这可能导致填满日志路径，从而在完全填满日志路径时防止数据库中出现任何数据更改。
场景11：查看综合系统（Sysplex）列表如果不使用db2pd -sysplex命令，那么报告综合系统（sysplex）列表的唯一方法是通过DB2 跟踪。
场景12：生成堆栈跟踪可对Windows 操作系统使用db2pd -stack all命令（对UNIX 操作系统使用时为-stack命令）来对当前数据库分区中的所有进程生成堆栈跟踪。
