informix 性能调优案例讲解

《informix 性能调优案例讲解》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、Informix性能调优案例讲解牛新庄(niuxinzhuang.zh@ccb.com),博士,IBM官方高级培训讲师,自由著者牛新庄博士是IBM官方高级培训讲师，于2002年获IBM杰出软件专家奖，于2006年获得“首届中国杰出数据库工程师奖”，获得“2006年IT168技术卓越奖”，是中国建设银行总行外聘资深技术专家，是中信银行，山东农信等公司的资深技术顾问，他拥有OCP，AIX，DB2，HP-UX，MQ，CICS和WebSphere等二十多项国际认证。曾经帮助工农商建招交六大行、上海移动、青岛海尔、云南红塔、江苏电力公司等公司做过问题诊断、性能调优和技术支持，他经常

2、往返于国内大中城市解决数据库技术难题，有着丰富的理论和实践经验。他拥有DB2V5/V6,V7,V8,V9所有DB2认证，是国内拥有DB2认证最多的DBA。简介： 在实际的生产运行环境中，笔者在国内很多客户现场都看到开发人员和系统管理人员遇到很多有关于Informix数据库引起的性能问题，进而被多次问起如何进行Informix数据库性能调优，笔者根据自己在工作中对Informix数据库的使用经验积累写下这篇文概述在实际的生产运行环境中，笔者在国内很多客户现场都看到开发人员和系统管理人员遇到很多有关于Informix数据库引起的性能问题，进而被多次问起如何进行Informix

3、数据库性能调优，笔者根据自己在工作中对Informix数据库的使用经验积累写下这篇文章。性能优化原则包括：·性能规划：深入了解应用与数据库的交互特征，确立良好的设计、开发、测试迭代过程，上线前消除模型上的性能瓶颈。·实例调优：建立性能基准，对比调节数据库、操作系统、存储、网络等的配置，主动监控、消除瓶颈。·SQL调优：书写高效SQL，优化相关数据库对象，充分借助优化器，确定最佳执行计划。性能优化流程1.首先执行下面的初始检查：o获取直接用户的使用反馈，确定性能目标和范围。o获取性能表现好与坏时的操作系统、数据库、应用统计信息。o对数据库做一次全面健康检查。2.根据收集的信

4、息，以及对应用特性的了解，构建性能概念模型，明确性能瓶颈所在，以及导致性能的根本原因。o首先应该排除操作系统、硬件资源造成的瓶颈。o然后针对数据库系统性能进行分析o必要时，还需要检查应用日志，因为系统性能问题也可能由于应用非SQL部分造成瓶颈。3.提出一系列针对的优化措施，并根据它们对性能改善的重要程度排序，然后逐一加以实施。不要一次执行所有的优化措施，必须逐条尝试，逐步对比。1.通过获取直接用户的反馈验证调节是否已经产生预期的效果，否则，需要重新提炼性能概念模型，直到对应用特性了解进一步准确。2.重复上述，直到性能达到目标或由于客观约束无法进一步优化。当从操作系统层面判

5、断系统存在瓶颈并且是数据库引起的，那么可以从下面的流程图来解决图1.性能诊断优化流程典型性能问题案例案例1：数据库应用突然变慢问题特征数据库应用突然变慢，查看系统信息，发现CPU空闲突然很低，IO性能没有明显恶化。处理步骤首先，需要排除操作系统上其他应用程序的问题。通过top(HP)/topas(AIX/Linux)命令可以看到当前占用CPU资源最多的进程，确认是oninit进程。Solaris上默认没有top命令，可以通过/usr/ucb/ps–aux

6、more的方式来查看，该输出是根据CPU占用情况来排序的。数据库进程占用了大量CPU资源时，往往是在对大表在做全表扫描

7、。通过4.1中的办法初步确认问题SQL后，如果是条件查询SQL，如带WHERE条件的SELECT/UPDATE/DELETE，还可以通过得到具体的SQL查询计划来确认是在进行全表扫描。此时需要对比dbschema得到的建表脚本，看是否建立了相应的索引，如果没有合适的索引，应该创建；如果应用没有合理应用已有索引，应该考虑修改应用SQL。如果表上有合适的索引，应用SQL也没有问题，那么就有可能是由于表中数据已经变化较大而长时间未对表收集统计信息，造成数据库引擎选择了错误的查询计划。此时应该对该表收集统计信息后，通常可以收到良好的效果。有时候问题SQL还会是INSERT语句，此

8、时通常需要查看表的建表脚本，看看表上是否有过多的索引，是否该表上有不适当的外键指向另一个大表，也可以通过适当删除表中的记录来实现优化。易出现时机新应用/新模块投入运行案例2：检查点持续时间突然显著增加问题特征数据库应用突然变慢，查看系统信息，发现CPU空闲突然很低，IO性能明显恶化。和问题1的显著不同在于，此时IO恶化现象非常明显。Vmstat显示b(block)很大，有很多等待IO的进程，sar显示wio明显超过平时值。观察数据库日志，发现数据库检查点持续时间(checkpointdurationtime)显著增加，平时在3