从调优强迫症中恢复过来

发表于:2007-06-22来源:作者:点击数: 标签:
从调优强迫症中恢复过来 性能调优专家Gaja Krishna Vaidyanatha想要帮助那些受到他们称之为“调优强迫症”(CTD)困扰的 数据库 管理员们摆脱痛苦。 Vaidyanatha是DBPerfMan.com咨询公司的所有人,他还是几本 Oracle 书籍的作者,其中有《Oracle性能调优101》

   
  从调优强迫症中恢复过来

  性能调优专家Gaja Krishna Vaidyanatha想要帮助那些受到他们称之为“调优强迫症”(CTD)困扰的数据库管理员们摆脱痛苦。

Vaidyanatha是DBPerfMan.com咨询公司的所有人,他还是几本Oracle书籍的作者,其中有《Oracle性能调优101》创造了许多术语来描述那些数据库管理员们都在使用的一些偶然发现的技术。在下个月奥兰朵召开的IOUG Live! 2005会议演讲中,Vaidyanatha会谈论一些他用来探明性能问题的特殊方法。SearchOracle.com与Vaidyanatha进行了讨论并且提前对他的陈述作个介绍。

  调优强迫症是否意味着数据库管理员可以有效地工作呢?还是不能呢?

  GKV:数据库管理员如果得了调优强迫症的话,就不能有效地工作了。我在2001年里推荐过的一些方法中,我发明了“调优强迫症”这个词。我正在编写我的第一本书,在十一月的一个漆黑的夜晚,我问我自己该如何轻松地表达这个问题——数据库管理员们对性能调整、调整、调整,却看着不想关的事情。现在很多人都使用了这个词语,但是这个意思却实际上发生了变化。我听见人们使用它来表达没有做某些事情的意思。这个表述的全部想法就是帮助人们去战胜它——不仅仅是对Oracle 10g,而且包括所有的Oracle版本。

  有没有一些数据库管理员应该遵循的标准?数据库管理员如何才能知道什么时候性能已经是足够好了?

  GKV:你得定义响应时间目标。一旦响应时间目标达到了,性能就足够好了。这就是问题的症结所在——人们没有定义目标,他们认为性能调优具有只有调优的魔法才具有的一种令人深陷其中的魔力。我对于性能管理的推理就是你已经得到了有关这个问题的精确的证据。这也是驱使你去解决问题的关键——并不紧紧是遵循一大堆的最好的实践方案。你不能物品的干洗名单进行调整。我的底线是:让我们找出问题所在。让我们用数学来驱动我们的所作所为,而不是某些观点或者专家的令人迷惑的技术。

  什么是最常见的性能问题?

  GKV:一个查询运行得太慢或者一个任务运行得太慢。问题是什么导致了这么慢。很多人都没有花时间去找出原因。他们把时间花费在改变事情,你可以更改八件事情,然后问题就消失了。你是解决了它,还是把它伪装过去了?问题还会回来的。如果你没有使用数学,解决方案就是不可重复的,你也不能使用一个一致的方法来解决性能问题。它总是或者成功,或者失败、测试、纠正错误。

  什么是数学的方法?

  GKV:使用底层的追踪方法去找出应用程序将时间花在了哪里。写一个追踪语句并对其进行分析。之后,事情就很简单了。你可以发现你花了78%的时间在I/O上,那么你就会问自己为什么花了那么长时间在这上面。

  你在不同的Oracle版本中看到了不同的问题出现吗?

  GKV:是的。你一定会遇到某些事情在一个版本中运行良好,但是同样的应用程序在升级之后就不工作了,就是因为数据库管理系统发生了变化,优化器计划也改变了。有时候引入一些新的参数。有上百个参数摆弄,这一点通常是好事,但是一旦人们开始管理上百个数据库,人们就不会有时间去摆弄上百个东西了。优化器正在逐渐成熟,取代了调整这些参数的一部分工作。大多数的时间里,在不同的版本之间,问题的存在是因为bug,或者缺乏某项应用程序需要的功能。

  10g中有哪些用来解决特定的性能问题的以前版本中没有的特性?

  GKV:很多个特性,一些处理数据收集,例如10g中的历史收集——自动负载仓库。作为数据收集的一部分,还有另外一个特性,活动会话历史,它是流入AWR的一个输入流。一旦你开始收集数据,你需要某些种类的分析引擎,现在这就是可用的了——它叫做自动数据库诊断监控器。那些都是Oracle的一些新东西,可以帮助你来了解是什么花费了时间,而不是仅仅看着比率。人们总是希望能够找到尚方宝剑并且改变它,但是尚方宝剑实际上是不存在的。都是逻辑的、可重复的、精确的方法——由响应时间驱动。10g为数据库管理员提供了收集和分析的功能,用这些功能数据库管理员可以走上了解核心问题的正确道路。

  什么是最常见的调优误区或者错误的概念?

  GKV:很多人都试图调整数据库环境自身,而不是首先看看应用程序。这就是尚方宝剑中的一部分。数据库是简单的——改变参数并重新启动,你就完成了一次修改。应用程序的调整会花费更多的力气——找出应用程序的组件就是造成问题阻塞的开端,然后是找出问题所在的实际工作,然后是分析它,最后再解决它。整个过程要遵守规则,并且耗费体力,但是不是一个长期的拉锯战。如果你梦想挥舞着魔法棒,你就不会赞成这种方法。你之前曾试过,并且也期望现在能够发生同样的事情,但是参数不一样了,或者它们因为不再有关系而产生作用。查看响应时间的努力背后的基本目标就是让人们看看正确的数据,让人们摒弃查看洗衣单的老方法。用人力去每天看100个数据库是不可能的。即使是你说,“所以我们使用监控软件啊,”那么,如果它抛出100个警告,哪一个才是最重要的?问问自己有没有遇到性能问题,也就是有没有遇到响应时间问题,从这个角度出发再来看看。

  最好的分析就像你去看医生。你说你的右脚疼。如果医生说他需要对你做一个彻底的扫描并且化验血液,你就会想,为什么我们不先看看我的右脚呢?你也许会置疑医生的人品。这就是古老的方法。我会在每次出现问题的时候都做血液测试、CT扫描,还有MRI。我们不需要只是因为脚疼就做彻底的血液化验。这就是我们想要说的。

原文转自:http://www.ltesting.net