[转载]DB2与ORACLE、MYSQL比较2

原文地址：DB2与ORACLE、MYSQL比较2作者：欣颖

4.2 Oracle9i 
Oracle的产品战略是每12到18个月发布一个主要版本。主要发行版本所遵循的命名战略在PC领域中更为常见，它不再采用通常的版本编号方法，而是采用市“姹竞牛ò姹8.1变成8i，以反映Oracle在Internet上的重点）。下一个主要版本是Oracle 9i，这在以前称为Oracle 8.2 。

Oracle 9i不是数据库服务器的版本名称，而是围绕核心服务器的一整套产品套件的家族名称。这些产品包括：

Oracle9i 应用服务器 
Oracle9i DBMS 
Oracle9i 开发者套件 
Oracle9i 的官方发布是在2001年6月在欧洲的Oracle Open World上公布的，此后立即开始供货。因为本报告仅仅是比较DBMS产品，因此只考虑了Oracle9i DBMS。

Oracle9i的核心方法是强调Oracle对Internet和电子商务的专注。它将增强Oracle在关键事务计算领域中的地位。为了确认这一方法，Oracle9i在如下领域提供了新的或增强的功能：

可用性增强 
备份（stand-by）数据库支持，例如初始化实例，故障恢复，主从相互切换，日志应用延迟。

增强了完全的在线重组织和重定义体系，使得更多的管理动作可以在线完成，例如更改表或列的属性，将表移动到一个新的位置，或是分区一个表，动态增减内存的分布（SGA）

面向数据块的表恢复可以在恢复损坏的块的同时可以保持表的其它块在线

LogMiner允许损坏点之后的重作（redo）项被获取和应用

查询历史和SQL等级上的撤销功能使用了多版本读取一致性

扩展性和性能改进 
提高Oracle9i Real Application Clusters的交易吞吐量

减少了每个用户占用的空间，允许更多的用户使用

精心优化的消费者组等级上的自动资源管理

多项性能增强，例如预取，自调节直接I/O，虚拟接口（Virtual Interface, VI）支持，等

安全性增强 
强壮的三层安全性，包括X.509认证，并与LDAP集成

基于标准的公开密钥体系（PKI） 
精心细化的审计功能 
n 增强的用户和安全策略管理

n 数据加密和标签加密（Label Security）

? 开发平台 
n 企业Java引擎（以前是JServer）

n XML类型和XDK 
n SQL增强，例如支持CASE，兼容ANSI的联接，滚动游标

n PL/SQL支持所有的SQL语法

? 管理性 
n DBMS管理撤销（undo）表空间中的回滚段

n 动态内存管理 
n Oracle管理的文件 
n 可恢复运行的语句 
n 一个数据库中存在多种大小的块

n 恢复管理器支持自动管理备份

n 企业管理器（Enterprise Manager）中综合了基于Web的管理工具

? 集成Windows 2000（Active Directory，PKI，OLE DB提供者）

? 商业智能 
n 完整的商业智能平台：集成ETL，OLAP分析和个性化功能

n OLAP Server，Oracle新的OLAP计算引擎

n 支持外部表 
n 核心引擎中的ETL功能

n 核心引擎中的数据挖掘功能（基于Darwin）

? 电子商务增强 
n 支持通过XML和Advanced Queuing在Internet上传输消息

n 与其它专用消息系统的网关，例如MQSeries，Tibco和MSMQ

n 改进的分布式环境 
? 全球化 
n 对UTF-8和UTF-16的Unicode支持

n 新的支持时区的日期时间格式

n Locale Builder可以查看、更改和定义各种与地区相关的数据

? Internet 内容管理

n 存储、管理和搜索各种类型的内容 – 文件，多媒体，电子邮件 …

n 适于Internet应用的内容联合（Content Syndication）

n 适于协作型项目的内容组织

n 支持各个位置、面向移动的内容

5 比较 
比较DBMS一般不是一项简单的任务，这是因为：

? 数据库的功能和复杂度非常广泛，因此深入的比较极端耗时

? 一些特性的价值只能通过实际的经验和基准测试才能判断（即，性能的影响）

? 因为潜在上不同的实现深度以及体系方法与产品哲学的普遍不同，导致从特性上进行比较很困难

? 详尽的特性往往很难直接比较

我们确定了会影响到管理员的日常工作的10个主要领域。对于每个领域，都简要并分别给出两种产品的体系方法和实现特性。

接下来，对两种产品进行直接比较，明确两者的不同点、共同点、优势和劣势。但是，我们不做任何评分。这里描述的一些特性都是新的，需要进行基准测定，并可能需要进一步成熟。我们认为没有一个评分模型能够合理地含盖了这些方面。

这10个领域分别以单独的章节描述，它们的顺序是以从技术DBA的角度来看的重要性进行排列的。重要的是要意识到根据商业实例和角度的不同，这种排列也可能不同。但是正如在第三章（作者）中提到的，本文主要是从DBA技术的角度上进行评价。这也解释了本文中将“集成”（第5.10章）作为最不重要的角度的原因，尽管在众多其它场合，这个角度可能是最重要的。

5.1 性能 
引用IBM Almaden 研究中心的Burce Lindsay的话来说，对于一个有效的数据库系统来说，有三个因素非常关键。它们是性能，性能，和性能。尽管我们认为可靠性、可扩展性、易管理性、使用性和功能一起构成了第二个关键因素，但无疑性能是数据库处理中最为重要的。

性能是对处理数据库请求的效率的衡量。应用软件需要高的数据库性能来确保他们的用户的满意度。数据仓库用户需要高的效率，在可接受的时间内获取他们的复杂的查询的结果。为了在完成数据库维护时能不影响应用或用户，数据库管理员需要高的性能。在本节中，我们不讨论性能的这最后一个方面，它更适合于可用性，我们主要集中于讨论性能，因为它与完成数据请求相关。

DB2 UDB V7.2

DB2性能的核心组成部分是SQL编译器。在接收到SQL并确认它的有效性之后，SQL编译器使用众多先进的技术将接收到的查询转换为可以进行更好优化的等价格式 – 即查询重写工具。在操作合并（Operation Merging）（视图合并，共享聚集以及其它）中，DB2通过合并，减少了对数据进行的操作的数量。操作转移（Operatino Movement）的查询重写功能通过重新定位或消除（消除DISTINCT操作符，通用谓词pushdown，消除相关）操作，来最小化操作的数量。查询重写的最后一个主要的类别是谓词转换（Predicate Translation）。在这些技术中，添加了隐含的谓词，以便更好地考虑联接的策略，并将OR谓词转换为IN。

优化器接收到重写的查询，并使用保存在编目（catalog）中的信息（例如数据分布，约束，索引）和系统资源（例如CPU速度和可用的内存）来计算最优的访问路径。为了评估是否可以使用并行机制，优化器构建分段部分（subsection pieces，SSP）。SSP是一组可以并行执行的操作。SSP的成本（cost）也被用于确定访问路径。DB2的优化器总是以成本为基础的；根据所有可以被用来满足查询的资源来分析候选访问路径，最后选择最为有效的路径。DB2具有众多的扫描方法、索引访问策略、谓词评价选择、联接技术和并行技术。

从最开始，DB2就支持静态SQL。在准备程序时，SQL编译器计算访问路径，并将路径保存下来。对于以后的SQL，将利用预先计算的访问路径执行。通过这种方法消除了动态SQL的开销。也可以通过包缓存（Package cache）特性来消除动态SQL的开销。当重复执行SQL时，访问路径从内存中读出，并执行。CLI，ODBC和JDBC编程模型从本质上说就是动态的。利用DB2，你可以使用Static Profiling将动态的SQL转换为静态的SQL。DB2具有一个特殊的工具，使您可以在应用软件运行时捕捉SQL语句。然后这些语句传送到SQL编译器中。DB2将识别动态的CLI/ODBC/JDBC SQL调用，并找到存储的访问路径。DB2使您可以利用您最喜欢的编程工具轻松编程，同时还您还将拥有静态SQL的性能。

性能的一个很重要的影响因素是并行机制。DB2 可以并行执行所有的SQL。查询内并行机制（Intra-query parallelism）能将单个的查询或数据库操作分解为多个部分，这些部分可以在一个数据库分区内并行执行。分段部分可以自己复制自己，也就是说它们可以执行相同的操作，但却针对不同部分的数据。SSP是SMP并行机制的基础。在EEE环境中，每个分区都具有一部分数据。SSP可以在每个分区上使用，从而可以在MPP并行机制中使用SMP并行机制。

使用复杂SQL语句的数据仓库应用可以利用被称为自动摘要表（automatic summary table）的高级特性。您可以定义一个摘要表，它包含一个大型事实表（fact table）中的多个角度的摘要信息。它可以包括联接、累计和高级分组。优化器就可以识别SQL请求的事实表中的摘要信息，使用摘要表中预先计算的结果。CUBE或ROLLUP的的高级分组功能使得DB2 可以使用1个表，而不是利用多个表来获取多维的摘要信息。摘要表可以与基础数据保持同步，这种同步可以利用REFRESH IMMEDIATE（使得DB2 总是保持摘要表与基”淼耐剑部梢岳肈EFERRED：DB2将根据一个命令优化生成所有的摘要信息。因此一个大型的事实表的12个摘要表的刷新只需要扫描一遍数据。

DB2 拥有全局优化功能。在多个数据库联合查询中（其中涉及了多个数据库系统，例如Oracle），DB2可以根据数据的位置以及涉及的数据库系统优化查询。DB2 将分解查询，并将要完成的工作发送到成本最小的地点，其中要考虑的因素包括CPU的相对速度，通讯成本以及其它系统的功能。DB2可以补充数据源不支持的功能。DB2的全局优化很彻底，使对其它数据库系统的查询将得到更好的优化，以至于通过DB2运行查询时甚至比在其它数据库系统的本地执行查询性能还要好。

Oracle9i 
Oracle9i除了具有基于成本的优化器的标准特性之外，它还精心优化了查询优化器，可以动态收集访问时间以便在实际系统条件下定制成本的计算。此外，增强的优化器还将更多的因素考虑在内，例如CPU成本和网络传输的成本，以尽量提供最快的响应速度。在支持所有现代的方法来增强性能（例如视图合并、谓词推动，子查询解除嵌套，利用实例化视图重写查询）之外，它还能够更多地利用现有的索引。9i引入了新的开发现有索引的途径，例如使用索引跳跃扫描可以略过没有在where条件中但在索引中的列。在这项技术中，以前没有使用的索引现在可以集成到访问路径中。新的索引类型，例如允许跨表索引的位图联合索引（或实例化联合）（位图是根据外键引用的其它表的值创建的），现在可以高性能的执行商业规则。Oracle对动态和永久位图索引的支持使用这种类型的索引。在调整不好的SQL性能时，管理员将特别喜欢历史访问路径的可用性，这些访问路径显示了上一个语句执行时的准确路径，并在SQLTRACE中提供所有的信息。

除了范围和散列分区外（两者联合在一起称作组合分区），Oracle引入了一种新的分区类型，称作列表分区，它允许在一定的范围内（例如A-K）分区数据，或是在不一致的范围内分区（例如TX，NM，AZ，CA）。

在将数据插入到表中时，多表插入（根据定义的标准，一个select语句中的所有的记录将插入到多个表中）由于仅收集数据一次，从而节省了开发人员构建的时间，省去了不必要的开发，并提供整体的性能。

尽管实例化视图（materialized views）可以节省查询的时间，但有时刷新很耗时。在9i中，引入了增量刷新功能，减轻了这种权衡的考虑。为实例化视图添加索引可以进一步加速查询的性能。优化器的查询重写功能使用在实例化视图中存储的结果，加速获”磺肭蟮氖荩苊饬酥馗唇懈吆姆训牧踊蚓酆稀_sina_nbsp_word__

不仅数据收集本身与查询的性能相关，数据仓库领域（CUBE，ROLLUP，RANK和其它）中的分析函数也能帮助降低得到最终结果的时间，它将以前在客户端完成的工作发送到最适于完成这一任务的服务器。

可以将处理密集型的PL/SQL包编译为高性能的本地代码，这也是向着获得高速响应所迈出的一步。

以前，要区分已有记录（需要更新）和新记录（插入时不会出现主键冲突）区别开来，需要进行2步操作，新的MERGE操作符将可以在1步中完成这一功能。

为了稳定执行所选择的计划，Oracle可以存储访问路径，并复用存储的概要来保证稳定的性能。

结论 
性能是数据库的一个属性，两家提供商都严肃地对待这一特性。性能的范围很宽。因为数据库的用途以及对性能的需求相差很大，应避免空洞的结论。在这种情况下，我们在一些场景（scenario）中比较性能的组成部分。

索引对于性能来说至关重要。Oracle拥有多个索引类型 – 索引的选择依据是所期望的处理的类型，如果处理模式发生变化，索引可能成为性能的拖累。DB2 只具有一种索引类型 – 但也可以在查询执行需要时动态创建位图和散列联接（hash-join）索引。

在线、面向事务的应用场合中，SQL必须能快速生成一个结果集（往往相对较小）。索引和缓冲区是主要组成部分。DB2和Oracle都提供了相应技术，表现良好的性能。DB2因为长期支持静态SQL，因此稍稍具有优势。

数据仓库是的性能表现与事务处理系统相反。对于数据仓库或数据中心，复杂的SQL一般会需要扫描、搜索和比较大量的数据，并返回相当巨大的结果集。部分结果集可以自动计算并透明地在DB2（自动摘要表 – 从版本5开始提供）和Oracle（实例化视图 – 在Oracle8i中首次引入）中使用。用于访问数据仓库的查询可以非常复杂。报表工具所生成的查询不能被手工优化。因此优秀性能的关键是基于成本的优化器，因为可能的访问路径很多，而且还要考虑到并行机制。尽管Oracle在它的查询优化器中集成了以成本为基础的模型，在这一方面迈出了一大步，但DB2仍然具有优势。此外，DB2利用Static Profiling也取得的更好的性能，这一自动特性可以将动态SQL转变为静态SQL。

DB2的这一出色的优化器功能，使它在事务型和数据仓库环境中都领先。

5.2 可扩展性 
可扩展性指的是DBMS在不同的硬件平台上，从手持设备到具有TB级数据和数千用户，无需应用重新设计或其它根本上的变化就能提供可相比较的服务的能力。可扩展性也包括在给定环境中根据构建者的业务需要进行扩展的灵活性等级。

DB2 UDB V7.2

DB2 产品系列涵盖了异构平台，从手持设备到大型主机。家族成员并不总是采用相同的代码，以便能够利用各种平台的特性更好地运行。尽管在在特性的提供方面有所差异，但是共同的特性一般相同，确保移植性。IBM的战略是根据客户的优先级实现特性，这些优先级在不同的平台上可能是不同的，从而导致针对每种代码具有不同的实施计划。有关产品家族成员的更为相信的信息，参看“前言：DB2产品系列”一章。

本文所关注的是DB2 UDB for UWO V7.2。在中型平台上，扩展所面临的一个主要问题是能够面对伴随OLTP和电子商务类型应用的数据仓库所提出的挑战。DB2 UDB 企业扩展版（即EEE）被认为是UWO系列中的“扩展型”，主要支持MPP，但也支持SMP和Numa。DB2 UDB企业版（即EE）支持SMP体系。

DB2 UDB EEE在SMP、Numa以及MPP上扩展。对它很多的研究成果被用于增强引擎本身，而且所有的操作或多或少是并行完成的。这并不是仅仅针对select操作，而且所有的insert、update和delete以及命令和实用工具也都是并行完成的。

DB2 UDB EEE在不同硬件体系上的扩展性的关键是数据库在一个非共享的环境中被分解为独立的分区。在一个非共享的群集中，每个分区都具有自己的资源，例如内存，CPU和磁盘。分区可以存在于SMP内，Numa内，以及群集内的服务器中。DB2 UDB EEE为一个群集添加节点的数量限制在1000个节点之内。

数据将通过散列分布到分区内。添加新的分区将通过数据重新分布来处理。分布是通过一个非常有效的散列的方法完成的 – 比关键范围查找方法更为有效。

除了在DB2 UDB EEE内的分区内提供系统之间的并行机制之外，DB2还在每个数据库分区内提供系统内并行机制。

当分区是在两个系统中间建立时，它们被认为是物理分区，通讯和数据传输是通过高速通讯链接（可以是RS/6000高性能交换机，共享内存通讯或基于VI的设备）完成的。当分区是在一个SMP环境中建立时，分区被认为是逻辑分区，通讯和数据传输是通过共享内存完成的。尽管其中涉及到多个DB2实例，但它们被看作是一个单一的数据库，它们共享相同的DB2编目。

为了在OLTP环境中支持大量的用户，DB2提供连接池、本地旁路和负载均衡功能。

DB2能够很好扩展的必要条件（也是关键的研究成果），是查询优化器。它可以逐个分析所有可能的检索方法，以便提供最快的答案。另一个关键领域是大规模的分析：引擎具有内置的、复杂的可以并行执行的SQL OLAP扩展以及通过自动摘要表提供的内置的聚合。

基准，例如TPC-C（OLTP）和TPC-H（Ad-Hoc Query），显示了DB2在扩展性方面的能力。在MPP和NUMA环境中，可以提供95％的扩展比，在SMP环境中，经SUN在64 CPU E1000上的测量，可达到90％的扩展性（详细信息参见www.tpc.org）。 
Oracle9i 
Oracle9i支持从手持设备到超级计算机的扩展。这是因为，根据Oracle的说法，除Oracle Mobile for handhelds之外（因为它的规模要小），所有的产品在所有的操作系统上和所有的家族成员中（从标准版，到企业版，到Real Application Cluster – 以前称为Oracle 并行服务器）都使用相同的基础代码。共同的代码使得Oracle可以在所有平台上提供近乎相同的功能，使得开发者可以将他们的应用缩放到适用于任何OS平台，而且不必进行应用的重新设计。一般说来，在实施一个多平台战略时，您可以使用Oracle的所有特性。采用共同的代码的另一个优势是可以在很短的时间内在最具吸引力的硬件平台上提供产品。

Oracle9i缩减了每个用户所占用的空间，从而可以在相同的硬件上，尤其是咱大型系统中可以提供更令人满意的响应时间。

为了实现这种扩展性，Oracle并行处理的实现与数据的分发无关（有时也称为数据分区分布）。这就意味着所有的实例都通过一个分布式锁管理器来访问所有的数据和同步数据的变化，从而可以无需应用分区即可透明扩展。因为所有的处理器都可以访问在共享磁盘环境中的所有数据，每个处理器都可以用来运行一个查询从进程。此外，对行或语句缓存的共同访问可以加速系统的访问，这是因为可以复用已经被另外一个资源（处理器或磁盘）完成的工作，避免了不必要的浪费资源。在使用来自不同应用分区的数据时，这种方法尤其有效。在DML的读写操作中都可以使用并行机制。此外，Oracle可以并行化DDL语句，例如CREATE TABLE表或CREATE INDEX。

在Oracle9i中，Oracle发布了第二代的“缓存融合（cache fusion）”，即Real Application Cluster（RAC）。RAC的目标是使得DBMS可以在多个节点之间扩展，这一特性往往不能被Oracle共享磁盘体系提供。RAC依赖于与操作系统相关的群件（Cluster Manager和进程间通讯），对于UNIX操纵系统，由OS-vendor提供，对于Windows NT和Windows 2000，由Oracle和Oracle OSD群件提供。群件中节点数量的限制取决于所使用的群件，当前在大多数情况下不超过8个节点。不幸的是，当前只针对Compaq Alpha和Compaq Linux具有一个认证 – 当前还没有公布其它的认证。

在RAC环境中，Oracle随附了共享磁盘体系。这一体系允许访问来自群集中每个节点的数据 – 无需为了优化性能而复制或重新配置数据。RAC的运行带有这一方式所固有的弱点 – 基于磁盘的并行控制 – 通过全局缓存服务和全局队列服务。这些服务放置在每个节点的内存中，可以通过消息进行进程间的通讯。

Oracle建议针对RAC仔细调整数据库和应用设计，以便达到最佳性能。这就意味着在向群集中添加节点的时候建议重新检查设计。

Oracle9i还引入了一个经过改善的动态内存的特性，它允许数据库引擎动态为进行分配内存，无需DBA的干涉。Oracle对行级锁的实现不会将锁升级到其它等级（块，表），配合多版本读取模型，可以支持扩展性，因为与重写无关的读进程将不会阻塞一个写进程。

 青春就应该这样绽放  游戏测试：三国时期谁是你最好的兄弟！！  你不得不信的星座秘密