Oracle Database 11g 和SQL Server 2008 技术比较：针对可 ...

Oracle Database 11g 和 SQL Server 2008 技术比较：针对可

管理性

Oracle 白皮书 2008 年 12 月

Oracle Database 11g 和 SQL Server 2008 技术比较：针对可管理性第 2 页

Oracle Database 11g 和 SQL Server 2008 技术比较：针对可管理性引言........................................................................................................3 管理工具 ................................................................................................3 存储管理 ................................................................................................5 空间和对象管理......................................................................................6

主动空间管理......................................................................................6 联机重新组织......................................................................................7 行大小限制 .........................................................................................7 处理空间用尽状况...............................................................................8

性能管理 ................................................................................................8 性能诊断 .............................................................................................8

性能统计信息收集...........................................................................9 性能对比分析 ..................................................................................9 活动会话历史记录 (ASH) ...............................................................9 自动性能诊断 ................................................................................10

识别和调优高负载 SQL 语句...........................................................12 自动 SQL 调优 ................................................................................14 调优打包的应用程序 .........................................................................15 执行计划稳定性 ................................................................................16 管理资源 ...........................................................................................17

更改保证 ..............................................................................................18 负载测试 ...........................................................................................18 确保 SQL 性能 ................................................................................19

备份与恢复 ...........................................................................................20 备份文件管理....................................................................................20 完备的备份 .......................................................................................21 智能恢复 ...........................................................................................21 从人为错误中恢复.............................................................................22

恢复已删除的表 ............................................................................22 从逻辑数据损坏中恢复..................................................................23

安装与配置 ...........................................................................................24 实例创建 ...........................................................................................24 数据库复制 .......................................................................................24 安装克隆 ...........................................................................................25

软件维护 ..............................................................................................26 打补丁 ..............................................................................................26 故障诊断 ...........................................................................................27

跨平台可移植性....................................................................................28 可伸缩性 ..............................................................................................28 总结......................................................................................................30


Oracle Database 11g 和 SQL Server 2008 技术比较：针对可管理性

引言在可管理性方面，SQL Server 一向是 Oracle 的主要竞争对手。这两家

供应商已将增强其数据库服务器的可管理性作为自己的一项主要目标，

他们不断在每个新推出的版本中增加新特性以使数据库管理更加轻松和

经济高效。但是，尽管 SQL Server 2008 针对可管理性增加了一些新特

性，但它仍然落后于 Oracle Database 11g。Oracle Database 11g 是一

个成熟的具有自我管理能力的数据库，它能够自动进行自我监视、自适

应和自我修复。Oracle 数据库的自我管理解决方案使 DBA 的工作更为

高效，有助于其组织在不降低服务级别目标的情况下降低管理成本。

SQL Server 的新版本意在赶上 Oracle 已通过其 Oracle Database 11g 新版本引入的可管理性特性，Oracle 发布该新版本时引入的这

些特性在当时显著扩大了两家竞争对手之间的差距。

管理工具 Oracle 和 SQL Server 分别提供了 Oracle Enterprise Manager 和 SQL Server Management Studio 来管理和维护其系统，这两个工具均

为 GUI 工具。Enterprise Manager 11g 是 Oracle 提供的用于管理和

监视基于 Oracle 和第三方组件的应用程序和系统的统一、集成的解决方

案。该工具能够通过单点控制无缝地管理跨组织和地理边界的成百数千

的系统。Enterprise Manager 具有基于 web 的体系结构，该体系结构

强健、可靠、可伸缩，并且在当今互联网驱动的环境中易于部署和运

营。该工具提供一个基于 HTML 的控制台界面，通过该界面，管理员可

从任何位置进行管理 — 只需一个 Web 浏览器即可。其强健的分组和

任务自动化功能提供的核心特性使以前耗时、易错的任务（如应用性能

管理、基于策略的标准化和系统供应）能够可靠、迅速、安全地自动进

行。从以数据库为中心的角度来看，Enterprise Manager 极大地简化了

数据库的日常管理，将这种简洁性与一组丰富特性相结合可以管理所有

操作系统平台上任何规模的环境。通过提供以下能力，该工具使许多关

键管理任务能够自动进行，从而提高了管理员的工作效率：


• 在数据库创建过程中配置和启动所有必要的框架组件进程，

Enterprise Manager 提供的功能随即可用。一旦创建了新的数据

库，Enterprise Manager 即已完全配置并且可以使用了。

• 在主页面上提供企业运行状况的统一概览。它显示数据库的可用

性、警报和作业状态、配置信息、重要补丁的软件维护公告，并且

能够追溯所有这些方面的更多详细信息。

• 系统监视和警报通知，目的是预测问题并且如有可能，使用 “fix-it” 作业自动纠正问题。

众多 Oracle 客户，如 British Telecom、Boeing、Telstra、Fidelity 和 Shell，已围绕 Enterprise Manager 进行了标准化实施以管理他们的生

产系统。这些客户的经历生动地证明了 Oracle 的管理工具在提高管理

员工作效率、提高每位 DBA 可以管理的数据库数量方面是多么的富有

成效。

Oracle Enterprise Manager 能够提供深度管理，而 SQL Server Management Studio 缺乏深度管理能力。后者不具有基于 HTML 的控

制台界面，因而，对于管理员想要通过其管理 SQL Server 数据库的所

有系统，均需安装相应的客户端工具。这大大限制了管理员随时随地管

理其数据库的能力。SQL Server 的管理工具所存在的另一个缺陷是，它

不能通过单个控制台提供对整个系统的端到端的管理和诊断。SQL Server 的管理工具不能监视有关操作系统、中间层应用服务器的度量信

息。

Oracle 和 SQL Server 之间的另一个不同之处是它们的管理模式。

Oracle Enterprise Manager 遵循的是基于异常的管理模式，在这种模式

下，只有在发生或即将发生异常状况时才需要 DBA 的干预。Oracle 在其主页面上突出显示出问题区域，如空间压力、性能问题等，这样人们

可立即发现并处理任何潜在的问题或异常。而 SQL Server 的方式与此

非常不同，在 SQL Server 的方式下，DBA 只能靠自己来监视系统以

发现潜在的问题。例如，如果一条 SQL 语句运行了很长时间还没有结

束，在 Oracle Enterprise Manager 11g 主页面的诊断汇总区域下会主

动显示出这条语句。相比之下，对于 SQL Server，DBA 必须先对该数

据库开启监视计数器（这显然会对性能产生负面影响），重新运行该工

作负载（这可能不会总是可行的，并且永远是不方便的），然后对跟踪

文件进行分析以确定哪条 SQL 语句占用的资源多。只有这样 DBA 才能知道是否存在正在影响系统性能的任何问题 SQL。因此，与 Oracle 的管理工具不同，SQL Server 的管理工具需要其用户投入相当

多的时间来执行通常的管理工作，其管理方式本质上是被动的而不是主

动的，并且缺乏 Oracle 提供的许多管理功能。


存储管理数据库管理员在存储管理方面面临着诸多挑战。数据库的规模在迅速增

长，而人们还要求数据库正常运行时间也要不断增长，这种情况下，越

来越难以安排时间来使数据库脱机以进行维护操作（如更改磁盘配

置）。此外，系统管理员查找并消除 I/O 热点或碎片问题的过程可能十

分辛苦。与此同时，降低成本的压力不再允许扩大 DBA 队伍以应对数

据库的高速增长。这种情况将导致所谓“管理空白”的产生。DBA 需要

更好的工具以便能够提高工作效率并帮助使其手动任务自动进行。

自动存储管理 (ASM) 是 Oracle 数据库的一个特性，该特性首次在 10g 版数据库中引入，它通过使整个功能自动化进行而提供了应对上述存储

管理挑战的解决方案。管理员只需要将一组存储设备分配给一个数据库

实例，所有其它工作则由 Oracle ASM 解决方案自动完成。ASM 将数

据库文件自动存放于指定的磁盘组中，并将数据均匀分布于所有可用存

储资源上以大程度提高性能和利用率。对数据库文件的这种均匀分布

使得人们不必再手动进行 I/O 性能调优。ASM 还提供了三个镜像选项

以防止磁盘故障：无镜像、双重镜像和三重镜像。此外，有了 ASM，

DBA 不必使数据库脱机即可更改存储配置。在添加或删除磁盘后，ASM 自动在磁盘组中重新均衡分布文件。

ASM 特性专为简化存储管理工作而构建。该功能可节省管理员的时间并

提供高效管理动态数据库环境的灵活性。

SQL Server 不具备 Oracle 所提供的诸如此类的任何存储管理功能。存

储管理只能通过 SQL Server 2008 引入的共享与存储管理控制台手动进

行，或者，只能购买另一个工具来提供此功能。


空间和对象管理主动空间管理

Oracle 通过其空间监视、通知和空间趋势特性提供主动空间管理。

Oracle 数据库服务器并非通过使用外部工具对数据库进行轮询来监视空

间的使用情况（本质上来讲，这种方法要占用大量资源），而是具有内置

的智能，能够提供对数据库空间使用情况的非侵入性、及时的检查。如果

表空间的空间使用超过了用户定义的阈值，Oracle 服务器会发出警报来

预先警告相应人员（即 DBA）数据库即将用尽其空间，这样 DBA 就可

以采取纠正措施。默认情况下，Oracle 会在表空间占用达到 85% 时发

出一个警告性的警报，在表空间占用达到 97% 时发出严重警报。DBA 可以覆盖指定表空间的这些默认值（以已使用空间百分比的形式，或以字

节计的可用空闲空间总量的形式），还可以对整个数据库设置新的默认

值。一旦采取了纠正措施，警报即被服务器自动清除。

Oracle 还提供了完善的警报通知系统。DBA 可通过电子邮件、寻呼机、

Enterprise Manager，或者直接通过查询数据库服务器中的视图来接收警

报。

Oracle 空间管理的关键之处在于其效率。数据库服务器跟踪空间使用情

况，同时执行常规的空间管理操作，如分配新的 extent。一个后台进程

将表空间的状态与指定的阈值相比较，以确定是否发出或清除一个警报。

出现状态转换时，执行相应的操作，触发或清除一个警报。

Oracle 的主动空间管理在默认情况下处于启用状态，它对系统的性能影

响是可以忽略不计的。

SQL Server 也具有监视空间使用情况的功能，但是它在以下几个方面不

同于 Oracle。首先，它使用 SQL Server 代理来监视空间的使用情况，

这个代理的主要功能是作业调度和警报处理。因此，其监视和警报机制基

于对数据库元数据的轮询，这种技术本质上讲效率低下且开销过高。其

次，SQL Server 的空间监视和警报基础架构不如 Oracle 的灵活。SQL Server 只允许用户在数据库一级设置用于警报的空间使用阈值。这意味

着，如果您有两个不同的文件组（也就是 Oracle 术语的表空间），一个

用于表，另一个用于索引，而您想对它们分别设置两个不同的警报阈值，

这是一个非常基本的要求，但是您却办不到。而 Oracle 允许在数据库级

或表空间级设置警报阈值。这增加了监视的粒度，使 Oracle DBA 能够

更为灵活和精确地设置空间使用准则以满足服务级别协议的要求。

联机重新组织

Oracle Database 11g 允许管理员联机执行几乎所有的段维护操作，即在

执行段维护操作的同时，完全可以对数据进行查询、更新和删除。

Schema evolution 使得可以在数据表处于服务状态时对表定义进行修

改。可以对表进行重定位、碎片整理、重新组织，或者对其存储参数进行

更改。可以联机添加索引、重建索引或对其进行碎片整理。

SQL Server 对联机操作的支持不如 Oracle Database 11g 广泛。SQL Server 只是在近才增加了联机创建、重建、删除索引的功能。这允许

在对索引执行 DDL 操作时对底层表或集群索引数据和任何相关索引进行

并发修改（DML 操作）。这是对早期 SQL Server 版本的重大改进，在

早期版本中，索引创建/重建操作需要获得底层数据和相关索引的排它

锁，从而在完成该索引操作之前阻止对其进行修改或查询1。Oracle 许多

年前就已提供了这一功能，而且目前 SQL Server 仍然不具备 Oracle 所提供的联机 Schema evolution、表重新组织以及表重新定义这些功

能。这些维护操作中有许多是经常进行的操作，可能花费数小时才能完

成，因此 SQL Server 2008 应用程序用户可能要忍受明显的数据不可用

性带来的痛苦。为了对付这一问题，SQL Server DBA 必须精确巧妙地

安排执行这些操作的时间，以便减少系统不可用之影响。这极大地增加了

其 DBA 的管理工作量。而对于 Oracle DBA 来说，在他们的日常操作

中对此是一点也无需顾虑的。

行大小限制

除少数例外，SQL Server通常对记录行的大小加以 8060 字节 (8KB) 的限制。但在某些情况下这一限制会放宽，具体来说，对于包含 varchar、nvarchar、varbinary 或 sql_variant 列的表该限制会放宽。这些列中每

一列的长度仍然必须在 8KB 的范围内，然而它们加在一起的宽度可以超

过表的 8,060 字节行限制。这适用于 varchar、nvarchar、varbinary 或 sql_variant 列，无论是在更新或插入数据时，还是在创建、更改这些列

时都是如此2。对于不在上述例外情况之内的表，SQL Server DBA 只能

以某种方法来克服 8KB 行大小的限制。在这种情况下，SQL Server DBA 的通常做法是垂直地将该表划分为多个表。这种做法尽管解决了 8KB 限制的问题，却造成了另一问题，它使得应用程序的设计达不到

佳。这又是一个 Oracle DBA 无需顾虑的方面。Oracle 允许一个记录行

跨越多个页面（Oracle 称之为块），对其行大小不加限制。

1 面向数据库管理员的 SQL Server 2008 测试版 2 概述，

www.microsoft.com/technet/prodtechnol/sql/2008/maintain/sqlydba.mspx2 SQL Server 2008 在线书籍，数据库设计与创建，表设计。


http://www.microsoft.com/technet/prodtechnol/sql/2008/maintain/sqlydba.mspx


处理空间用尽状况

数据加载、批处理更新之类的操作在空间用尽时会遇到错误。遗憾的

是，这些错误有时发生于操作即将完成之时。Oracle 通过其可恢复空间

分配特性，以一种无中断的方式来处理这类错误。当操作遇到空间用尽

的情况时，该操作留滞于“挂起”状态，同时系统产生一个警报来将问

题通知给管理员以便纠正该问题。一旦错误状况得以纠正，这个被“挂

起”的操作就立即自动恢复。在问题是瞬时的情况下（例如，一个查询

用尽了临时空间），可能不需要管理员的干预，因为一旦该瞬时问题消

失，Oracle 会自动恢复该操作。实际上，任何类型的操作，不论是 PL/SQL 或 Java 存储过程、DML 或 DDL 语句，还是导出/导入或加

载器会话，均可运行于“可恢复”模式。

该功能为 Oracle 所独有，在 SQL Server 中没有类似的功能。SQL Server DBA 要花费大量的时间来监视操作进度和重新执行需要长时运行

的失败的操作，而 Oracle DBA 却因为此功能而节省了大量的这类时

间。在 SQL Server 中，如果操作在其运行过程中遇到空间用尽的状

况，只能在解决了空间问题之后重新运行整个操作。这种方式不仅浪费

时间，还可能有碍数据库的正常性能，例如，DBA 不得不在正常的工作

负载时段重新运行失败的批处理作业，这有碍于数据库的正常性能。通

过以无中断的方式来处理空间用尽状况，Oracle 的可恢复空间分配特性

避免了 SQL Server 用户可遇到的所有这类问题。

性能管理性能诊断

性能诊断是 DBA 使用的非常重要的功能，往往被认为是即复杂又耗时

的。Oracle Database 11g 提供了自动性能诊断和监视技术，该技术内

置于数据库服务器中，能够使整个性能诊断过程自动进行，并且在遇到

性能问题时可提供详细信息及其纠正措施。


性能统计信息收集

Oracle Database 11g 维护着一个容纳系统运行相关信息的信息库，该信

息库名为自动负载信息库 (AWR)。这个基础架构是 Oracle 的性能诊断

解决方案的一个关键构建块。它自动运行以收集有关 Oracle 系统运行的

性能数据并将这些数据存储于数据库中。作为数据库内核的一部分，

AWR 以佳方式捕获为相关的数据。对它的设计目标是轻型、可自我

管理。它自动地每小时捕获一次数据，每 8 天清除一次数据。该数据捕

获频度以及数据保留时长是可以配置的。此外，AWR 还可按需运行，以

便随人们的意愿在特定时间捕获信息。

AWR 捕获所有需要的数据，根据这些数据足以执行彻底的系统级或用户

级性能分析。通过主动捕获数据，使人们不再需要为了进行问题诊断而重

新运行负载。

AWR 为改善 Oracle Database 11g 中的性能诊断工具打下了基础。正

是在 AWR 提供的数据基础上，自动数据库诊断监视器（Oracle 的性能

诊断引擎）才能执行分析以发现和纠正性能问题。

性能对比分析

Oracle Database 11g 还提供丰富的报告和性能基准功能以促进性能对比

分析。一个性能基准包含某特定时段的性能数据，该数据是受保护的，不

会被清除。之后可以使用该基准来与任何其他时段的性能相对比。通常，

您会在数据库的运行性能参数处于可接受范围时创建一个基准。之后，如

果您察觉到性能背离了其常规状态，您随时可以运行 AWR 比较时段报

告，该报告将确切地告诉您，与基准时段相比发生了什么变化。该报告指

出两个时段之间所有不同的性能属性和配置设置，有助于迅速找出性能背

离常规的原因。

活动会话历史记录 (ASH)

活动会话历史记录 (ASH) 是 Oracle 内核收集的、作为 AWR 快照一部

分保存的另一类重要统计数据。ASH 抽样采集所有活动会话的当前状

态，所谓活动会话就是连接到数据库并且在当时正在使用 CPU，或者正

在等待非空闲事件的会话。ASH 每秒对活动会话进行一次状态采集，采

集到的数据被保存到系统全局区域 (SGA) 的循环缓冲区中。ASH 数据

还会经由 AWR 快照处理写到永久存储中。

活动会话历史记录使我们能够“回到过去”并进行极为详细的分析，通常

能使我们不必重放负载来收集额外的性能跟踪信息以作为性能诊断的一部

分。举例来讲，通过 ASH 报告，我们可以诊断瞬时性能问题、锁定问

题、事务长时运行问题、高开销 SQL 语句、占用数据库 CPU 多的

用户、普遍性的性能问题（DB 时间的多维聚合以进行偏差分析）。


自动性能诊断

自动数据库诊断监视器 (ADDM) 是 Oracle 数据库的一个特性，它主动

分析 AWR 中现有的大量性能统计信息，向 DBA 准确指出问题所在以

及如何纠正该问题。由于 ADDM 是数据库内核的一部分，不是一个外部

工具，因此，与传统监视系统相比，其诊断开销可以忽略不计。该代码工

具的引入对 Oracle Enterprise Manager 11g 所支持的实时反应性的调优

方法的功能提供了支持和进一步的增强。

ADDM 每小时主动运行一次，并报告数据库的运行状况。AWR 在默认

情况下对所有性能相关信息的保留时间为 8 天，这使 DBA 能够对该保

留时段内发生的任何问题进行诊断。DBA 只需查看相关时段的 ADDM 报告并实施它提出的建议。

下面总结了 ADDM 具备的主要优势：

1. 每小时一次的自动性能诊断报告。

2. 基于时间的量化的问题影响以及建议。

3. 查明根本原因，而不只是症状。

4. 由于 AWR 中保留的数据十分完整，因此极大减少了为进行详细分

析而重放负载的需要。

在 Oracle Database 11g 中，提供了对 Real Application Clusters (RAC) 数据库的集群级性能分析，从而增强了 ADDM。对于 RAC 环境，

ADDM 分析 RAC 集群，对当前影响整个数据库及其各个实例的问题加

以报告。ADDM 针对全局资源执行数据库级分析，如高负载 SQL、全局

缓存互连流量、网络延迟问题、实例响应时间偏差、I/O 容量等。DBA 能够限制 ADDM 分析只对 RAC 集群的一些指定的实例来进行。这称

作局部分析 ADDM，它只能通过 PL/SQL API 来使用。有了针对 RAC 的 ADDM，对 RAC 数据库的性能分析就象对单个实例数据库的性能分

析一样简便。

在 Oracle Database 11g 中，DBA 可以通过过滤和只显示其感兴趣的 ADDM 结果来隐藏其他的 ADDM 结果。为了在以后更好地理解这些结

果的影响，每个结果都有一个便于搜索的描述性名称、一个指向该结果在 24 小时内出现的次数的链接，以及一个指向受影响的实例的链接。


对于 ADDM 的自我诊断功能，SQL Server 完全不具备类似功能。对于 SQL Server 来说，所有性能问题只能通过手动方式来监视和诊断。在 SQL Server 的性能诊断过程中，DBA 首先必须根据要分析的问题类型

来决定使用哪种工具来监视性能。对于内存、磁盘和 CPU 操作的监

视，您可能会使用 Windows 操作系统的系统监视工具。而为了诊断 SQL Server 中其他类型的问题，DBA 必须从以下工具中进行选择：

• SQL Profiler

• SQL Trace

• SQL Server Management Studio Activity Monitor

• SQL Server Management Studio Graphical Showplan

• Database Console Commands (DBCC)

诊断过程的下一步是指定要监视的组件。举例来说，如果使用 SQL Profiler 来跟踪一个服务器，DBA 必须指定该跟踪去收集与其环境有关

的特定事件的相关数据。

在指定要监视的组件后，下一步是确定要监视的组件的指标。例如，在选

择跟踪要包括哪些事件后，DBA 应选择只包括这些事件的特定相关数

据，以便降低执行该跟踪时对系统资源的需求。

只有在完成所有上述步骤之后，DBA 才可以开始对该服务器进行实际监

视。之后，作为监视结果而生成的跟踪文件只能手动加以分析以找出性能

问题的原因。SQL Server 的性能诊断过程不仅笨拙耗时，还需要专业的

性能工程师查看和理解收集的数据，并且在对性能问题提出纠正建议方面

毫无帮助。SQL Server 方法的另一个局限是，它在本质上是被动的。举

例来讲，如果 SQL Server 系统的运行速度减慢，DBA 首先要使用 SQL Profiler 来启用跟踪，接着重新运行负载，之后才可以对诸如 SQL 性能不佳等性能问题进行任何的分析。与之相反的是，如果 Oracle 系统

的性能表现低于预期，DBA 只需查看当前的 ADDM 报告即可找出真正

的原因及其纠正措施。

在新的 SQL Server 2008 版本中，Microsoft 增加了一个新的名为 Management Data Warehouse 的特性并且大力推广之。这是一个新的

集中式数据信息库，可配置的性能数据收集和新的报告和监视工具用它来

存储性能数据。为了对性能问题进行有效的诊断，DBA 需要知道系统出

现问题之前的状况。在 SQL Server 2008 中，这三个特性：Data Collector、Management Data Warehouse (MDW) 和专业的性能报告被

认为可以解决这一问题。


支撑 SQL Server 的 MDW 的理念远非创新性的理念。它和 Oracle 的 AWR 有点相像，但 Oracle 的 AWR 在多年前即已通过 Oracle Database 10g 而推出。因此，这一次，SQL Server 又重演了通过复制

其竞争对手以前版本中的特性来追赶 Oracle 的一幕。另外，与 Oracle 的 AWR/ASH 框架相比，MDW 本身还存在不足。它不象 Oracle 那样

是现成配置的，在默认配置下它每日对每个实例收集的数据量可达 0.5GB 之多。可通过 SQL Server 的中心管理控制台 Management Studio 更改默认收集设置。

总之，Oracle 在性能诊断方面优于 SQL Server。它提供的解决方案是

如此的全面和强大，甚至连新手也能轻松纠正性能问题。一直在模仿 Oracle 旧版本特性的 SQL Server，现在仍然采用的是手动的调优方

法，这种方法既被动，又需要专业技能，并且十分耗时。

识别和调优高负载 SQL 语句

DBA 可能会花大量时间去发现占用大量资源的 SQL 语句并对其进行调

优。在这一方面，Oracle 使这一工作可完全自动化进行。ADDM 可主动

识别高负载的 SQL 语句。Oracle DBA 只需查看 ADDM 报告（该报告

每小时自动生成一次），看是否存在需要注意的高负载 SQL 语句。除了 ADDM 之外，Oracle 还在自动负载信息库 (AWR) 中每小时捕获一次高

负载 SQL 语句。这类语句会显示于 Enterpriser Manager 11g 的 Top Activity 页面上。

在 SQL Server 中，识别高负载 SQL 语句的过程要复杂得多。DBA 首先要通过 SQL Profiler 建立一个跟踪事件，启用相关事件，然后重新运

行负载以便在跟踪文件中捕获到运行时统计信息。在跟踪文件生成之后，

DBA 还得手动进行分析以便找出高负载 SQL 语句。这对于 SQL Server 管理员来说是一个很大的可管理性问题，原因如下：首先，对占

用大量资源的 SQL 语句进行监视是数据库管理员常见的管理工作，因

此，如果为了获取该信息而花费超过数分钟的时间常常是不可接受的。其

次，如果系统繁忙，则生成的跟踪文件的大小可能很容易就迅速增长到非

常之大，从而非常难于从中提取有意义的信息。在使这件非常重要的 DBA 任务自动化进行这一方面，SQL Server 非常明显地落后于 Oracle。

接着要对 SQL 语句进行调优。Oracle Database 11g 提供的 SQL Tuning 和 Access Advisor 使这一过程也能自动进行。这些工具用一个

或多个 SQL 语句作为输入，以一种特殊的调优模式调用查询优化器以对

这些 SQL 语句进行全面的调优。其中会执行四种分析：


• 统计分析：查询优化器需要新的对象统计信息以产生良好的执行

计划。该分析过程会识别出统计信息陈旧或缺失的对象并收集缺失

的统计信息。应注意的是，Oracle Database 11g 是自动进行统计信

息收集的。因而，只有在自动统计信息收集特性被人为禁用时，才

会出现此类问题。

• SQL 配置文件生成：这是以前在 Oracle Database 10g 中引入的

一个新特性（请不要与 SQL Server 的 SQL Profiler 工具相混淆，

SQL Profiler 基本上是一个用于跟踪文件管理的 GUI 界面），该特

性彻底改革了 SQL 调优方法。由于该特性的出现，我们不再需要

根据优化器提示手动对 SQL 语句进行调优，该特性会为我们进行

语句调优，而无需对 SQL 代码进行任何更改。在该分析过程中，

一条 SQL 语句的配置文件称作一个 SQL 配置文件，对这条语句

建立的 SQL 配置文件包含了该语句特定的辅助统计信息。由于缺

少查询中有关不同对象之间关系的信息，查询优化器有时生成的执

行计划可能不是佳的。在过去，Oracle 和 SQL Server 均需通过

在代码中手动添加查询提示来处理此问题。现在，由于有了 SQL 配置文件功能，Oracle 不再需要这种手动过程了，因为 SQL 配置

文件功能通过采样和部分执行技术来收集额外的信息。另外，从 Oracle Database 11g 开始，SQL Tuning Advisor 用建议的 SQL 配置文件产生的新执行计划对 SQL 语句进行测试执行。这极大提

高了 SQL Tuning Advisor 建议的准确性和可靠性。

• 访问路径分析：索引、分区和物化视图可减少全表扫描的需要，从

而极大地提高 SQL 语句的性能。该分析过程可找出能够极大提高

查询性能的新的索引、分区、物化视图 (mv) 和 mv 日志。

• SQL 结构分析： SQL 语句若存在结构问题则可能导致性能不佳。

这些问题可能是语句的语法、语义或设计问题。该分析过程提出重

构 SQL 语句的建议以便提高性能。

通过执行上述分析并提出合适的操作建议，Oracle Database 11g 及其 SQL Tuning 和 Access Advisor 提供了一个全面的 SQL 调优解决方

案，该解决方案使得人们不必再进行费时费力代价高昂的手动调优过程。


在这一方面，SQL Server 只提供了一个片面的解决方案。除了手动添加

查询提示外，它没有提供其他的 SQL 调优方法，在对结构不良的 SQL 查询进行重写这一方面也没有提供任何帮助。所有这些均需手动完成，这

需要深入了解 SQL Server 的优化技术。它只在簇索引、非簇索引和索

引视图的生成这一方面提供了帮助，这依靠的是它的 Database Tuning Advisor，Database Tuning Advisor 是其 Index Tuning Wizard 的增强

版本。Database Tuning Wizard 提供了一些在 Index Tuning Wizard 中所没有的新选项，如时限调优，通过这一选项，用户可以指定该 advisor 对语句进行分析所花时间的限制，另外，还提供了执行实例级调优的能

力。所有这些调优选项及其他一些调优选项早已是 Oracle 的 SQL Tuning 和 Access Advisor 的组成部分。虽然 SQL Server 的 Database Tuning Advisor 有助于对物理数据库设计进行调优，但是它将 SQL 调优中更具挑战性和耗时的工作留给了 DBA 和应用开发人员。

SQL Server 2008 中新增加的功能是针对查询性能稳定性和可预测性

的计划冻结功能，该功能用于锁住查询计划，从而使组织能够在进行硬件

服务器更换、服务器升级和生产部署时推广稳定的查询计划。此特性非常

类似于 Oracle 的 Outlines，Outlines 近来为 SQL 配置文件所代替，

后者是解决 SQL 语句性能不佳问题的一个更为智能的方法。

比起 SQL Server 的解决方案，Oracle 的调优解决方案不仅全面和简

便，而且，它是通过查询优化器自身来进行实际调优的，并非通过外部工

具（外部工具通过各种方法强迫或哄骗优化器产生更好的执行计划），这

是它与 SQL Server 解决方案的另一个重大不同之处。与其他供应商

（包括 Microsoft）提供的调优工具相比，这是 Oracle 的一个重大优

势，因为由查询优化器自身执行的调优操作在质量、可靠性和有效性方面

超过了任何的外部组件。

自动 SQL 调优

与以前的版本相比，Oracle Database 11g 中的 SQL 调优过程已得到了

进一步的增强和自动化。现在，SQL Tuning Advisor 在系统维护时段可

作为一个维护任务而自动运行。每次运行时，它会自动选择系统中高负载

的 SQL 查询并就如何对这些查询进行调优给出建议。

该自动 SQL Tuning Advisor 可配置为自动执行 SQL 配置文件建议。这

意味着数据库会自动对高负载 SQL 进行调优，不需要用户的任何输入或

干预。


您可以查看指定时段内（如前七日）自动 SQL 调优的运行结果汇总，

也可以查看对所有处理过的 SQL 语句提出的建议的详细报告。该自动 SQL Tuning Advisor 经配置可运行于任何维护时段，如果需要，也可完

全禁用它。

SQL Server 没有提供可与 Oracle 的自动 SQL 调优相匹敌的特性，这

主要是因为其 SQL 调优工具只能提供索引建议。SQL Server 的调优工

具不如 Oracle 的解决方案全面，特别是，它们不能帮助执行计划调优，

这意味着它们无法使这种复杂的工作自动进行。在应用程序代码中手动

添加查询提示是 Microsoft 对 SQL 执行计划进行调优的唯一方法，这

种方法永远无法自动进行。

调优打包的应用程序

对打包应用程序（如 SAP、Siebel 或 PeopleSoft）进行调优是对调优

的另一种挑战。由于客户无权修改应用程序代码，任何时候如果在打包

的应用程序中遇到了严重的性能问题，客户只能将其作为缺陷记录下来

发给应用程序供应商，然后就只能等待数周、数月甚至更长时间，直到

收到对该问题的修复代码。在过去，这是数据库管理系统客户所能采用

的唯一办法。而如今，Oracle 为客户提供了另一个办法。其 SQL 配置

文件特性（该特性是 SQL Tuning Advisor 的一部分）无需更改应用程

序代码即可调优 SQL 语句。如前所述，SQL 配置文件包含 SQL 语句

中引用的各种表之间数据关系的相关信息，通过向查询优化器提供此额

外信息来对 SQL 语句进行调优。由于 SQL 配置文件存储于数据字典

中而不是应用程序代码中，它们使得 Oracle 能够透明地调优打包应用程

序。Oracle 是当今市场中唯一具有该功能的商业数据库。Oracle 客户不

必将缺陷记录下来，也不必等待性能问题得以纠正。有了 SQL 配置文

件生成特性，调优可以立即进行。

SQL Server 确实也提供了对打包应用程序进行调优的能力，但是它的解

决方案本质上是重复性的并且必须手动进行。在 SQL Server 2005 中引

入并且集成到了 SQL Server 2008 的 Management Studion 中的计划

指南，是一些可与 SQL 语句相关联的查询提示，用这种方法无需直接

修改应用程序代码。这确实使打包应用程序的调优成为可能，但是仍然

需要 DBA 来确定用于调优 SQL 语句的正确提示。这个过程本质上是

重复而耗时的，需要 DBA 具备 SQL 优化技术的深入知识和专业技

能。而 Oracle 的解决方案是自动、准确和可伸缩的方案。


执行计划稳定性

DBA 的一个渴望是可预测性，对于查询性能来说尤其如此。查询的性能

取决于其执行计划的优化程度。执行计划越有效，查询性能就越好。然

而，Oracle 和 SQL Server 均使用的优化模式 — 基于开销的优化，在

生成查询执行计划时却依赖于数据库环境。因此，数据库环境中的变化，

如底层对象、内存参数等优化器统计信息的变化，可能会突然改变查询执

行计划，大多数情况下这可改善执行计划，但有时也可使执行计划变得很

糟。

在 SQL Server 中这是一个严重的问题，因为该数据库服务器在默认情

况下会不断地重新生成优化器统计信息，从而使执行计划可能会不断变

化。在这种情况下，DBA 只能关闭优化器统计信息自动生成和更新功能

以使执行计划不再改变。但是这会引发一系列新的问题。因为此时表和索

引的统计信息可能会变得过时，优化器被迫基于过时的数据来生成执行计

划，从而产生不良优化结果。SQL Server 没有真正的解决方案来解决执

行计划稳定性问题，事实上，其不断更新优化器统计信息的默认行为使这

一问题更为严重。

不同于 SQL Server，Oracle 提供冻结执行计划的功能，它允许 DBA 通过创建 SQL 计划基准（作为 SQL 计划管理解决方案的一部分）来冻

结执行计划。该功能在 Oracle Database 11g 中引入，旨在防止因突然

更改 SQL 执行计划而使性能退化。它为捕获、选择和改进 SQL 执行计

划提供了基础。SQL 性能可因各种更改而受到影响，如新的优化器版本

或对优化器统计信息或参数的更改。SQL 计划管理是这么一种机制，它

不断地记录和评估 SQL 语句的执行计划并建立由一组已知为高效的现有

执行计划组成的基准。之后，无论系统中发生着什么变化，都使用这些 SQL 执行计划基准来保持相应 SQL 语句的性能。

SQL 计划管理通常用于在以下情形改善或保持 SQL 性能：

• 要安装新的优化器版本的数据库升级。这种情况常常会使小部分 SQL 语句的执行计划产生变化，大多数这类计划更改不会改变或改

善性能。而其中有些计划更改却可能导致性能退化。这时使用 SQL 计划基准可显著降低因数据库升级而引发的性能退化的可能性。

• 正在进行系统或数据更改。这些情况可影响一些 SQL 语句的执行

计划，有可能导致性能退化。使用 SQL 计划基准将有助于降低性

能退化的可能并稳定 SQL 性能。

• 部署新的应用模块。部署新的应用程序或应用模块意味着将新的 SQL 语句引入系统。应用软件可以使用在新 SQL 语句的标准测试

配置下产生的合适的 SQL 执行计划。

SQL 计划基准会不断地发展以产生更好的性能。在 SQL 计划基准的发

展阶段，Oracle Database 11g 可配置为对新的执行计划进行例行评

估，即在后台执行这些计划，然后将性能更佳的计划纳入到 SQL 计划

基准中。将一个新计划与 SQL 计划基准中采纳的计划进行性能比较，

确认该计划提供更佳的性能，经过这一过程后，该计划验证成功。

只是在近，SQL Server 2008 才增加了一个相当于 Oracle 的 Outlines 的用于冻结查询计划的功能。然而，它仍然缺乏能考虑到底层

数据变化的全面的解决方案，因此 DBA 仍然要靠自己来想方设法稳定 SQL 性能。

管理资源

能够轻松而正确地进行系统和资源管理，这对于保持应用程序和数据库

的性能、可伸缩性和可用性来说至关重要。Oracle Database Resource Manager 允许根据业务优先级来在数据库用户和应用程序之间分配 CPU 资源，从而使管理员能够按企业目标来分配系统资源。它能够自动

限制批处理作业占用的资源，从而有助于确保在混合负载环境中，这类

操作不会对联机用户产生负面影响。此外，Database Resource Manager 还能够对运行时间较长的并发操作的数量进行限制，并能阻止

在特定时段执行占用大量资源的查询。因此，Database Resource Manager 能够极为轻松地提供可预测的服务级别，大程度降低了人工

干预，有助于提供几乎无限的系统可伸缩性同时无需牺牲性能3。

3 有关详情，可访问以下网站，参阅其中标题为 Oracle 数据库资源管理器的白皮书：

http://www.oracle.com/technology/products/manageability/database/pdf/twp03/twp_oracle% 20database%2010g%20resource%20manager.pdf


http://www.oracle.com/technology/products/manageability/database/pdf/twp03/twp_oracle%25%2020database%2010g%20resource%20manager.pdf

http://www.oracle.com/technology/products/manageability/database/pdf/twp03/twp_oracle%25%2020database%2010g%20resource%20manager.pdf


SQL Server 2008 终发布了一个类似于 Oracle Resource Manager 的特性。该特性名为 Resource Governor，与其 Oracle 的对应特性在功

能上是类似的。据 Microsoft 所说，Resource Governor 允许数据库管

理员为不同的负载定义资源限制和优先级，从而使并发负载能够向终用

户提供稳定的性能。尽管 Resource Governor 毫无疑问被视为 SQL Server 2008 的重要的特性之一，却并非没有缺点。首先，Resource Governer 只有在其发现没有可用剩余内存时才限制用户对内存的使用，

使用户占用的内存不超过之前分配的内存百分比，但是，如果存在可用内

存，并且没有挂起的负载，它会允许用户占用超过其指定限额的内存。这

在设计上是特意为之，目的是能好地利用内存，避免资源浪费。但是这

么做也可产生负作用。举例来讲，如果某位用户在其他用户之前发起了一

个查询，则 SQL Server 将开始利用所有的可用内存，而后来的所有其

他用户只能忍受这种结果。其次，Resource Governor 只针对数据库引

擎，并不针对 SQL Server 中任何其他服务。这意味着，您无法控制对 Reporting Services、Analysis Services 和 Integration Services 的使

用。后，如果有多个实例运行于同一台计算机上，Resource Governor 不能跨实例管理负载。

更改保证

IT 经理们每天都要面对来自各个方面的更改之需。企业合规组要求 IT 基础架构（如数据库和操作系统）始终跟上新补丁级别。应用程序需要

通过补丁或重大升级来进行升级。这些可能是为了满足业务流程变更或为

了修复应用程序缺陷。无论企业是因合规性还是业务流程方面的原因而改

善基础架构或更改数据库，Oracle 数据库凭借其真正应用测试解决方案

提供了一个全面的更改管理框架。

“Oracle 真正应用测试使更改测试

所需时间减少 80% 之多，使测试

成本降低 70% 之多，通过减少意

外停机次数而降低了风险，并且改

善了 IT 运营的服务质量。”

David Mitchell

高级副总裁

OVUM

负载测试

数据库重放是真正应用测试解决方案的一个组成部分，它通过在测试系统

中确实重建生产负载环境来对系统更改进行实际的测试。为此，需要以低

到可忽略不计的性能开销在生产系统中捕获负载，然后在测试系统中以原

始负载的时限、并发性和事务特点重放负载。这可以对更改影响（包括不

理想结果、新的争用点或性能回退）进行完全评估。提供了大量分析和报

告，用于帮助识别任何潜在的问题，如新的系统错误或性能降级。由于能

够准确捕获生产负载，可完全消除开发模拟负载或脚本的必要性，从而可

节省大量成本和时间。因此，以前使用负载模拟工具/脚本对复杂应用程

序进行的需要花几个月才能完成的测试，现在借助数据库重放的帮助只需

几天就可完成。因此，使用数据库重放，企业可以降低其测试成本，同时

仍然对系统更改整体成功充满高度的信心。


SQL Server 没有提供全面的负载测试解决方案。对此，Microsoft 希望

用户购买第三方产品来实现此目标。

SQL Server 的 Profiler 提供了一个图形界面来生成和管理跟踪文件，然

后分析和重放跟踪结果。如果使用 SQL Profiler 来跟踪生产服务器，明

智的做法是使跟踪在时间上更为集中有限，以便尽可能降低跟踪对您的

服务器带来的负荷。

SQL Profiler 的问题是它提供的负载测试并非实际负载测试。它分析数据

库中各种操作和事件产生的跟踪文件，在进行测试和诊断时利用该信息

向数据库重新提交同样的调用。该方法的困难之处在于，提交的这些调

用并不具有原先的并发性和定时特征。事实上，所有调用均以串联方式

来提交。另外，SQL Profiler 在重放过程中不能保持多个会话间事务的相

关性。这使得 SQL Profiler 不是十分有用，因为它确实不能生成具有生

产环境特征的负载来用于测试。此外，SQL Profiler 不具备数据库重放所

能提供的诸如提高或降低重放速度等这类高级功能，数据库重放可通过

对调用之间的思考时间进行控制来提高或降低重放速度。与 SQL Profiler 不同，Oracle 真正应用测试的数据库重放是一个成熟的解决方案，此方

案的设计是为了满足市场的这种非常重大的需求 — 能够用真实发生的

实际生产负载来对数据库系统进行测试。

确保 SQL 性能

SQL 性能分析程序 (SPA) 是 Oracle 真正应用测试的第二个组件，它

提供的功能类似于数据库重放，但其重点在于对任何影响 SQL 执行性

能的更改导致的问题进行预测。SPA 对 SQL 执行计划和统计信息的更

改提供细粒度的评估，为此，它顺次在更改前后执行 SQL 语句，然后

自动比较它们的性能以确定性能变化。

这使得用户可以对更改的整体效果进行评估，从而能够在终用户受到

影响前纠正不良结果。能够准确预测系统更改对 SQL 性能的潜在影

响，这种能力使您能够预先对系统进行调优防止一些 SQL 语句出现性

能退化，或者在 SQL 语句性能提高时能够验证并估量性能提高程度。

SQL Server 未提供可与 Oracle 的 SPA 相媲美的解决方案。其 SQL Profiler 可以捕获 SQL 语句，但是它不能发现 SQL 语句的性能变化，

而且和 SPA 不同，它没有任何可显示出应用负载的性能差异的报告。


备份与恢复备份文件管理

数据库备份的对象包括不同类型的多个文件，如数据文件、事务日志文

件、重做日志文件、控制文件等。随着常规备份的不断进行，这些文件可

能会不断增多，对它们进行手动管理的工作可能会迅速变得繁重起来。如

果 DBA 手动管理备份文件，则他们需要确保在恢复时所需的所有不同

类型的文件都确实得到了正确的备份；他们必须有一个可靠的备份跟踪机

制以便确定这些文件是否变得多余因而可以被删除；他们必须密切监视备

份位置以保证有足够的空间可用于新的备份，等等。即使对于小型系统来

说，手动完成这些工作都可能是繁重的事情。Oracle Database 11g 通过

引入快速恢复区域特性来使所有备份文件的管理工作自动进行。快速恢复

区域是 Oracle 数据库中所有与恢复相关的文件的一个统一的存储位置。

通过定义初始化参数 DB_RECOVERY_FILE_DEST，将所有的 RMAN（恢复管理器）备份、归档日志、控制文件和数据文件副本自动写入到 Oracle 管理下的指定磁盘位置。如果存在空间压力，快速恢复区域根据 DBA 指定的保留策略自动删除不再需要的过时备份和归档日志。若您将

保留策略设置为 7 天的恢复时窗，则 Oracle 会保留为将数据库恢复到

过去 7 天的状态而需要的所有备份。Oracle Database 11g 的快速恢复

区域特性使 DBA 能够从肩头卸下另一件单调繁重的任务，使介质恢复

操作更为迅速、简单和可靠。

SQL Server 也提供管理备份文件的功能，但它不如 Oracle 提供的功能

成熟高级。它提供的备份向导可对相关文件进行备份，但是，不象 Oracle，它没有一种智能机制来自动清理备份位置。在 SQL Server 中，DBA 可以指定一个时段，备份位置中早于这个时段的所有文件均为

过期文件因而可以删除。这种方法太过单纯以至于不太有用。在备份即包

含完全备份又包含增量备份（如今，这是相当常见的备份策略）的混合环

境下，SQL Server 不具备识别这两种备份之间不同之处的智能，因而，

即使系统处于空间压力之下，它也将保持多余的增量备份，只要这些备份

不早于预定义的过期时间。在系统即将用尽空间，须删除不需要的文件

时，DBA 实际上只能人为地将需要的文件与不需要的文件区分开来。另

外要记住的是，在 SQL Server 的术语中，一个实例一般包括若干数据

库（一个 SQL Server 数据库可被视作相当于一个 Oracle 表空间）。

这使得事情愈加复杂，因为 DBA 不仅要跟踪单个数据库所需要的文

件，还要在多个 (SQL Server) 数据库间使它们相互关联并维护它们以便

确保在需要进行恢复操作时能够提供所有必备的文件。这增加了 DBA 的负担，并且带来了因人为错误导致恢复失败的可能。在 SQL Server 2008 中，以备份压缩的方式增加了对数据库备份的改善。通过压缩，联

机保持备份需要更少的磁盘 I/O、更少的存储空间，并且速度得到了一些

提高。然而，其数据库备份整体方法未变，从而该解决方案比不上 Oracle Database 11g。

完备的备份

在 Oracle 中，备份是全面和非常完备的。只要存在数据库的良好备份，

DBA 就可以在任何情况下恢复 Oracle 数据库。在 SQL Server 中却不

是这样。如果 SQL Server 系统数据库 msdb 丢失，DBA 即使执行过

常规备份，也要在疯狂地搜索到原始安装 CD 之后才有可能恢复系统。

这是由于 SQL Server 备份是不完备的。DBA 首先要使用命令行实用程

序 rebuildm.exe，通过原始安装 CD 手动重建系统数据库 msdb4。只

有在主数据库恢复之后，才能开始恢复应用数据库。这使得完全恢复 SQL Server 实例的工作相当复杂，非常不直观，这不象 Oracle，在 Oracle 中，只需使用恢复向导即可执行同样的操作。甚至在恢复中断的

数据库实例这一为重要的 DBA 工作方面，SQL Server 对其 DBA 造成了一个严重的可管理性障碍。

智能恢复

Oracle 数据库以其 Data Recovery Advisor (DRA) 工具进一步证明了其

优越的可管理性和可靠性。DRA 自动诊断数据故障，确定并提供合适的

可选修复方法，并根据用户的请求执行修复。DRA 以一种智能方式提供

可选修复方法，从而使管理员用于寻找数据库故障根本原因和制定行动计

划的时间大为减少。与 SQL Server 的修复技术相比，DRA 使 Oracle 具有以下优势：

• DRA 可在早期发现、分析和修复数据故障，因而可减少因数据损坏

而造成的损害。

• 自动故障诊断对数据故障的症状进行判断，将它们与问题综述相关

联，并将这些结果报告给用户。

• 在存在多个故障的情况下，修复的正确次序并非总是显而易见。

DRA 自动确定好的修复方法，运行检查以确保在该环境中这些方

法切实可行。

• 执行数据修复的过程可能复杂且易于出错。DRA 使这一过程自动进

行，此外，它还会对是否成功修复进行验证。

4 SQL Server 在线书籍：如何重建主数据库。


SQL Server 重建事务日志、运行修复以纠正任何损坏、确保不打破数据

逻辑完整性的手动过程过于复杂、易错和耗时。这种手动过程迫使许多 DBA 为了保持 SLA 而仅仅重建事务日志就开始继续其日常操作 — 不进行检查、不进行修复、不进行根本原因分析。5

从人为错误中恢复

众多可用性研究均已强调人为错误是造成应用中断的主要的原因。人们

可以增强针对软硬件故障的防护措施，却几乎不可能使系统杜绝人为错误

（如意外删除重要数据）。再一次地，只有 Oracle 利用其闪回技术特性

提供了从这类故障中进行恢复的简便、完备、非侵入性的方法。闪回技术

提供了一组新的特性来查看和来回回退数据。使用闪回特性，可以查询模

式对象的过往版本、查询历史数据、执行更改分析，或者执行自助修复，

以便在数据库联机时从逻辑损坏中恢复。利用 Oracle 数据库的闪回技

术，您确实可以回到过去（根据需要回到过去的任意时间）以撤消您所犯

下的错误！

恢复已删除的表

Oracle 的闪回删除特性允许即时恢复被误删的表。当用户删除一个表

时，Oracle 自动将该表放入“回收站”中。该回收站是一个虚拟容器，

所有被删除的对象都位于这里。对象保留于回收站中，直到 Oracle 需要

回收空间以容纳新的数据或者被删除对象的拥有者决定用新的 PURGE 命令永久删除它们。只要被删除对象保留于回收站中，即可用一条简单的 SQL 语句将其恢复：

FLASHBACK TABLE <table_name > TO BEFORE DROP;

5 “快速发现数据库损坏并进行恢复的秘密武器”，Paul S. Randall，TechEd 2006

中的讲座。



从逻辑数据损坏中恢复

由于用户的错误（如一个批处理作业运行了两次），在数据库中可能会

出现逻辑损坏。在这种情况下，常用的补救办法是将数据库恢复到造

成该损坏的操作执行前的某个时间。传统地，这意味着要先通过一个备

份来恢复数据库，然后对其执行时间点介质恢复。这种形式的恢复可能

单调乏味并且常常要花费很长的时间。这是 SQL Server 中唯一可用的

方法。而 Oracle 不仅提供了传统的介质恢复方法，还提供了明显更为快

速和简单的基于其闪回技术的解决方案。闪回支持任何粒度级（包括数

据库、表、事务和行级）的恢复。

• 闪回数据库：这是应对大范围数据损坏的好的方法。闪回数据库

方法使用名为“闪回日志”的一种特殊类型的文件将 Oracle 数据

库迅速回退到用户指定的某个过去的时间。此文件随着数据块不断

发生变化而捕获这些数据块的映像，因而保存有过去时间的数据块

映像。此文件越大，数据库可以回退到的时间点就越久远。DBA 可以根据其业务需要来规定该文件的大小。使用 FLASHBACK DATABASE 命令来恢复数据库没有与恢复备份相伴的中断时间，并

且能够非常轻松迅速地从人为错误造成的逻辑数据损坏中进行恢

复。

• 闪回表：对于只影响到少数表的数据损坏，这提供了一个更有针对

性的恢复方法。闪回表方法使 DBA 能够将一个或一组表迅速地联

机恢复到一个指定的过去时间点。它在恢复表时自动保持表的各种

属性，如当前的索引、触发器和约束，并且不需要 DBA 发现和恢

复应用的特定属性。闪回表方法减少了对整个数据库执行更为复杂

的恢复操作的需要。

• 闪回事务：此特性支持更加细粒度的恢复，它可使导致损坏发生的

特定事务倒退回去。它提供了一种在事务级查看对数据库的更改和

撤消这些更改的机制。它可使数据库回退到这么一种状态，就好象

这个事务，以及与该事务有关的任何事务，从来没有发生过。

• 闪回版本查询：该方法允许在行级进行恢复。它提供了这么一种机

制，即不断查看在记录行一级对数据库进行的更改，使用户能够有

选择性地撤消因人为错误而导致的意外更改。

• 闪回数据归档（全面撤消）：此技术提供了一个极为安全、高效、

易用和应用透明的历史数据管理解决方案，还提供了一个集中、安

全、可查询的数据存储，这些功能具有高的资源效率，同时降低

了诸如 SOX、HIPAA 和 BASEL-II 等法规的相关合规性成本。


该闪回技术为 Oracle 所独有，SQL Server 不具备可与之相媲美的技

术。在 SQL Server 中，对所有上述人为错误的纠正方法是整个数据库

的时间点恢复。这种恢复是一种脱机操作，它的速度很慢，并且可导致

数据丢失。与之相反的是，Oracle 的闪回技术为用户提供了多种从人为

错误中恢复的可选方法，而且这些方法不会牺牲任何数据，也不会降低

系统的可用性。此技术从损害中进行恢复的能力非常精确、高效，并且

值得一提的是，它是快速而易用的。

安装与配置实例创建

创建实例是 DBA 的一项基本和重要的任务。Oracle 有一个简便易用

的 GUI 工具，Database Configuration Assistant (DBCA)，该工具用于

创建数据库实例。DBCA 替用户执行所有必需的步骤，它只需要少的

用户输入，用户无需详细设计数据库的参数和结构。此外，DBCA 还根

据用户输入提供关于一些数据库设置的建议，因而有助于数据库管理员

根据数据库的具体用途（是用于数据仓储、OLTP 还是混合负载应用）

来进行正确的决策以得到佳的数据库配置。

在 SQL Server 中，每次创建实例时，都需要全部重新安装所有的二进

制文件和脚本。而 Oracle 与此不同，其在同一台计算机上的多个实例共

享二进制文件及其他相关文件。结果是，只要多个实例需要共享同一台

计算机，SQL Server DBA 就得接受相当大量的空间被浪费的情况，因

为每个实例都需要自己专用的二进制文件和脚本。在 SQL Server 2008 中，Microsoft 声称已重新设计了更好的安装过程。这些改进将计算机上

的程序安装与 SQL Server 软件的配置相分离，这使得组织和软件合作

伙伴可提供建议的安装配置。然而，在 SQL Server 软件的配置过程

中，在对数据库参数的设置方面没有提供任何帮助，因而增加了其 DBA 的负担。

数据库复制

为企业级数据库创建一个标准的定义是相当常见的做法。使所有数据库

遵循一个标准会大大简化对它们的管理，因为这样可以使用一致的管理

和监视过程。另外，为了建立开发和测试环境，DBA 常常想要复制数据

库。Oracle 数据库模板支持以 XML 格式保存数据库定义，有了这些模

板，就能极为简便地完成上述两种任务。模板定义包括数据库的所有特

征，如初始化参数、重做日志设置等，可使用模板定义在本地或远程计

算机上创建同样的数据库。模板有两种类型，一类只包含数据库的结

构，另一类即包含结构也包含数据。此功能使得管理员既可以创建新的

结构相同的数据库，又可以连同数据一起克隆一个数据库。可通过对现

有数据库的反向工程来创建一个模板。这种功能极为有用，因为它可节

省管理员在创建和测试脚本以便复制数据库这些方面所花的大量的时间

和精力。

SQL Server 没有可与之相媲美的特性。它只有一种方法来创建新的 SQL Server 数据库，就是使用 Copy Database Wizard。此方法有许多

缺点。首先，这种方法不能只复制数据库的结构，只能连数据库结构带

数据一起复制。其次，要复制的数据库上不能有任何活动的会话，就是

说，该数据库必须处于脱机状态，不能为用户所使用6。若 SQL Server DBA 只想复制数据库的结构（这种情况更为常见），则只能使用脚本或 GUI 工具手动重建该数据库及其所有对象。这是非常笨拙和易错的方

法，当然无法与 Oracle 提供的功能相提并论。

安装克隆

Oracle Enterprise Manager 为用户提供了一个将 Oracle 软件安装（又

称为 Oracle 主目录）复制到多台主机上的方便灵活的方法。在一个直观

向导的指导下，用户可以指定源系统上的一个 Oracle 软件主目录，然后

选择一个或多个目标主机以便将该主目录复制到这个（些）主机上。通

过“多播”技术，只需一次操作即可创建多个新的安装。唯一的要求

是，在所有相关系统上都要安装 Enterprise Manager 代理。

对 Oracle 主目录的克隆以一种智能的方式来进行，即，在克隆过程中对

环境相关的主目录属性（如主目录名称、IP 地址或监听器设置）进行自

动调整。此外，对于跟踪系统上所有 Oracle 安装的 Oracle Universal Installer (OUI) 库，克隆过程中会对其进行自动更新。克隆操作可作为 Enterprise Manager作业在非工作时间调度执行以极大降低网络负载。

SQL Server 不支持软件克隆。用户只能在所有系统上手动安装 SQL Server 软件，然后只能用 Database Copy 向导特性将数据库分别复制

到新的位置。不能克隆软件安装是 SQL Server 的另一个不足之处，它

加剧了用户面临的可管理性挑战。

6 SQL Server 2008 在线书籍，使用复制数据库向导管理数据库引擎。



软件维护打补丁

管理员花费大量时间来进行软件维护操作，如应用软件补丁。能够快速

发现系统的相关补丁并在系统上应用它们对于维护系统的可靠性和性能

来说至关重要。Oracle Enterprise Manager 为管理员提供了强大的新的

补丁管理工具。其中一个新工具是 Critical Patch Advisor，它会向用户

提醒 Oracle 发布的重要补丁，并立即识别出企业中可能需要新补丁的那

些系统。这样，管理员就能够知道是否要打补丁以及何时要打补丁了。

之所以能够提供此功能，是因为 Oracle 收集企业管理下的所有数据库的

详细配置信息。收集的数据包含以下信息：

• 主机硬件规格，包括 CPU 的个数和时钟速度、内存、硬盘和网络

信息

• 操作系统参数设置、文件系统信息和安装的程序包和补丁

• 主机上安装的 Oracle 软件，包括版本和组件信息、补丁集和临时

补丁，以及软件配置设置

这个全面的系统信息库存储于 Enterprise Manager Repository 中，它是 Oracle 的许多配置管理解决方案（包括软件维护）的基础。默认情况下

这些配置数据每日刷新一次。此外，用户只需单击一个按钮即可随时刷

新这些数据。

在收到补丁提醒后，下一步是应用该补丁。另一个工具，Patch Wizard，有助于完成这一工作。该工具搜索、下载并应用补丁。利用 Patch Wizard，可以搜索到适用于特定目标数据库的所有补丁，如果需要，管

理员还可以用该工具来查询企业中所有可应用特定补丁的数据库。在定

位到必要补丁后，可以使用 Enterprise Manager 来下载和部署它。另

外，Enterprise Manager 还可以执行终用户提供的脚本来安装补丁。

通过这些步骤，管理员可以小的工作量在客户的整个企业中快速应用

补丁。


Enterprise Manager Database Control 11g 有一个自动打补丁功能，这

使得它可以为自己打补丁。该打补丁的功能通过可定制的部署过程而得到

支持。其工作流包括整个打补丁周期，从通过 Metalink 获取补丁、准备

补丁、关闭服务、安装补丁到启动数据库。Oracle Database 11g 提供基

于特性的补丁包通告。它将补丁元数据与正在使用的特性相关联（与已安

装的相对）。这可以使数据中心避免大量令人失望的停机时间，这是由于

它基于当前使用的产品而避免了不必要的补丁应用。

SQL Server 2008 在这一方面几乎没有提供任何解决方案。它让管理员

自己来决定需要哪些补丁，并且在其近引入的基于策略的管理框架（需

要进行设置）中几乎没有对补丁应用提供什么帮助。这种情况下，主动性

强的管理员经常要浏览 Microsoft 网站以便发现重要补丁，或者定期与

其支持组织联系以了解那里是否有他们要应用的补丁。主动性不强的其他

管理员有可能只是被动等待，直到出现问题才会采取行动来弥补已造成的

损害及对问题作出补救。这不仅会额外占用管理员的时间，还可能会影响

系统的可用性、可靠性和性能。

故障诊断

Oracle 数据库包含一个可以防止、检测、诊断和解决问题的高级故障诊

断基础架构。这一基础架构特别针对那些影响数据库运行的严重错误。发

生严重错误时，系统为错误分配一个事件号，通过此号可以立即捕获和标

记该错误的诊断数据。接着将诊断数据存储在自动诊断信息库 (ADR) 中，这是一个位于数据库之外的基于文件的信息库，可以通过事件号检索

信息库中的诊断数据并对其进行分析。DBA 随时都可通过单击一个按钮

来自动打包有关严重错误的所有诊断数据（跟踪、转储、运行状况检查报

告、SQL 测试用例等），将这些数据打包为一个适于通过事件打包服务

特性传输给 Oracle Support 的 zip 文件。

Enterprise Manager Support Workbench 是与 Oracle 数据库诊断基础

架构进行交互的界面，该界面易于使用，它将系统中与数据库运行相关的

事件及时呈现给 DBA，同时还给出了如何处理事件的有关信息。另外，

该界面帮助 DBA 查看多个 Oracle 产品（如 Net、客户端、ASM、

Oracle RAC 等）的诊断信息、执行运行状况检查、将事件数据打包发给 Oracle 支持以及处理事件。

Support Workbench 提供了一个查看和诊断事件数据并将其打包发给 Oracle Support 的简单工作流界面，从而大大缩短了为用户解决问题的

时间。

SQL Server 没有提供用于故障诊断及解决的有竞争性的解决方案。一旦

发生数据库错误，没有工具可以自动收集 Microsoft 支持专家高效解决

问题所必需的有关信息。使用 Oracle，如果有适用于眼前问题的补丁，

则系统将自动下载并应用该补丁。若是使用 SQL Server，则解决问题的

时间和工作量将明显加大。

跨平台可移植性 Oracle 体系结构的主要特长之一就是它对不同平台的可移植性。Oracle 实际上可用于所有平台，迄今为止，与其任何竞争对手相比，它是可移

植性好的数据库。这意味着 Unix 上的 Oracle 数据库与 Windows OS 上运行的 Oracle 数据库具有相同的代码库，这就确保了不同平台上

的 Oracle 数据库管理是相同的。这样，无需对 Oracle DBA 进行额外

培训就可以管理任何和全部平台上的数据库。广泛可移植性的另一个好

处是，可以独立于平台设计应用程序，从而可以目标专一地以佳方式

满足业务需求。

SQL Server 却无法达到这种情况，因为它只能运行于 Windows 平台。

因此，未来任何的业务发展都将受限于 Windows 平台。如果业务的发

展超过了 Windows 的承受能力，这意味着，需要投入大量的时间和金

钱来将所有硬件和软件系统升级到 Unix、将数据迁移到更加可伸缩的数

据库、重写应用程序以便运行于新的数据库上以及聘用或重新培训 DBA。如果使用 Oracle，永远不必担心业务发展超过硬件承受能力这种

情况，因为 Oracle 数据和应用程序完全兼容所有主要的硬件和操作系统

平台，可完全移植到这些硬件和平台上。

可伸缩性 Oracle 数据库值得骄傲的一个优点是它的可伸缩性。Oracle 数据库可

以无缝地从数百个用户扩展到数千个用户。另外，从部署和管理的角度

看，Oracle Real Applications Cluster (RAC) 提供了透明的集群数据库

解决方案。可以动态向 RAC 数据库添加节点而不会影响现有的节点。

并且，由于 RAC 环境中的所有节点都访问同一个数据库，因此节点的

添加或删除不会给 DBA 造成额外的工作。然而，RAC 独特的方面在

于，应用程序无需经过任何修改就可以从单个节点转移到 RAC 环境，

这与其他数据库产品（包括 SQL Server）不同，使用其他产品时，必须

针对集群环境重写应用程序。RAC 的这一独特优势归功于自 Oracle9i 开始引进的已获得专利的缓存融合技术。7

7 有关 RAC 和缓存融合的详细信息，请参阅白皮书“Oracle 真正应用集群：缓存

融合提供可伸缩性”，可在以下位置获得该白皮书：

http://otn.oracle.com/products/oracle9i/pdf/cache_fusion_rel2.pdf


http://otn.oracle.com/products/oracle9i/pdf/cache_fusion_rel2.pdf

Microsoft 建议通过以下两种方式来实现 SQL Server 的可伸缩模型：分

布式数据库环境或联合数据库体系结构，在这些环境中，许多独立的数据

库连接在一起而不使用公共数据字典，单个应用程序可以跨所有数据库访

问数据。这里假设要执行在 SQL Server 联合体系结构环境中添加一个

节点这么一个简单的任务。就是这样一个简单任务，DBA 或系统管理员

也必须进行以下所有工作：

• 添加硬件

• 配置新实例（设置实例特有的参数等）

• 创建新数据库

• 断开所有用户

• 从现有表卸载数据

• 重新定义分区表和索引

• 重新定义分区表或复制表上的触发器

• 重新定义分布式分区视图

• 重新加载数据使其分散在更多分区中

• 重新连接所有用户。

这是一组高度复杂和精细的管理任务，包括卸载并重新加载数据、重新定

义视图、修改触发器等等。此外，在执行这些任务的整个操作期间，所有

数据库均不能使用。而如果使用 Oracle Real Application Clusters，添加节点时，管理员只要执行以下两项任务：

• 添加硬件

• 配置新实例（设置实例特有的参数等）。

DBA 无需卸载并重新加载数据，无需修改任何模式定义，系统始终也没

有脱机。因此，与 Oracle 相比，SQL Server 的伸缩性解决方案甚至对

于基本的任务也存在管理性方面的欠缺。

有关 SQL Server 要注意的另一点是，当要管理、维护、备份和升级的

数据库数量达到数十个以上时，其管理的复杂性将急剧上升。例如，为了

达到较高的 TPC-C 基准，Microsoft 必须使用 32 个不同的数据库。因

此，Microsoft 的方法是分散，而不是包容复杂性。对 DBA 们来说，与

实现和管理像 Oracle 这样的单个更具伸缩性的数据库相比，管理如此之

多的数据库确实令他们十分烦恼。SQL Server Magazine 编辑 Brian Moran 对此说道：“Microsoft 在推销 SQL Server 时只是强调它的易用

性，而在涉及到与 UNIX 对手相比管理性方面的复杂性（还有费用较

高）时却含糊其辞。”8

8 SQL Server Magazine UPDATE 新闻编辑，2001 年 1 月。



Oracle 的可伸缩性优势并非仅局限于多节点 RAC 模型。作为市场上可

移植性高的数据库，它可以运行于所有主要 OS 平台（包括大型 SMP）。然而，SQL Server 却只能运行于 Windows 操作系统。这意味

着，在一个机箱内 SQL Server 的可伸缩性局限于小型 Windows 计算

机上，而 Oracle 却不受这种限制，因为它可以运行于所有主要平台。它

可以基于大型 64 cpu SMP 机柜轻松进行伸缩而不会有任何问题。从可

管理性角度看，这是一个很大的优势，因为应用程序会随着时间不断扩

展，而 Oracle DBA 只需向计算机中添加更多的 CPU 就能满足这一扩

展，然而，如果使用 SQL Server，不断扩展的应用程序可能很快就会超

过小型 Windows 计算机的承受能力。这使得 DBA 没有其他选择，只

能添加更多的计算机，之后寄希望于针对联合体系结构重新设计应用程

序。即使可以实现这种扩展，但却是一个极其痛苦和耗时的工作。

为了弥补 SQL Server 可伸缩性的不足，DBA 必须管理一个复杂的、实

际难以管理的环境。即使类似于添加新节点这样简单的任务，也必须对应

用程序数据进行精细的重新分配，这需要深入了解应用程序逻辑和数据库

布局。这些只是 SQL Server DBA 日常必需应对的可管理性问题的一部

分，而 Oracle 的可伸缩性体系结构使所有这些对其 DBA 来说不再成为

问题。

总结与 SQL Server 2008 相比，Oracle Database 11g 不仅功能丰富，而且

易于管理。随着软件管理成本快速超越购置成本，其易用性和可管理性已

经成为影响采购决策的重要因素。Oracle 是市场上能够同时兼具这两

方面优势的唯一解决方案。SQL Server 2008 缺少许多基本管理功能，

而这些功能对实现任务关键应用程序的高效数据库管理却是至关重要的。

迄今为止，SQL Server 始终遵循并充分采用了延迟赶超战略，一直在复

制 Oracle 以往版本的一些特性及成功之处。由于 SQL Server 的 DBA 往往别无选择，他们只能采取繁琐的方法，这些方法既不直观，又十分复

杂，常常会带来管理噩梦。Oracle 在可管理性方面的全面及结构化方

法，无疑将使其未来版本与其竞争对手相比始终处于领先地位。

甲骨文（中国）软件系统有限公司北京总部地址：北京市朝阳区建国门外大街1号，国贸大厦2座2208室邮编：100004 电话：(86.10) 6535-6688 传真：(86.10) 6505-7505 北京上地6号办公室地址：北京市海淀区上地信息产业基地，上地西路8号，上地六号大厦D座

702室邮编：100085 电话：(86.10) 8278-7300 传真：(86.10) 8278-7373 上海分公司地址：上海市卢湾区湖滨路222号，企业天地商业中心1号楼16层邮编：200021 电话：(86.21) 2302-3000 传真：(86.21) 6340-6055 广州分公司地址：广州市天河北路233号，中信广场53楼5301&5308室邮编：510613 电话：(86.20) 8513-2000 传真：(86.20) 3877-1026 成都分公司地址：成都市人民南路二段18号，四川川信大厦20层A&D座邮编：610016 电话：(86.28) 8619-7200 传真：(86.28) 8619-9573 大连分公司地址：大连软件园东路23号，大连软件园国际信息服务中心2号楼五层502号A区邮编：116023 电话：(86.411) 8465-6000 传真：(86.411) 8465-6499 济南分公司地址：济南市泺源大街150号，中信广场11层1113单元邮编：250011 电话：(86.531) 8518-1122 传真：(86.531) 8518-1133 甲骨文软件研究开发中心（北京）有限公司地址：北京市海淀区中关村软件园孵化器2号楼A座一层邮编：100094 电话：(86.10) 8278-6000 传真：(86.10) 8282-6455 甲骨文研究开发中心（深圳）有限公司地址：深圳市南山区高新南一道飞亚达大厦16层邮编：518057 电话：(86.755) 8396-5000 传真：(86.755) 8601-3837

沈阳分公司地址：沈阳市沈河区青年大街219号，华新国际大厦17层D单元邮编：110016 电话：(86.24) 2396 1175 传真：(86.24) 2396 1033 南京分公司地址：南京市玄武区洪武北路55号，置地广场19层1911室邮编：210028 电话：(86.25) 8476-5228 传真：(86.25) 8476-5226 杭州分公司地址：杭州市西湖区杭大路15号，嘉华国际商务中心702室邮编：310007 电话：(86.571) 8717-5300 传真：(86.571) 8717-5299 西安分公司地址：西安市高新区科技二路72号，零壹广场主楼1401室邮编：710075 电话：(86.29) 8833-9800 传真：(86.29) 8833-9829 福州分公司地址：福州市五四路158号，环球广场1601室邮编：350003 电话：(86.591) 8801-0338 传真：(86.591) 8801-0330 重庆分公司地址：重庆市渝中区邹容路68号，大都会商厦1611室邮编：400010 电话：(86.23) 6370-8898 传真：(86.23) 6370-8700 深圳分公司地址：深圳市南山区高新南一道飞亚达大厦16层邮编：518057 电话：(86.755) 8396-5000 传真：(86.755) 8601-3837 甲骨文亚洲研发中心（上海）地址：上海市杨浦区淞沪路290号，创智天地10号楼512-516单元邮编：200433 电话：86-21-6095 2500 传真：86-21-6095 2555

公司网址：http://www.oracle.com（英文）中文网址：http://www.oracle.com/cn（简体中文）销售中心：800-810-0161 售后服务热线：800-810-0366 培训服务热线：800-810-9931 欢迎访问： http://www.oracle.com（英文） http://www.oracle.com/cn（简体中文）版权© 2010 归 Oracle 公司所有。未经允许，不得以任

何形式和手段复制和使用。本文的宗旨只是提供相关信息，其内容如有变动，恕不另

行通知。Oracle 公司对本文内容的准确性不提供任何保

证，也不做任何口头或法律形式的其他保证或条件，包括

关于适销性或符合特定用途的所有默示保证和条件。本公

司特别声明对本文档不承担任何义务，而且本文档也不能

构成任何直接或间接的合同责任。未经 Oracle 公司事先

书面许可，严禁将此文档为了任何目的，以任何形式或手

段(无论是电子的还是机械的)进行复制或传播。 Oracle 是 Oracle 公司和/或其分公司的注册商标。其他

名字均可能是各相应公司的商标。

Oracle Database 11g 和SQL Server 2008 技术比较：针对可 ...

Documents

Transcript of Oracle Database 11g 和SQL Server 2008 技术比较：针对可 ...