因为 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 命令来获取下列结果：
锁定： Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att ReleaseFlg 0x07800000202E5238 3 00020002000000040000000052 Row ..X G 3 1 0 0x0000 0x40000000 0x07800000202E4668 2 00020002000000040000000052 Row ..X W* 2 1 0 0x0000 0x40000000
对于使用 -db 数据库名称选项指定的数据库，开头的结果会显示该数据库的锁定。您会发现 TranHdl 2 正在等待 TranHdl 3 挂起的锁定。
您会发现 TranHdl 2 与 AppHandl 11 相关联，而 TranHdl 3 与 AppHandl 12 相关联。
应用程序： Address AppHandl [nod-index] NumAgents CoorPid Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid 0x07800000006879E0 12 [000-00012] 1 1073336 UOW-Waiting 0 0 17 1 *LOCAL.burford.060303225602 0x0780000000685E80 11 [000-00011] 1 1040570 UOW-Executing 17 1 94 1 *LOCAL.burford.060303225601
您会发现 AppHandl 12 最后运行动态语句 17, 1。ApplHandl 11 是当前正在运行的动态语句 17, 1，而最后运行的语句是 94, 1。
动态 SQL 语句： Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text 0x07800000209FD800 17 1 1 1 2 2 update pdtest set c1 = 5 0x07800000209FCCC0 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 AppID 47 [000-00047] 8 00020004000000000840000652 Row ..X G 5160 db2bp VENUS *LOCAL.venus.071207213730 46 [000-00046] 2 00020004000000000840000652 Row .NS W 5913 db2bp VENUS *LOCAL.venus.071207213658
场景 3：使用 -apinfo 选项捕获关于锁定所有者和锁定等待者的详细运行时信息
下面的样本输出是在与上面的场景 2 相同的条件下捕获的。
venus@boson:/home/venus =>db2pd -apinfo 47 -db pdtest
数据库分区 0 -- 数据库 PDTEST -- 活动 -- 正常运行 0 天 00:01:30
应用程序：
地址： 0x0780000001676480
AppHandl [nod-index]： 47 [000-00047]
应用程序 PID ： 876558
应用程序节点名： boson
IP 地址： 不适用
连接开始时间： (1197063450)Fri Dec 7 16:37:30 2007
客户机用户标识： venus
系统授权标识： VENUS
协调程序 EDU 标识： 5160
协调程序分区： 0
代理程序数： 1
锁定超时值： 4294967294 秒
锁定升级： 否
工作负载标识： 1
工作负载出现标识： 2
可信上下文： 不适用
连接信任类型： 不可信
继承的角色： 不适用
应用程序状态： UOW 正在等待
应用程序名称： db2bp
应用程序标识： *LOCAL.venus.071207213730
ClientUserID： n/a
ClientWrkstnName： n/a
ClientApplName： n/a
ClientAccntng： n/a
当前 UOW 的不活动语句列表：
UOW 标识： 2
活动标识： 1
程序包模式： NULLID
程序包名称： SQLC2G13
程序包版本：
节号： 203
SQL 类型： 动态
隔离： CS
语句类型： DML 以及 Insert/Update/Delete
语句： insert into pdtest values 99
venus@boson:/home/venus =>db2pd -apinfo 46 -db pdtest
数据库分区 0 -- 数据库 PDTEST -- 活动 -- 正常运行 0 天 00:01:39
应用程序：
地址： 0x0780000000D77A60
AppHandl [nod-index]： 46 [000-00046]
应用程序 PID： 881102
应用程序节点名： boson
IP 地址： 不适用
连接开始时间： (1197063418)Fri Dec 7 16:36:58 2007
客户机用户标识： venus
系统授权标识： VENUS
协调程序 EDU 标识： 5913
协调程序分区： 0
代理程序数： 1
锁定超时值： 4294967294 秒
锁定升级： 否
工作负载标识： 1
工作负载出现标识： 1
可信上下文： 不适用
连接信任类型： 不可信
继承的角色： 不适用
应用程序状态： 锁定等待
应用程序名称： db2bp
应用程序标识： *LOCAL.venus.071207213658
ClientUserID： n/a
ClientWrkstnName： n/a
ClientApplName： n/a
ClientAccntng： n/a
活动语句列表：
*UOW 标识： 3
活动标识： 1
程序包模式： NULLID
程序包名称： SQLC2G13
程序包版本：
节号： 201
SQL 类型： 动态
隔离： 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 分区号：0 PID：940 TID：2136 函数：sqlplnfd 组件：锁管理器 探测点：999 时间戳记：2006-02-17-01.40.04.106000 AppID：*LOCAL.DB2... AppHdl： ... 数据库分区 0 -- 数据库 SAMPLE -- 活动 -- 正常运行 0 天 00:06:53 锁定： Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att Rlse 0x402C6B30 3 00020003000000040000000052 Row ..X W* 3 1 0 0 0x40
仅查找“W*”，因为这是经历超时的锁定。当锁定转换为更高级的方式时，也会发生锁定超时。在这种情况下，您只会在输出中见到“C*”，而不会见到“W*”。但是，在此特定情况下发生了锁定等待。可使用 db2cos 文件中的其他 db2pd 命令提供的输出将结果映射至事务、应用程序、代理程序甚至是 SQL 语句。可以缩小输出范围或使用其他命令来收集需要的信息。例如，可以更改 db2pd 命令选项以使用 -locks wait 选项，后一个选项仅打印具有等待状态的锁定。如果需要 -app 和 -agent 选项，也可以输入它们。
场景 5：将应用程序映射至动态 SQL 语句
db2pd -applications 命令报告动态 SQL 语句的当前和最后一个锚点标识和语句唯一标识。这允许直接从应用程序映射至动态 SQL 语句。
db2pd -app -dyn 应用程序： Address AppHandl [nod-index] NumAgents CoorPid Status 0x00000002006D2120 780 [000-00780] 1 10615 UOW-Executing C-AnchID C-StmtUID L-AnchID L-StmtUID Appid 163 1 110 1 *LOCAL.burford.050202200412 动态 SQL 语句： Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text 0x0000000220A02760 163 1 2 2 2 1 CREATE VIEW MYVIEW 0x0000000220A0B460 110 1 2 2 2 1 CREATE VIEW YOURVIEW
场景 6：监视内存使用情况。
尝试了解内存使用情况时，db2pd -memblock 命令非常有用。例如：
DBMS 集中的所有内存块。 地址 池标识 池名称 块存活时间 大小（字节） I LOC 文件 0x0780000000740068 62 resynch 2 112 1 1746 1583816485 0x0780000000725688 62 resynch 1 108864 1 127 1599127346 0x07800000001F4348 57 ostrack 6 5160048 1 3047 698130716 0x07800000001B5608 57 ostrack 5 240048 1 3034 698130716 0x07800000001A0068 57 ostrack 1 80 1 2970 698130716 0x07800000001A00E8 57 ostrack 2 240 1 2983 698130716 0x07800000001A0208 57 ostrack 3 80 1 2999 698130716 0x07800000001A0288 57 ostrack 4 80 1 3009 698130716 0x0780000000700068 70 apmh 1 360 1 1024 3878879032 0x07800000007001E8 70 apmh 2 48 1 914 1937674139 0x0780000000700248 70 apmh 3 32 1 1000 1937674139 ...
接下来是已排序的“性能池”输出：
按 ostrack 池的大小排序的内存块： 池标识 池名称 总大小（字节） 总计数 LOC 文件 57 ostrack 5160048 1 3047 698130716 57 ostrack 240048 1 3034 698130716 57 ostrack 240 1 2983 698130716 57 ostrack 80 1 2999 698130716 57 ostrack 80 1 2970 698130716 57 ostrack 80 1 3009 698130716 ostrack 池的总大小：5400576 字节 按 apmh 池的大小排序的内存块： 池标识 池名称 总大小（字节） 总计数 LOC 文件 70 apmh 40200 2 121 2986298236 70 apmh 10016 1 308 1586829889 70 apmh 6096 2 4014 1312473490 70 apmh 2516 1 294 1586829889 70 apmh 496 1 2192 1953793439 70 apmh 360 1 1024 3878879032 70 apmh 176 1 1608 1953793439 70 apmh 152 1 2623 1583816485 70 apmh 48 1 914 1937674139 70 apmh 32 1 1000 1937674139 apmh 池的总大小：60092 字节 ...
最后一部分输出对整个 DBMS 集的内存使用者进行排序：
DBMS 内存集中的所有内存使用者： 池标识 池名称 总大小（字节） 字节 % 总计数 计数 % LOC 文件 57 ostrack 5160048 71.90 1 0.07 3047 698130716 50 sqlch 778496 10.85 1 0.07 202 2576467555 50 sqlch 271784 3.79 1 0.07 260 2576467555 57 ostrack 240048 3.34 1 0.07 3034 698130716 50 sqlch 144464 2.01 1 0.07 217 2576467555 62 resynch 108864 1.52 1 0.07 127 1599127346 72 eduah 108048 1.51 1 0.07 174 4210081592 69 krcbh 73640 1.03 5 0.36 547 4210081592 50 sqlch 43752 0.61 1 0.07 274 2576467555 70 apmh 40200 0.56 2 0.14 121 2986298236 69 krcbh 32992 0.46 1 0.07 838 698130716 50 sqlch 31000 0.43 31 2.20 633 3966224537 50 sqlch 25456 0.35 31 2.20 930 3966224537 52 kerh 15376 0.21 1 0.07 157 1193352763 50 sqlch 14697 0.20 1 0.07 345 2576467555 ...
在 UNIX 和 Linux 上，还可以报告专用内存的内存块。例如：
db2pd -memb pid=159770 专用内存集中的所有内存块。 地址 池标识 池名称 块存活时间 大小（字节） I LOC 文件 0x0000000110469068 88 private 1 2488 1 172 4283993058 0x0000000110469A48 88 private 2 1608 1 172 4283993058 0x000000011046A0A8 88 private 3 4928 1 172 4283993058 0x000000011046B408 88 private 4 7336 1 172 4283993058 0x000000011046D0C8 88 private 5 32 1 172 4283993058 0x000000011046D108 88 private 6 6728 1 172 4283993058 0x000000011046EB68 88 private 7 168 1 172 4283993058 0x000000011046EC28 88 private 8 24 1 172 4283993058 0x000000011046EC68 88 private 9 408 1 172 4283993058 0x000000011046EE28 88 private 10 1072 1 172 4283993058 0x000000011046F288 88 private 11 3464 1 172 4283993058 0x0000000110470028 88 private 12 80 1 172 4283993058 0x00000001104700A8 88 private 13 480 1 1534 862348285 0x00000001104702A8 88 private 14 480 1 1939 862348285 0x0000000110499FA8 88 private 80 65551 1 1779 4231792244 内存集总大小：94847 字节 按大小排序的内存块： 池标识 池名称 总大小（字节） 总计数 LOC 文件 88 private 65551 1 1779 4231792244 88 private 28336 12 172 4283993058 88 private 480 1 1939 862348285 88 private 480 1 1534 862348285 内存集总大小：94847 字节
场景 7：确定哪个应用程序用完了表空间
通过使用 db2pd -tcbstats，可以标识对一个表执行插入操作的次数。以下是用户定义的全局临时表 TEMP1 的样本信息：
TCB 表信息： Address TbspaceID TableID PartID MasterTbs MasterTab TableName SchemaNm ObjClass DataSize LfSize LobSize XMLSize 0x0780000020B62AB0 3 2 n/a 3 2 TEMP1 SESSION Temp 966 0 0 0 TCB 表状态： Address TableName Scans UDI PgReorgs NoChgUpdts Reads FscrUpdates Inserts Updates Deletes OvFlReads OvFlCrtes 0x0780000020B62AB0 TEMP1 0 0 0 0 0 0 43968 0 0 0 0
然后，可以通过 db2pd -tablespaces 命令获取表空间 3 的信息。样本输出如下所示：
表空间 3 配置： Address Type Content PageSz ExtentSz Auto Prefetch BufID BufIDDisk FSC NumCntrs MaxStripe LastConsecPg Name 0x0780000020B1B5A0 DMS UsrTmp 4096 32 Yes 32 1 1 On 1 0 31 TEMPSPACE2 表空间 3 统计信息： Address TotalPgs UsablePgs UsedPgs PndFreePgs FreePgs HWM State MinRecTime NQuiescers 0x0780000020B1B5A0 5000 4960 1088 0 3872 1088 0x00000000 0 0 表空间 3 自动调整大小统计信息： Address AS AR InitSize IncSize IIP MaxSize LastResize LRF 0x0780000020B1B5A0 No No 0 0 No 0 None No 容器： Address ContainNum Type TotalPgs UseablePgs StripeSet Container 0x0780000020B1DCC0 0 File 5000 4960 0 /home/db2inst1/tempspace2a
您会注意到通过引用 FreePgs 列填满的空间。因为可用页数值下降，所以可用空间减少。还应注意，FreePgs 加上 UsedPgs 的值将等于 UsablePgs 的值。
一旦了解这一点，就可以标识使用表 TEMP1 的动态 SQL 语句：
db2pd -db sample -dyn
数据库分区 0 -- 数据库 SAMPLE -- 活动 -- 正常运行 0 天 00:13:06
动态高速缓存：
当前使用的内存 1022197
堆总大小 1271398
高速缓存溢出标志 0
引用数 237
语句插入数目 32
语句删除数目 13
变动插入数目 21
语句数目 19
动态 SQL 语句：
Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text
0x0000000220A08C40 78 1 2 2 3 2 declare global temporary table temp1 (c1 char(6)) not logged
0x0000000220A8D960 253 1 1 1 24 24 insert into session.temp1 values('TEST')
最后，可以将它映射至 db2pd -app 输出以标识应用程序。
应用程序： Address AppHandl [nod-index] NumAgents CoorPid Status 0x0000000200661840 501 [000-00501] 1 11246 UOW-Waiting C-AnchID C-StmtUID L-AnchID L-StmtUID Appid 0 0 253 1 *LOCAL.db2inst1.050202160426
针对先前使用的 db2pd 中的动态 SQL 语句的请求产生的锚点标识（AnchID）将与针对关联应用程序的请求一起使用。应用程序结果显示最后一个锚点标识（L-AnchID）值与该锚点标识（AnchID）相同。一次运行 db2pd 产生的结果将在下一次运行 db2pd 时使用。
db2pd -agent 的输出将显示应用程序读取的行数（Rowsread 列）和写入的行数（Rowswrtn 列）。这些值将显示应用程序已完成的部分及尚未完成的部分。
Address AppHandl [nod-index] AgentPid Priority Type DBName 0x0000000200698080 501 [000-00501] 11246 0 Coord SAMPLE State ClientPid Userid ClientNm Rowsread Rowswrtn LkTmOt Inst-Active 26377 db2inst1 db2bp 22 9588 NotSet
db2pd -agent 请求中的 AppHandl 和 AgentPid 的值可映射回 db2pd -app 请求中的 AppHandl 和 CoorPiid 的对应值。
如果您怀疑内部临时表占满了表空间，那么这些步骤会稍有不同。仍然可以使用 db2pd -tcbstats 来标识具有最大插入数目的表。以下是隐式临时表的样本信息：
TCB 表信息： Address TbspaceID TableID PartID MasterTbs MasterTab TableName SchemaNm ObjClass DataSize ... 0x0780000020CC0D30 1 2 n/a 1 2 TEMP (00001,00002) <30> <JMC Temp 2470 ... 0x0780000020CC14B0 1 3 n/a 1 3 TEMP (00001,00003) <31> <JMC Temp 2367 ... 0x0780000020CC21B0 1 4 n/a 1 4 TEMP (00001,00004) <30> <JMC Temp 1872 ... TCB 表状态： Address TableName Scans UDI PgReorgs NoChgUpdts Reads FscrUpdates Inserts ... 0x0780000020CC0D30 TEMP (00001,00002) 0 0 0 0 0 0 43219 ... 0x0780000020CC14B0 TEMP (00001,00003) 0 0 0 0 0 0 42485 ... 0x0780000020CC21B0 TEMP (00001,00004) 0 0 0 0 0 0 0 ...
在此示例中，使用命名约定“TEMP (TbspaceID, TableID)”的表中有大量插入。这些是隐式临时表。SchemaNm 列中的值的命名约定为 AppHandl 的值与 SchemaNm 的值并置，这使得它能够标识正在工作的应用程序。
然后，可以将这些信息映射至 db2pd -tablespaces 产生的输出，以查看表空间 1 的已使用空间。在表空间统计信息中记下已使用的页数与可用页数之间的关系。
表空间配置： Address Id Type Content PageSz ExtentSz Auto Prefetch BufID BufIDDisk FSC NumCntrs MaxStripe LastConsecPg Name 0x07800000203FB5A0 1 SMS SysTmp 4096 32 Yes 320 1 1 On 10 0 31 TEMPSPACE1 表空间统计信息： Address Id TotalPgs UsablePgs UsedPgs PndFreePgs FreePgs HWM State MinRecTime NQuiescers 0x07800000203FB5A0 1 6516 6516 6516 0 0 0 0x00000000 0 0 表空间自动调整大小统计信息： Address Id AS AR InitSize IncSize IIP MaxSize LastResize LRF 0x07800000203FB5A0 1 No No 0 0 No 0 None No 容器： ...
然后，可以使用命令 db2pd -app 标识应用程序句柄 30 和 31（因为它们出现在 -tcbstats 输出中）：
应用程序： Address AppHandl [nod-index] NumAgents CoorPid Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid 0x07800000006FB880 31 [000-00031] 1 4784182 UOW-Waiting 0 0 107 1 *LOCAL.db2inst1.051215214142 0x07800000006F9CE0 30 [000-00030] 1 8966270 UOW-Executing 107 1 107 1 *LOCAL.db2inst1.051215214013
最后，使用 db2pd -dyn 命令将它映射至动态 SQL：
动态 SQL 语句： Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text 0x0780000020B296C0 107 1 1 1 43 43 select c1, c2 from test group by c1,c2
场景 8：监视恢复
命令 db2pd -recovery 显示了几个可用于验证是否正在进行恢复的计数器。当前日志和当前 LSN 提供了日志位置。已完成的工作计算目前已完成的字节数。
恢复： 恢复状态 0x00000401 当前日志 S0000005.LOG 当前 LSN 000002551BEA 作业类型 ROLLFORWARD RECOVERY 作业标识 7 作业开始时间 (1107380474) Wed Feb 2 16:41:14 2005 作业描述 数据库前滚恢复 调用程序类型 用户 总阶段 2 当前阶段 1 进度： 地址 阶段号 描述 开始时间 已完成的工作 总工作 0x0000000200667160 1 向前 Wed Feb 2 16:41:14 2005 2268098 字节 未知 0x0000000200667258 2 向后 NotStarted 0 字节 未知
场景 9：确定事务正在使用的资源量
命令 db2pd -transactions 提供了锁定数、第一个日志序号（LSN）、最后一个 LSN、已使用的日志空间和保留空间。这对于了解事务行为很有用。
事务： Address AppHandl [nod-index] TranHdl Locks State Tflag 0x000000022026D980 797 [000-00797] 2 108 WRITE 0x00000000 0x000000022026E600 806 [000-00806] 3 157 WRITE 0x00000000 0x000000022026F280 807 [000-00807] 4 90 WRITE 0x00000000 Tflag2 Firstlsn Lastlsn LogSpace SpaceReserved 0x00000000 0x000001072262 0x0000010B2C8C 4518 95450 0x00000000 0x000001057574 0x0000010B3340 6576 139670 0x00000000 0x00000107CF0C 0x0000010B2FDE 3762 79266 TID AxRegCnt GXID 0x000000000451 1 0 0x0000000003E0 1 0 0x000000000472 1 0
场景 10：监视日志使用情况
命令 db2pd -logs 对于监视数据库的日志使用情况很有用。通过观察已写入的页面输出，可以确定是否正在使用日志。
日志： Current Log Number 0 Pages Written 0 Method 1 Archive Status n/a Method 1 Next Log to Archive n/a 方法 1 首次失败 不适用 Method 2 Archive Status n/a Method 2 Next Log to Archive n/a 方法 2 首次失败 不适用 Log Chain ID 0 Current LSN 0x00000177000C Address StartLSN State Size Pages Filename 0x0000002AC1240818 0x000001770000 0x00000000 1000 1000 S0000000.LOG 0x0000002AC12408D8 0x000001B58000 0x00000000 1000 1000 S0000001.LOG 0x0000002AC1240998 0x000001F40000 0x00000000 1000 1000 S0000002.LOG
使用此输出可以确定两个问题：
- 如果归档存在问题，那么“归档状态”将设置为值“失败”，表示最近的日志归档失败。或者，如果正在发生的归档失败导致根本无法归档日志，那么将设置“首次失败”。
- 如果日志归档速度非常慢，那么“下一个要归档的日志”值将小于“当前日志编号”值。这可能导致填满日志路径，从而在完全填满日志路径时防止数据库中出现任何数据更改。
场景 11：查看综合系统（Sysplex）列表
如果不使用 db2pd -sysplex 命令，那么报告综合系统（sysplex）列表的唯一方法是通过 DB2 跟踪。
综合系统（sysplex）列表： 别名： HOST 位置名： HOST1 计数： 1 IP 地址 端口 优先级 连接状态 PRDID 1.2.34.56 400 1 0 0
场景 12：生成堆栈跟踪
可对 Windows 操作系统使用 db2pd -stack all 命令（对 UNIX 操作系统使用时为 -stack 命令）来对当前数据库分区中的所有进程生成堆栈跟踪。如果您怀疑某个进程或线程正在循环或正被挂起，那么可能要反复使用此命令。
可以通过发出命令 db2pd -stack <eduid> 来获取特定引擎可调度单元（EDU）的当前调用堆栈。例如：
db2pd -stack 137 正在尝试转储 eduid 137 的堆栈跟踪。 有关陷阱文件，请参阅当前 DIAGPATH。
如果需要所有 DB2 进程的调用堆栈，请使用 db2pd -stack all 命令，例如，在 Windows 操作系统上：
db2pd -stack all 尝试转储实例的所有堆栈跟踪。 有关陷阱文件，请参阅当前 DIAGPATH。
如果您正在使用具有多个物理节点的分区数据库环境，那么通过使用命令 db2_all "; db2pd -stack all" 可以获取所有分区中的信息。但是，如果分区是同一机器上的所有逻辑分区，那么使用 db2pd -alldbp -stacks 时的速度会更快。
场景 13：查看数据库分区的内存统计信息
db2pd -dbptnmem 命令显示 DB2 服务器当前消耗的内存量，并在较高级别显示使用这些内存的服务器区域。
以下是 AIX 机器上 db2pd -dbptnmem 的输出示例：
数据库分区内存控制器统计信息 控制器自动： Y 内存限制： 122931408 KB 当前使用量： 651008 KB 使用的 HWM： 651008 KB 高速缓存的内存： 231296 KB
以下是这些数据字段和列的描述：
- 控制器自动：当 instance_memory 配置参数设置为 AUTOMATIC 时，控制器自动的值为 Y。这意味着数据库管理器自动确定内存消耗的上限。
- 内存限制：DB2 服务器可以消耗的内存上限。它是 instance_memory 配置参数的值。
- 当前使用量：服务器当前消耗的内存量。
- 使用的 HWM：自激活数据库分区（在 db2start 命令运行时）以来消耗的内存高水位标记（HWM）或峰值。
- 高速缓存的内存：当前使用量中未使用但为了提高将来内存请求的性能而高速缓存的内存量。
下面显示了 AIX 上 db2pd -dbptnmem 的样本输出的后续部分。
各个内存使用者： 名称 使用的内存（KB） 使用的 HWM（KB） 高速缓存的内存（KB） =========================================================== APPL-DBONE 160000 160000 159616 DBMS-name 38528 38528 3776 FMP_RESOURCES 22528 22528 0 PRIVATE 13120 13120 740 FCM_RESOURCES 10048 10048 0 LCL-p606416 128 128 0 DB-DBONE 406656 406656 67200
列示了 DB2 服务器中所有已注册的内存“使用者”以及它们消耗的内存总量。列描述如下：
- 名称：内存“使用者”的简短专有名称。示例包括：
- APPL-<dbname> 表示为数据库 <dbname> 消耗的应用程序内存
- DBMS-xxx 表示全局数据库管理器内存要求
- FMP_RESOURCES 表示与 db2fmps 通信需要的内存
- PRIVATE 表示其他专用内存要求
- FCM_RESOURCES 表示快速通信管理器资源
- LCL-<pid> 表示用于与本地应用程序通信的内存段
- DB-<dbname> 表示为数据库 <dbname> 消耗的数据库内存
- 使用的内存（KB）：当前分配给该使用者的内存大小。
- 使用的 HWM（KB）：使用者已使用的内存高水位标记或峰值。
- 使用的内存中高速缓存的内存（KB）：当前未使用但立即可用于将来的内存分配的内存量。