节选：第2章 性能优化利器——小节与案例分析总结

第2章

性能优化利器——PAT方法

数据库系统出现性能问题，好比人得了病一样，需要治疗。俗话说，“症见于四肢五官，病隐于五脏六腑”。本章阐述如何从体系层面上运用PAT方法学定位问题、调理系统、优化性能。PAT方法学使用PAT树来定位数据库性能问题，其本质是提供了一套系统化的优化思路。这已成为一种标准，被大量实践证明是切实可行的。

在本章结尾的“案例分析总结”中，就记录了PAT方法学的现场应用。

 

2.6  小结

本章以电信金融行业的经营分析系统为例，讲解了如何通过业务分析来确认性能问题，如何通过系统分析来确定性能原因，随后基于业务分析和系统分析的结果来制订优化计划，希望大家能够从中得到一些启发。

在实际生产环境中发生性能问题时，问题的原因并不单一，往往比较复杂，使用PAT方法就能很好地解决这一难题。本章中，经营分析系统的6个真实案例的性能原因就比较复杂，但是我们使用PAT四大原则和系统化方法可以很好地加以解决。

在后面的章节，读者可以更加清晰地理解PAT方法学，它是本书的一个思路，也是数据库性能优化的思想体系。把握了这种思想体系，一定会成为一名出色的“医生”。

 

 

案例分析总结

 

第1章结尾我们看到了启用“PAT树”的背景是，通信运营商系统性能优化时，在深夜发生崩溃。接下来我们看一看工程师们是如何运用“PAT树”的。

2010年4月15日 笔记整理                               地点：北京  

离最后“回退”时间还有55分钟，项目组经过激烈讨论后决定：立即执行“PAT”方案。“PAT”强调的是思路和方法，现在情况紧急且复杂，依靠经验调整会找出一堆“疑似”问题，而冒然在生产系统上“敲敲打打”是极其危险的，这会由于考虑不周引起更严重的后果。

于是，急救任务被划分为三组：

第一组，安排David立即和运营商业务人员、应用开发人员召开会议，从客户管理系统本身来确定性能问题，重新设定每个问题的优化目标及优先级。

第二组，派 Chen和资深运维人员取得联系，对每一个性能问题，从系统角度来分析原因。由于资深运维人员对系统非常熟悉，很快就把性能问题定位到磁盘瓶颈上。

第三组，我组织人员对确认的性能问题，按照优先级从高到低，影响范围从系统到应用的顺序进行优化。我先讲述PAT优化策略的四个步骤：（1）问题监控；（2）配置检查；（3）设计检查；（4）性能优化。然后在白板上画出与磁盘瓶颈有关的“PAT树”。

“通常对DB2这样基于磁盘的数据库来说，磁盘瓶颈是很容易发生的，”我一边讲解，一边在投影仪上放大“PAT树”。 之前已接受过PAT方法培训的运维人员开始执行PAT优化第一步——收集磁盘瓶颈子树中不同路径的监控信息，然后将收集的报告“架”在这棵树上。

很快，问题暴露无遗——客户关系管理应用存在“热表”，而在这些“热表”上存在costly SQL语句，这些costly SQL语句执行时导致表空间高度活跃而引发磁盘瓶颈。

终于找出了根本原因，大家仿佛看到了一丝曙光，精力更加集中起来。David通过PAT优化第二步——配置检查，还发现了事务日志和数据表空间共享磁盘的问题。

接着是PAT优化第三步：设计检查。“用DB2 Design Advisor分析一下这几个costly SQL语句，看看是否发起了一个不期望的表扫描，检查一下缓冲池的命中率，”我掰着指头对Chen说，“记住，我要的是已经优化好的SQL方案！”Chen久经沙场，带着他的人迅速完成了所有设计检查工作，并拿出一个通过安全测试的优化方案。我通知运维人员，启动第四步——性能优化操作。他们与3位DBA按照新的优化方案，开始执行优化操作，包括：调整事务日志的存放路径；增大缓冲区大小；建立索引避免执行那些costly SQL时启用表扫描；最后使用DB2 物化查询表（MQT）技术进一步加速这些costly SQL的执行速度。

经过漫长的等待，DBA告知方案操作完成，小白带着测试小组立刻启动测试。过了一段时间，终于听到小白在那边喊起来：“PASS！全都PASS了！”几个层面的测试都宣告成功，大厅里欢呼声一片。

下楼时研发工程师出身的Chen小声对我说：“这个数据库的逻辑设计很糟糕，今天这颗定时炸弹爆炸了。”我迈着沉重的脚步走出大楼，这时天已经亮了。我仍然没有停止思考，上车后又开始揣摩逻辑设计上的问题。

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

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