第1章反对任何猜测-图灵社区.docVIP

反对任何猜测 Alex Gorbachev 在使用Oracle的过程中，我非常喜欢参与用户社区的讨论。我是Oracle技术网络论坛和Oracle–L上的常客，现在已成为用户组会议及其他活动的主要参与者和贡献者。最开始我是为了寻求帮助，但逐渐变成了帮助他人解决问题。我学习Oracle的历程与互联网的蓬勃发展息息相关；通过互联网，无论是寻求帮助还是帮助别人都易如反掌。 互联网增加了社会参与性，但同时也降低了信息的质量。我曾目睹在线讨论变成了争吵，而这些所谓的“战斗者”靠的都是猜测。很少会有人停下来想想到底发生了什么，相反的，他们在想当然的问题上进行着无休止的争吵。 虽然在社区我只关注技术，但本章更通用，强烈建议阅读。我在励志方面的第一次贡献是2007年6月创建了BattleAgainstAnyG，简称BAAG，这正是本章标题的来由。建立BAAG的动机是想在互联网上得到靠猜测的解决方案，这样每当遇到类似的问题时，我就能找到一些有用的东西。因此，将以一些由于猜测引起的问题为本章的开端。 在猜测中摸索 您提问的方式非常重要，拙劣的方式只能得到基于猜测的解决办法。下面的人想从Oracle-L List中寻求快速解决方案： “我在使用Oracle 10g的时候遇到了性能问题，查询表需要很长时间才能返回结果，这是什么原因？…而Oracle 9i只需几秒钟，但在Oracle 10g中却需要几分钟，甚至有时候会崩溃... ” 在被问到这个问题时，很难知道这个人真正遇到的麻烦是什么。对问题没有一个明确的认识，提出的解决办法都是纸上谈兵。以下是一些很快出现的建议： “您可能需要分析系统表。” “在10g中有几个已知的DD查询错误，他们很少涉及到CDEF$表，因此您可以对遇到问题的几个特定视图和CDEF$表进行查询。解决办法是删除有关表的统计信息，然后锁定统计状态（stats）。” “删除Oracle 9i的所有初始化参数。” “采用应用程序供应商的建议（like_optimizer_cost_based_transformation =false，NLS_LENGTH_SEMANTICS =CHAR，_gby_hash_aggregation_enabled =false）。” “禁用子查询unnesting（_UNNEST_SUBQUERY =FALSE）。” “不要以FIRST_ROWS为优化目标。” 对不同人的问题，所有这些回答都可能是绝对有效的解决方案，其中某一个可能是提问者所需要的答案，但我们不知道具体是哪一个。实际上解决方案之间可能会相互矛盾（收集与删除统计信息）。这些建议是基于以往的经验（也许是很久以前），他们可能很符合观察到的症状，比如“查询表需要很长的时间才能返回结果。”但是，所有提出的解决办法有一个通病：缺少分析。即使解决了问题，但没有人分析测试问题，以及验证他们提供的解决方案。事实上，每个人都只是猜测。 为了说明猜测的危害和造成的后果，这里给出另外一个例子，来自OTN论坛： “我的数据库运行在AIX 5.3上，Oracle的版本是.0，迁移后数据库变得非常缓慢。请提供一个解决方案来优化数据库以提高性能。” 因为无知和懒惰，作者只想着寻找一个快速解决方案。现在看看人们是如何回复这个求助帖的。首先，大多数人会要求详细说明哪些地方运行缓慢，以及给出运行环境的一些细节。不过，也有很多有心无力的忠告。 一个善意的忠告是： “升级后，为您的应用模式删除并重新收集数据库管理系统的统计信息。” 在楼主试过上面的建议后，得到的结果是： “还是遇到同样的问题，数据库不断被锁定，dbcache的命中率只有60％。总SGA的大小是20GB，db_cache_size 是13gb。” 下面提出的解决方案会好一点，有点分析问题的迹象了： “通过OEM，您可以查看性能和被时刻监控的SQL状态，然后找到丢失的索引或是优化SQL。” 接下来的建议是从一个Oracle数据库性能优化大师的角度出发的。这一建议给出了11个要点，每点应用之后都可能解决某些特定问题，但也有可能使性能更差。希望修改的11处中有一处能解决问题，这并不是一个好想法。 以下是一个关于异步输入/输出配置的建议。在某些情况下它可能会有效，但在这种情况下它是否有效了？ “在AIX上配置了异步I/O吗？” 楼主确实设置了异步I/O，但它并没有解决问题。 随机提出的解决方案一条接着一条，但讨论已经偏离了原来的问题。楼主到底有没有得到帮助了？我不知道，但看起来应该没有。 为什么我们会猜测？ 靠猜测解决问题是由人类天生的懒惰造成的。在众多的建议中可能存在解决问题的方法，为什么还要去调查问题呢？原因是随机的解决方法虽然能够解决一些通用问题，但同时也有可能提高解决错误问题的几率，这使问题更糟，或者隐