DB2 监控及snapshot性能分析

1、Welcome to HUAWEI Technologiespresentation 北信数据库系统监控工具 对数据库系统的监控可以得到数据库系统健康状况的反馈信息。目前北京信息中心在数据库监控上主要通过以下三种方式跟踪可能出现的性能或锁等问题：1. 使用db2cos工具捕获deadlock与锁超时的SQL DB2COS是db2提供的一种针对某种错误进行自动抓取信息的工具，比如死锁，锁超时，有特定的ZRC号或者ECF号的故障等，当故障发生时自动触发抓取相关信息的文件。 目前生产上联机系统数据库DPPADBS01/02/03/04，DPCUDBS01/02/03，DPCUTFR02主机上实例均打

2、开该自动监控开关。2014-03-05-00.00.20、2014-03-06-18.52发生了两次锁超时(问题单PBI000008507)均通过该工具捕获的cos文件分析。2. 使用db2快照snapshot监控器(事件监控器辅之) 由于快照监控器会消耗部分系统性能，主要性能影响包括系统调用和所耗内存，因此在抓取快照时一般打开session级别快照以减少对性能影响，在执行时需要先打开各快照监控器开关(用于获取各监控元素值)，在数据库性能遇瓶颈问题时间段内通过定期(比如30s，需小于db cfg配置中锁超时时间)捕获特定时间点快照信息，然后进行对比分析，监控的数据库对象包括缓冲池，锁，应用，S

3、QL语句，排序等。目前生产上2014.02.01开始的北信清算保障流程第20步中“乐高74场-清分场次”执行失败(PBI000008187)的分析，转接数据转移问题均通过快照监控器分析与定位。3. 使用getdbinf.sh脚本捕获数据库快照信息 目前生产上各数据库主机均部署该脚本，脚本位置/LSYSFIL/dbshellog/getdbinf.sh，用于为生产数据库系统发生异常收集信息，以帮助快速处理数据库故障恢复生产（使用较少）。 DB2数据库系统监控器 数据库监控是一项重要的活动，若将其作为日常活动来执行，将连续提供数据库系统健康状况的反馈信息。实际上，数据库系统监控器由两种不同的工具组

4、成，可用于捕获和返回系统监控信息：一个快照监控器 和一个或多个事件监控器。快照监控器允许您捕获特定时间点的数据库状态图，而事件监控器在特定数据库事件发生时捕获并记录数据。这两种工具所收集的数据均存储在称为监控元素(或数据元素)的实体中。所使用的各监控元素通过惟一的名称标识，且均设计用于容纳特定类型的信息。以下类型的元素用于存储监控数据:计数器计数器(Counter)。计数器保存活动或事件已发生的次数。在监控器的整个生命周期中，计数器值逐渐增加;通常，计数器监控元素是可重置的。为某个数据库执行的 SQL 语句总数就是计数器元素的一个示例。计量器计量器(Gauge)。计量器保存在特定时间点发生的活

5、动或事件的次数。与计数器值不同，计量器值可增加，也可减少，计量器在给定时间点的值通常取决于数据库活动的级别。当前连接到某个数据库的应用程序数量就是计量器元素的一个示例。水位标水位标(Watermark)。水位标表示自监控开始以来观测到的最高(最大)或最低(最小)值。更新操作所影响的最大行数就是水位标元素的一个示例。信息要素信息要素(Information)。顾名思义，信息元素提供所执行的全部监控活动的引用类型细节。信息元素的示例包括缓冲池名称、数据库名称和别名、路径详细信息等。时间戳时间戳(Timestamp)。时间戳表示活动或事件发生的日期和时间。时间戳值以 1970 年 1 月 1 日后流

6、逝的秒和微秒数形式提供。与数据库的第一个连接的建立日期和时间就是一个时间戳元素的示例。时间要素时间要素(Time)。时间元素保存执行一个活动或事件所花费的时间。时间值以自活动或事件开始以后流逝的秒和微秒数形式提供，有些时间元素是可重置的。执行一次排序操作所花费的时间就是一个时间元素的示例。存储监控数据的元素快照监控器开关参数组别组别所提供的信息所提供的信息监视器监视器开关开关DBM 参数参数缓冲池缓冲池活动的数量（读取和写入操作的数量，以及各次读/写操作所用时间）BUFFERPOOLDFT_MON_BUFFERPOOL锁定保持锁定数目，死锁数目LOCKDFT_MON_LOCK排序所执行的排序操

7、作数量、使用的堆数量、遇到的溢出数、排序性能SORTDFT_MON_SORTSQL 语句开始时间、结束时间、语句标识STATEMENTDFT_MON_STMT表测量活动（读行，写行）TABLEDFT_MON_TABLE时间戳时间和时间戳信息TIMESTAMPDFT_MON_TIMESTAMP工作单元开始时间、结束时间及完成状态UOWDFT_MON_UOW1. 1.这些开关可以在实例（这些开关可以在实例（DBMDBM配置配置) )级别或应用程序会话级别上打开或关闭级别或应用程序会话级别上打开或关闭; ;2. 2.在在DBMDBM（实例）配置参数中设置默认的开关值，将影响该实例中所有数据库。而且每

8、个与数（实例）配置参数中设置默认的开关值，将影响该实例中所有数据库。而且每个与数据库相连接的据库相连接的sessionsession（会话）将继承在（会话）将继承在DBMDBM配置中所设置的默认开关值；配置中所设置的默认开关值；3. 3.默认情况下，表中的所有开关均设置为默认情况下，表中的所有开关均设置为 OFFOFF，TIMESTAMP TIMESTAMP 开关是个例外，其默认设置为开关是个例外，其默认设置为 ONON，并在一个实例初次启动时初始化。并在一个实例初次启动时初始化。快照监控器开关快照监控器开关关于快照监控器开关的几点说明1. 性能损耗通常情况下，收集系统监控数据需要额外的处理开

9、销。例如，为了计算 SQL 语句的执行时间，DB2 Database Manager 必须调用操作系统，获取 SQL 语句执行之前和之后的时间戳。此类系统调用的成本高昂。使用系统监控器的另外一个副作用就是所消耗的内存量大大增加 DB2 Database Manager 要使用内存来存储为系统监控器所追踪的各监控元素收集的数据。2. 不同级别的快照监控器开关快照监控器开关设置可在实例级更改，通过 UPDATE DATABASE MANAGER CONFIGURATION 命令修改，也可在应用程序级更改，方法是执行 UPDATE MONITOR SWITCHES 命令。在实例级设置快照监控器开关将

10、影响到受此实例控制的所有数据库(也就是说，所有与该实例控制的数据库建立了连接的应用程序都将继承实例配置中的开关设置)。此外，在实例级做出的快照监控器开关设置在实例重启后依然保留。在应用程序级设置快照监控器开关仅影响到与这一个应用程序交互的数据库。此外，开关设置仅在此应用程序的生命周期内持续。每个连接至数据库的应用程序都有其自己的监视器开关集，这些监视器开关与数据库管理器和其它应用程序无关。应用程序在连接至数据库时，从数据库管理器上继承它们的监视器开关设置。要查看应用程序的所有监视器开关设置的设置选项，使用 GET MONITOR SWITCHES 命令。 实例级实例级会话（应用程序）级会话（应

11、用程序）级查看查看GET DATABASE MANAGER MONITOR SWITCHES GET MONITOR SWITCHES更改更改（打开（打开与关闭）与关闭）UPDATE DBM CFG USING SwitchID ON | OFF ,.UPDATE MONITOR SWITCHES USING SwitchID ON | OFF ,.SwitchID包括： BUFFERPOOL、LOCK、SORT、STATEMENT、TABLE、TIMESTAMP 和 UOW快照监控器的查看与更改对应于不同级别的快照监控器开关的状态查看与更改见下表：监控元素用于存储数据的一种元素就是计数器，计

12、数器用于保存一个运行期间的具体活动或事件发生的次数的数量的累积。典型的计数器开始于快照监视器开关打开或与数据库的连接被建立的时候)。计数器一旦开始，它将一直继续直到快照显示器开关被关闭或所有数据库连接被终止为止。但有时也希望将所有计数器重置为 0，最简便的方法就是执行 RESET MONITOR 命令。此命令的基本语法是：RESET MONITOR FOR ALL 或 RESET MONITOR FORDATABASE | DB DatabaseAlias其中 DatabaseAlias 表示将为之重置快照监控器计数器的数据库的别名。 如果想重置一个实例控制下的所有数据库快照监控器的计数器，可

13、以切换到这个实例下，然后执行reset monitor all命令。如果只是想把与sample数据库相关联的快照监视器的计数器重置为0的话，可以执行reset monitor for database sample命令。这里有一个需注意的重点，不能使用 RESET MONITOR 命令选择性地对快照监视器开关所控制的特殊的监视器组重置它们的计数器。在命令行调用快照监视器只是调用快照监视器的一种方法，并且在有些时候在命令行调用快照并不是很好的选择，比如还可以利用表函数监控或性能管理视图监控。重置计数器重置计数器 当数据库被激活或与数据库的连接建立时，打开快照监控器立即开始收集监控数据。但在所收集

14、到的任何数据能够被查看之前，必须捕获快照。可通过执行 GET SNAPSHOT 命令捕获快照或在应用程序中嵌入 db2GetSnapshot() API 得到快照。快照级别快照级别查看命令查看命令Buffer Pooldb2 get snapshot for bufferpools on Locksdb2 get snapshot for locks on 或db2 get snapshot for locks on for application agentid appl-handler 注：appl-handler可从list applicaitions得到Dynamic SQLdb2 g

15、et snapshot for dynamic sql on Table Activitydb2 get snapshot for tables on Applicationsdb2 get snapshot for applications on 或 db2 get snapshot for application agentid appl-handlerTablespacedb2 get snapshot for tablespaces on Databasedb2 get snapshot for database on Database Managerdb2 get snapshot

16、for DBM1.利用命令行快照获取数据2.使用表函数监控(1) DB2数据库从V8版本后提供了很多表函数，利用这些表函数可以获得很多与数据库性能有关的信息，因而也就可以通过使用这些表函数代替get snapshot命令来收集这些监控数据。 快照表函数能够捕获的许多监视器元素都受控于监视器开关。如果快照表函数中的某些函数描述中提供特定的监控器开关，则表明受控于该开关。在DB2 UDB8.1中我们可以通过引用20多个可用的快照监视器表函数中的一个来构造查询去收集快照数据。 快照表函数快照表函数返回的信息返回的信息SNAPSHOT_DBM 获得数据库管理器信息SNAPSHOT_DATABASE 数

17、据库信息。只有当至少一个应用程序连接至数据库时，才会返回信息SNAPSHOT_APPL 连接至分区上数据库的应用程序上有关锁等待的应用程序信息，包括累积计数器，状态信息和最近执行的SQL语句(如果设置的语句监视器开关)SNAPSHOT_APPL INFO 每个连接至分区上数据库的应用程序的常规应用程序标识信息SNAPSHOT_LOCKWAIT 有关锁等待连接至分区上数据库的应用程序信息SNAPSHOT_STATMENT 有关应用程序的语句的信息，包括最近执行的SQL语句(如果设置的语句监视器开关)SNAPSHOT_TABLE 连接至数据库的应用程序所访问的每个表的表活动信息，需要表监视器开关S

18、NAPSHOT_LOCK 数据库级别上的锁信息，以及每个连接至数据库的应用程序在应用程序级别上的锁信息SNAPSHOT_TBS数据库级别上的表空间活动信息SNAPSHOT_BP指定数据库的缓冲池活动计数器，需要缓冲池监视器开关SNAPSHOT_DYN来自用于数据库的SQL语句高速缓存的某个时间点语句的信息使用表函数监控(2)1.连接至数据库2.确定打开需要捕获的快照类型3.使用希望的快照表函数发出查询快照监视器数据组织快照监视器数据组织 所有的快照表函数都返回一张监视器数据表，其中的每一行代表一个正被监控的数据库对象实例，而每一列代表一个监视器元素(监视器元素代表数据库系统状态的特定属性).举

19、例使用快照表函数捕获快照的查看步骤举例使用快照表函数捕获快照的查看步骤1.db2 connect to sample2.db2 update dbm cfg using DFT_MON_TABLE on3.db2 “select * from table(SNAPSHOT_TABLE(SAMPLE,-1) as T”说明：快照表函数的两个输入参数，第一个用于数据库名称，输入NULL表示使用当前已连接的数据库名称，第二个参数用于分区号，要捕获当前已连接分区的快照，需输入值-1或NULL.3.使用性能管理视图 DB2 UDB 的较早版本中，捕获快照监控数据的惟一途径就是执行 GET SNAPSHO

20、T 命令或在应用程序中调用其相应的 API，DB2数据库版本从V9后提供了很多性能管理视图（这些性能管理视图类似Oracle数据库中的v$开头的动态性能视图），使用这些管理视图可以获得与表函数和快照类似的监控数据。举例来说，如果希望为当前连接的数据库获取锁信息，可执行类似于下面这样的查询：SELECT AGENT_ID, LOCK_OBJECT_TYPE, LOCK_MODE, LOCK_STATUSFROM SYSIBMADM.SNAPLOCKSNAP_GET_LOCK 例程返回与 SNAPLOCK 管理视图相同的信息，但允许为特定数据库或特定数据库分区(而非当前连接的数据库)上的特定数据库

21、检索信息。使用 SNAP_GET_LOCK 例程的查询形式如下：SELECT AGENT_ID, LOCK_OBJECT_TYPE, LOCK_MODE, LOCK_STATUSFROM TABLE(SNAP_GET_LOCK(,-1) AS T在使用 SNAP_GET_LOCKWAIT 表函数时，SNAP_GET_LOCK 表函数提供的信息与 GET SNAPSHOT FOR LOCKS ON DatabaseAlias 命令相同。背景：背景：p北信清算保障流程第20步中“乐高74场-清分场次”执行失败(见问题单PBI000008187 )091957|I|23528894|1|NCS_Ke

22、rnel.*|excute_*|645 : cycle74 time over(100min)!p74场会使用mpay_trans_log表，而且每月切换一次。p1月份时74场乐高清分场次使用表mpay_trans_log12（不存在问题），2月1号开始切换到mpay_trans_log11后，每日出现74场执行超时失败的问题。Snapshot分析场景1:清算74场执行失败系统岗判研过程：系统岗判研过程： 该问题首次发现时间为2014年2月2日7:00，清算白班流程74场数据库SQL语句执行缓慢，后在分析时由应用作业岗重做74场，系统岗在同时打开session级别所有快照监视器开关，在性能缓慢

23、的时间段每隔30s抓取快照： db2 get snapshot for database on cusltdb1. 通过Database Snapshot查看得知Total buffer pool read time (millisec) = 9409382，发现bufferpool读取所耗时间较大，定位问题为缓冲池读;Snapshot timestamp = 02/03/2014 15:13:18.257211Time database waited on locks (ms) = 602Lock Timeouts = 0Total sort time (ms) = 194Total buf

24、fer pool read time (milliseconds) = 9409382Total buffer pool write time (milliseconds)= 165767Total elapsed asynchronous read time = 4635589Total elapsed asynchronous write time = 156366Time waited for prefetch (ms) = 322250Direct reads elapsed time (ms) = 57293Direct write elapsed time (ms) = 26974

25、Host execution elapsed time = 1133.538570Log read time (sec.ns) = 0.000000004Log write time (sec.ns) = 224.0000000042. Database Snapshot中还发现No victim buffers available = 6897616，发现缓冲池大量被抢占，干净页不足;3. 随后系统岗研判时通过事件监控器抓取静态SQL语句，发现cu_legdb.tbl_cuslt_lego_mpay_trans_log11读取量最大，该静态语句执行对该表的select操作。通过db2expl

26、n查看Package得知该语句执行计划缓慢，对索引和表进行双倍预取，额外消耗509889数据页，占用了大量缓冲池页面(如右所示)。No victim buffers available = 6897616LSN Gap cleaner triggers = 315Dirty page steal cleaner triggers = 526Dirty page threshold cleaner triggers = 0Time waited for prefetch (ms) = 328803Access Table Name = CU_LEGDB.TBL_CUSLT_LEGO_MPAY_T

27、RANS_LOG11 ID = 10,49| Index Scan: Name = CU_LEGDB.IND_CUSLT_MPAY_BDB11_PK ID = 1| | Regular Index (Not Clustered)| | Index Columns:| | | 1: PRI_KEY (Ascending)| | | 2: LOG_CD (Ascending)| #Columns = 196| Skip Deleted Rows| #Key Columns = 0| | Start Key: Beginning of Index| | Stop Key: End of Index|

28、 Data Prefetch: Eligible 509889| Index Prefetch: Eligible 509889| Isolation Level: Uncommitted Read| Lock Intents| | Table: Intent None| | Row : None| Sargable Predicate(s)| | #Predicates = 1| | Return Data to Application| | | #Columns = 196Return Data CompletionSnapshot分析场景1:清算74场执行失败分析原因：分析原因： 初步分

29、析为上海重构清算库后，没有对mpay_trans_log11进行runstats, 执行计划尚可，同步到北信后，在进行rbind时未对涉及该表的应用重绑，执行计划缓慢，读取该表消耗大量数据页，占用了大量缓冲池页面，导致场次时间超时。解决方案：解决方案： 1. 修改脚本，增加对该表的runstate及rbind all操作，系统岗执行db2rbind后查看对应SQL的优化后的执行计划见右图; 2. 推动信总对这张表做runstat，是否要信总针对该表做runstat，要和开发中心、信总一同讨论，并结合MAD改造的情况综合考虑最后确定； 3. 类似问题清算库的其他表，其他库是否也有类似需求需要评估

30、。Optimizer Plan: Rows Operator (ID) Cost 174438 RETURN ( 1) 102449 | 174438 TBSCAN ( 2) 102449 | 174438 SORT ( 3) 102449 | 174438 TBSCAN ( 4) 101565 | 4.36095e+06 Table: CU_LEGDB TBL_CUSLT_LEGO_MPAY_TRANS_LOG11Snapshot分析场景1:清算74场执行失败Snapshot分析2:转接数据转移问题排查1.对Database Snapshot的分析 Database的snapshot中包含了

31、很多数据库本身的信息，其中主要包括：应用连接数，锁相关统计，排序及溢出统计，数据库缓冲池读写统计，SQL语句及Package统计，数据库内存使用统计等，下表接合缓冲池读写及数据更新情况对四个日志快照分析：1.log2.log条差条差13.log条差条差24.log条差条差3Total buffer pool read time (milliseconds)1386585215336682317784Total buffer pool write time (milliseconds)056015601124426841191306688Rows deleted 096961929628290R

32、ows inserted 861789617811229456115618439861453Rows updated0299299549250855306Rows selected20191018903776186656631887Rows read 263609358371103501106883578通过以上分析发现：在相同间隔的三个时间段，数据库缓冲池读写较平均，波动值较小，对数据库表的读写增删改查操作均无大波动，没有因为某个事务执行时间长或其他问题（比如锁）引起较大的性能问题。数据库整体性能和状态均正常。我们可以重点关注一下Database Snapshot中的排序DB2 排序可以通过

33、 SNAPSHOT 快照监控，快照监控结果提供了很多关于排序的信息以供排障定位，如总的排序次数、排序时间、排序溢出数量等。以下是第四个日志中关于数据库快照排序的部分监控指标：Total Private Sort heap allocated = 0Total Shared Sort heap allocated = 0Shared Sort heap high water mark = 25867Post threshold sorts (shared memory) = 0Total sorts = 11352Total sort time (ms) = 0Sort overflows =

34、0Active sorts = 0Total sorts：表示发生的总排序次数； Total sort time(ms)：表示发生的总排序时间； Sort overflows：表示发生的排序溢出次数； Active sorts：表示监控时正在进行的排序次数。前三个指标是自数据库启动以来的统计值，最后一个指标是当前值。几个关键的指标如下：Sort overflows/Total sorts * 100% 表示排序溢出百分比，通常情况下，该值应该小于 3。如果大于 3，表示溢出的比例太高，需要优化；Total sorts time(ms)/Total sorts 表示每次排序花费的时间 ( 毫秒

35、)，对于交易系统来说，该值最好小于 50ms；Total sorts time(ms)/(Commit statements attempted + Rollback statements attempted) 表示每个事务花费在排序上的时间。一个事务响应时间包含很多方面，比如读 / 写时间、锁时间、排序时间、CPU 时间等。排序时间越少，最终用户的响应时间也越快，占用的 CPU 资源也越少。除了数据库快照，应用程序快照、动态 SQL 快照也包含一些排序信息。这对于我们定位排序根源有很大帮助。对于动态 SQL 语句快照片段，假设某条语句平均每次执行需要 4 次排序，而且 3 次发生溢出，根据这

36、些信息，该语句很明显需要优化。Snapshot分析2:转接数据转移问题排查2. 对Bufferpool Snapshot缓冲池的分析 Bufferpool常常成为影响DB2性能的重要指标，定期抓取的四个log日志中均包括6个Bufferpool的信息，这六个Bufferpool分别为：以上的bufferpool中只有IBMDEFAULTBP与BP32K使用频繁，并且IBMDEFAULTBP的data和index的physical read也均为0，说明IBMDEFAULTBP表空间的命中率基本为100%。而其他四个表空间基本无使用。根据Bufferpool命中率计算公式：(1-( Buffer

37、 pool data physical reads + Buffer pool index physical reads)/(Buffer pool data logical reads+ Buffer pool index logical reads)*100%对四个log日志的BP32K缓冲池命中率计算结果如下： 此上数据说明缓冲池命中率高，不影响性能。Snapshot分析2:转接数据转移问题排查IBMDEFAULTBPBP32K IBMSYSTEMBP4KIBMSYSTEMBP8KIBMSYSTEMBP16KIBMSYSTEMBP32K1.log2.log3.log4.logBuffer

38、poolHit ratio(%)98.299.9699.9699.96 3. 对Dynamic SQL Snapshot Result进行分析 在抓取的Dynamic SQL Snapshot Result中，主要包含了在抓取快照的时间段内执行过的所有动态SQL语句的相关信息，包括总执行次数，总编译次数，数据行读写更新数，缓冲池使用情况，语句执行时间，文本内容等。在抓取的第四个日志中搜索执行得最频繁的语句对应的Dynamic SQL Snapshot如下文本所示： grep n Number of executions 20141620cuswtdb4.log | grep -v = 0 |

39、sort -k 6rn | head Number of executions = 103044 Number of compilations = 1 -编译次数，是个累加值 Worst preparation time (ms) = 6 - SQL语句编译的最长时间 Best preparation time (ms) = 5 Total execution time (sec.microsec)= 6.308665 Statement text = INSERT INTO CU_SWTDB.TBL_CUSWT_AUTH_HIST_LOG2_2() “Total execution time

40、”是将语句每次执行时间加起来得到的总执行时间。我们可以很方便地将这个数字除以执行的次数来得到平均执行时间。如果发现语句的平均执行时间很长，那么可能是因为表扫描和/或出现锁等待(lock-wait)。索引扫描和页面获取导致的大量 I/O活动也是原因之一。通过使用索引可以避免表扫描和锁等待。锁会在提交的时候解除，因此如果提交得更频繁一些，或许可以弥补锁等待的问题。“Statement text”显示语句文本。如果注意到了重复的语句，这些语句除了WHERE子句中谓词的值有所不同以外，其他地方都是一致的，那么就可以使用参数标记，从而避免重新编译语句。这样可以使用相同的包，从而帮助避免重复的语句准备，而

41、这种准备的消耗是比较大的。Snapshot分析2:转接数据转移问题排查 在抓取的日志中对动态SQL语句的分析可以得出很多有用的信息，包括每条SQL语句的执行次数，插入删除或更新的行数，SQL语句对Buffer pool的资源占用情况，SQL语句的执行时间及SQL语句本身的内容。通过分析发现，数据转移操作占用CPU时间最多且执行次数最多的SQL语句为insert操作，分别针对如下两张表：CU_SWTDB.TBL_CUSWT_TRANS_LOG2_2CU_SWTDB.TBL_CUSWT_TRANS_LOG1_2对四个日志中以上两表insert语句执行次数除以Total execution time

42、得到理论插入速率：Snapshot分析2:转接数据转移问题排查insert插入下表插入下表对应各对应各log执行执行次数次数1.log执执行次数行次数2.Log执行次执行次数数/时时间间理论理论速率速率13.Log执行次执行次数数/时时间间理论理论速率速率24.Log执行次执行次数数理论理论速率速率3CU_SWTDB.TBL_CUSWT_TRANS_LOG2_2034492/2.0568301676969350/4.25218916309103044/6.30866516333CU_SWTDB.TBL_CUSWT_TRANS_LOG1_2022110/1.3740741609044299/2.

43、7765171595466609/4.12653516141通过以上分析得到理论执行速率约16000笔/s，真实插入速率是该值的1/10，判断无性能问题。Snapshot分析2:转接数据转移问题排查4. 对Application Snapshot Result进行分析 对Application的snapshot快照可以得到应用程序的句柄，抓取快照时的执行状态，应用客户端信息及应用名称，应用程序持有的锁信息，排序信息，缓冲池使用信息，SQL语句执行信息及内存使用信息等。通过对application的快照分析发现无明显异常持有数据库对象的应用存在。Application Snapshot的分析很有价值，包含众多监控元素，详细请参考右侧附件。5. 对Tablespace Snapshot 进行分析，查看表空间均正常。6. 对Database Lock Snapshot 进行分析，查无死锁。通常系统岗在进行实时锁分析时通常DB2中提供的三种工具（目前生产上的联机库均已部署db2cos工具供实时捕获锁相关信息）：a. 快照监控方式 db2 get snapshot for locks on snap.outgr