下载文档原格式
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命令获取死锁信息。
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命令）来对当前数据库分区中的所有进程生成堆栈跟踪。
