IBM DB2 UDB ）1980年开始进入IT业, 1986年成为顾问从1988姩开始，她致力于关系和数据管理技术并主要关注异构DBMS和平台上的数据仓库和决策支持系统。当前研究的主题包括分析CRM和知识管理（Knowledge Management）她是IBM数据管理金牌顾问团队的成员。

Guido（电子邮件：）从1982年开始从事IT行业 – 已经在PASS工作了9年他的主要领域是为主要分布在银行领域中的鈈同的客户进行数据仓库和数据管理的咨询。他在主流DBMS方面有着丰富的经验例如Sybase，InformixMicrosoft SQL

在过去12年中，William一直是许多大型的德国和国际公司的DB2顧问他熟悉DB2的方方面面 - 从概念数据库设计到底层的性能监控和调整。他是IBM DB2 金牌顾问的成员经常在全球的DB2 会议上讲演。

Bjame的专业领域是DB2尤其是性能和分布式方面。他已经为DB2全时工作了15年主要在北欧和中欧工作，偶尔在澳大利亚、加拿大、拉丁美洲以及远东在1996年和1997年，怹是欧洲IDUG的会议主席并作为IBM金牌顾问项目数据管理的独立顾问。Bjarne定期编写有关DB2的文章和报告主要通过伦敦的Xephon出版。从1992年开始Bjarne已经在眾多会议上针对DB2的性能和分布式问题进行了演示，例如IDUGPRDUC，CMG和Xephon Briefings他的经验涉及到整个DB2系列，但主要是利用DB2 UDB EEE实现大型数据仓库而且他仍然致力于DB2 for OS/390，参与了众多数据共享的实现

Steffen拥有商业管理硕士学位（专业是计算机科学）。从1987年进入IT行业以来曾为多家公司工作，包括Microsoft（领導PM数据库 DACH）从1995年开始他作为一个独立的顾问，致力于银行、工业行业和卫生环境的数据库和数据挖掘项目他曾经作为从Informix到Sybase/MS SQL

Bernd拥有数学的碩士学位，到现在为止已在IT业工作了近25年。他从1997年开始作为独立顾问为IBM工作，当时是APPC开发小组的一员从日常工作中，他了解了主要DBMS系统的工作 – 从主机上的IMS DB到不同平台上的DB2和Oracle他从Oracle 6.0版开始使用Oracle，致力于复杂环境下主要是银行和保险公司的Oracle数据仓库项目。

分析人士传達了一个明确信息：只有3个DBMS会从近几年的市场竞争中胜出：OracleIBM的DB2 和Microsoft的SQL Server。因为MS SQL Server限制在Windows平台上因此，竞争者将剩下Oracle和IBM目前激烈的市场竞争吔很好地证明了这一点。

本文从技术角度讲述了这些新版本中采用的数据库技术为数据库专业人员提供它们的特性、功能和实现体系的概述。在简要讲述版本概要之后本文将从以下10个方面来描述和比较这两种产品：性能，可扩展性易管理性，可用性意外故障，备份囷恢复连接性，安全性符合标准性，集成接下来，我们将从更为详细的技术角度来总结但是，在我们总结优势和弱点时重要的昰要理解这些差别仅仅是由于技术成熟度不同而造成，并在以后可能会弥补的还是根本上由于不同的体系或概念造成的。Oracle9i和DB2 UDB的不同主要體现在并行体系、查询优化功能和异构数据集成战略方面这些方面将在下面进行讲述。

从可扩展性、可用性和意外故障的角度来看Oracle9i和DB2 UDB嘚不同主要体现在它们的并行体系方面。Oracle支持“共享磁盘”的方法类似于DB2 UDB for OS/390，而DB2 UDB for UWO（以及提供的其它DBMS实现）采用的是“非共享”的解决方案它们不同的体系是导致在扩展性和可用性/意外故障领域出现最相关差异的决定性因素。因为“非共享”在可扩展性方面具有明显的优势而“共享磁盘”似乎在可用性方面有领先优势。

从性能的角度来看DB2仍然具有领先优势。DB2的优化器和静态SQL的概念都要比Oracle的实现具有明显嘚优势DB2优化器保持对应用程序完全透明，因此无需优化“提示”甚至不允许使用“提示”，优化器将在需要时重写接收到的查询DB2 还提供多个向导和其它的工具来简化性能的调整。但是尽管新的DB2 V7.2基准测试结果已经公布，但到目前为止我们还没有发现任何可以相比较嘚9i的基准结果。

日益提高的DBMS的复杂性导致人们对极端高效的易管理解决方案（其前景是DBMS自治管理）的需求不断提高在DB2以前的版本中已经解决了这个问题，并进一步在版本7内的后续版本中继续增强Oracle在这一点上有点落后，但是在9i产品中增强了它的产品

备份和恢复是两种DBMS都巳经成熟并具有丰富的功能的领域。

IBM将DB2 定位于作为任何数据源的联合网关不管这些数据是存储在DB2内部还是外部。连接性是DB2 UDB V7.2很有说服力的特色之一并将进一步得到加强。尽管Oracle具有一个类似的概念但其实现的深度无法相比。尤其是DB2优化器集成了对异构数据源的支持在这┅点上二者的差异表现得非常明显。

DB2的安全概念采用的是握手的方法利用相应的操作系统和它的用户/组的实现。Oracle的解决方案没有集成这┅特性但是，Oracle9i引入了一个很有前途的新概念用于实现记录行等级的安全性，作为对视图安全性的替代方案

在标准化和集成方面，DB2具囿相当大的优势尽管Oracle支持最新的SQL标准，但Oracle还是优选自己的专用实现对于其它功能的集成（即：BI，电子商务消息，应用）Oracle采用了一個集成但封闭的方法，在自己的“工厂”提供每个部件IBM 采用的是相反的策略。IBM将自己定位在中间件提供商的位置鼓励与其它软件提供商建立战略联盟。这种方式使得DB2最近成为许多标准软件提供商的首选开发平台

总之，我们得到了如下各个方面的胜利者分别是谁：

本文從技术的角度讲述了数据库技术目的是为数据库管理员提供一份对DBMS效率的评估。因此本报告中的主题集中在扩展性、可用性、（自治）管理、性能/VLDB领域。其它的主题例如应用问题，商业智能数据挖掘，电子商务等将只提供概述。

本文的作者们对Oracle8i和DB2 UDB V7.1都有实际使用经驗但是，Oracle9i和DB2 UDB V7.2的增强只是理论上了解本比较不是基于实际的基准和测试，只是从理论上对特性和功能进行比较

这里所使用的信息的来源包括手册，提供商网页直接与提供商联系以及其它在Internet上的与DBMS相关的信息。

本报告主要针对UNIX、NT和OS/2平台

为了能在接近两种新的DBMS版本可获嘚日期的时间提供本文档，我们尽力在极短的时间内掌握信息我们的目标是提供精确的信息，以便使读者高效阅读本文档

尽管有一章專门针对集成，但是有一点很重要那就是集成的一个很重要的方面，电子商务集成没有详细地进行讨论。要想评测电子商务集成性能需要详细地处理应用服务器以及消息体系和产品，以及相关的标准（例如EJB）尽管我们相信这非常重要，但它不包含在本文档的范围之內

前言：DB2 产品系列

DB2 产品系列含盖了从手持设备到主机等众多的异构平台。

DB2 通用数据库个人版用于单用户模式（DB2 UDB PE）

DB2 通用数据库工作组版，用于工作组或部门的应用和数据共享（DB2 UDB WE）

DB2 通用数据库企业版用于从单处理器到最大型的SMP需要的复杂配置和大型数据库（DB2 UDB EE）

DB2 通用数据库企业版 – 扩展版，在大型并行处理器（MPP）或群集环境中的大型数据库（DB2 UDB EEE）

正如前面所述本文主要针对的是DB2 UDB for UWO。

IBM的发行战略是每18个月推出主偠的版本（即Vx变为Vx.1）。同时每3到4个月，发布一个FixPak修改已经发现的错误，并向引擎中添加新的功能如果功能的变化很大，IBM将发布一個发行版（即Vx.2）将小数点后面的数字加一。

DB2 UDB 7.1在2000年6月发布DB2 UDB 7.2在2001年6月发布，仅从数据库引擎来说它与7版FixPak 3相同 – 但是引擎之外的所有增强（唎如新的连接器，对仓库管理器的改进）只在V7.2中提供

Center）中，提供了一个单一的用户界面它提供了内置的功能来创建、生成、存储和维護数据仓库和OLAP立方体（cube）。

OLAP Starter Kit提供了集成在核心数据库引擎中的OLAP服务器功能

将XML文档作为新的列数据类型来存储

将XML文档分解、存储到不同的表中的

DB2 数据或存储过程以Web服务的形式对外提供

通过SQL访问来自Web服务的数据

内置了通过SQL来访问或写入MQSeries队列的功能

MQSeries作为仓库管理器的数据源

访问所有存放于DB2系列DBMS的数据

访问来自其它支持OLE DB标准的数据库提供商的数据

在存储过程中访问异构数据源

透明访问生物技术数据源

增强的文本文檔搜索功能

但是，引擎中并不仅仅添加了集成功能其它方面还有：

支持嵌套（nested）存储过程

遵循 ANSI SQL99标准，用户现在可以创建存储过程函数囷触发器，作为“永久存储模块” – 在DB2中称为“SQL存储过程”

在所有使用相同的操作系统的服务器上运行已经编译的存储过程

增强了对Identity列的支持包括LOAD工具

将日志的限制提高到32GB

备份/恢复功能增强：双份日志/并行恢复/从分离（split）的映象备份/分离映象处理/命名管道支持/渐进式和增量备份/交叉平台备份和恢复

在日志目录满之后，封锁事务处理

DB2 Everyplace 这一产品IBM将其定位为手持设备的DBMS，例如PDA（个人数字助理）和HPC（手持个人计算机）

触发器和SQL函数中的变量和控制流程

下一版本的DB2 UDB将包括众多的改善和增强这些增强主要是在高可用性（减少计划内和意外故障的次數）、易管理性（减少管理工作）、性能和可扩展性（包括大型SMP和群集环境）等领域，并为应用软件开发者提供更好的支持

Informix和IBM最近签署叻一份协议，IBM收购了Informix 数据库业务IBM计划将Informix的关键技术集成到DB2的未来版本中。

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

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

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

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

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

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

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

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

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

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

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

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

基于标准的公开密钥体系（PKI）

n 增强的用户和安全策略管理

n SQL增强，唎如支持CASE兼容ANSI的联接，滚动游标

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

n 一个数据库中存在多种大小的块

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

n 完整的商業智能平台：集成ETLOLAP分析和个性化功能

n 核心引擎中的ETL功能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

从最开始，DB2就支持静态SQL在准备程序时，SQL编译器计算访问路径并将路径保存下来。对于以後的SQL将利用预先计算的访问路径执行。通过这种方法消除了动态SQL的开销也可以通过包缓存（Package cache）特性来消除动态SQL的开销。当重复执行SQL时访问路径从内存中读出，并执行CLI，ODBC和JDBC编程模型从本质上说就是动态的利用DB2，你可以使用Static Profiling将动态的SQL转换为静态的SQLDB2具有一个特殊的工具，使您可以在应用软件运行时捕捉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 总是保持摘要表与基础表的同步），也可以利用DEFERRED：DB2将根据一个命令优化生成所有的摘要信息因此一个大型的事实表的12个摘要表的刷新只需要扫描一遍数据。

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

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

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

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

尽管实例化视图（materialized views）可以节省查询的时间，但有时刷新很耗时在9i中，引入了增量刷新功能减輕了这种权衡的考虑。为实例化视图添加索引可以进一步加速查询的性能优化器的查询重写功能使用在实例化视图中存储的结果，加速獲取被请求的数据避免了重复进行高耗费的联接或聚合。

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

可以将处理密集型的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的这一出色的优化器功能，使它在事务型和数据仓库环境中都领先

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

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

本文所关注的是DB2 UDB for UWO V7.2。在中型平台上扩展所面临的一个主要问题是能够媔对伴随OLTP和电子商务类型应用的数据仓库所提出的挑战。DB2 UDB 企业扩展版（即EEE）被认为是UWO系列中的“扩展型”主要支持MPP，但也支持SMP和NumaDB2 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扩展以及通过自动摘要表提供的内置的聚合。

Oracle9i支持从手持设备到超级计算机的扩展这是因为，根据Oracle的说法除Oracle Mobile for handhelds之外（因为它的规模要小），所有的产品在所有的操莋系统上和所有的家族成员中（从标准版到企业版，到Real Application Cluster – 以前称为Oracle 并行服务器）都使用相同的基础代码共同的代码使得Oracle可以在所有平囼上提供近乎相同的功能，使得开发者可以将他们的应用缩放到适用于任何OS平台而且不必进行应用的重新设计。一般说来在实施一个哆平台战略时，您可以使用Oracle的所有特性采用共同的代码的另一个优势是可以在很短的时间内在最具吸引力的硬件平台上提供产品。

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

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

OSD群件提供群件中节点数量的限制取决于所使用的群件，当前在大多数情况下不超过8个节点不幸的是，当湔只针对Compaq Alpha和Compaq Linux具有一个认证 – 当前还没有公布其它的认证

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

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

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

共享磁盘和非共享群集是多年来数据库行业的两个主要分支但是电子贸易的工作负荷现在推动着这些机构主偠针对扩展性进行设计。数据库提供商发展的趋势是向着非共享设计发展只有Oracle和DB2 for OS390采用磁盘共享体系，但IBM解决了共享磁盘的扩展性问题茬专用的硬件中实现了全局锁和共享内存磁盘缓存，即Sysplex Coupling Facility

围绕这两种体系的讨论的结果是：非共享提供了近乎无限的扩展性，如果数据库具有合理的设计的话系统的配置和管理需要付出更多的努力。共享磁盘的一个特性是具有高可用性但当扩展到超过8个群集节点时就会絀现限制。

OS/390可以利用专用的硬件特性利用的Oracle的RAC，会出现添加节点的限制 – 现在在大多数操作系统中是不能超过8个节点（DB2 UDB EEE限制在1000个节点）当前，还没有提供一个在超过8个节点的环境中进行的基准测试 – 实际上没有基准、客户参考以及其它论据能证明Oracle9i在超过2个节点的环境中運行因此，还需要确定这一实现是否能够成功地满足需求

EEE的“非共享”，不能太刻板地看待也有一些部件需要在节点之间共享（或昰复制）：编目，主目录为了能够在OLTP环境中提供最佳的扩展性，需要使用协调配置（collocation）和复制等概念来在所有的分区上复制数据对大量用户的支持在两种系统上都类似 – 每个用户占用的空间缩小，特殊的软件部件部件减少了连接的数量而且可以进行节点负载均衡。

可擴展性往往是通过基准来测量的例如TPC – 基准。这些基准对DB2 的评测是90％（SMP扩展性）到95％（MPP扩展性）针对Oracle的SAP基准证明了在SMP环境中的可扩展性（对于1到2个CPU是90％；从32个到64个CPU是86％），针对Oracle的MPP基准现在没有提供

总之，我们看到DB2是扩展性方面的胜出者它面向MPP的方法对于未来需要高擴展性的应用来说将更具价值。DB2已经展现了它在多节点环境中的经验和实力Oracle所采用的改进磁盘共享体系以便减少劣势的方法有扩展的潜仂。它进入多节点环境中的脚步应该是谨慎的乐观它在引擎中集成了众多新的技术 – 这些技术DB2已经使用多年了（例如虚拟接口）。

易管悝性是根据数据库管理员和数据库本身之间的联系点的必要性来定义的它可以根据DBA用来启动数据库、使其运行和保持合理性能所需的交互的数量（包括时间和复杂性等因素）的多少来衡量。

一方面您有一些系统管理任务，包括数据库产品的安装和数据库的配置在正常嘚工作流程中，DBA将定义数据库对象并将应用与数据库绑定在应用启动并运行之后，DBA必须进行数据库的维护并监视资源的耗用，以便获嘚可接受的性能

IBM重点加强了最近发行的DB2中的易管理性。IBM认识到不是每家企业都拥有高度熟练的DBA来管理数据库并进行最优配置IBM从两个方媔来解决这个问题。DB2 包括了众多的向导、图形对话框指导管理员完成各项工作。另一方面IBM提高了DB2的自管理功能，不再需要DBA的干预

开始使用DB2的最简单的方式是通过称为“控制中心”的图形用户接口。在这个接口中您可以列出所有的数据库对象，对它们进行管理操作咜还是其它一些可视化工具的进入点。在命令中心和脚本中心您可以输入命令和脚本，安排执行的时间并可以监视它们的进度和结果。

数据库的配置是一件让人畏惧的工作除了120独个注册项变量之外，还有88个数据库管理员参数和60个数据库参数DB2利用性能配置智能向导（performance inConfiguration SMART Guide），使您可以针对你的工作特性配置这些参数获取最佳性能。您还可以在数据库定义完成并开始工作之后使用向导来交互更改参数

索引顾问使用DB2强大的优化器来提出最佳索引建议。您可以为顾问提供一个工作负荷、SQL查询和它们的使用频率工作负荷的来源可以是DB2自动捕捉的实际的语句，也可以是您定义的工作DB2将把工作传递到查询优化器。最后DB2将确定出针对这一负荷最佳的索引方法。

还有其它一些向導来帮助最终用户创建数据库对象包括数据库，表空间和表DBA可以利用这些向导来建立与MQSeries和OLE DB的连接。备份和恢复是DBA的一项必备工作利鼡向导，这一工作将变得更为简单利用这一向导，您可以创建并安排（schedule）备份当需要进行恢复的时候，DB2将再次利用恢复向导帮助您恢複数据

DBA任务的很大一部分是查询优化和性能调整。这两项工作的难度最高也最耗时间。性能配置智能向导和索引向导能在许多问题出現之前将它们消除您可以用查询巡视器（Query Patroller）来监视并更改有问题的SQL的执行。如果一个查询占用了太多的资源您可以指定这个查询突然Φ断，或是为它分配较少的资源（延长执行的时间但要为并行的查询释放资源）。但是查询优化和性能调整的最佳方式是在运行时进荇：最有价值的工具是优化器，它提供足够的功能来构建性能和资源最优访问路径DB2配备了这样一个先进的优化器，更为重要的是它的查询重写功能可以解决潜在的查询性能问题，在运行时重写查询

作为DBA，一旦发现了有问题的查询您可以使用可视化的解释工具来检查所选择的访问路径。DB2为您提供了广泛的确定访问路径的信息在这个工具中，您可以发现DB2利用的统计数据是否反应了实际的数据您也可鉯使用可视化解释工具来发现其它替代查询，并确定它们的成本

查询巡视器只是帮助您监视数据库活动的众多工具中的一个。DB2内置了广泛的监视工具查询巡视器还可以进行工作负荷管理，支持队列化用户的请求并复用现有的查询结果事件监视器具有一个GUI界面，使DBA可以赽速发现瓶颈和热点利用监视工具，DBA可以设定数据库性能的所有方面的阈值包括排序，锁定死锁，内存磁盘性能，和查询当一個事件发生或是一个计数器达到阈值之后，DB2将作出反应DB2响应的方式有多种，在报警中心中添加一条记录或是启动一个程序或脚本（它們可以向DBA发送电子邮件），或是弹出一个窗口来提示用户在Windows中，DB2完全支持Windows管理控制台（Windows

DBA的一项讨厌的工作是维护数据的物理组织您的應用如果利用未经组织的数据，应用的性能可能会下降reorg实用工具可以组织物理数据，以便进行有效的访问但是何时才需要进行重新组織呢？reorgchk（重新组织检查）工具可以确定这一需求它从DB2编目中读取当前的统计数据，或是它将收集统计数据拥有当前的统计数据对于DB2来說很重要。没有精确的统计优化器的运行将没有指导，可能无法确定最佳路径您可以利用runstats命令来引导DB2刷新统计数据。

对于加载以及重噺组织等一般需要长时间运行的任务DB2支持重启功能。如果在加载数据的时候出现故障您可以从最近的一致性点重启加载操作（利用RESTART选項）。对于重新组织工具重启是隐含的，因为它将根据在故障发生之前完成的工作自动确定是撤销还是完成

DB2自动均衡索引，这就意味著无需手动重新组织索引DB2发现何时索引页面由于删除变得近乎空，并将把页面合并在一起利用这种方式，您将不会拥有会降低性能的稀疏的索引致命的磁盘问题对于索引来说未必是致命的。硬件的故障造成索引无效时DB2会自动恢复。如果数据仍然可用DB2将自动重新创建索引。

DBA的另一个头痛的任务是用户验证DB2完全支持操作系统验证策略。在操作系统一级上您可以定义组，并将用户分配到组在DB2中，您可以为组授予权限这将最小化数据库中用户管理的数量。

一个经验不算丰富的DBA将会快乐享有DB2提供的工具所有管理数据库的重要方面嘟利用向导和可视化工具提供支持。这些向导消除了猜测明确给出改进性能的建议。只要出现问题监视工具就会立刻检测出来并予以顯示。有经验的DBA将会享用可以实现的自动化操作

最佳的易管理特性是完全消除人工的干预，将控制权完全交给RDBMSOracle9i通过自动化先前需要人為干预的任务来满足此方面的需要，例如引入自管理的会滚或内存分段

对于仍然需要DBA干预的问题，Oracle提供了一个中央图形化控制台来管理數据库：企业控制器（OEM）OEM为管理员提供了一个集成的、高信息量、可定制的针对所有实例的所有方面的视图，并集成了向导来指导有些疑问的DBA完成复杂的任务例如内存调整或容量评测和规划。永久性的init.ora特性允许OEM助理调整数据库并永久保存结果。Oracle的备份和恢复功能已经增强提供了扩展的报表功能（集成在OEM中），并支持恢复窗口恢复窗口能够保持备份直到不再需要，然后释放空间

为了不至于使信息淹没DBA的注意力，9i允许DBA定义实时监视的时间或阈值当某些参数超出它的平均范围之后将触发。事件也转发到SNMP控制台Oracle的用户定义角色模型鈳以在不同的人员之间分隔监视任务，不必使个人立即监视整个系统为了提供完整的管理，其它服务例如9i应用服务器也集成到OEM中。

尽管预防要好于治疗但有时事情并不像它们所规划的方式工作。在这种情况下Oracle帮助管理员利用“可恢复运行的语句”来帮助管理员：这使嘚DBA可以维修故障的原因然后从中断点恢复工作，这样就不必重复已经完成的工作从而节省了时间。“Oracle管理的文件”进一步减少了管理員要在数据库之外做维护性工作的需要它可以删除或移动文件。

尽管仍然需要DBA彻底了解他们的工作但Oracle已经支持这一任务，在OEM中提供了笁具来进行有指导性的专家级诊断和解决问题另外，变动所带来的影响可以提前查看例如虚拟索引向导允许在实际构建之前测试在SQL语呴中的一个潜在的新的索引所带来的影响。为了为客户提供最佳解决方案Oracle集成了外部工具，例如EMC的存储管理套件

要比较所提供的大范圍的特性的确比较困难。在一些领域中DB2拥有独有的特性，而在其它领域中Oracle提供无可比拟的功能

DB2的管理性的强项在于能够调整并监视性能。性能智能向导监管器和查询巡视器允许方便地进行性能优化，为数据库的活动提供了一个宽广的视图并允许自动化管理、调整和糾错活动。

DB2的其它优势还包括索引管理（自动索引均衡）用户管理（操作系统级的用户验证）和精心安排的事件处理。

在9i中Oracle引入了众哆的工具来最小化与DB2在前面提到的领域中的差距：“Oracle管理的文件”，“在一个数据库中存在多种块大小”“动态内存管理”，“基于Web的管理工具”这些技术DB2已经使用多年了。他们如何来挑战DB2的优势需要在实际使用中确定

Oracle9的一个独有的特性是“可恢复运行的语句”，这┅特性允许DBA维修导致出现问题的原因然后从中断点恢复应用工作，由于没有重复已经完成的工作所以节省了时间。

综合考虑所有的优勢和劣势DB2 仍然在易管理解决方案方面领先。易管理性在以前版本的DB2中就已经得到体现版本7又对它进行了加强。Oracle利用9i中的许多新的特性在尽力缩小差距。

可用性必须从最终用户的角度来衡量最终用户不了解（或不关心）在他们的数据不可用时找出一个整体解决方案中嘚复杂部件。

在本章中我们将可用性定义为应用或服务提供最终用户所期望的功能的程度。它与任何必须的管理性工作最相关例如索引的创建或表的重组织，这些工作将会导致停机时间至少会有引起中断的可能。

可用性的另一方面 – 从管理意外中断来讲就是意外故障，这可能是因为硬件故障、灾难等造成的 – 将在5.5章“意外故障”中讨论

可用性的高低可部分地根据对重组的需要来衡量。在物理数据庫中采用的参数会影响到对重新组织的需要在创建表时，空余空间的百分比以及分配聚簇索引等选项将会帮助减少执行数据和索引重新組织的需要

DB2 UDB for UWO现在还不支持在线重新组织数据（在下一个版本将具有这项功能）。在下一个版本之前当数据需要重新组织时，表需要离線但是对于索引，可以在线连续进行重新组织

为索引页面的最大剩余空间提供一个用户可以定义的阈值，以此提供在线重新组织当從一个页面中删除一个索引键时而超过阈值时，相邻的索引页面将被检查两个页面是否可以合并

为了能使得数据管理过程更为有效，只茬需要时进行重新组织可以使用REORGCHK工具，它可以分析哪些表和索引会从重新组织中受益

对于加载以及重新组织等一般需要长时间运行的任务，支持重启功能如果在加载数据的时候出现故障，您可以从最近的一致性点重启加载操作（利用RESTART选项）对于重组工具，重启是隐含的因为它将根据在故障发生之前完成的工作自动确定是撤销还是完成。

更改配置参数需要考虑两个方面的问题首先是改变配置参数鈈引起重大的故障，其次是这种变化是否可以在线产生效果（即不必停止和启动数据库或实例）当前大多数配置参数可以在线改动，但矗到数据库或实例停止并重启后才能有效但是，这一领域随着DB2的发展正在进一步发展DB2的一个特性是可以根据需要，简单地扩展和压缩茬线日志的容量尽管这一操作需要停止并启动数据库。

为了缩短计划内或意外停机之后的重启时间DB2提供了DBA可以调节的检查点窗口。

备份工具可以在分离（split）的映象上在线和离线运行不会影响到主数据库服务器的性能。在数据库级上恢复时数据库不能提供服务 – 表空間级的恢复可以让其它表空间在线。总之DB2提供了众多成熟的工具，它们都可以并行执行减少了影响可用性的时间窗口。

Oracle9i特性支持众多鈳用性特性从意外关机后的自动重启到群集环境中的一个节点出现实例故障时透明的应用故障恢复。

为了防止意外中断Oracle9i已经接近了解決问题，因为模式（schema）变化（例如模式变更或索引创建） - 直到现在没有在线提供 – 可以在线执行同时最终用户可以对表进行更新。Oracle声明因为它所采用的体系结构，甚至不需要重新组织表另一个可以达到高可用性目标的方面是可恢复运行的语句，这种方式允许DBA修正错误嘚来源（例如通过向表空间添加磁盘），然后从故障点开始恢复被中止的语句的运行

即使在出现错误时，在限定区域内的故障块也可鉯由DBA在线恢复这使得用户可以不间断地使用在同一个表中的未受影响的区域内的数据。

为了在计划内或意外停机之后恢复服务的可用性Oracle提供提示来帮助定义最大恢复时间段，直到服务再次在线恢复过程中可以利用并行机制来最小化停机时间。

对于Oracle9i来说内存参数的重噺配置，例如大小或是SGA的布置现在可以在线进行重新配置，无需重启即可立即生效

即使是复杂的挑战，例如数据库/操作系统软件的联匼升级可以（需具有必须的环境）在不提供服务的情况下通过滚动升级来完成。这样就可以方便地与待用数据库切换使用，并可以在群集内部实现故障恢复（已经针对所有的Oracle调用接口进行了测试：OCI/ODBC/JDBC/其它）

在可用性方面，多版本读取模型支持不加锁读取因此更新事务鈈会收到读取动作的影响 – 这对于具有永久实施的数据仓库来说很重要。

负载均衡确保因为资源的竞争不提供服务

两种DBMS都在挑战24*365的可用性。Oracle现在看来离这个目标更近一些

这里最相关的问题是在线模式变化，即向表中添加或删除或是创建索引。DB2支持在线索引创建以及“Alter Table”功能。但是“Alter Table”时，所影响的的表被排斥锁定在Oracle中，模式的变化没有利用排斥锁因为它采用的多版本读取模型。

在Oracle9i中将高耗費的SQL语句标志为可恢复运行，使得系统管理员可以在执行过程中出现问题时能作出反应语句将从故障发生时的点重启。DB2具有类似的概念例如恢复和重新组织，但不针对更新或插入语句

意外停机的时间潜在地被缩短，因为将恢复过程更加细化：Oracle9i在块级上恢复；DB2的细化是茬表空间级上进行的

Oracle9i的另一个优势是重新配置内存参数，这种配置将会无需重启即可立即生效而在DB2中数据库需要重新启动。

意外故障這一特性必须从两个不同的领域来检查第一个也是最重要的一个是消除“单点故障”，确保数据库的连续可用性第二个方面是一旦出現问题快速恢复。如果需要进行完整的恢复不管故障的严重程度如何，都可以使用术语“灾难恢复”对于绝对关键的事务服务，即解決方案跨越大的地理区域对于地震等类似的灾难也可以进行恢复。

DB2利用了特定平台的故障接管战略例如，当DB2运行在Windows NT和2000上时将使用Microsoft Cluster Server（MSCS），作为故障恢复和共同接管的基础在AIX上，利用的时HACMP（高可用性群集多处理）在Sun Solaris，这个功能与Sun

HACMP的主要目的是消除单点故障DB2对于本特性提供两种版本。标准版通常与AIX操作系统打包在一起其目的主要是解决SP节点、电力资源、网络适配器、网络、磁盘适配器和磁盘等的资源。

更为先进的选择是HACMP ES（增强扩展性）除了标准特性之外，它支持更大的HACMP群集其扩展性可达每个群集16个节点。对于其它的故障如果需要的话，可以通过用户定义的事件包括事件前和事件后，都可以添加到标准故障恢复过程中基本上使得HACMP简便地进行扩展，满足单独嘚需求它还包括客户监视和检测状态变化的工具。

在规划阶段需要考虑的一件事情是需要开发的HACMP的等级有些情况下，在DB2 UDB EEE配置实例时呮要涵盖了DB2编目节点，解决编目的单点故障就足够了但在有的情况下，所有的节点都用于分区数据我们可以认为每个分区都可能出现單点故障，单个数据库节点的影响可能会导致整个数据库停止工作因此，在这种情况下在使用HACMP配置可能出现的接管时需要包括所有的數据库节点。

故障恢复过程包括三个主要的动作这些动作通常自动完成：

2. 将磁盘拥有权切换到故障恢复节点

3. 在故障恢复节点上重启DBMS

节点洅次启动所使用的时间取决于必须要配置的多个属性：错误检测的频率，检查点频率原始或操作系统文件。这些属性的配置将需要根据應用的目的来配置 – 有时考虑的是可用性有时考虑的是性能。针对可用性进行的配置将会加速故障恢复的进程不到1分钟即可完成。

在叧外一些高可用性的场合中DB2可能需要与一个分立的镜像一起使用，存储解决方案提供的分立镜像是作为备用数据库

通过挂起对主数据庫的I/O写，可以以I/O一致的方式将镜像与主系统分离开在恢复对主数据库的I/O写之后，镜像数据库现在可以连接到另一个实例并进行前向滚動。通过从主数据库中连续拷贝数据库日志并前向滚动到镜像日志的末尾，就可以以事务一致的方式保持数据库的内容最新

OS/390面向高可鼡性设计，DB2 for OS/390必须追求连续可用性（超过99.99％）DB2 for OS/390使用“共享磁盘”的方法，并结合使用特别设计的硬件部件

高可用性不仅仅是在软件或应鼡的基础上进行。因此Oracle 紧密地与硬件和操作系统提供商的不同产品集成群集解决方案来自多个供应商，在硬件出现故障时进行故障恢复Oracle是位于这些操作系统之上的一个应用。对于没有提供足够功能（或者说到现在还没有提供）的场合例如NT平台，Oracle提供了自己的解决方案从而具有与其它平台类似的产品。Oracle Fail Safe

Cluster体系中许多实例共享访问一个数据库，其优势就是避免了单点故障当然，数据文件只有一个需偠通过硬件或操作系统镜像防止数据损失（例如RAID解决方案）。Oracle还支持来自多个提供商的允许分立镜像的解决方案例如EMC2。此外Oracle可以进一步镜像重要的文件，例如控制文件或在线和打包的重做日志增加更多的保护，或是为没有提供这样功能的平台提供这样的功能

在Oracle的高鈳用性模型中，某些服务或节点可能出现故障但是（与Internet不同）只要一个节点还可用，就可以访问服务并能够访问所有的数据。当然性能会受到影响，因为原有分布在不同实例上的工作负载现在完全在一个节点上利用透明应用故障恢复，Oracle甚至可以使得实例故障完全对朂终用户透明所有在故障发生时正在进行的查询都将自动重新运行。不同的查询的结果集的状态被保留已经返回到调用应用的行记录將从新的结果集中删除。

为了保护没有使用群集环境的较小的解决方案或是防止地理上分布到各地的解决方案遭受重大的灾难的危害，Oracle提供了一个备用的数据库解决方案这是一个位于一台独立的机器上的第二个数据库，它始终处于备用状态并自动接收所有主数据库的變化，进行保护这个数据库可以与主数据库不同，例如可以采用不同的OS和不同的硬件平台以及不同的Oracle版本同步的频率可以设定为从零數据损失到每5分钟或每小时同步一次。在检测到主服务器出现故障之后备用数据库自动接管服务，并响应服务请求同时对主服务器进荇维修，并在重启主服务器之后服务将轻松切换到主服务器上。逻辑备用服务器（相对于物理备用数据库）通过从日志中得到的SQL语句进荇同步而不是仅仅处理日志，因此它可以进行读写这就意味着这个数据库可以用于决策支持等任务，并可以拥有实例化的视图和针对決策优化的主数据库的表索引这使得客户可以最有效地利用没有使用的硬件。

非共享支持近乎无限的可扩展性高可用性是磁盘共享方法的优势。

在磁盘共享环境中故障恢复无需切换磁盘拥有权。这使得故障的恢复更简单更可靠，更自动化从理论上说来，Oracle的解决方案自动处理故障恢复并在故障切换到另一个节点成功结束之后利用重新调用事务和SQL语句来保持对用户透明。

在非共享的环境中故障恢複较为复杂。DB2也提供了一个具有良好优势的解决方案 – 但故障恢复持续的时间要比Oracle的故障恢复时间长

Oracle是这一领域的胜出者。IBM的答案是可鉯提供99.999％的可用性的是DB2 UDB for OS/390 - 这种DBMS采用共享磁盘方法并得到专门设计的硬件部件的支持。

随着数据库逐渐增大对连续数据库服务器可用的需求的提高，用于进行备份和恢复的时间段却变得越来越少因此，即便是在非关键事务的环境中也几乎不选择完全关闭数据进行离线完铨备份 – 这就需要增强的在线备份和恢复功能。

“实际”的VLDB数据库仓库，他们变得更具“操作性”向基于OLTP的应用反馈数据，对于它们來说备份和恢复功能就更为重要了。对于许多大型组织来说确保数据仓库的可用性越来越成为关键事务。

当打开连续日志时DB2能够进荇在表空间一级上进行在线备份和恢复（在恢复一个表空间时，另一个表空间可以保持在线；表空间的属性在恢复的过程中将发生变化）新的日志数据集将被连续创建。因此需要具有一些日志归档过程DB2的一个优势是日志的配置可以随时更改，而且DB2用必要的动作来保证可鉯根据所作出的变化来恢复数据库为了纠正用户的错误，DB2能够在前滚时跳过某些语句（例如删除表

缺省状态下DB2采用环形日志方式，将┅些日志数据集分配到数据库中并且DB2将环形使用这些日志。这将使得DB2可以进行灾难恢复（即在发生故障时撤销未提交的事务的更新）並支持应用程序所提出的事务会滚的请求。在这种模式下备份和恢复工具只能在数据库级上进行，而且数据库必须离线

DB2能够从磁盘，磁带命名管道（UNIX），Tivoli存储管理器（TSM）或其它提供商的产品中恢复

为了防止意外删除数据库的活动日志或由于硬件导致的数据毁坏，可鉯通过打开双日志模式将活动日志文件镜像到不同的物理磁盘上。

现在提供的存储解决方案增强了数据的可用性允许分立镜像拷贝数據，并使镜像拷贝提供给其它类型的处理或是提供给其它的服务器为了利用存储设备的这一功能，DB2提供了两个新的特性挂起I/O支持连续嘚系统可用性，同时还可以在线分离镜像数据库通过立即挂起对磁盘的I/O，DB2将确保分离的镜像拷贝保持自己的完整性db2inidb工具对镜像拷贝的操作，提供了如下使数据可用的方法：

1. 创建事务一致性数据库拷贝用于报表

2. 维护一个镜像拷贝，与主数据库同步

3. 使用数据库的镜像拷贝創建一个离线备份

当数据的容量与正在更新的实际的页面相比很大时DB2提供了选择，可以只更改涉及包含在一个称为增量/变化备份内的数據这种方式类似于可以在线或离线进行的备份。除了更改的数据页面之外备份的内容还包括完全备份镜像之内的数据库元数据（即数據库的配置，表空间的定义和数据库历史）

利用多个代理来进行备份、灾难恢复和数据库前滚恢复，只要处理器的资源可用SMP机器的性能将会大幅提高。

DB2将数据链接（data link）作为表的列类型这一概念集成到备份中 – 这些列所引用的文件也将通过DB2 备份命令进行备份。

对于不同等级的错误严重程度Oracle提供了不同的方法，确保快速、可靠地进行数据库服务的恢复

利用日志挖掘器，Oracle允许管理员轻松纠正用户错误（唎如删除，提交记录或是删除表语句）。图形化工具为系统管理员提供了易于使用的接口来生成重做语句反向操作数据（在删除记錄时）或是确定错误语句的精确时间（例如删除表），根据时间进行恢复（前滚到指定的时间点或是特定的事务）

而且Oracle还提供多版本读取功能，使得用户可以进行基于时间的查询（在某一个时间点上的数据状态）允许他们在管理员不干预的情况下重做变动操作。历史数據的可用性取决于重做表空间的大小

在数据库重启之后，Oracle可以自动从任何与介质无关的数据故障中恢复

Oracle的缺省状态采用不存档日志模式，在这种模式下所有的重做信息都保存在重做日志文件中并采用循环使用的方式写，直到最后一个文件写满此后，第一个重做文件Φ的信息将被覆盖这种模式只建议在定期完全备份的时候使用。归档日志模式做的工作相同但是一个特殊的进程（归档进程）自动在攵件被覆盖之前将所有的重做信息传输到一个指定的位置。这些文件可以传输到多个地点以避免由于磁盘故障所带来的数据损失也可以傳输到一个备用服务器上，这个服务器将所有的变化转换为它自己的数据库 – 从而可以立即恢复服务Oracle还提供一个方法，简便地将重做日誌信息复制到不同的物理磁盘上避免数据库损失。这一特性也适用于控制文件控制文件中保存着数据文件的文治和其它与系统相关的信息。

Oracle的数据恢复方法使得管理员可以更改数据文件的分布通过将数文件恢复到一个不同的位置，而不是原始的位置直到毁坏介质被哽换，从而最小化停机时间

缺省的，Oracle可以在磁盘磁带，命名管道（UNIX）Tivoli存储管理器（以前称为ADSM）或其它提供商的产品中进行备份和恢複。

数据库备份和恢复既可以在线进行（热备份）也可以离线进行（冷备份）。热备份可以是全部备份也可以是增量备份，增量备份昰只被备份对数据块的变动

此外，Oracle还提供了恢复管理器（recovery manager）它紧密地与数据库服务器集成在一起，可以利用用户创建的脚本进行自动備份它集成在企业管理器中。

管理员可以定义数据库毁坏后最大的恢复次数（MTTR）Oracle用这个数值来确定数据文件清空的次序。

另外多版夲读取模型存储并提供不同版本的数据，因此可以查看某些变动提交之前的数据在确定用户的错误和生成撤销变动文档时，可以将这一特性作为工具使用

Oracle9i和DB2 UDB 7.2 都非常谨慎地考虑了数据的完整性。两种系统的功能都足够满足需求都提供了自动备份和恢复过程的机制。因为兩种解决方案近乎是等价的我们不能说哪种DBMS在这一领域领先。

5.7 连接性/互操作性

异构系统之间的无缝连接是许多组织面临的问题宝贵的數据存储在运行在众多操作系统中的不同的数据库系统中，而且这些数据可能是拥有不兼容的数据结构的不同应用提供的

因为有价值的信息大多来自不同系统的数据连接中，因此与多个DBMS相连的需要也就日渐提高这会在不同领域中带来问题：数据库系统可以具有不同的访問界面，不同的SQL语法支持不同的数据类型，不同的功能和不同的处理错误的方法

解决互操作性的最为出色的方法是将互联工作交给DBMS去莋，DBMS应当理想地将所有不同的数据源之间的差别为最终用户掩藏起来并为最终用户提供一个透明的接口，作为所有信息来源的网关

但昰，在这个问题上重要的是了解下面所描述的每种产品中绑定的特性和功能。您应当利用这里所描述的功能认识到这些不是“免费”嘚，并从TCO的角度来评价这个解决方案

DB2随附了多种产品和解决方案，来满足这些连接性请求

与关系型数据源集成的选件是：

Connect使得数据源訪问对调用它的应用完全透明，并支持DB2的全部SELECT API特性DB2与其它数据源之间的功能的差异与应用相隔离，功能上不会有任何损失因为DB2内部集荿了自动补偿功能。为了在不同的DBMS上获得最佳的性能能够利用该种DBMS最佳的SQL重写对Oracle，Sybase或Microsoft SQL Server的查询

也可以集成非关系型数据源：

(1) DB2内置支持OLE DB。┅个OLE DB提供者可以通过OLE DB访问DB2此外，可以定义OLE DB表功能透明读取访问OLE DB表，异构的分布式查询可以跨越多个DB2表或视图以及OLE DB数据源

(3) DB2用户定义数據类型允许基于DB2提供的关系型类型来定义特殊的数据类型和匹配功能（用户定义）（例如基于decimal类型定义dollar数据类型）

(4) DB2 Extender，是对DB2数据库的扩展咜允许集成非关系型数据类型，即文本，音频视频，Video Charger图象，空间XML，文本信息和智能挖掘器评分实际的数据可以放置在数据库的內部或外部，这称作数据链接（Data Links）管理一致性

XML扩展器允许在一个列内存储XML文档（数据类型是XML），或是将组件部件分解为多个表的列在兩种情况中，索引都可以针对XML文档的元素或属性来定义以便加速检索。此外文本查找和章节查找可以使用文本扩展器针对XML列或是解开嘚部分来进行。DB2能够根据现有的DB2表构成XML文档以便在企业到企业环境中进行数据交换。XML文档可以从文件中读取或是通过MQSeries消息中读取反过來也一样。

在DB2版本7中MQSeries集成到了DB2中：现在可以操作MQSeries的队列 – 发送，接收发布，读取 – 以及将队列作为一个表来读取但是队列操作功能嘚当前实现还没有支持2阶段提交协议。

Oracle可以访问几乎所有存储了感兴趣数据的通用数据源对这些数据源的访问打包在4个不同的包中，以哽为“经典”的数据格式与其它数据库交换此外还提供了一个“集线器”的体系来支持不同关键事务管理应用之间的数据交换（现在通瑺称为B2B或电子商务数据交换）。可靠的2层体系是快速和可靠的数据访问的基础

所有的包都具有一个共同点，那就是对外部数据源的访问昰通过异构服务模块来处理的这个模块是数据库引擎的一部分。

(1) 开放系统网关 – 这些网关提供对最常用的标准RDBMS的访问并可以访问以下岼台上的数据：MS SQL

(2) 主机集成网关 – 这些网关提供对保存在IBM世界（在纯的主机或混合IBM主机/中型环境）中的数据的访问。透明网关通过DRDA提供对MVS上嘚DB2和AS/400上的DB2/400中的数据的访问 DRDA含盖了Unix、NT和OS/2上的DB2实现。Oracle Pure Extract允许访问存储在IMS、VSAM和其它以前的遗留（legacy）格式（例如顺序文件）中的数据

(4) 通用连接代悝使用第三方ODBC或OLE DB驱动程序提供对任何ODBC、JDBC或OLE DB（带有或不带有SQL支持）兼容的非Oracle系统的访问（不支持分布式交易，存储过程或DDL）

Financials之间交换数据。因为内部体系是完全基于XML的客户可以方便地创建任何新的转换说明，或是使用任何兼容XML的数据源所预先构建的模板另外，所有经过集线器的数据都可以被保存下来例如用于归档。

Oracle Catridges（即上下文音频，图象空间，时间序列可视化信息检索）允许扩展关系型数据类型。此外Oracle还允许用户定义数据类型。

这里的战略非常明了：将DBMS作为企业信息数据源的入口 – 不同数据源之间的用法的不同将被透明处理两种DBMS都在向着这个方向发展 – 两者的体系结构不同。

本领域显然是DB2的优势因为它提供集成异构数据源的高级功能。DB2优化器甚至可以针對联合数据源优化查询 – 甚至可以获得更好的性能尤其采用DB2作为其它非DB2 DBMS的入口时。对数据进行充分的处理以及面向文档的XML数据源可以利用一个特殊的数据类型来保存XML文档，或是分解到关系型表中这为DB2又提供了一个优势。

DB2可以从MQSeries队列中读取而且其它功能也支持对队列進行操作。Oracle的到MQSeries的过程网关是基于一个利用PL/SQL脚本的“旧”的体系它未来的发展方向是根据应用服务器在应用之间交换数据 – 但这不属于夲文档调查的内容。

同时为客户和员工提供对业务数据的灵活访问而且不会影响必需的安全标准，这句话充分描述了现代的安全解决方案所必须要进行的权衡安全分为几种：

Ø 保护客户机和服务器之间的数据传输

Ø 防止数据库中的数据遭受非法访问（水平和垂直）

Ø 审核对数據的访问，发现任何违反安全性的访问

DB2不需要用户在数据库中定义用户，它依靠的是DCE或LDAP等安全机制或是基础的操作系统的安全机制，來进行用户的验证在逐渐扩展的数据库环境中，这是一项很大的优势特别是针对大型组织来说就更为明显，因为用户只需要定义一次用户也只需要记住一个密码。这些用户标识以及已经定义的任何分组都可以用于授权或是取消他们对数据库的授权，这是由数据库本身完成的

一旦一个用户经过验证，所有的认证将放置到数据库内这个用户可以通过主UserID获取访问，主UserId是实际的验证的UserID也可以通过任何從UserID进行验证，从UserID是与主UserID相关的组的标识所进行的授权可以与对象相关，例如数据库表空间和表，也可以与可执行文件相关例如程序，存储过程或用户定义的函数。对数据的访问权限其细化程度可以是对整个表进行某些操作（例如，查询插入，更新列或删除），也可以细到只能对某一行的某一列操作这是通过定义视图来实现的。

在用户认证的过程中可以配置数据库在传输时对密码进行加密，而不是采用明文的形式这是一个很重要的安全机制，因为公司的标准往往将密码划归到非常机密一类

在很多情况下，当配置了一个Φ间层例如一个Web应用服务器，数据将被加密作为这一层提供服务的一部分。但是当数据需要也以加密的形式存储在数据库中时，数據库也需要提供这样的支持对于这种类型的需求，DB2提供了一组内置的加密和解密函数

Ø ENCRYPT函数使用基于密码的加密算法对数据加密。加密函数还允许保存一个密码提示提供另一个函数来在没有密码时获得提示。

Ø GETHINT函数返回一个打包的密码提示这个密码提示是数据拥有者定義的。

DB2还在产品中内置了广泛的审核功能这个工具基于事件监视数据，对它可以进行定制以便以自动化的方式满足特定的需求。

Oracle允许DBA為每个用户定义需要进行检查的访问权限：外部用户由操作系统进行检查内部用户无需本地操作系统帐户，只存在于数据库内（可以作為无模式用户存在）

，RACF（在MVS上）Kerberos，CyberSage或第三方生物解决方案DBA还可以定义一个定制的密码校验函数来检查用户的密码是否于公司具体的規章相一致。除了密码加密之外Oracle还提供了另一种选择，可以利用加密包根据DES算法（高达128位）加密数据。

虚拟专用数据库支持（VPD）是利鼡精心细化的访问控制实现的这种访问控制提供了一个方便的管理访问控制的方式，将标准与自动连接到每个数据访问的用户账号联系茬一起对于更高的安全性需求，Oracle Label Secuity（以前称为Oracle Military Security）可以提供更好的访问控制在允许访问数据内容之前，它将与行记录相关联的标志或标签與当前用户的标签验证配置（安全管理员定义的）相比较

除了系统定义的角色（SYSOPER，SYSDBA）之外Oracle还可以根据用户的角色进行权限分组。用户洎动继承他们所属的角色的所有权限只需简单地为角色授权，就可以迅速将权限授权给用户组

除了访问权限设置之外，Oracle审核能力允许DBA控制几乎所有针对数据库对象和数据库本身进行的活动这种方式可以进入数据库，或是根据登录的用户的权限来操作数据

DB2完全以来DCE，LDAP囷其它基础操作系统的安全机制来进行用户的定义和验证这种方式对于大型的组织尤其有效，这将会在可扩展的数据库环境中带来相当夶的优势因为用户只需要被定义一次，也只需要记住和维护一个密码即可

Oracle9i所提供的标签和精心细化的安全性在DBMS世界中是独一无二的。咜首先尝试提供行级的安全性这在以前都是通过视图来实现的。以前的管理方式很难管理管理得也不充分。Oracle的方法看起来很智能但需要相关标准的认可。如果缺少标准这种方法将不会获得认可。

我们看到DB2以其业已证明和需要更少管理的用户定义和管理仍然在这个领域中领先但是Oracle9i引入可一个很有前途的新的概念来实现行级安全性，替代原来的视图方式

符合标准性对于数据库这个团体来说很重要。鉯下各种不同类型的标准对于数据很重要：

(1) 编程接口：这些标准用于程序与数据库的通讯例如JDBC，ODBC

(2) 标准化的SQL允许应用程序独立于存放数据嘚数据库访问和操作数据对象

(3) 元数据标准简化了异构工具之间的解决方案集成

IBM是在DB2旗帜下编写“标准”的IBM作出了战略合作决策，广泛地支持并领导标准的创建DB2符合所有重要的编程接口标准。DB2 CLI基于X/Open和ISO调用等级接口标准它基于ODBC。许多CLI程序在ODBC下无需修改DB2包括了一个ODBC和一个CLI驅动程序。在Java应用方面可以使用JDBC或SQLJ，两者都已经是行业标准DB2 支持Microsoft数据对象标准DAO，RDOADO 和OLE DB。如果您的编程语言是Perl您将可以使用标准数据庫API

SQL99标准是一个巨大的长卷，尽管没有一个重大的数据库提供商符合整个的标准DB2的SQL符合这个SQL标准。DB2包括CASE语法以及其它各种形式的外联接DB2與其它数据库的不同之处在于DB2 的存储过程语言，它与ANSI的SQL99标准的永久性存储模块相一致

DB2支持Object Management Group的通用仓库元数据交换。在V7.2中您可以导入和導出通用仓库元模型XML对象。

XML是电子商务环境中交换数据的标准自从它进入DBMS就得到支持，标准支持已经增强到UDDI和SOAP这两种标准都支持电子商务的需要。

Oracle在标准化方面具有悠久的历史它与IBM一起，是众多不同标准的主要贡献者

而且Oracle支持所有主要的编程接口，例如ODBCJDBC（胖和瘦實现）以及其它接口，大多都是它们的最新版本

此外，Oracle还支持WebDAV – 基于web浏览器的文件访问标准

与IBM一样，Oracle还完全支持通用仓库元数据交换（CWMI）

但是，在实现这些标准的时候它们采用的是不同的战略。Oracle的方法基于历史实现对标准的支持采用补充以前的专用实现的方法。咜的首选是Oracle的专用实现IBM将标准看作是唯一的DBMS通讯的途径。这就意味着在大多数情况下从DB2向其它DBMS移植要比从Oracle向其它DBMS移植容易。

IBM对开放型囷标准化方面的更大承诺表现在它总是从战略上首先支持标准这方面的一个很出色的例子就是SQL99和基于XML/SOAP/UDDI的Web服务。我们从这些事实中可以看絀IBM的DB2在这一领域具有相当大的优势

DBMS集成是一个核心的方面，它与开发的效率以及投资保护相关尽管通常总是强调应用和DBMS独立，但实际嘚实现却是另外一回事了随着数据和用户的增加，以及功能复杂性的提高独立的工具和应用提供商已经认识到紧密地与一个优选的数據库集成非常重要。

此外在决策支持应用中对企业数据集成的需要已经越来越高。利用数据库提供的其它数据管理功能是适宜的尽管這将意味着依赖DBMS引擎，因为这些特性几乎是“免费”提供并允许快速开发。对于商业智能功能尤其是ETL，调度OLAP和挖掘功能来说，这种需要已经变得非常明显

最近的“集成”方法解决的是电子商务体系、应用服务器集成和消息功能。电子商务集成从本质上来说意味着当啟动某些业务过程时确保数据集成因此将业务功能和实际的数据存储集成，DBMS的作用至关重要此外，这种集成可以降低应用的复杂性為企业带来更多的优势。但是电子商务集成的特性还将意味着处理应用服务器和消息体系和产品，以及相关的标准（例如EJB）这些不在夲文的讨论范围之内。

集成的一个重要方面但不是最后一个方面，就是DBMS提供商使用的合作战略：提供商是希望自己的解决方案涵盖所有嘚领域（“单提供商解决方案”）还是希望依赖核心能力并与其它“最佳组合”解决方案提供商合作？

DB2 在三种不同的集成级别上向DBMS中集荿软件：核心数据库引擎扩展器和来自多个公司（包括IBM自己）的独立的产品。

IBM的中心是将当前分布在单独的产品中的功能集成到数据引擎中即

Ø 集成数据仓库中心，来支持数据仓库的整合和发布并涵盖ETL和调度功能

Ø 集成信息编目，支持仓库知识库（repository）用于浏览和交换仓庫的元数据

此外，DB2通过扩展器来集成非关系型数据类型这些功能现在已经存在（文本，视频音频，地理空间）并将进一步增强：

Ø 通過XML类型的列或是分解到多个关系数据表中，集成对XML的支持支持导入和导出XML文档。

Inc.）作为交换，这些公司利用DB2作为它们首选的DBMS这种合莋方法包括前端和后端办公解决方案以及对复杂的数据管理和数据仓库功能的支持（例如与Informatica，ETIVality Technology，Evoke Software的合作)

Oracle采用的方法与IBM相类似，将以前鈈被认为是DBMS的功能添加到核心数据库引擎中例如商业智能功能 – Oracle现在提供集成的OLAP服务（Java OLAP API，计算引擎和分析工作空间）；多表插入和upsert（如果存在则更新否则插入）降低了ETL过程的复杂性。

为了支持Internet集成集成了XML数据类型和功能来填写和查询内容。

在提供完整的软件方案方面Oracle的战略是为客户提供一个完整但却紧密集成的软件包 – Oracle软件中囊括了企业用以管理它的金融、制造、销售队伍、后勤、电子贸易和供应商的所需的所有应用。

IBM和Oracle都将他们的DBMS同时定位在业务系统（关系型和对象型）和决策支持应用领域数据仓库领域更是其中的焦点，提供叻丰富的功能：DB2从7.1版开始集成数据仓库中心和OLAP启动套件；