aix db2 登陆命令_使用AIX命令和实用程序确定DB2问题-优快云博客

本文介绍了如何使用AIX操作系统工具监控和排查DB2问题，包括CPU使用率、孤立进程、数据库损坏、内存泄漏和挂起等。通过分析输出，收集数据并利用如ps、topas、iostat等命令，可以帮助识别和解决DB2在AIX环境中的各种性能和故障问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在许多情况下，对DB2问题进行故障排除可能会涉及到这种情况，并且会受益于收集操作系统级别的数据并进行分析以进一步了解问题。

本文讨论了数据库可能遇到的许多问题，包括CPU使用率问题，孤立进程，数据库损坏，内存泄漏，挂起和应用程序无响应。学习使用AIX实用程序和命令来帮助您了解和解决这些麻烦的问题。

打开问题管理请求（PMR）时，可以将通过运行这些命令收集的数据发送给IBM技术支持团队，以加快PMR支持过程。本文每一节的末尾都讨论了应收集以发送给技术支持团队的文档。尽管本文提供了疑难解答技巧作为指导，但是您应该联系IBM技术支持团队以获取有关这些问题的官方建议。

监控CPU使用率

在使用数据库时，您可能会注意到某个DB2进程消耗了大量的CPU空间。本部分描述了一些AIX实用程序和命令，您可以使用它们自己分析问题或收集数据，然后再将PMR提交给IBM技术支持：

ps

清单1. `ps`输出样例

root@bagpuss $ ps auxw|sort -r +3|head -10
USER      PID   %CPU  %MEM   SZ  RSS    TTY STAT  STIME  TIME   COMMAND
sharon   1658958  0.1  9.0 218016 214804 - A      Sep 13 38:16 db2agent (idle) 0
dpf      1036486  0.0  1.0 14376 14068   - A      Sep 17  3:10 db2hmon 0
sharon   1822932  0.0  1.0 12196 11608   - A      Sep 12  6:41 db2hmon 0
dpf      1011760  0.0  0.0 9264  9060    - A      Sep 17  3:03 db2hmon 3
dpf      1532116  0.0  0.0 9264  9020    - A      Sep 17  3:04 db2hmon 2
dpf       786672  0.0  0.0 9264  8984    - A      Sep 17  3:02 db2hmon 5
dpf      1077470  0.0  0.0 9264  8968    - A      Sep 17  3:03 db2hmon 1
dpf      1269798  0.0  0.0 9248  9044    - A      Sep 17  2:50 db2hmon 4
db2inst1  454756  0.0  0.0 9012  7120    - A      Jul 19  0:52 db2sysc 0

托帕斯

清单2.示例topas输出

Name          PID    CPU%  PgSp Owner
db2sysc      105428  33.3  11.7 udbtest
db2sysc       38994  14.0  11.9 udbtest
test          14480   1.4   0.0 root
db2sysc       36348   0.8   1.6 udbtest
db2sysc      116978   0.5   1.6 udbtest
db2sysc      120548   0.5   1.5 udbtest
sharon        30318   0.3   0.5 root
lrud           9030   0.3   0.0 root
db2sysc      130252   0.3   1.6 udbtest
db2sysc      130936   0.3   1.6 udbtest
topas        120598   0.3   3.0 udbtest
db2sysc       62248   0.2   1.6 udbtest
db2sysc       83970   0.2   1.6 udbtest
db2sysc      113870   0.2   1.7 root

虚拟机

清单3.样本`vmstat`输出

kthr 	memory 	page 		faults		cpu 
----- ----------- ------------------------ ------------ ----------- 
r  b avm     fre   re pi po  fr sr  cy   in     sy   cs   us  sy id   wa 
32 3 1673185 44373 0  0  0    0 0    0  4009  60051 9744  62  38    0   0 
24 0 1673442 44296 0  0  0    0 0    0  4237  63775 9214  67  33    0   0 
30 3 1678417 39478 0  0  0    0 0    0  3955  70833 8457  69  31    0   0 
33 1 1677126 40816 0  0  0    0 0    0  4101  68745 8336  68  31    0   0 
28 0 1678606 39183 0  0  0    0 0    0  4525  75183 8708  63  37    0   0 
35 1 1676959 40793 0  0  0    0 0    0   4085 70195 9271  72  28    0   0 
23 0 1671318 46504 0  0  0    0 0    0  4780  68416 9360  64  36    0   0 
30 0 1677740 40178 0  0  0    0 0    0  4326  58747 9201  66  34    0   0 
30 1 1683402 34425 0  0  0    0 0    0  4419  76528 10042 60  40    0   0 
0 0 1684160 33808  0  0  0    0 0    0  4186  72187 9661  73  27    0   0

如上所述，在读取vmstat输出时，您可以忽略第一行。要查看的重要列是us, sy, id和wa 。

id ：空闲时间。

wa ：等待I / O所花费的时间。

us ：花费在运行非内核代码上的时间。（用户时间）

sy ：运行内核代码所花费的时间。（系统时间）

在清单3中，系统平均达到了65％的用户CPU使用率和35％的系统CPU使用率。 Pi和Po值等于0，因此没有分页问题。 wa列显示似乎没有任何I / O问题。

清单4显示wa （等待I / O）的异常高，这表明系统上可能存在I / O瓶颈，这又导致CPU使用效率低下。您可以检查errpt -a输出以查看系统上的介质或I / O是否有任何报告的问题。

清单4.样本`vmstat`输出显示了I / O问题

kthr memory page faults cpu 
----- ----------- ------------------------ ------------ ----------- 
r b  avm    fre re pi po  fr      sr     cy   in    sy   cs   us  sy id wa 
2 8  495803 3344 0 0   0   929    1689    0   998  6066  1832 4   3  76 16 
0 30 495807 3340 0 0   0   0        0     0   1093 4697  1326 0   2  0  98 
0 30 495807 3340 0 0   0   0        0     0   1055 2291  1289 0   1  0  99 
0 30 495807 3676 0 2   0   376    656     0   1128 6803  2210 1   2  0  97 
0 29 495807 3292 0 1   3   2266   3219    0   1921 8089  2528 14  4  0  82 
1 29 495810 3226 0 1   0   5427   7572    0   3175 16788 4257 37  11 0  52 
4 24 495810 3247 0 3   0   6830   10018   0   2483 10691 2498 40  7  0  53 
4 25 495810 3247 0 0   0   3969   6752    0   1900 14037 1960 33  5  1  61 
2 26 495810 3262 0 2   0   5558   9587    0   2162 10629 2695 50  8  0  42 
3 22 495810 3245 0 1   0   4084   7547    0   1894 10866 1970 53  17 0  30

iostat

清单5.样本`iostat`输出

System configuration: lcpu=4 disk=331 
tty: 	tin 	tout    avg-cpu:   % user    % sys    % idle    % iowait 
0.0 	724.0                17.9     12.3      0.0       69.7

Disks: 		% tm_act   Kbps 		tps        Kb_read  Kb_wrtn 
hdisk119 		100.0      5159.2 		394.4       1560    24236 
hdisk115 		100.0      5129.6 		393.0       1656    23992 
hdiskpower26   	100.0      10288.8		790.8       3216    48228

%tm_act ：报告物理磁盘处于活动状态的时间百分比或磁盘请求的总时间。
Kbps ：报告以千字节为单位的传输到驱动器的数据量。
tps ：报告向物理磁盘发出的每秒传输数。
Kb_read ：报告从测量间隔中从物理卷中读取的总数据（千字节）。
Kb_wrtn ：报告从您测量的间隔中写入物理卷的数据量（千字节）。

要检查是否遇到资源争用，可以集中注意上述输出中的%tm_act值。该值的增加（尤其是超过40％）意味着进程正在等待I / O完成，并且您手头上有一个I / O问题。如果检查这两个因素是否相关，那么检查哪个硬盘具有更高的磁盘活动百分比以及DB2是否使用这些硬盘可以使您更好地了解。

收集什么

在使用IBM技术支持来打开PMR之前，您应该收集以下信息：

db2support.zip
truss -f -o truss.out -p <pid>高CPU进程
高CPU进程的db2pd -stack <pid>

技术支持人员可能还会向您发送db2service.perf1脚本，该脚本基本上会在一段时间内重复收集数据。脚本的输出需要打包并发送回支持团队以进行进一步分析。

对孤立进程进行故障排除

在某些情况下，即使执行db2stop ，您仍然注意到（通过执行ps -ef | grep DB2 ）某些DB2进程（例如db2fmp进程）仍在运行并消耗资源。如果出现异常关闭的情况，建议在实例停止后再执行ipclean。进行db2stop应该会固有地关闭所有与DB2相关的进程。但是，如果使用这些进程的应用程序被异常终止，则可能导致相关的DB2进程成为孤立进程。

孤立DB2进程是未附加或链接到任何其他DB2进程的进程。异常终止应用程序包括执行Ctrl + C，关闭KSH会话或使用-9选项将其关闭以将其关闭。

确认该进程为孤立进程的一种方法是，尝试将ps -ef输出中的孤立进程的进程ID（PID）与db2 list applications show detail输出的Coordinator列进行匹配。如果在db2 list apps output找不到PID，则它是一个孤立进程。例如，如果发出db2 list applications show detail命令，则会得到以下输出：

清单6.示例`list applications`输出

CONNECT Auth Id Application Name Appl. Application Id Seq# Number of Coordinating DB 
Coordinator Status Status Change Time DB Name DB Path 
Handle Agents partition number pid/thread 

JDE test.exe 2079 AC1C5C38.G80D.011F44162421 0001 1 0 2068646
UOW Waiting 04/04/2006 09:25:17.036230 PTPROD 
/db2pd/otprod/ptprod/otprod/NODE0000/SQL00001/ 

--NOTICE PID 2068646. This is the PID on the local server. 

Part of the ps -ef output from the server: 

ps -ef |grep 2068646 
otprod 2068646 483566 0 09:06:28 - 0:59 db2agent (PTPROD) 0

此输出显示PID为2068646的进程不是孤立的进程，并且仍附加到DB2进程。

为了避免孤立进程，您可能需要执行以下操作：在客户端进行正常的干净出口，以便DB2知道并可以清理服务器上的资源。将TCPKEEPIDLE时间的值调整为小于缺省值的数字，并调整DB2CHECKCLIENTINTERVAL和KEEPALIVE值。

收集什么

如果您确实注意到孤儿进程并希望调查此问题，那么在与IBM技术支持一起打开PMR之前，应该收集以下信息：

ps -ef| grep db2 ps -ef| grep db2输出
带有-c选项的db2support.zip

使用dbx ， db2pd -stack或kill -36 <pid>收集的进程的调用堆栈。 dbx命令是Solaris和AIX系统中都使用的流行命令行调试器。 dbx输出很有帮助，可以按以下方式运行：

清单7. `dbx`命令

dbx -a <PID>
At the dbx prompt type 
th 		--- Displays all threads for the process 
th info 	--- Displays additional info about the threads 
where 		--- Get stack trace for thread 1 
th current 1  --- Makes t1 current 
where 		--- Displays stack for thread 1 
th current 2  --- Makes thread 2 current 
where 		--- Displays stack for thread 2. 
... continue for all threads of the process 
detach - 	--- Detach from process
dbx -a <PID of orphan process>

检测数据库损坏

如果用户抱怨无法访问某些数据库对象或无法连接到特定的数据库分区，则可以开始调查数据库是否已损坏。以下部分重点介绍了DB2记录的一些错误，以及如何确保不存在影响或导致DB2数据库损坏的操作系统（OS）级别问题。您可能会注意到与db2diag.log中记录的清单8中的错误类似的错误：

清单8.腐败错误

RETCODE : ZRC=0x87040001=-2029780991=SQLD_BADPAGE "Bad Data Page" 
DIA8500C A data file error has occurred, record id is "". 

Or
RETCODE: ZRC=0x86020019=-2046689255=SQLB_CSUM "Bad Page, Checksum Error"

DIA8426C A invalid page checksum was found for page "". 

Or
2007-07-09-11.29.45.696176+120 I16992C16377 LEVEL: Severe 
PID : 68098 TID : 1 PROC : db2agent (sample) 
INSTANCE: instest NODE : 000 DB : sample
APPHDL : 0-635 APPID: *LOCAL.instest.070709082609 
FUNCTION: DB2 UDB, buffer pool services, sqlbcres, probe:20 
MESSAGE : Important: CBIT Error 
DATA #1 : Hexdump, 4096 bytes

当DB2尝试访问容器中的数据并且存在某种形式的损坏时，将记录这些错误。在这种情况下，当DB2无法访问数据时，该数据库可能被标记为错误。您可以缩小可能损坏的范围。在db2diag.log中，查找类似于以下内容的消息：

清单9.显示数据库对象详细信息的损坏错误

2006-04-15-03.15.37.271601-360 I235258C487 LEVEL: Error 
PID : 152482 TID : 1 PROC : db2reorg (SAMPLE) 0 
INSTANCE: instest NODE : 000 DB : SAMPLE 
APPHDL : 0-68 APPID: *LOCAL.SAMPLE.060415091532 
FUNCTION: DB2 UDB, buffer pool services, sqlbrdpg, probe:1146 
DATA #1 : String, 124 bytes 
Obj={pool:5;obj:517;type:0} State=x27 Parent={5;517}, EM=55456, 
PP0=55488 Page=55520 Cont=0 Offset=55552 BlkSize=12 
BadPage

上面的错误指示表空间5和表ID 517中发生损坏。要检查它引用的表，请执行以下SQL查询：

清单10.查询查找有损坏的表

db2 "select tabname, tbspace from syscat.tables where tbspaceid = 5 and tableid = 517"

在操作系统（OS）级别上，最常见的损坏原因是硬件问题或文件系统损坏。例如，在db2diag.log中，是否看到数据库被标记为损坏，并带有ECORRUPT (89)错误，如下所示：

清单11.与样本文件系统相关的损坏错误

2007-05-22-13.45.52.268785-240 E20501C453 LEVEL: Error (OS) 
PID : 1646696 TID : 1 PROC : db2agent (SAMPLE) 0 
INSTANCE: tprod NODE : 000 DB : SAMPLE 
APPHDL : 0-32 APPID: GA260B45.M505.012BC2174219 
FUNCTION: DB2 UDB, oper system services, sqloopenp, probe:80 
CALLED : OS, -, unspecified_system_function 
OSERR : ECORRUPT (89) "Invalid file system control data detected."

清单12.示例errpt输出

LABEL: J2_FSCK_REQUIRED 
IDENTIFIER: B6DB68E0 
Date/Time: Thu Jun 7 20:59:49 DFT 2007 
Sequence Number: 139206 
Machine Id: 000BA256D600 
Node Id: cmab 
Class: O 
Type: INFO 
Resource Name: SYSJ2 
Description 
FILE SYSTEM RECOVERY REQUIRED 
Probable Causes 
INVALID FILE SYSTEM CONTROL DATA DETECTED 
Recommended Actions 
PERFORM FULL FILE SYSTEM RECOVERY USING FSCK UTILITY 
OBTAIN DUMP 
CHECK ERROR LOG FOR ADDITIONAL RELATED ENTRIES 
Detail Data 
ERROR CODE 
0000 0005 
JFS2 MAJOR/MINOR DEVICE NUMBER 
0032 0004 
CALLER 
0028 8EC8 
CALLER 
0025 D5E4 
CALLER 
002B 4AC8

在容器所在的文件系统上运行fsck命令，以确保它是正确的。 fsck交互方式检查和修复任何文件系统故障。在pSeries和AIX信息中心，我们可以找到以下使用fsck命令的示例。

清单13. `fsck`命令

To check all the default file systems enter:
fsck
This form of the fsck command asks you for permission

before making any changes to a file system.

To check the file system /dev/hd1, enter:
fsck /dev/hd1
This checks the unmounted file system located on the /dev/hd1 device.

收集什么

在使用IBM技术支持来打开PMR之前，您应该收集以下信息：

errpt -a
db2support.zip
fsck结果

调试内存泄漏

如果可能的话，区分内存泄漏和由于内存需求增加而导致的系统范围的性能下降非常重要。因此，最初有必要检查环境中是否有任何变化可以解释内存使用增加的原因。本节的其余部分讨论如何使用AIX操作系统技术来发现，跟踪和调试这些泄漏。本文没有讨论详细的DB2工具和技术，尽管在必要时有一些提及。

什么是内存泄漏？

维基百科将内存泄漏描述为

计算机程序的一种特定类型的无意内存消耗，其中该程序在不再需要时无法释放内存。这种情况通常是由于程序错误导致的，该错误阻止程序释放不再需要的内存。由于内存不会从计算机上物理丢失，因此该术语被称为幽默的不当用语。而是，将内存分配给程序，并且由于程序逻辑缺陷，该程序随后失去了访问该程序的能力。

具体来说，这是代码中的错误，其中相应的free（）内存调用无法满足malloc（）内存分配调用。没有相应的free（）系统调用会导致未释放的块。通常这是一个缓慢的过程，并且会持续数天或数周-尤其是如果该过程保持活动状态（通常如此）。有些泄漏甚至无法检测到，特别是如果应用程序终止并且其进程被破坏。

图14是一个C代码片段的示例，它演示了内存泄漏。在这种情况下，内存可用，并由变量“ s”指向，但未保存。此函数返回后，指针将被销毁并且分配的内存将变得不可访问，但仍保持分配状态。

清单14.示例c代码

#include <stdio.h>
#include <stdlib.h>
void f(void)
{
     void* s;
     s = malloc(50); /* get memory */
     return;         /* memory leak - see note below */ 
     /* 
      * Memory was available and pointed to by s, but not saved.
      * After this function returns, the pointer is destroyed, 
      * and the allocated memory becomes unreachable.
      *
      * To "fix" this code, either the f() function itself
      * needs to add "free(s)" somewhere or the s needs
      * to be returned from the f() and the caller of f() needs
      * to do the free().
      */
}
int main(void)
{
     /* this is an infinite loop calling the above function */
     while (1) f(); /* Malloc will return NULL sooner or later, due to lack of memory */
     return 0;
}

如何发现，跟踪和调试内存泄漏

首先，如果您怀疑DB2进程正在泄漏内存，则应该致电IBM。但是，您如何知道自己正在经历这种情况？本节讨论一些选项。

第一种选择是使用ps实用程序。 ps实用程序可用于快速简单地确定进程是否泄漏。此示例演示了特定过程的大小如何增长：

清单15.示例“ ps aux”输出显示了流程的规模不断扩大

ps aux:

1st iteration:      
USER         PID %CPU %MEM   SZ  RSS    TTY STAT    STIME  TIME
COMMAND                                                 
db2inst1  225284  0.2  0.0 19468 18280     - A    11:26:06 10:34    
db2logmgr                                                       
                                                                     
2nd iteration:                                                       
db2inst1  225284  0.1  0.0 19696 18512      - A    11:26:06 10:34    
db2logmgr                                                       
                                                                     
3rd iteration:                                                       
db2inst1  225284  0.1  0.0 19908 18724      - A    11:26:06 10:36    
db2logmgr                                                       
                                                                     
4th iteration:                                                       
db2inst1  225284  0.1  0.0 20116 18932      - A    11:26:06 10:36    
db2logmgr                                                      
                                                                     
5th iteration:                                                       
db2inst1  225284  0.1  0.0 20312 19128      - A    11:26:06 10:37    
db2logmgr                                                    
                                                                     
ps -kelf:                                                            
                                                                     
1st iteration:        
F S      UID     PID    PPID   C PRI NI ADDR    SZ    WCHAN    
STIME    TTY  TIME CMD                                               
40001 A db2inst1  225284  254158   0  60 20 580e59400 18466         
11:26:06      - 10:34 db2logmgr (***) 0                           
                                                                     
2nd iteration:                                                       
40001 A db2inst1  225284  254158   1  60 20 580e59400 18696          
11:26:06      - 10:34 db2logmgr (***) 0                           
                                                                     
3rd iteration:                                                       
40001 A db2inst1  225284  254158   0  60 20 580e59400 18900          
11:26:06      - 10:36 db2logmgr (***) 0                           
                                                                     
4th iteration:                                                       
40001 A db2inst1  225284  254158   0  60 20 580e59400 20106          
11:26:06      - 10:36 db2logmgr (***) 0                           
                                                                     
5th iteration:                                                       
40001 A db2inst1  225284  254158   0  60 20 580e59400 20312          
11:26:06      - 10:37 db2logmgr (***) 0

ps aux输出中的SZ和RSS值是尝试发现潜在内存泄漏时要重点关注的2个关键列。如您所见，粗体的值正在增加。但是，仅仅确定根本原因还不够，因此肯定需要进行更多调试。再次，请向IBM技术支持提出此问题，但是接下来是IBM将采取的一些可能的问题确定步骤。

使用procmap和gencore进行调试

作为根：

procmap <db2logmgr pid>> procmap.1
ps aux > ps_aux.1
ps -kelf > ps_kelf.1
gencore <db2logmgr pid> <file>

睡眠一段时间，然后：

procmap <db2logmgr pid> > procmap.2
ps aux > ps_aux.2
ps -kelf > ps_kelf.2
gencore <db2logmgr pid> < file>

清单16. `lsattr`命令

lsattr -El sys0| grep -i core
fullcore     true                  Enable full CORE dump                             True

并且实例所有者的限制也需要适当设置。可能会要求您启用MALLOC_DEBUG并将其导出到DB2环境。以下是一个示例：

要在下次启动实例时启动DB2内存调试，请运行：
db2set DB2MEMDBG=FFDC

要在下次启动实例时启动malloc调试，请运行：
export MALLOCDEBUG log:extended stack_depth 12
并将MALLOCDEBUG附加到DB2注册表变量DB2ENVLIST中：
db2set DB2ENVLIST MALLOCDEBUG

然后停止并重新启动DB2。

创建核心文件后，您可以使用snapcore将核心文件和库捆绑到pax文件中。 snapcore的示例如下：

清单17.示例快照

snapcore /home/db2inst1/sqllib/db2dump/c123456/core
/home/db2inst1/sqllib/adm/db2sysc

默认情况下，这会在/ tmp / snapcore中创建一个扩展名为* .pax的文件。没有核心可执行文件，核心文件就没有用了，在这种情况下，它是db2sysc而不是db2logmgr ，这在增长，因为它不是可执行文件。然后，DB2支持人员可以查询内核，以跟踪针对free()调用的DB2 malloc()分配。

从挂起中恢复

什么是挂

当进程在一段时间后没有前进或更改时，将发生挂起。如果线程或进程在执行过程中到达无法继续执行并等待响应的地步，则会发生这种情况。当过程处于非常紧密的循环中并且从未完成功能时，也会发生这种情况。

第一步是确定您遇到的是死机还是严重退化。然后，您需要了解受影响的因素或范围。一些简单的问题会有所帮助：

您为什么认为它已挂起？
所有的DB2命令都挂了吗？
该命令已运行多长时间了？
它通常运行多长时间

然后访问范围：

OS命令也挂了吗？如果答案是肯定的，那么您需要AIX支持团队的帮助。
db2 connect语句是否受影响？
可以通过现有连接发出SQL吗？
如果在DPF环境中，可以对其他分区发出命令吗？
您可以对其他数据库发出命令吗？

复苏

请记住，请在恢复之前收集堆栈。一旦有了堆栈，唯一的选择就是发出db2_kill 。然后检查是否有任何进程和IPC共享内存，杀死后剩余的消息队列和信号量。您可能必须删除手动找到的任何内容。您也可以尝试使用ipclean删除这些资源。如果ipclean或ipcrm未清除IPC，而kill -9则删除了进程，则该进程很可能挂在内核中，您需要致电AIX支持。

一旦出现故障，请使用db2start重新启动，然后执行restart db命令。

收集什么

收集的最重要的一条信息是被认为是挂起的过程的堆栈跟踪。没有此功能，IBM DB2支持将无法调试挂起，并且必须在恢复DB2之前收集堆栈跟踪。如果不这样做，将来可能会再次出现故障。

重新启动DB2会有压力，但是您必须抵抗。为了诊断问题的根本原因并进行必要的调试，系统必须处于挂起状态。重新启动可以清除这种情况，并且您失去了进行必要更改的机会。更严重的是，您无法确定它不会再次出现。因此，您需要承受重新启动DB2的压力，直到收集了所有诊断信息为止。

下表描述了良好的探针确定（PD）和数据caputre与不良的PD和数据捕获。请注意，最佳的PD和数据性能要求最少的步骤，并且在确定根本原因方面具有更好的成功更改。

PD和数据捕获不良：

发生
侦测
复苏
FFDC开启（需要重新启动）
重新启动（中断2）计划中断，希望问题不会再次发生
发生（中断3）
侦测
数据采集
复苏
诊断（时钟滴答）

更好的PD和数据捕获：

发生（中断1）
侦测
复苏
FFDC开
发生（中断2）
侦测
数据采集
复苏
诊断（时钟滴答）

良好的PD和数据捕获：

发生（中断1）
侦测
数据采集
复苏
诊断（时钟滴答）

堆栈痕迹

堆栈跟踪是在特定时间点的函数调用的快照。因此，相距几分钟的多条堆栈走线可提供运动感。有多种收集堆栈跟踪的方法。我认为以下列表是最可靠的：
Procstack <pid of hung process> >> pid.pstack.out
这是一个AIX实用程序，仅将堆栈转储到文件中。在这种情况下，我将附加文件，因为它稍后会再次运行，并且我不想重新编写它。

Kill -36 <pid>
该命令不会终止该进程，但会发送一个信号以转储其堆栈。实际上，这会在DB2的DIAGPATH区域中创建一个完整格式的陷阱文件。因为它比procstack及其内部工作方式提供更多的信息，所以它通常更昂贵，尤其是在有数百个进程的情况下（通常是这种情况）。本文的主要重点是讨论用于调试DB2的AIX操作系统工具。在不提及db2pd ，没有完成关于挂起问题确定的讨论，因此可以使用以下调用来生成堆栈跟踪：

db2pd -stacks （这将再次生成所有PID的堆栈转储）
db2pd -stack <pid> （这将为指定的PID生成堆栈转储）
陷阱文件在DIAGPATH区域中创建。清单18显示了其用法示例：

清单18. db2pd -stacks的用法

1. -stacks
$ db2pd -stacks
Attempting to dump all stack traces for instance.
See current DIAGPATH for trapfiles.
2. -stack <pid>
$ db2pd -stack 1454326
Attempting to dump stack trace for pid 1454326.
See current DIAGPATH for trapfile.

DB2支持人员将要求您压缩并压缩DIAGPATH区域。如果使用了正确的标志，大多数情况下，他们会要求您运行db2support命令来执行该命令。但是，如果使用procstack的OS方法，则必须提交输出文件。

桁架

可以使用truss命令，但它的效果不如堆栈转储，并且仅在进程循环且可以复制时才可能显示任何内容。如果进程被挂起，则只有堆栈转储可以显示它如何到达那里。

ps

最好在堆栈转储之前和之后收集所有分区的ps列表（如果适用）。如果您手动收集数据，则伪代码如下所示：

清单19. procstack

Procstack Pid or PIDs  >> procstack.out
Ps eafl >>  pseafl.out
Ps aux >>  psaux.out
Sleep 120
Repeat for at least 3 iterations.

Or:

Kill -36 <pid> or PIDs
Ps eafl  >>  pseafl.out
Ps aux  >>  psaux.out
Sleep 120
Repeat for at least 3 iterations.


NB: IBM DB2 support can provide a data collect script which automates this process.

调查无响应的应用程序

有时，应用程序只是无响应，您必须弄清楚为什么它无响应，以及如何使其响应。如果您发出force application但没有回应，您可能会想知道您能做什么。首先，重要的是要知道force不能保证武力。它只是OS Kill命令的包装。

在不讨论DB2的体系结构细节的情况下，有些情况是很危险的。这样，db2agent将其优先级设置为高于强制优先级。在这种情况下，武力是行不通的，这是设计使然。

最重要的是，并非每个无响应的应用程序都是由错误引起的。在完成当前任务之前，应用程序可能只是在做重要的事情，而不响应任何其他命令。

复苏

恢复几乎肯定需要一个db2stop,db2start因为DB2并不善待被杀死的关键引擎进程。它倾向于引起恐慌并使实例崩溃。我会评估恶意应用程序所带来的影响，如果可能的话，将其留在原处，直到可以回收为止。例如，它可能持有与其他用户竞争的锁，这对应用程序产生了不利影响，在这种情况下，您可能必须停机才能将其删除。