节选：第2章 性能优化利器——PAT方法 小节2.5.1-2.5.3

2.5  使用PAT方法

根据上一节的优化计划，使用PAT优化策略对经营分析系统的6个真实案例进行逐一优化。为了防止连带效应，每次只优化一个问题。其中，在优化中所用到的诸如设计、配置及监控的技术细节都可以在本书的后续章节找到，为了方便读者阅读，我们给出了这些技术所在的具体章节。

2.5.1  优化“每天下午系统响应慢”问题（Perf_SlowAfterNoon_Sys）

此问题由于CPU瓶颈导致，如图2-4所示，查找PAT树，按照下面的步骤优化：

图2-4 “每天下午系统响应慢”PAT分析树

 问题监控。

首先通过管理视图等工具排除了高成本SQL语句的问题，随后通过下面的方法确认性能问题的原因，即LOAD例程每天下午1点都会被用户johnh调度执行。

—    使用“db2pd –edus”找到CPU使用率最高的线程17

EDU  ID TID Kernel TID EDU Name USR (s) SYS (s)

21   2946493344 10227 db2agent (DS2) 2.200000 0.90000020

20   2947541920 10226 db2lfr (DS2) 0.000000 0.00000019

19   2948590496 10225 db2loggw (DS2) 1.700000 0.60000018

18   2949639072 10224 db2loggr (DS2) 2.170000 1.68000017

17   2950687648 10214 db2agent (DS2) 29.310000 4.60000016

—    使用“db2pd –db edwdata –applications”找到与线程17相应的后台进程

Address App-[nod-index] Num-Coor-Status L-Anch-L-Stmt-Appid

HandlAgents EDUID ID UID

0x20A55FD0 12 [000-00012] 1 30 ConnectCompleted 0 0 *LOCAL.DB2.091015124129

0x20A40060 9 [000-00009] 1 27 ConnectCompleted 0 0 *LOCAL.DB2.091015124126

0x20A06C00 8 [000-00008] 1 26 ConnectCompleted 0 0 *LOCAL.DB2.091015124125

0x20A00060 7 [000-00007] 3 17 PerformingLoad 937 1 *LOCAL.johnh.091015130001

 配置检查：正常。

 设计检查：LOAD例程调度时间错误导致系统性能降低。

 性能优化。

找到原因后，就可以非常容易地解决问题了。数据库管理员可以通过下面的方法解决：

（1）使用工作负载管理来管理LOAD例程，这可以参考本书工作负载管理设计的相关内容（6.4节）。

（2）另外一个权宜之计是将LOAD例程安排在业务负载不太繁忙的时间段，例如凌晨左右。

2.5.2  优化“大数据转入”问题（Perf_Load_App）

此问题由数据转入设计不良导致，首先进行配置检查，随后重新设计数据转入方式：

 问题监控：存在I/O瓶颈。

 配置检查：检查了DB参数NUM_IOSERVERS和NUM_IOCLEANERS，发现一切正常。

 设计检查：数据转入设计不好导致性能低下。

 性能优化。

考虑到数据日转入的记录数在500万条左右、用时超过2个小时，采取如下措施：

（1）使用表分区加速大数据量的日转入。

有关表分区（Table Partition）的内容，请参考本书3.4节表分区设计的相关内容。使用表分区的语句如下所示：

CREATE TABLE NewDayRecords      //创建空的staging表

LOAD/Insert into NewDayRecords  //对NewDayRecords执行 ETL

//极快的操作，不需要数据移动，稍后完成索引的维护

ALTER TABLE CDR_Table ATTACH PARTITION STARTING '01/01/2011

'ENDING '01/02/2011'FROM TABLE NewDayRecords

COMMIT

SET INTEGRITY FOR CDR_Table     //验证数据

COMMIT                          //新数据变成可视

（2）加载时将主外键或相关索引删除，加载完成后重建相关键以及索引，对主外键约束尽量通过加载程序来保证它的数据完整性。这一点往往会被大家忽略，为了提高加载效率，需要在真正加载数据前检查一下所有表的索引状态及主外键约束。

2.5.3  优化“客户流失分析”问题（Perf_Customer_App）

此问题存在CPU瓶颈，如图2-5所示，查找PAT树，按照下面的步骤优化：

图2-5 “客户流失分析”PAT分析树

 问题监控。

使用下面的语句找到CPU代价最高的前10条SQL语句：

SELECT MEMBER,SECTION_TYPE ,varchar(stmt_text,200) as statement,num_exec_with_metricsas numExec, TOTAL_CPU_TIME/NUM_EXEC_WITH_METRICS as AVG_CPU_TIME,TOTAL_CPU_TIMEFROM TABLE(MON_GET_PKG_CACHE_STMT( 'D', NULL, NULL, -2)) as T WHERE T.NUM_EXEC_WITH_METRICS <> 0 ORDER BY AVG_CPU_TIME descfetch first 10 rows only

发现涉及的都是大数据量的表，而且有多表之间的连接，以及诸如AVG，SUM之类的聚类计算。

 配置检查：正常。

 设计检查：高耗时SQL语句设计不良。

 性能优化。

找到原因后，如图2-6所示，查找PAT树来解决问题。数据库管理员可以通过下面的方法解决：

（1）首先使用visual Explain或者db2exfmt来分析这些高代价SQL语句。

（2）随后使用Design Advisor工具来重新设计这些SQL语句。

（3）最后该性能问题通过更改索引、使用MQT表成功解决。关于MQT的相关内容，请参考3.6节。

图2-6 “客户流失分析”问题SQL优化

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24801454/viewspace-694169/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24801454/viewspace-694169/