SQL调优之“忧”:如何进行SQL调优

日期:2013-4-27作者:Ranma

DBA   SQL调优   DB2   

【TechTarget中国原创】

DBA们应该将自己从“我要对什么调优?”的老路上解放出来,而在指标、配置和成本方面花费一定的时间。研究这些测量指标并做一个对根本原因的分析,而这将花费很多时间和精力。DBA都是聪明人,但很少在操作系统和DBMS系统性能调优上有发言权。

  所以那个曾经需要花费10分钟 CPU时间的查询,在进行过调优之后,现在只需要几秒钟,这又如何呢?我们来考虑一些现实的例子……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

DB2数据库性能诊断与调优>更多

相关推荐

  • DBA也要和领导抢饭碗?

    数据库架构师Ziaul Mannan 认为,DBA有成为高管的潜在可能,而这种潜力在过去往往被忽视,他还将证明DBA技能到领导力的转变是可行的。

  • Oracle备份和恢复简史

    这些年来,Oracle数据库备份和恢复方式已经发生了重大变化,特别是在Recovery Manager(RMAN)功能有了进一步改善之后。

  • 数据库产品巡礼:IBM DB2概览

    IBM DB2关系型数据库管理系统提供了支持多平台系统的关键技术,它具备较高的可用性和良好的性能。

  • Oracle用户组主席:DBA可以更出色

    John Matelski是一位IT管理者,他目前是国际Oracle用户组IOUG的主席,他在努力提高DBA们的领导能力,IOUG成员优先。

技术手册>更多

  • 09年必会的十大SQL Server开发技巧

    本专题为SQL Server开发十大技巧总结。如果你在工作过程中不了解这些开发技巧,可能会大大影响你的工作兴趣。无论你是现在是不是正将日期/时间数据类型转换成为字符数据类型,还是在SQL Server2005中操作DATETIME和SMALLDATETIME,或者用存储程序查找SQL Server表大小或用XQuery检索XML数值等等,本技术专题中的十大技巧都是今年你必须了解、知道的话题。

  • SQL Server索引设计和调优技巧大全

    本技术专题主要围绕sql server设计这个话题展开,侧重介绍了sql server集簇索引的设计、如何创建sql server索引、如何优化索引、索引的能与不能、处理sql server 2000索引碎片技巧以及维护sql server索引以实现查询优化等等。

  • 数据库用户名和密码安全

    今天我们更加需要注意确保数据库安全。数据库安全当然包括数据库的用户名和密码安全问题。本文介绍设置用户名和密码的最佳方法、在授予或撤消用户访问权限时我们应该注意的事项以及我们能采取的真正确保用户名和密码安全的方法。

  • 专家汇总:SQL Server十大最热门技巧

    本文为SQL Server相关方面的技巧。如设计SQL Server集簇索引以提升性能、SQL Server 2005的XML数据类型和VARCHAR(MAX)、如何创建与DB2链接的SQL Server服务器、SQL Server数据库设计灾难、用存储过程查询SQL Server表和其它对象大小等等大多数人关注的话题。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • SOA
  • 云计算
  • 商务智能
【TechTarget中国原创】

DBA们应该将自己从“我要对什么调优?”的老路上解放出来,而在指标、配置和成本方面花费一定的时间。研究这些测量指标并做一个对根本原因的分析,而这将花费很多时间和精力。DBA都是聪明人,但很少在操作系统和DBMS系统性能调优上有发言权。

  所以那个曾经需要花费10分钟 CPU时间的查询,在进行过调优之后,现在只需要几秒钟,这又如何呢?我们来考虑一些现实的例子。

  假设DB2的配置参数SRTPOOL(排序池大小)设置太低。可能的结果就是SQL语句在请求排序 (即通过GROUP BY)时会因为排序池空间不足而出错。所以DBA告诉开发人员应该将ORDER BY从他们的查询中移除,然而自己对返回的结果进行排序来对查询进行“调优”。这算是调优么?

  还有DBA发现一个查询要运行长达两小时,并且会消耗15分钟的CPU时间。接着DBA就对查询做了调优,现在它在10分钟的运行时间里占用10分钟的CUP时间。这么做有意义吗?那个查询原来只消耗12.5%的CPU,但是现在却要消耗100%的CPU。在任何时候只要一运行这个查询,CPU占用率就会飙升,从而导致损失。这又算是什么调优呢?

  这里有另外一个例子。DBA确信在一个特定表的字段上添加索引会对某条性能不佳的SQL语句提速。所以就添加了索引。

  问题是:为什么不早点构建这个索引?

  难道是之前的数据库设计流程有误?如果是这样,那么DBA们可能就需要在数据建模上花费更多的时间了。

  难道是新应用程序的业务逻辑太过模糊,以至于SQL无法在早期阶段获知这种情况?这便指出了应用程序设计流程上存在的问题。

  鉴于SQL性能分析是一项为人所熟知的流程,那么开发人员为什么不自己进行SQL调优呢?难道他们缺乏相应工具和知识吗?

  关键在于DBA必须调查造成性能不佳的根本原因,而非简单的定位单条SQL语句。否则,他们将会在以后的职业生涯里疲于应付SQL调优。对于DBA来说,将时间精力花费在SQL调优上是否值得呢?通过优化应用程序设计和数据库设计流程,让80%的索引从一开始就得以确定,这种方法岂不是更好?

  有几个方法可供DBA用来做为简单SQL调优:

    如何减少CUP使用

    如果症状表现为大量的CPU资源请求,那么原因是什么?在SQL语句层面可能包括:

  进行SQL语句调优将解决CPU容量问题,在正确得出类似结论之前,DBA必须首先收集相关数据。甚至还需要做更多的工作来证明通过给DB2子系统添加CPU容量可以增加吞吐量。

  我并不是说SQL调优总是在浪费时间,如果你不衡量在这一过程中资源耗费和节省的状况,你又怎么能知道这样做值不值得呢?作为一个管理者,我更倾向于DBA能将它们宝贵的时间投入到灾难恢复准备,数据可用性和安全性等这些高优先级的问题中去。

  开发人员编写性能不佳的SQL代码

  这可以说是一个普遍的事实存在。DBA可以给开发人员提供最佳实践以及SQL实现标准,让他们知道好的SQL开发人员应该怎样写代码,然后提供SQL代码示例。

  另一个常被忽视的问题是: IT部门有对用户的资源成本负责吗?也就是说,他们有对CPU和磁盘存储的使用进行支付吗?对于事务/应用程序有没有订立服务水平协议以及配套的处罚措施呢?如果不存在任何的这样的机制,那么程序开发人员就会没有动力去编写性能优良的代码。

  那么我到底要不要做SQL调优?

  要摆脱疲于应付SQL调优的状态就要做根本原因分析。为什么不良SQL总是不断汹涌而来?难道是开发人员写代码太糟糕?如果是这样,也许解决之道就是培训,或是让他们自己进行调优。工具是否会自动生成性能不佳的SQL呢?答案可能会比较复杂,因为它会涉及到工具的升级,索引管理,RunStats管理,甚至是DB2子系统调优等诸多方面。

  最后,DB2子系统,数据共享以及操作系统配置是最常影响应用程序和SQL性能的。如果你花费大量时间在SQL查询调优上,也仅仅是发现系统参数值造成这样的结果,难道你不会觉得烦躁吗?难道你就真的希望每每配置发生改变就要一遍又一遍的对单条不良SQL语句进行调优吗?

  总结

  如果DBA花费时间去做SQL调优而不是修复导致问题的根本原因,那么支持人员和IT部门要如何成长?你又如何才能有机会变得积极主动呢?企业则会越来越依赖于各种问题专家。

  如果你花费职业生涯来做SQL调优,你可能会成为这方面的专家。这意味着类似子系统配置,新功能实施,协调灾难恢复等工作就会被交给其他人去做。这对于DBA职业的发展其实是很不利的。