打破oracle数据库树立的种种神话

欢迎进入Oracle社区论坛，与200万技术人员互动交流 >>进入 “神话”这个词指的是Oracle的那些从未是真的或者曾经是真的，但是现在不是真的的行为的基本情况。大多数的Oracle神话的起源都是技更换术产生的结果。 大多数的人都认为今天的许多Oracle神话在他们

欢迎进入Oracle社区论坛，与200万技术人员互动交流 >>进入

　　“神话”这个词指的是Oracle的那些从未是真的或者曾经是真的，但是现在不是真的的行为的基本情况。大多数的Oracle神话的起源都是技更换术产生的结果。

　　大多数的人都认为今天的许多Oracle神话在他们那个年代都是真实的（例如，“磁盘负载平衡对于性能非常重要”），但是当硬件和Oracle软件都改进了之后却发现它们都变成了神话。

　　我们不要忘记Oracle的技术已经超过了15年了，1989年的技术也与今天的技术大相径庭。幸运的是，大多数Oracle的专业人员都充分理解了Oracle神话的不断改变，曾经正确的建议今天是如何变得不再正确，并且成为了具有神话色彩的谎言。

　　古老的Oracle神话

　　有许多古老的Oracle技术在过去都是非常有用的，但是当技术改变的时候，成为了神话。问题的混乱是上千家运行在古老的硬件并且不支持发布的Oracle 软件的Oracle店铺带来的。让我们看一些比较古老的神话。

　　神话：对象在单区域内执行得更好

　　Oracle大学在20世纪90年代的早期教授了compress=y 输出选项会到达改善结果表的性能。今天，本地管理的表空间（LMT）让这个建议不再有效。

　　神话：数据缓冲命中率应该保持在超过90%的概率

　　这个神话也是Oracle在90年代早期宣传的，当时几乎全部的Oracle数据库的I/O成为了瓶颈，并且SGA的尺寸也被32位的服务器技术所限制了。基于Oracle的产品，例如SAP，也都在他们的手册中指出了数据缓冲命中率应该超过90%.Oracle的作者Robert Freeman 提示到：

　　很多的情况都证明了要证明任何事情都是很简单的。假设有一个基本的证据，我可以证明缓冲区命中率毫无意义，或者我可以证明它是世界上最重要的事情了。

　　我知道有一些脚本可以运行在你的数据库上，从而产生任何你想要的数据缓冲命中率。这看上去是不是像一个神话？Oracle看起来并不这么认为，基于比率的建议形成了Oracle 10g自动内存管理工具的基础，还有v$db_cache_advice 的建议。

　　现在也还是存在一些Oracle神话――让我们看一下。

　　现在的Oracle神话

　　现代的Oracle神话在很大程度上都是由于Oracle技术的更换，还有一些Oracle专业人员无法调整以适应改变导致的。

　　神话：索引和表不需要分开

　　这个神话的产生根据Oracle在90年代早期提出的建议，当时有关磁盘的争论是一个主要的话题。直到不久之前，数据库中索引和表的分离才被认为是好的办法，并且作为改善性能的方法被接受。

　　当然，还有一部分原因是因为他们在同一个磁盘上，如果他们不分离的话，会互相冲突。将索引移动到一块独立磁盘上的表空间上，与表相分离，而不仅仅是分隔到独立的表空间上，这通常都会带来性能上的提高。

　　主要的论据，由对单用户系统的10046个追踪所支持，就是在一个查询中访问表和索引的操作在本质上不是异步的，而是线性的过程。然而，然而，即使是在单用户的系统中，也没有考虑到被请求的头移动和与读取索引以及表有关的磁盘延迟。在多用户的环境中，也没有考虑到以上所有的因素，以及多用户访问协同定位的表和索引产生的影响。

　　现在，当合理地放置了RAID之后，许多有关协同定位的问题的争论都没有了或者转移了。然而，将表和索引分割到几个表空间中仍然使得维护更加简单了。分隔到离散的表空间中使得追踪I/O速率和特定对象或者对象类型成为可能，并且允许用户使用多块尺寸。

　　神话：频繁更新的表和索引几乎不需要重新组织

　　这个神话是由于Oracle的专家发表的声明引起的，他宣称Oracle的索引总是保持平衡的，重新构建并不会给索引带来多大的好处。下面我们看一下这个声明，在某种程度上可以帮助我们理解碎片是如何生成的：

　　除非你想陷入无休止的组织、再组织、组织、再组织……的循环中去，你最好找一下原因。

　　在完美的世界中，你只要使用绝对正确的参数构建一次即可，永远都不用再重新构建，我恐怕这种情况永远都不会在现实世界中出现。就像期望只清扫你的房间一次，而这个房间里面装满了吵吵闹闹的10几岁的孩子――这是毫无意义的。

　　今天，能够理解表和索引具有很高频率的并发插入、更新和删除动作是一件好事情，它可以很快地获得次佳的结构并需要重新组织以便位多块扫描操作减少I/O操作（使用Oracle的dbms_redefinition包，更改索引移动/重新构建，更改索引接合，或者甚至是根据可用性需求更改表移动）。索引平衡的概念是分两个叉的，B树总是高度平衡的，它也可以变得稀疏或者向右旋转的，所以就变得更宽或者负载不平衡。

　　神话：多个块尺寸不会改善性能

　　这个神话是不朽的，因为多个块尺寸最初是为了支持可传输的表空间而设计的，同时一些人还不能看到多个块尺寸带来的另一方面很重要的好处。不同的块尺寸带来的最大的好处就是更加有效地利用了受到限制的内存区域（db_cache_size， db_32k_cache_size等）以及能够减少多块扫描读取的逻辑I/O次数的对象智能隔离。

　　今天，Metalink 提示说多个块尺寸参数是Oracle性能调整中最重要的部分了，并且还说Robin Schumacher 等专家们都证明了Oracle的索引可以在较大的块尺寸中构建更加优化的B树结构。还有，重新组织高DML 索引，或者对随机单行读取（唯一索引访问）小行数据的时候使用小的块尺寸，可以减少db_cache_size 的尺寸，并且会因为更多的块适合了缓冲区的大小而减少PIO.

　　例如，一些实验试图用小的、人造的单用户实验来证明这个断言，并且提出多个块尺寸并不能给现实世界的数据库带来任何好处。然而，现实生活中的店铺却报告了一个有关多个块尺寸和索引用的32k块尺寸的截然不同的结果：

　　“我最近比较喜欢关注的问题就是有关32KB索引的问题：我们的客户端（200GB+）从这个简单的变化中看到I/O缩减了20%……”，EMEA的技术服务经理Steve Taylor 说。

　　所以，在这里我们看到了技术的改变是如何将一项15年前本来有效的方式转换为一个“神话”的，并最终得到了一个有关单用户测试脚本的错误结论，同样，由于技术的改变它们还会继续创建新的现代神话。

　　Oracle神话正在形成

　　当Oracle的专业人员观察了不同的数据库行为之后得到了不一致的结论之后，神话还在继续。

　　我们还可以看到Oracle公司大力推荐了一些提出观点的先进人物，但是他们却针对Oracle的性能公开了误导他人的言论，从而制造了新的神话：

　　“一致是不可能的，也不会被任何的优化人员的设置所影响。”他们影响了优化人员处理事物的方式；但是他们却没有影响事物真正进行的方式。

　　当然，改变optimizer_mode， optimizer_index_cost_adj和 optimizer_index_caching 的值可以改变优化人员对于是否应该做一个完全的扫描或者索引访问执行计划的判断，这也会对所有查询的一致性数量产生直接的影响。

　　目前Oracle的专业人员分成两个截然不同的群体，每个群体都会Oracle的性能调整有着完全不同的看法，每个群体都认为对方是造成持续不断的Oracle神话的罪魁祸首。

　　“经验法则”神话――许多Oracle专业人员都相信“经验法则”（ROT）是非常危险的，并且都了解如果经验法则可以被证明是错误的，即使是在单个的人为的测试中，经验法则在科学上来说都不再是正确的，因此也就是毫无用处了。

　　“脚本小子”神话――这个神话说的是运行单用户的SQL*Plus 脚本来“证明”的Oracle的运行方式，在多用户的数据库中几乎总是错误的。