IBM DB2 UDB V7.2 与 Oracle9i的比较
IBM DB2 UDB V7.2 与 Oracle9i的比较
目录
1 作者
2 概要说明
3 范围
4 新特性概述
4.1 IBM DB2 通用数据库7版
4.2 Oracle9i
5 比较
5.1 性能
5.2 可扩展性
5.3 易管理性
5.4 可用性
5.3 意外故障
5.6 备份和恢复
5.7 连接性/互操作性
5.8 安全性
5.9 符合标准性
5.10 集成
1 作者：
Jacqueline Bloemen
Jacqueline（电子邮件：[email protected]）1980年开始进入IT业, 1986年成为顾问。从1988年开始，她致力于关系和数据管理技术，并主要关注异构DBMS和平台上的数据仓库和决策支持系统。当前研究的主题包括分析CRM和知识管理（Knowledge Management）。她是IBM数据管理金牌顾问团队的成员。
Guido Brunner
Guido（电子邮件：[email protected]）从1982年开始从事IT行业 – 已经在PASS工作了9年。他的主要领域是为主要分布在银行领域中的不同的客户进行数据仓库和数据管理的咨询。他在主流DBMS方面有着丰富的经验，例如Sybase，Informix，Microsoft SQL Server，DB2（OS390和NT）和Oracle – 在最近的12个月中他主要研究DB2 UDB 7.1和Oracle 8.1.6。
William Miller
在过去12年中，William一直是许多大型的德国和国际公司的DB2顾问。他熟悉DB2的方方面面 - 从概念数据库设计到底层的性能监控和调整。他是IBM DB2 金牌顾问的成员，经常在全球的DB2 会议上讲演。
Bjarne Nelson
Bjame的专业领域是DB2，尤其是性能和分布式方面。他已经为DB2全时工作了15年，主要在北欧和中欧工作，偶尔在澳大利亚、加拿大、拉丁美洲以及远东。在1996年和1997年，他是欧洲IDUG的会议主席，并作为IBM金牌顾问项目数据管理的独立顾问。Bjarne定期编写有关DB2的文章和报告，主要通过伦敦的Xephon出版。从1992年开始，Bjarne已经在众多会议上针对DB2的性能和分布式问题进行了演示，例如IDUG，PRDUC，CMG和Xephon Briefings。他的经验涉及到整个DB2系列，但主要是利用DB2 UDB EEE实现大型数据仓库，而且他仍然致力于DB2 for OS/390，参与了众多数据共享的实现。
Steffen Oliver Schulz
Steffen拥有商业管理硕士学位（专业是计算机科学）。从1987年进入IT行业以来，曾为多家公司工作，包括Microsoft（领导PM数据库 DACH）。从1995年开始他作为一个独立的顾问，致力于银行、工业行业和卫生环境的数据库和数据挖掘项目。他曾经作为从Informix到Sybase/MS SQL Server到Oracle数据库的开发者和管理员，了解众多的DBMS。他从Oracle 版本7开始使用Oracle – 现在正在管理8.1.7 Parallel Server。
Bernd Strohle
Bernd拥有数学的硕士学位，到现在为止，已在IT业工作了近25年。他从1997年开始作为独立顾问，为IBM工作，当时是APPC开发小组的一员。从日常工作中，他了解了主要DBMS系统的工作 – 从主机上的IMS DB到不同平台上的DB2和Oracle。他从Oracle 6.0版开始使用Oracle，致力于复杂环境下，主要是银行和保险公司的Oracle数据仓库项目。
2 概要说明
分析人士传达了一个明确信息：只有3个DBMS会从近几年的市场竞争中胜出：Oracle，IBM的DB2 和Microsoft的SQL Server。因为MS SQL Server限制在Windows平台上，因此，竞争者将剩下Oracle和IBM，目前激烈的市场竞争也很好地证明了这一点。
在2001年6月，Oracle和IBM都发布了最新的DBMS版本：Oracle9i和DB2 通用数据库 V7.2 for Unix, Windows, Linux and OS/2。
本文从技术角度讲述了这些新版本中采用的数据库技术，为数据库专业人员提供它们的特性、功能和实现体系的概述。在简要讲述版本概要之后，本文将从以下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最近成为许多标准软件提供商的首选开发平台。
总之，我们得到了如下各个方面的胜利者分别是谁：
性能：DB2 UDB V7.2
可扩展性：DB2 UDB V7.2
易管理性：DB2 UDB V7.2
可用性：Oracle9i
意外故障：Oracle9i
备份和恢复：平手
连接性/互操作性：DB2 UDB V7.2
安全性：DB2 UDB V7.2
符合标准性：DB2 UDB V7.2
集成：DB2 UDB V7.2
3 范围
Oracle和IBM在2001年6月都发布了最新的DBMS版本：Oracle9i和DB2 通用数据库 V7.2 for Unix, Windows, Linux and OS/2。
本文从技术的角度讲述了数据库技术，目的是为数据库管理员提供一份对DBMS效率的评估。因此，本报告中的主题集中在扩展性、可用性、（自治）管理、性能/VLDB领域。其它的主题，例如应用问题，商业智能，数据挖掘，电子商务等，将只提供概述。
本文的作者们对Oracle8i和DB2 UDB V7.1都有实际使用经验，但是，Oracle9i和DB2 UDB V7.2的增强只是理论上了解。本比较不是基于实际的基准和测试，只是从理论上对特性和功能进行比较。
这里所使用的信息的来源包括手册，提供商网页，直接与提供商联系以及其它在Internet上的与DBMS相关的信息。
本报告主要针对UNIX、NT和OS/2平台。
为了能在接近两种新的DBMS版本可获得日期的时间提供本文档，我们尽力在极短的时间内掌握信息。我们的目标是提供精确的信息，以便使读者高效阅读本文档。
尽管有一章专门针对集成，但是有一点很重要，那就是集成的一个很重要的方面，电子商务集成，没有详细地进行讨论。要想评测电子商务集成性能，需要详细地处理应用服务器以及消息体系和产品，以及相关的标准（例如EJB）。尽管我们相信这非常重要，但它不包含在本文档的范围之内。
4 新特性概述
4.1 IBM DB2 通用数据库7版
前言：DB2 产品系列
DB2 产品系列含盖了从手持设备到主机等众多的异构平台。
DB2 通用数据库 for Unix, Windows, Linux and OS/2 （DB2 UDB for UWO）分为4个版本：
DB2 通用数据库个人版，用于单用户模式（DB2 UDB PE）
DB2 通用数据库工作组版，用于工作组或部门的应用和数据共享（DB2 UDB WE）
DB2 通用数据库企业版，用于从单处理器到最大型的SMP需要的复杂配置和大型数据库（DB2 UDB EE）
DB2 通用数据库企业版 – 扩展版，在大型并行处理器（MPP）或群集环境中的大型数据库（DB2 UDB EEE）
DB2 通用数据库 for AS/400（DB2 UDB for AS/400）
DB2 通用数据库 for OS/390（DB2 UDB for OS/390）
DB2 for VSE & VM
DB2 Everyplace 用于手持设备运行环境。
正如前面所述，本文主要针对的是DB2 UDB for UWO。
UNIX、Windows和OS/2环境下的IBM DB2 通用数据库7.2版
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中提供。
DB2 版本7（7.1 和7.2）关注集成：
集成商业智能功能
数据仓库中心（Data Warehouse Center）将以前的“Visual Warehouse”集成到DB2 控制中心（Control Center）中，提供了一个单一的用户界面。它提供了内置的功能来创建、生成、存储和维护数据仓库和OLAP立方体（cube）。
OLAP Starter Kit提供了集成在核心数据库引擎中的OLAP服务器功能。
新的预先定义的仓库管理器（Warehouse Manager）连接器扩展了对SAP R/3，i2 TradeMatrix BPI等应用的访问。其它新的数据源将点击流（clickstream）数据、OLE DB对象和MQSeries队列引入到仓库中。
7.2 DB2 现在支持OMG的通用仓库模型（Common Warehouse Model，CWM）
集成XML文档
将XML文档作为新的列数据类型来存储
将XML文档分解、存储到不同的表中的
支持基于XML/SOAP/UDDI的Web服务
DB2 数据或存储过程以Web服务的形式对外提供
通过SQL访问来自Web服务的数据
与IBM MQSeries集成
内置了通过SQL来访问或写入MQSeries队列的功能
MQSeries作为仓库管理器的数据源
通过MQSeries队列的XML文档
与DB2打包在一起的MQSeries
集成IBM DataJoiner与通用数据库
访问所有存放于DB2系列DBMS的数据
访问来自其它支持OLE DB标准的数据库提供商的数据
访问位于Oracle、Sybase、Informix和MS SQL Server中的数据
在存储过程中访问异构数据源
DB2 生命科学数据连接（Life Sciences Data Connect）
透明访问生物技术数据源
DB2 文本信息扩展器（Text Information Extender）
增强的文本文档搜索功能
与Windows 2000 Active Directory和Kerberos集成
但是，引擎中并不仅仅添加了集成功能。其它方面还有：
存储过程
支持嵌套（nested）存储过程
遵循 ANSI SQL99标准，用户现在可以创建存储过程，函数和触发器，作为“永久存储模块” – 在DB2中称为“SQL存储过程”
支持以Visual Basic编写的存储过程
在所有使用相同的操作系统的服务器上运行已经编译的存储过程
各种数据管理增强
增强了对Identity列的支持，包括LOAD工具
将日志的限制提高到32GB
支持外部保存点（savepoint）
重新命名表空间
在AIX，HP-UX和Solaris上支持64位 – 在Windows 2000上使用AWE
增强了Unicode
加密和解密字符串数据
备份/恢复功能增强：双份日志/并行恢复/从分离（split）的映象备份/分离映象处理/命名管道支持/渐进式和增量备份/交叉平台备份和恢复
按需日志存档
在日志目录满之后，封锁事务处理
语句级隔离等级
DB2 Everyplace 这一产品，IBM将其定位为手持设备的DBMS，例如PDA（个人数字助理）和HPC（手持个人计算机）
UserID支持超过8个字符
动态组合SQL语句
触发器和SQL函数中的变量和控制流程
可更新的分区键
下一版本的DB2 UDB将包括众多的改善和增强，这些增强主要是在高可用性（减少计划内和意外故障的次数）、易管理性（减少管理工作）、性能和可扩展性（包括大型SMP和群集环境）等领域，并为应用软件开发者提供更好的支持。
Informix和IBM最近签署了一份协议，IBM收购了Informix 数据库业务。IBM计划将Informix的关键技术集成到DB2的未来版本中。
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 总是保持摘要表与基础表的同步），也可以利用DEFERRED：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中，引入了增量刷新功能，减轻了这种权衡的考虑。为实例化视图添加索引可以进一步加速查询的性能。优化器的查询重写功能使用在实例化视图中存储的结果，加速获取被请求的数据，避免了重复进行高耗费的联接或聚合。
不仅数据收集本身与查询的性能相关，数据仓库领域（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对行级锁的实现不会将锁升级到其它等级（块，表），配合多版本读取模型，可以支持扩展性，因为与重写无关的读进程将不会阻塞一个写进程。
结论
共享磁盘和非共享群集是多年来数据库行业的两个主要分支，但是电子贸易的工作负荷现在推动着这些机构主要针对扩展性进行设计。数据库提供商发展的趋势是向着非共享设计发展。只有Oracle和DB2 for OS390采用磁盘共享体系，但IBM解决了共享磁盘的扩展性问题，在专用的硬件中实现了全局锁和共享内存磁盘缓存，即Sysplex Coupling Facility。
围绕这两种体系的讨论的结果是：非共享提供了近乎无限的扩展性，如果数据库具有合理的设计的话。系统的配置和管理需要付出更多的努力。共享磁盘的一个特性是具有高可用性，但当扩展到超过8个群集节点时就会出现限制。
Oracle在9i中利用第二代的“缓存融合（cache fusion）”- Real Application Cluster来对抗这些劣势。这一体系具有与IBM的DB2 UDB for OS/390类似的特性，但是由于平台具体的实现，DB2 UDB for OS/390可以利用专用的硬件特性。利用的Oracle的RAC，会出现添加节点的限制 – 现在在大多数操作系统中是不能超过8个节点（DB2 UDB EEE限制在1000个节点）。当前，还没有提供一个在超过8个节点的环境中进行的基准测试 – 实际上没有基准、客户参考以及其它论据能证明Oracle9i在超过2个节点的环境中运行。因此，还需要确定这一实现是否能够成功地满足需求。
对于DB2 UDB 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已经使用多年了（例如虚拟接口）。
5.3 易管理性
易管理性是根据数据库管理员和数据库本身之间的联系点的必要性来定义的。它可以根据DBA用来启动数据库、使其运行和保持合理性能所需的交互的数量（包括时间和复杂性等因素）的多少来衡量。
一方面，您有一些系统管理任务，包括数据库产品的安装和数据库的配置。在正常的工作流程中，DBA将定义数据库对象并将应用与数据库绑定。在应用启动并运行之后，DBA必须进行数据库的维护，并监视资源的耗用，以便获得可接受的性能。
DB2 UDB V7.2
IBM重点加强了最近发行的DB2中的易管理性。IBM认识到不是每家企业都拥有高度熟练的DBA来管理数据库并进行最优配置，IBM从两个方面来解决这个问题。DB2 包括了众多的向导、图形对话框，指导管理员完成各项工作。另一方面，IBM提高了DB2的自管理功能，不再需要DBA的干预。
开始使用DB2的最简单的方式是通过称为“控制中心”的图形用户接口。在这个接口中，您可以列出所有的数据库对象，对它们进行管理操作。它还是其它一些可视化工具的进入点。在命令中心和脚本中心，您可以输入命令和脚本，安排执行的时间，并可以监视它们的进度和结果。
数据库的配置是一件让人畏惧的工作。除了120独个注册项变量之外，还有88个数据库管理员参数和60个数据库参数。DB2利用性能配置智能向导（Performance Configuration 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 Management Console）。
DBA的一项讨厌的工作是维护数据的物理组织。您的应用如果利用未经组织的数据，应用的性能可能会下降。reorg实用工具可以组织物理数据，以便进行有效的访问。但是何时才需要进行重新组织呢？reorgchk（重新组织检查）工具可以确定这一需求。它从DB2编目中读取当前的统计数据，或是它将收集统计数据。拥有当前的统计数据对于DB2来说很重要。没有精确的统计，优化器的运行将没有指导，可能无法确定最佳路径。您可以利用runstats命令来引导DB2刷新统计数据。
对于加载以及重新组织等一般需要长时间运行的任务，DB2支持重启功能。如果在加载数据的时候出现故障，您可以从最近的一致性点重启加载操作（利用RESTART选项）。对于重新组织工具，重启是隐含的，因为它将根据在故障发生之前完成的工作自动确定是撤销还是完成。
DB2自动均衡索引，这就意味着无需手动重新组织索引。DB2发现何时索引页面由于删除变得近乎空，并将把页面合并在一起。利用这种方式，您将不会拥有会降低性能的稀疏的索引。致命的磁盘问题对于索引来说未必是致命的。硬件的故障造成索引无效时，DB2会自动恢复。如果数据仍然可用，DB2将自动重新创建索引。
DBA的另一个头痛的任务是用户验证。DB2完全支持操作系统验证策略。在操作系统一级上，您可以定义组，并将用户分配到组。在DB2中，您可以为组授予权限。这将最小化数据库中用户管理的数量。
一个经验不算丰富的DBA将会快乐享有DB2提供的工具。所有管理数据库的重要方面都利用向导和可视化工具提供支持。这些向导消除了猜测，明确给出改进性能的建议。只要出现问题，监视工具就会立刻检测出来并予以显示。有经验的DBA将会享用可以实现的自动化操作。
Oracle9i
最佳的易管理特性是完全消除人工的干预，将控制权完全交给RDBMS。Oracle9i通过自动化先前需要人为干预的任务来满足此方面的需要，例如引入自管理的会滚或内存分段。
对于仍然需要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.4 可用性
可用性必须从最终用户的角度来衡量。最终用户不了解（或不关心）在他们的数据不可用时找出一个整体解决方案中的复杂部件。
在本章中，我们将可用性定义为应用或服务提供最终用户所期望的功能的程度。它与任何必须的管理性工作最相关，例如索引的创建或表的重组织，这些工作将会导致停机时间，至少会有引起中断的可能。
可用性的另一方面 – 从管理意外中断来讲，就是意外故障，这可能是因为硬件故障、灾难等造成的 – 将在5.5章“意外故障”中讨论。
DB2 UDB V7.2
可用性的高低可部分地根据对重组的需要来衡量。在物理数据库中采用的参数会影响到对重新组织的需要。在创建表时，空余空间的百分比以及分配聚簇索引等选项将会帮助减少执行数据和索引重新组织的需要。
DB2 UDB for UWO现在还不支持在线重新组织数据（在下一个版本将具有这项功能）。在下一个版本之前，当数据需要重新组织时，表需要离线。但是对于索引，可以在线连续进行重新组织。
为索引页面的最大剩余空间提供一个用户可以定义的阈值，以此提供在线重新组织。当从一个页面中删除一个索引键时而超过阈值时，相邻的索引页面将被检查两个页面是否可以合并。
为了能使得数据管理过程更为有效，只在需要时进行重新组织，可以使用REORGCHK工具，它可以分析哪些表和索引会从重新组织中受益。
对于加载以及重新组织等一般需要长时间运行的任务，支持重启功能。如果在加载数据的时候出现故障，您可以从最近的一致性点重启加载操作（利用RESTART选项）。对于重组工具，重启是隐含的，因为它将根据在故障发生之前完成的工作自动确定是撤销还是完成。
更改配置参数需要考虑两个方面的问题。首先是改变配置参数不引起重大的故障，其次是这种变化是否可以在线产生效果（即不必停止和启动数据库或实例）。当前大多数配置参数可以在线改动，但直到数据库或实例停止并重启后才能有效。但是，这一领域随着DB2的发展正在进一步发展。DB2的一个特性是可以根据需要，简单地扩展和压缩在线日志的容量，尽管这一操作需要停止并启动数据库。
为了缩短计划内或意外停机之后的重启时间，DB2提供了DBA可以调节的检查点窗口。
备份工具可以在分离（split）的映象上在线和离线运行，不会影响到主数据库服务器的性能。在数据库级上恢复时，数据库不能提供服务 – 表空间级的恢复可以让其它表空间在线。总之，DB2提供了众多成熟的工具，它们都可以并行执行，减少了影响可用性的时间窗口。
Oracle 9i
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中数据库需要重新启动。
5.3 意外故障
意外故障这一特性必须从两个不同的领域来检查。第一个也是最重要的一个是消除“单点故障”，确保数据库的连续可用性。第二个方面是一旦出现问题快速恢复。如果需要进行完整的恢复，不管故障的严重程度如何，都可以使用术语“灾难恢复”。对于绝对关键的事务服务，即解决方案跨越大的地理区域，对于地震等类似的灾难也可以进行恢复。
DB2 UDB V7.2
DB2利用了特定平台的故障接管战略。例如，当DB2运行在Windows NT和2000上时，将使用Microsoft Cluster Server（MSCS），作为故障恢复和共同接管的基础。在AIX上，利用的时HACMP（高可用性群集多处理）。在Sun Solaris，这个功能与Sun solstice和Verita集成，对于Linux，它将通过SteelEye提供，在HP-UX上，通过ServiceGuard支持这一功能。
HACMP的主要目的是消除单点故障。DB2对于本特性提供两种版本。标准版通常与AIX操作系统打包在一起，其目的主要是解决SP节点、电力资源、网络适配器、网络、磁盘适配器和磁盘等的资源。
更为先进的选择是HACMP ES（增强扩展性）。除了标准特性之外，它支持更大的HACMP群集，其扩展性可达每个群集16个节点。对于其它的故障，如果需要的话，可以通过用户定义的事件，包括事件前和事件后，都可以添加到标准故障恢复过程中。基本上使得HACMP简便地进行扩展，满足单独的需求。它还包括客户监视和检测状态变化的工具。
在规划阶段需要考虑的一件事情是需要开发的HACMP的等级。有些情况下，在DB2 UDB EEE配置实例时，只要涵盖了DB2编目节点，解决编目的单点故障就足够了。但在有的情况下，所有的节点都用于分区数据，我们可以认为每个分区都可能出现单点故障，单个数据库节点的影响可能会导致整个数据库停止工作。因此，在这种情况下，在使用HACMP配置可能出现的接管时需要包括所有的数据库节点。
故障恢复过程包括三个主要的动作，这些动作通常自动完成：
1. 错误检测
2. 将磁盘拥有权切换到故障恢复节点
3. 在故障恢复节点上重启DBMS
节点再次启动所使用的时间取决于必须要配置的多个属性：错误检测的频率，检查点频率，原始或操作系统文件。这些属性的配置将需要根据应用的目的来配置 – 有时考虑的是可用性，有时考虑的是性能。针对可用性进行的配置将会加速故障恢复的进程，不到1分钟即可完成。
在另外一些高可用性的场合中，DB2可能需要与一个分立的镜像一起使用，存储解决方案提供的分立镜像是作为备用数据库。
通过挂起对主数据库的I/O写，可以以I/O一致的方式将镜像与主系统分离开。在恢复对主数据库的I/O写之后，镜像数据库现在可以连接到另一个实例，并进行前向滚动。通过从主数据库中连续拷贝数据库日志，并前向滚动到镜像日志的末尾，就可以以事务一致的方式保持数据库的内容最新。
OS/390面向高可用性设计，DB2 for OS/390必须追求连续可用性（超过99.99％）。DB2 for OS/390使用“共享磁盘”的方法，并结合使用特别设计的硬件部件。
Oracle9i
高可用性不仅仅是在软件或应用的基础上进行。因此Oracle 紧密地与硬件和操作系统提供商的不同产品集成。群集解决方案来自多个供应商，在硬件出现故障时进行故障恢复，Oracle是位于这些操作系统之上的一个应用。对于没有提供足够功能（或者说到现在还没有提供）的场合，例如NT平台，Oracle提供了自己的解决方案，从而具有与其它平台类似的产品。Oracle Fail Safe on NT就是这样的一个例子，它对一个空闲的节点提供一个冷的故障恢复。不幸的是，现在只存在对于Compaq Alpha和Compaq Linux的Real Application Cluseter认证。
在Oracle的Real Application 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采用共享磁盘方法，并得到专门设计的硬件部件的支持。
5.6 备份和恢复
随着数据库逐渐增大，对连续数据库服务器可用的需求的提高，用于进行备份和恢复的时间段却变得越来越少。因此，即便是在非关键事务的环境中，也几乎不选择完全关闭数据进行离线完全备份 – 这就需要增强的在线备份和恢复功能。
“实际”的VLDB，数据库仓库，他们变得更具“操作性”，向基于OLTP的应用反馈数据，对于它们来说，备份和恢复功能就更为重要了。对于许多大型组织来说，确保数据仓库的可用性越来越成为关键事务。
DB2 UDB V7.2
当打开连续日志时，DB2能够进行在表空间一级上进行在线备份和恢复（在恢复一个表空间时，另一个表空间可以保持在线；表空间的属性在恢复的过程中将发生变化）。新的日志数据集将被连续创建。因此需要具有一些日志归档过程。DB2的一个优势是日志的配置可以随时更改，而且DB2用必要的动作来保证可以根据所作出的变化来恢复数据库。为了纠正用户的错误，DB2能够在前滚时跳过某些语句（例如删除表 - drop table）。
缺省状态下，DB2采用环形日志方式，将一些日志数据集分配到数据库中，并且DB2将环形使用这些日志。这将使得DB2可以进行灾难恢复（即在发生故障时撤销未提交的事务的更新），并支持应用程序所提出的事务会滚的请求。在这种模式下，备份和恢复工具只能在数据库级上进行，而且数据库必须离线。
DB2能够从磁盘，磁带，命名管道（UNIX），Tivoli存储管理器（TSM）或其它提供商的产品中恢复。
为了防止意外删除数据库的活动日志或由于硬件导致的数据毁坏，可以通过打开双日志模式，将活动日志文件镜像到不同的物理磁盘上。
现在提供的存储解决方案增强了数据的可用性，允许分立镜像拷贝数据，并使镜像拷贝提供给其它类型的处理或是提供给其它的服务器。为了利用存储设备的这一功能，DB2提供了两个新的特性。挂起I/O支持连续的系统可用性，同时还可以在线分离镜像数据库。通过立即挂起对磁盘的I/O，DB2将确保分离的镜像拷贝保持自己的完整性。db2inidb工具对镜像拷贝的操作，提供了如下使数据可用的方法：
1. 创建事务一致性数据库拷贝，用于报表
2. 维护一个镜像拷贝，与主数据库同步
3. 使用数据库的镜像拷贝创建一个离线备份
当数据的容量与正在更新的实际的页面相比很大时，DB2提供了选择，可以只更改涉及包含在一个称为增量/变化备份内的数据，这种方式类似于可以在线或离线进行的备份。除了更改的数据页面之外，备份的内容还包括完全备份镜像之内的数据库元数据（即数据库的配置，表空间的定义和数据库历史）。
利用多个代理来进行备份、灾难恢复和数据库前滚恢复，只要处理器的资源可用，SMP机器的性能将会大幅提高。
DB2将数据链接（data link）作为表的列类型，这一概念集成到备份中 – 这些列所引用的文件也将通过DB2 备份命令进行备份。
Oracle9i
对于不同等级的错误严重程度，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 UDB V7.2
DB2随附了多种产品和解决方案，来满足这些连接性请求。
与关系型数据源集成的选件是：
(1) DB2 Relational Connect是IBM集成战略的一部分：IBM的DataJoiner的功能将逐渐集成UDB引擎中。在集成的第一步中，DB2 Relational Connect提供了对Oracle、Sybase和Microsoft SQL Server数据库的native读访问。DB2 Ralational Connect使得数据源访问对调用它的应用完全透明，并支持DB2的全部SELECT API特性。DB2与其它数据源之间的功能的差异与应用相隔离，功能上不会有任何损失，因为DB2内部集成了自动补偿功能。为了在不同的DBMS上获得最佳的性能，能够利用该种DBMS最佳的SQL重写对Oracle，Sybase或Microsoft SQL Server的查询。
(2) DB2 DataJoiner
Ø 对Oracle，Oracle RDB，Informix和Sybase提供完全native的SQL支持，包括DML和DDL查询；
Ø 集成多供应商数据库复制；
Ø 对IMS和VSAM数据源提供连续支持
(3) DB2 Connect这个工具用于通过DRDA连接主机数据库
(4) DB2 Life Sciences Data Connect支持DB2 联邦系统集成分布在不同地点的基因、化学、生物和其它研究数据。
也可以集成非关系型数据源：
(1) DB2内置支持OLE DB。一个OLE DB提供者可以通过OLE DB访问DB2。此外，可以定义OLE DB表功能，透明读取访问OLE DB表，异构的分布式查询可以跨越多个DB2表或视图以及OLE DB数据源。
(2) DB2大对象数据类型，即BLOB，CLOB和DBCLOB
(3) DB2用户定义数据类型允许基于DB2提供的关系型类型来定义特殊的数据类型和匹配功能（用户定义）（例如基于decimal类型定义dollar数据类型）
(4) DB2 Extender，是对DB2数据库的扩展，它允许集成非关系型数据类型，即，文本，音频，视频，Video Charger，图象，空间，XML，文本信息和智能挖掘器评分。实际的数据可以放置在数据库的内部或外部，这称作数据链接（Data Links）管理一致性。
DB2 XML扩展器允许在一个列内存储XML文档（数据类型是XML），或是将组件部件分解为多个表的列。在两种情况中，索引都可以针对XML文档的元素或属性来定义，以便加速检索。此外，文本查找和章节查找可以使用文本扩展器针对XML列或是解开的部分来进行。DB2能够根据现有的DB2表构成XML文档，以便在企业到企业环境中进行数据交换。XML文档可以从文件中读取或是通过MQSeries消息中读取，反过来也一样。
在DB2版本7中，MQSeries集成到了DB2中：现在可以操作MQSeries的队列 – 发送，接收，发布，读取 – 以及将队列作为一个表来读取。但是队列操作功能的当前实现还没有支持2阶段提交协议。
Oracle9i
Oracle可以访问几乎所有存储了感兴趣数据的通用数据源。对这些数据源的访问打包在4个不同的包中，以更为“经典”的数据格式与其它数据库交换，此外还提供了一个“集线器”的体系来支持不同关键事务管理应用之间的数据交换（现在通常称为B2B或电子商务数据交换）。可靠的2层体系是快速和可靠的数据访问的基础。
所有的包都具有一个共同点，那就是对外部数据源的访问是通过异构服务模块来处理的，这个模块是数据库引擎的一部分。
(1) 开放系统网关 – 这些网关提供对最常用的标准RDBMS的访问，并可以访问以下平台上的数据：MS SQL Sever（NT），Informix（Solaris，HP-UX），Sybase（Solaris，HP-UX），Ingres（Solaris，HP-UX），Teradata（Solaris，NT，HP-UX），RDB（Alpha OpenVMS）和RMS（Alpha OpenVMS）。
(2) 主机集成网关 – 这些网关提供对保存在IBM世界（在纯的主机或混合IBM主机/中型环境）中的数据的访问。透明网关通过DRDA提供对MVS上的DB2和AS/400上的DB2/400中的数据的访问， DRDA含盖了Unix、NT和OS/2上的DB2实现。Oracle Pure Extract允许访问存储在IMS、VSAM和其它以前的遗留（legacy）格式（例如顺序文件）中的数据。
(3) 企业集成网关允许Oracle集成到信息交换体系中，例如IBM MQSeries（通过Procedural Gateway to MQSeries），或是通过APPC进行进程间应用过程调用（使用主机中的CICS或IMS/TM）
(4) 通用连接代理使用第三方ODBC或OLE DB驱动程序提供对任何ODBC、JDBC或OLE DB（带有或不带有SQL支持）兼容的非Oracle系统的访问（不支持分布式交易，存储过程或DDL）。
Oracle 9iAS InterConnect（即集成服务器）是新的“集线器”体系产品，允许Oracle在几乎所有的应用（例如SAP R/3）和Oracle Financials之间交换数据。因为内部体系是完全基于XML的，客户可以方便地创建任何新的转换说明，或是使用任何兼容XML的数据源所预先构建的模板。另外，所有经过集线器的数据都可以被保存下来，例如用于归档。
Oracle Catridges（即上下文，音频，图象，空间，时间序列，可视化信息检索）允许扩展关系型数据类型。此外，Oracle还允许用户定义数据类型。
结论
这里的战略非常明了：将DBMS作为企业信息数据源的入口 – 不同数据源之间的用法的不同将被透明处理。两种DBMS都在向着这个方向发展 – 两者的体系结构不同。
本领域显然是DB2的优势，因为它提供集成异构数据源的高级功能。DB2优化器甚至可以针对联合数据源优化查询 – 甚至可以获得更好的性能，尤其采用DB2作为其它非DB2 DBMS的入口时。对数据进行充分的处理，以及面向文档的XML数据源可以利用一个特殊的数据类型来保存XML文档，或是分解到关系型表中，这为DB2又提供了一个优势。
DB2可以从MQSeries队列中读取。而且其它功能也支持对队列进行操作。Oracle的到MQSeries的过程网关是基于一个利用PL/SQL脚本的“旧”的体系。它未来的发展方向是根据应用服务器在应用之间交换数据 – 但这不属于本文档调查的内容。
5.8 安全性
同时为客户和员工提供对业务数据的灵活访问，而且不会影响必需的安全标准，这句话充分描述了现代的安全解决方案所必须要进行的权衡。安全分为几种：
Ø 保护客户机和服务器之间的数据传输
Ø 防止数据库中的数据遭受非法访问（水平和垂直）
Ø 审核对数据的访问，发现任何违反安全性的访问。
DB2 UDB V7.2
DB2不需要用户在数据库中定义用户，它依靠的是DCE或LDAP等安全机制，或是基础的操作系统的安全机制，来进行用户的验证。在逐渐扩展的数据库环境中，这是一项很大的优势，特别是针对大型组织来说就更为明显，因为用户只需要定义一次，用户也只需要记住一个密码。这些用户标识以及已经定义的任何分组，都可以用于授权或是取消他们对数据库的授权，这是由数据库本身完成的。
一旦一个用户经过验证，所有的认证将放置到数据库内。这个用户可以通过主UserID获取访问，主UserId是实际的验证的UserID，也可以通过任何从UserID进行验证，从UserID是与主UserID相关的组的标识。所进行的授权可以与对象相关，例如数据库，表空间和表，也可以与可执行文件相关，例如程序，存储过程，或用户定义的函数。对数据的访问权限，其细化程度可以是对整个表进行某些操作（例如，查询，插入，更新列，或删除），也可以细到只能对某一行的某一列操作。这是通过定义视图来实现的。
在用户认证的过程中，可以配置数据库在传输时对密码进行加密，而不是采用明文的形式。这是一个很重要的安全机制，因为公司的标准往往将密码划归到非常机密一类。
在很多情况下，当配置了一个中间层，例如一个Web应用服务器，数据将被加密，作为这一层提供服务的一部分。但是，当数据需要也以加密的形式存储在数据库中时，数据库也需要提供这样的支持。对于这种类型的需求，DB2提供了一组内置的加密和解密函数。
Ø ENCRYPT函数使用基于密码的加密算法对数据加密。加密函数还允许保存一个密码提示，提供另一个函数来在没有密码时获得提示。
Ø DECRY_BIN和DECRY_CHAR函数使用基于密码的解密算法进行解密。
Ø GETHINT函数返回一个打包的密码提示，这个密码提示是数据拥有者定义的。
DB2还在产品中内置了广泛的审核功能。这个工具基于事件监视数据，对它可以进行定制，以便以自动化的方式满足特定的需求。
Oracle9i
Oracle允许DBA为每个用户定义需要进行检查的访问权限：外部用户由操作系统进行检查，内部用户无需本地操作系统帐户，只存在于数据库内（可以作为无模式用户存在）。
通过Oracle Internet Directory（OID）支持LDAP。可以方便地集成外部的验证适配器，例如RADIUM ，DCE ，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引入可一个很有前途的新的概念来实现行级安全性，替代原来的视图方式。
5.9 符合标准性
符合标准性对于数据库这个团体来说很重要。以下各种不同类型的标准对于数据很重要：
(1) 编程接口：这些标准用于程序与数据库的通讯，例如JDBC，ODBC
(2) 标准化的SQL允许应用程序独立于存放数据的数据库访问和操作数据对象
(3) 元数据标准简化了异构工具之间的解决方案集成
DB2 UDB V7.2
IBM是在DB2旗帜下编写“标准”的。IBM作出了战略合作决策，广泛地支持并领导标准的创建。DB2符合所有重要的编程接口标准。DB2 CLI基于X/Open和ISO调用等级接口标准，它基于ODBC。许多CLI程序在ODBC下无需修改。DB2包括了一个ODBC和一个CLI驱动程序。在Java应用方面，可以使用JDBC或SQLJ，两者都已经是行业标准。DB2 支持Microsoft数据对象标准DAO，RDO，ADO 和OLE DB。如果您的编程语言是Perl，您将可以使用标准数据库API – Perl DBI。
SQL99标准是一个巨大的长卷，尽管没有一个重大的数据库提供商符合整个的标准，DB2的SQL符合这个SQL标准。DB2包括CASE语法以及其它各种形式的外联接。DB2与其它数据库的不同之处在于DB2 的存储过程语言，它与ANSI的SQL99标准的永久性存储模块相一致。
DB2支持Object Management Group的通用仓库元数据交换。在V7.2中，您可以导入和导出通用仓库元模型XML对象。
XML是电子商务环境中交换数据的标准，自从它进入DBMS就得到支持，标准支持已经增强到UDDI和SOAP，这两种标准都支持电子商务的需要。
Oracle9i
Oracle在标准化方面具有悠久的历史，它与IBM一起，是众多不同标准的主要贡献者。
Oracle 9i现在在很大程度上符合ANSI/ISO SQL1999。这个包括以前所没有的功能：
Ø Coalesce
Ø Case
Ø 永久存储模块
Ø 时间戳（带有时区）
Ø SQL99 联接语法
Ø 全外联接
Ø 对象关系扩展中的继承
而且Oracle支持所有主要的编程接口，例如ODBC，JDBC（胖和瘦实现）以及其它接口，大多都是它们的最新版本。
此外，Oracle还支持WebDAV – 基于web浏览器的文件访问标准。
与IBM一样，Oracle还完全支持通用仓库元数据交换（CWMI）。
结论
Oracle9i和DB2 UDB 7.2现在都支持大多数和DBMS通讯的标准。
但是，在实现这些标准的时候，它们采用的是不同的战略。Oracle的方法基于历史实现，对标准的支持采用补充以前的专用实现的方法。它的首选是Oracle的专用实现。IBM将标准看作是唯一的DBMS通讯的途径。这就意味着在大多数情况下，从DB2向其它DBMS移植要比从Oracle向其它DBMS移植容易。
IBM对开放型和标准化方面的更大承诺表现在它总是从战略上首先支持标准，这方面的一个很出色的例子就是SQL99和基于XML/SOAP/UDDI的Web服务。我们从这些事实中可以看出IBM的DB2在这一领域具有相当大的优势。
5.10 集成
DBMS集成是一个核心的方面，它与开发的效率以及投资保护相关。尽管通常总是强调应用和DBMS独立，但实际的实现却是另外一回事了。随着数据和用户的增加，以及功能复杂性的提高，独立的工具和应用提供商已经认识到紧密地与一个优选的数据库集成非常重要。
此外，在决策支持应用中对企业数据集成的需要已经越来越高。利用数据库提供的其它数据管理功能是适宜的，尽管这将意味着依赖DBMS引擎，因为这些特性几乎是“免费”提供，并允许快速开发。对于商业智能功能，尤其是ETL，调度，OLAP和挖掘功能来说，这种需要已经变得非常明显。
最近的“集成”方法解决的是电子商务体系、应用服务器集成和消息功能。电子商务集成从本质上来说意味着当启动某些业务过程时确保数据集成。因此将业务功能和实际的数据存储集成，DBMS的作用至关重要。此外，这种集成可以降低应用的复杂性，为企业带来更多的优势。但是，电子商务集成的特性还将意味着处理应用服务器和消息体系和产品，以及相关的标准（例如EJB）。这些不在本文的讨论范围之内。
集成的一个重要方面，但不是最后一个方面，就是DBMS提供商使用的合作战略：提供商是希望自己的解决方案涵盖所有的领域（“单提供商解决方案”），还是希望依赖核心能力并与其它“最佳组合”解决方案提供商合作？
DB2 UDB V7.2
DB2 在三种不同的集成级别上向DBMS中集成软件：核心数据库引擎，扩展器和来自多个公司（包括IBM自己）的独立的产品。
IBM的中心是将当前分布在单独的产品中的功能集成到数据引擎中，即
Ø 商业智能功能
Ø 通过SQL提供OLAP服务
Ø OLAP服务器功能集成在OLAP启动套件中
Ø 集成数据仓库中心，来支持数据仓库的整合和发布，并涵盖ETL和调度功能
Ø 集成信息编目，支持仓库知识库（repository），用于浏览和交换仓库的元数据
Ø DataJoiner将逐渐集成到核心引擎中：在V7.2中可以读访问Oracle，Sybase和MS SQL Server
此外，DB2通过扩展器来集成非关系型数据类型。这些功能现在已经存在（文本，视频，音频，地理空间），并将进一步增强：
Ø 数据挖掘功能（Inteligent Miner Scoring）；
Ø 通过XML类型的列或是分解到多个关系数据表中，集成对XML的支持，支持导入和导出XML文档。
在应用集成方面，IBM正采取最佳组合的方法，在战略上与领先的应用提供商合作，一起提供解决方案套件（例如SAP AG, Siebel Systems Inc., Ariba Inc., i2 Technologies Inc., PeopleSoft Inc.）。作为交换，这些公司利用DB2作为它们首选的DBMS。这种合作方法包括前端和后端办公解决方案以及对复杂的数据管理和数据仓库功能的支持（例如与Informatica，ETI，Vality Technology，Evoke Software的合作)。
Oracle9i
Oracle采用的方法与IBM相类似，将以前不被认为是DBMS的功能添加到核心数据库引擎中。例如商业智能功能 – Oracle现在提供集成的OLAP服务（Java OLAP API，计算引擎和分析工作空间）；多表插入和upsert（如果存在则更新，否则插入）降低了ETL过程的复杂性。
数据仓库被单独的工具进一步利用：Warehouse Builder for ETL和Workflow Builder for scheduling。
为了支持Internet集成，集成了XML数据类型和功能来填写和查询内容。
在提供完整的软件方案方面，Oracle的战略是为客户提供一个完整但却紧密集成的软件包 – Oracle软件中囊括了企业用以管理它的金融、制造、销售队伍、后勤、电子贸易和供应商的所需的所有应用。
结论
IBM和Oracle都将他们的DBMS同时定位在业务系统（关系型和对象型）和决策支持应用领域。数据仓库领域更是其中的焦点，提供了丰富的功能：DB2从7.1版开始集成数据仓库中心和OLAP启动套件；数据仓库管理器已经拥有众多适配器，并将逐渐提供更多的外部数据适配器，当前提供的适配器包括SAP，i2和Websphere 站点分析器。从7.2开始，DB2通过DB2扩展器提供集成的挖掘功能。在最近的DB2版本中，还添加了SQL的OLAP扩展（根据SQL3标准 - ISO99）的支持。现在提供的功能颇具吸引力，并与MDBMS解决方案竞争。Oracle最近只利用OLAP功能丰富了它的数据库引擎。ETL功能是利用Warehouse Builer提供的，Workflow Manager提供调度安排。
在这个领域，DB2适配器稍稍领先Oracle。OLAP扩展以及ETL工具之间的功能差别需要实际进行评测和比较，这项任务比较复杂，所以本文没有进行评测。当OLAP工具提供商开始使用这些扩展时，这些功能的好处仍然需要进行测定。
双方也关注电子商务应用的集成。其特点是XML，消息服务和应用服务集成。
DBMS的定位为单点访问企业数据（结构化和非结构化，关系型和非关系型），本文在“5.7 连接性/互操作性”进行了详细说明。
从用户的角度来看，Oracle紧密集成软件包的做法是有益的。但只有很少的企业是从原始状态开始的 – 对于其它企业来说，DBMS集成其它提供商的应用和工具的能力更为重要。IBM的战略是成为中间件提供商，并与最佳组合的应用和工具提供商进行开放性的合作，这一战略更适合于用户自由选择解决方案的需求。
总之，我们可以看出DB2在这一领域占据领先地位 – 原因并不仅仅是IBM的合作战略。
李守亮整理 [email protected]
2003-03-21