Database11g和SQLServer2008技术比较：针对可管理性
Oracle白皮书2008年12月
OracleDatabase11g和SQLServer2008技术比较：针对可管理性
引言........................................................................................................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
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第2页
OracleDatabase11g和SQLServer2008技术比较：针对可管理性
引言
在可管理性方面，SQLServer一向是Oracle的主要竞争对手。
这两家供应商已将增强其数据库服务器的可管理性作为自己的一项主要目标，他们不断在每个新推出的版本中增加新特性以使数据库管理更加轻松和经济高效。
但是，尽管SQLServer2008针对可管理性增加了一些新特性，但它仍然落后于OracleDatabase11g。
OracleDatabase11g是一个成熟的具有自我管理能力的数据库，它能够自动进行自我监视、自适应和自我修复。
Oracle数据库的自我管理解决方案使DBA的工作更为高效，有助于其组织在不降低服务级别目标的情况下降低管理成本。
SQLServer的最新版本意在赶上Oracle已通过其OracleDatabase11g最新版本引入的可管理性特性，Oracle发布该最新版本时引入的这些特性在当时显著扩大了两家竞争对手之间的差距。
管理工具 Oracle和SQLServer分别提供了OracleEnterpriseManager和SQLServerManagementStudio来管理和维护其系统，这两个工具均为GUI工具。
EnterpriseManager11g是Oracle提供的用于管理和监视基于Oracle和第三方组件的应用程序和系统的统
一、集成的解决方案。
该工具能够通过单点控制无缝地管理跨组织和地理边界的成百数千的系统。
EnterpriseManager具有基于web的体系结构，该体系结构强健、可靠、可伸缩，并且在当今互联网驱动的环境中易于部署和运营。
该工具提供一个基于HTML的控制台界面，通过该界面，管理员可从任何位置进行管理—只需一个Web浏览器即可。
其强健的分组和任务自动化功能提供的核心特性使以前耗时、易错的任务（如应用性能管理、基于策略的标准化和系统供应）能够可靠、迅速、安全地自动进行。
从以数据库为中心的角度来看，EnterpriseManager极大地简化了数据库的日常管理，将这种简洁性与一组丰富特性相结合可以管理所有操作系统平台上任何规模的环境。
通过提供以下能力，该工具使许多关键管理任务能够自动进行，从而提高了管理员的工作效率： OracleDatabase11g和SQLServer2008技术比较：针对可管理性第3页 •在数据库创建过程中配置和启动所有必要的框架组件进程，EnterpriseManager提供的功能随即可用。
一旦创建了新的数据库，EnterpriseManager即已完全配置并且可以使用了。
•在主页面上提供企业运行状况的统一概览。
它显示数据库的可用性、警报和作业状态、配置信息、重要补丁的软件维护公告，并且能够追溯所有这些方面的更多详细信息。
•系统监视和警报通知，目的是预测问题并且如有可能，使用“fix-it”作业自动纠正问题。
众多Oracle客户，如British、Boeing、Telstra、Fidelity和Shell，已围绕EnterpriseManager进行了标准化实施以管理他们的生产系统。
这些客户的经历生动地证明了Oracle的管理工具在提高管理员工作效率、提高每位DBA可以管理的数据库数量方面是多么的富有成效。
OracleEnterpriseManager能够提供深度管理，而SQLServerManagementStudio缺乏深度管理能力。
后者不具有基于HTML的控制台界面，因而，对于管理员想要通过其管理SQLServer数据库的所有系统，均需安装相应的客户端工具。
这大大限制了管理员随时随地管理其数据库的能力。
SQLServer的管理工具所存在的另一个缺陷是，它不能通过单个控制台提供对整个系统的端到端的管理和诊断。
SQLServer的管理工具不能监视有关操作系统、中间层应用服务器的度量信息。
Oracle和SQLServer之间的另一个不同之处是它们的管理模式。
OracleEnterpriseManager遵循的是基于异常的管理模式，在这种模式下，只有在发生或即将发生异常状况时才需要DBA的干预。
Oracle在其主页面上突出显示出问题区域，如空间压力、性能问题等，这样人们可立即发现并处理任何潜在的问题或异常。
而SQLServer的方式与此非常不同，在SQLServer的方式下，DBA只能靠自己来监视系统以发现潜在的问题。
例如，如果一条SQL语句运行了很长时间还没有结束，在OracleEnterpriseManager11g主页面的诊断汇总区域下会主动显示出这条语句。
相比之下，对于SQLServer，DBA必须先对该数据库开启监视计数器（这显然会对性能产生负面影响），重新运行该工作负载（这可能不会总是可行的，并且永远是不方便的），然后对跟踪文件进行分析以确定哪条SQL语句占用的资源最多。
只有这样DBA才能知道是否存在正在影响系统性能的任何问题SQL。
因此，与Oracle的管理工具不同，SQLServer的管理工具需要其用户投入相当多的时间来执行通常的管理工作，其管理方式本质上是被动的而不是主动的，并且缺乏Oracle提供的许多管理功能。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第4页 存储管理 数据库管理员在存储管理方面面临着诸多挑战。
数据库的规模在迅速增长，而人们还要求数据库正常运行时间也要不断增长，这种情况下，越来越难以安排时间来使数据库脱机以进行维护操作（如更改磁盘配置）。
此外，系统管理员查找并消除I/O热点或碎片问题的过程可能十分辛苦。
与此同时，降低成本的压力不再允许扩大DBA队伍以应对数据库的高速增长。
这种情况将导致所谓“管理空白”的产生。
DBA需要更好的工具以便能够提高工作效率并帮助使其手动任务自动进行。
自动存储管理(ASM)是Oracle数据库的一个特性，该特性首次在10g版数据库中引入，它通过使整个功能自动化进行而提供了应对上述存储管理挑战的解决方案。
管理员只需要将一组存储设备分配给一个数据库实例，所有其它工作则由OracleASM解决方案自动完成。
ASM将数据库文件自动存放于指定的磁盘组中，并将数据均匀分布于所有可用存储资源上以最大程度提高性能和利用率。
对数据库文件的这种均匀分布使得人们不必再手动进行I/O性能调优。
ASM还提供了三个镜像选项以防止磁盘故障：无镜像、双重镜像和三重镜像。
此外，有了ASM，DBA不必使数据库脱机即可更改存储配置。
在添加或删除磁盘后，ASM自动在磁盘组中重新均衡分布文件。
ASM特性专为简化存储管理工作而构建。
该功能可节省管理员的时间并提供高效管理动态数据库环境的灵活性。
SQLServer不具备Oracle所提供的诸如此类的任何存储管理功能。
存储管理只能通过SQLServer2008引入的共享与存储管理控制台手动进行，或者，只能购买另一个工具来提供此功能。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第5页 空间和对象管理 主动空间管理 Oracle通过其空间监视、通知和空间趋势特性提供主动空间管理。
Oracle数据库服务器并非通过使用外部工具对数据库进行轮询来监视空间的使用情况（本质上来讲，这种方法要占用大量资源），而是具有内置的智能，能够提供对数据库空间使用情况的非侵入性、及时的检查。
如果表空间的空间使用超过了用户定义的阈值，Oracle服务器会发出警报来预先警告相应人员（即DBA）数据库即将用尽其空间，这样DBA就可以采取纠正措施。
默认情况下，Oracle会在表空间占用达到85%时发出一个警告性的警报，在表空间占用达到97%时发出严重警报。
DBA可以覆盖指定表空间的这些默认值（以已使用空间百分比的形式，或以字节计的可用空闲空间总量的形式），还可以对整个数据库设置新的默认值。
一旦采取了纠正措施，警报即被服务器自动清除。
Oracle还提供了完善的警报通知系统。
DBA可通过电子邮件、寻呼机、EnterpriseManager，或者直接通过查询数据库服务器中的视图来接收警报。
Oracle空间管理的关键之处在于其效率。
数据库服务器跟踪空间使用情况，同时执行常规的空间管理操作，如分配新的extent。
一个后台进程将表空间的状态与指定的阈值相比较，以确定是否发出或清除一个警报。
出现状态转换时，执行相应的操作，触发或清除一个警报。
Oracle的主动空间管理在默认情况下处于启用状态，它对系统的性能影响是可以忽略不计的。
SQLServer也具有监视空间使用情况的功能，但是它在以下几个方面不同于Oracle。
首先，它使用SQLServer代理来监视空间的使用情况，这个代理的主要功能是作业调度和警报处理。
因此，其监视和警报机制基于对数据库元数据的轮询，这种技术本质上讲效率低下且开销过高。
其次，SQLServer的空间监视和警报基础架构不如Oracle的灵活。
SQLServer只允许用户在数据库一级设置用于警报的空间使用阈值。
这意味着，如果您有两个不同的文件组（也就是Oracle术语的表空间），一个用于表，另一个用于索引，而您想对它们分别设置两个不同的警报阈值，这是一个非常基本的要求，但是您却办不到。
而Oracle允许在数据库级或表空间级设置警报阈值。
这增加了监视的粒度，使OracleDBA能够更为灵活和精确地设置空间使用准则以满足服务级别协议的要求。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第6页 联机重新组织 OracleDatabase11g允许管理员联机执行几乎所有的段维护操作，即在执行段维护操作的同时，完全可以对数据进行查询、更新和删除。
Schemaevolution使得可以在数据表处于服务状态时对表定义进行修改。
可以对表进行重定位、碎片整理、重新组织，或者对其存储参数进行更改。
可以联机添加索引、重建索引或对其进行碎片整理。
SQLServer对联机操作的支持不如OracleDatabase11g广泛。
SQLServer只是在最近才增加了联机创建、重建、删除索引的功能。
这允许在对索引执行DDL操作时对底层表或集群索引数据和任何相关索引进行并发修改（DML操作）。
这是对早期SQLServer版本的重大改进，在早期版本中，索引创建/重建操作需要获得底层数据和相关索引的排它锁，从而在完成该索引操作之前阻止对其进行修改或查询
1。
Oracle许多年前就已提供了这一功能，而且目前SQLServer仍然不具备Oracle所提供的联机Schemaevolution、表重新组织以及表重新定义这些功能。
这些维护操作中有许多是经常进行的操作，可能花费数小时才能完成，因此SQLServer2008应用程序用户可能要忍受明显的数据不可用性带来的痛苦。
为了对付这一问题，SQLServerDBA必须精确巧妙地安排执行这些操作的时间，以便减少系统不可用之影响。
这极大地增加了其DBA的管理工作量。
而对于OracleDBA来说，在他们的日常操作中对此是一点也无需顾虑的。
行大小限制 除少数例外，SQLServer通常对记录行的大小加以8060字节(8KB)的限制。
但在某些情况下这一限制会放宽，具体来说，对于包含varchar、nvarchar、varbinary或sql_variant列的表该限制会放宽。
这些列中每一列的长度仍然必须在8KB的范围内，然而它们加在一起的宽度可以超过表的8,060字节行限制。
这适用于varchar、nvarchar、varbinary或sql_variant列，无论是在更新或插入数据时，还是在创建、更改这些列时都是如此
2。
对于不在上述例外情况之内的表，SQLServerDBA只能以某种方法来克服8KB行大小的限制。
在这种情况下，SQLServerDBA的通常做法是垂直地将该表划分为多个表。
这种做法尽管解决了8KB限制的问题，却造成了另一问题，它使得应用程序的设计达不到最佳。
这又是一个OracleDBA无需顾虑的方面。
Oracle允许一个记录行跨越多个页面（Oracle称之为块），对其行大小不加限制。
1面向数据库管理员的SQLServer2008测试版2概述，/prodtechnol/sql/2008/maintain/sqlydba.mspx2SQLServer2008在线书籍，数据库设计与创建，表设计。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第7页 处理空间用尽状况 数据加载、批处理更新之类的操作在空间用尽时会遇到错误。
遗憾的是，这些错误有时发生于操作即将完成之时。
Oracle通过其可恢复空间分配特性，以一种无中断的方式来处理这类错误。
当操作遇到空间用尽的情况时，该操作留滞于“挂起”状态，同时系统产生一个警报来将问题通知给管理员以便纠正该问题。
一旦错误状况得以纠正，这个被“挂起”的操作就立即自动恢复。
在问题是瞬时的情况下（例如，一个查询用尽了临时空间），可能不需要管理员的干预，因为一旦该瞬时问题消失，Oracle会自动恢复该操作。
实际上，任何类型的操作，不论是PL/SQL或Java存储过程、DML或DDL语句，还是导出/导入或加载器会话，均可运行于“可恢复”模式。
该功能为Oracle所独有，在SQLServer中没有类似的功能。
SQLServerDBA要花费大量的时间来监视操作进度和重新执行需要长时运行的失败的操作，而OracleDBA却因为此功能而节省了大量的这类时间。
在SQLServer中，如果操作在其运行过程中遇到空间用尽的状况，只能在解决了空间问题之后重新运行整个操作。
这种方式不仅浪费时间，还可能有碍数据库的正常性能，例如，DBA不得不在正常的工作负载时段重新运行失败的批处理作业，这有碍于数据库的正常性能。
通过以无中断的方式来处理空间用尽状况，Oracle的可恢复空间分配特性避免了SQLServer用户可遇到的所有这类问题。
性能管理 性能诊断 性能诊断是DBA使用的非常重要的功能，往往被认为是即复杂又耗时的。
OracleDatabase11g提供了自动性能诊断和监视技术，该技术内置于数据库服务器中，能够使整个性能诊断过程自动进行，并且在遇到性能问题时可提供详细信息及其纠正措施。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第8页 性能统计信息收集 OracleDatabase11g维护着一个容纳系统运行相关信息的信息库，该信息库名为自动负载信息库(AWR)。
这个基础架构是Oracle的性能诊断解决方案的一个关键构建块。
它自动运行以收集有关Oracle系统运行的性能数据并将这些数据存储于数据库中。
作为数据库内核的一部分，AWR以最佳方式捕获最为相关的数据。
对它的设计目标是轻型、可自我管理。
它自动地每小时捕获一次数据，每8天清除一次数据。
该数据捕获频度以及数据保留时长是可以配置的。
此外，AWR还可按需运行，以便随人们的意愿在特定时间捕获信息。
AWR捕获所有需要的数据，根据这些数据足以执行彻底的系统级或用户级性能分析。
通过主动捕获数据，使人们不再需要为了进行问题诊断而重新运行负载。
AWR为改善OracleDatabase11g中的性能诊断工具打下了基础。
正是在AWR提供的数据基础上，自动数据库诊断监视器（Oracle的性能诊断引擎）才能执行分析以发现和纠正性能问题。
性能对比分析 OracleDatabase11g还提供丰富的报告和性能基准功能以促进性能对比分析。
一个性能基准包含某特定时段的性能数据，该数据是受保护的，不会被清除。
之后可以使用该基准来与任何其他时段的性能相对比。
通常，您会在数据库的运行性能参数处于可接受范围时创建一个基准。
之后，如果您察觉到性能背离了其常规状态，您随时可以运行AWR比较时段报告，该报告将确切地告诉您，与基准时段相比发生了什么变化。
该报告指出两个时段之间所有不同的性能属性和配置设置，有助于迅速找出性能背离常规的原因。
活动会话历史记录(ASH)活动会话历史记录(ASH)是Oracle内核收集的、作为AWR快照一部分保存的另一类重要统计数据。
ASH抽样采集所有活动会话的当前状态，所谓活动会话就是连接到数据库并且在当时正在使用CPU，或者正在等待非空闲事件的会话。
ASH每秒对活动会话进行一次状态采集，采集到的数据被保存到系统全局区域(SGA)的循环缓冲区中。
ASH数据还会经由AWR快照处理写到永久存储中。
活动会话历史记录使我们能够“回到过去”并进行极为详细的分析，通常能使我们不必重放负载来收集额外的性能跟踪信息以作为性能诊断的一部分。
举例来讲，通过ASH报告，我们可以诊断瞬时性能问题、锁定问题、事务长时运行问题、高开销SQL语句、占用数据库CPU最多的用户、普遍性的性能问题（DB时间的多维聚合以进行偏差分析）。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第9页 自动性能诊断自动数据库诊断监视器(ADDM)是Oracle数据库的一个特性，它主动分析AWR中现有的大量性能统计信息，向DBA准确指出问题所在以及如何纠正该问题。
由于ADDM是数据库内核的一部分，不是一个外部工具，因此，与传统监视系统相比，其诊断开销可以忽略不计。
该代码工具的引入对OracleEnterpriseManager11g所支持的实时反应性的调优方法的功能提供了支持和进一步的增强。
ADDM每小时主动运行一次，并报告数据库的运行状况。
AWR在默认情况下对所有性能相关信息的保留时间为8天，这使DBA能够对该保留时段内发生的任何问题进行诊断。
DBA只需查看相关时段的ADDM报告并实施它提出的建议。
下面总结了ADDM具备的主要优势：
1.每小时一次的自动性能诊断报告。
2.基于时间的量化的问题影响以及建议。
3.查明根本原因，而不只是症状。
4.由于AWR中保留的数据十分完整，因此极大减少了为进行详细分 析而重放负载的需要。
在OracleDatabase11g中，提供了对RealApplicationClusters(RAC)数据库的集群级性能分析，从而增强了ADDM。
对于RAC环境，ADDM分析RAC集群，对当前影响整个数据库及其各个实例的问题加以报告。
ADDM针对全局资源执行数据库级分析，如高负载SQL、全局缓存互连流量、网络延迟问题、实例响应时间偏差、I/O容量等。
DBA能够限制ADDM分析只对RAC集群的一些指定的实例来进行。
这称作局部分析ADDM，它只能通过PL/SQLAPI来使用。
有了针对RAC的ADDM，对RAC数据库的性能分析就象对单个实例数据库的性能分析一样简便。
在OracleDatabase11g中，DBA可以通过过滤和只显示其感兴趣的ADDM结果来隐藏其他的ADDM结果。
为了在以后更好地理解这些结果的影响，每个结果都有一个便于搜索的描述性名称、一个指向该结果在24小时内出现的次数的链接，以及一个指向受影响的实例的链接。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第10页 对于ADDM的自我诊断功能，SQLServer完全不具备类似功能。
对于SQLServer来说，所有性能问题只能通过手动方式来监视和诊断。
在SQLServer的性能诊断过程中，DBA首先必须根据要分析的问题类型来决定使用哪种工具来监视性能。
对于内存、磁盘和CPU操作的监视，您可能会使用Windows操作系统的系统监视工具。
而为了诊断SQLServer中其他类型的问题，DBA必须从以下工具中进行选择： •SQLProfiler•SQLTrace•SQLServerManagementStudioActivityMonitor•SQLServerManagementStudioGraphicalShowplan•DatabaseConsoleCommands(DBCC)诊断过程的下一步是指定要监视的组件。
举例来说，如果使用SQLProfiler来跟踪一个服务器，DBA必须指定该跟踪去收集与其环境有关的特定事件的相关数据。
在指定要监视的组件后，下一步是确定要监视的组件的指标。
例如，在选择跟踪要包括哪些事件后，DBA应选择只包括这些事件的特定相关数据，以便降低执行该跟踪时对系统资源的需求。
只有在完成所有上述步骤之后，DBA才可以开始对该服务器进行实际监视。
之后，作为监视结果而生成的跟踪文件只能手动加以分析以找出性能问题的原因。
SQLServer的性能诊断过程不仅笨拙耗时，还需要专业的性能工程师查看和理解收集的数据，并且在对性能问题提出纠正建议方面毫无帮助。
SQLServer方法的另一个局限是，它在本质上是被动的。
举例来讲，如果SQLServer系统的运行速度减慢，DBA首先要使用SQLProfiler来启用跟踪，接着重新运行负载，之后才可以对诸如SQL性能不佳等性能问题进行任何的分析。
与之相反的是，如果Oracle系统的性能表现低于预期，DBA只需查看当前的ADDM报告即可找出真正的原因及其纠正措施。
在最新的SQLServer2008版本中，Microsoft增加了一个新的名为ManagementDataWarehouse的特性并且大力推广之。
这是一个新的集中式数据信息库，可配置的性能数据收集和新的报告和监视工具用它来存储性能数据。
为了对性能问题进行有效的诊断，DBA需要知道系统出现问题之前的状况。
在SQLServer2008中，这三个特性：DataCollector、ManagementDataWarehouse(MDW)和专业的性能报告被认为可以解决这一问题。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第11页 支撑SQLServer的MDW的理念远非创新性的理念。
它和Oracle的AWR有点相像，但Oracle的AWR在多年前即已通过OracleDatabase10g而推出。
因此，这一次，SQLServer又重演了通过复制其竞争对手以前版本中的特性来追赶Oracle的一幕。
另外，与Oracle的AWR/ASH框架相比，MDW本身还存在不足。
它不象Oracle那样是现成配置的，在默认配置下它每日对每个实例收集的数据量可达0.5GB之多。
可通过SQLServer的中心管理控制台ManagementStudio更改默认收集设置。
总之，Oracle在性能诊断方面优于SQLServer。
它提供的解决方案是如此的全面和强大，甚至连新手也能轻松纠正性能问题。
一直在模仿Oracle旧版本特性的SQLServer，现在仍然采用的是手动的调优方法，这种方法既被动，又需要专业技能，并且十分耗时。
识别和调优高负载SQL语句 DBA可能会花大量时间去发现占用大量资源的SQL语句并对其进行调优。
在这一方面，Oracle使这一工作可完全自动化进行。
ADDM可主动识别高负载的SQL语句。
OracleDBA只需查看ADDM报告（该报告每小时自动生成一次），看是否存在需要注意的高负载SQL语句。
除了ADDM之外，Oracle还在自动负载信息库(AWR)中每小时捕获一次高负载SQL语句。
这类语句会显示于EnterpriserManager11g的TopActivity页面上。
在SQLServer中，识别高负载SQL语句的过程要复杂得多。
DBA首先要通过SQLProfiler建立一个跟踪事件，启用相关事件，然后重新运行负载以便在跟踪文件中捕获到运行时统计信息。
在跟踪文件生成之后，DBA还得手动进行分析以便找出高负载SQL语句。
这对于SQLServer管理员来说是一个很大的可管理性问题，原因如下：首先，对占用大量资源的SQL语句进行监视是数据库管理员常见的管理工作，因此，如果为了获取该信息而花费超过数分钟的时间常常是不可接受的。
其次，如果系统繁忙，则生成的跟踪文件的大小可能很容易就迅速增长到非常之大，从而非常难于从中提取有意义的信息。
在使这件非常重要的DBA任务自动化进行这一方面，SQLServer非常明显地落后于Oracle。
接着要对SQL语句进行调优。
OracleDatabase11g提供的SQLTuning和essAdvisor使这一过程也能自动进行。
这些工具用一个或多个SQL语句作为输入，以一种特殊的调优模式调用查询优化器以对这些SQL语句进行全面的调优。
其中会执行四种分析： OracleDatabase11g和SQLServer2008技术比较：针对可管理性第12页 •统计分析：查询优化器需要最新的对象统计信息以产生良好的执行计划。
该分析过程会识别出统计信息陈旧或缺失的对象并收集缺失的统计信息。
应注意的是，OracleDatabase11g是自动进行统计信息收集的。
因而，只有在自动统计信息收集特性被人为禁用时，才会出现此类问题。
•SQL配置文件生成：这是以前在OracleDatabase10g中引入的一个新特性（请不要与SQLServer的SQLProfiler工具相混淆，SQLProfiler基本上是一个用于跟踪文件管理的GUI界面），该特性彻底改革了SQL调优方法。
由于该特性的出现，我们不再需要根据优化器提示手动对SQL语句进行调优，该特性会为我们进行语句调优，而无需对SQL代码进行任何更改。
在该分析过程中，一条SQL语句的配置文件称作一个SQL配置文件，对这条语句建立的SQL配置文件包含了该语句特定的辅助统计信息。
由于缺少查询中有关不同对象之间关系的信息，查询优化器有时生成的执行计划可能不是最佳的。
在过去，Oracle和SQLServer均需通过在代码中手动添加查询提示来处理此问题。
现在，由于有了SQL配置文件功能，Oracle不再需要这种手动过程了，因为SQL配置文件功能通过采样和部分执行技术来收集额外的信息。
另外，从OracleDatabase11g开始，SQLTuningAdvisor用建议的SQL配置文件产生的新执行计划对SQL语句进行测试执行。
这极大提高了SQLTuningAdvisor建议的准确性和可靠性。
•访问路径分析：索引、分区和物化视图可减少全表扫描的需要，从而极大地提高SQL语句的性能。
该分析过程可找出能够极大提高查询性能的新的索引、分区、物化视图(mv)和mv日志。
•SQL结构分析：SQL语句若存在结构问题则可能导致性能不佳。
这些问题可能是语句的语法、语义或设计问题。
该分析过程提出重构SQL语句的建议以便提高性能。
通过执行上述分析并提出合适的操作建议，OracleDatabase11g及其SQLTuning和essAdvisor提供了一个全面的SQL调优解决方案，该解决方案使得人们不必再进行费时费力代价高昂的手动调优过程。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第13页 在这一方面，SQLServer只提供了一个片面的解决方案。
除了手动添加查询提示外，它没有提供其他的SQL调优方法，在对结构不良的SQL查询进行重写这一方面也没有提供任何帮助。
所有这些均需手动完成，这需要深入了解SQLServer的优化技术。
它只在簇索引、非簇索引和索引视图的生成这一方面提供了帮助，这依靠的是它的DatabaseTuningAdvisor，DatabaseTuningAdvisor是其IndexTuningWizard的增强版本。
DatabaseTuningWizard提供了一些在IndexTuningWizard中所没有的新选项，如时限调优，通过这一选项，用户可以指定该advisor对语句进行分析所花时间的限制，另外，还提供了执行实例级调优的能力。
所有这些调优选项及其他一些调优选项早已是Oracle的SQLTuning和essAdvisor的组成部分。
虽然SQLServer的DatabaseTuningAdvisor有助于对物理数据库设计进行调优，但是它将SQL调优中更具挑战性和耗时的工作留给了DBA和应用开发人员。
SQLServer2008中最新增加的功能是针对查询性能稳定性和可预测性的计划冻结功能，该功能用于锁住查询计划，从而使组织能够在进行硬件服务器更换、服务器升级和生产部署时推广稳定的查询计划。
此特性非常类似于Oracle的Outlines，Outlines近来为SQL配置文件所代替，后者是解决SQL语句性能不佳问题的一个更为智能的方法。
比起SQLServer的解决方案，Oracle的调优解决方案不仅全面和简便，而且，它是通过查询优化器自身来进行实际调优的，并非通过外部工具（外部工具通过各种方法强迫或哄骗优化器产生更好的执行计划），这是它与SQLServer解决方案的另一个重大不同之处。
与其他供应商（包括Microsoft）提供的调优工具相比，这是Oracle的一个重大优势，因为由查询优化器自身执行的调优操作在质量、可靠性和有效性方面超过了任何的外部组件。
自动SQL调优 与以前的版本相比，OracleDatabase11g中的SQL调优过程已得到了进一步的增强和自动化。
现在，SQLTuningAdvisor在系统维护时段可作为一个维护任务而自动运行。
每次运行时，它会自动选择系统中高负载的SQL查询并就如何对这些查询进行调优给出建议。
该自动SQLTuningAdvisor可配置为自动执行SQL配置文件建议。
这意味着数据库会自动对高负载SQL进行调优，不需要用户的任何输入或干预。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第14页 您可以查看指定时段内（如前七日）自动SQL调优的运行结果汇总，也可以查看对所有处理过的SQL语句提出的建议的详细报告。
该自动SQLTuningAdvisor经配置可运行于任何维护时段，如果需要，也可完全禁用它。
SQLServer没有提供可与Oracle的自动SQL调优相匹敌的特性，这主要是因为其SQL调优工具只能提供索引建议。
SQLServer的调优工具不如Oracle的解决方案全面，特别是，它们不能帮助执行计划调优，这意味着它们无法使这种复杂的工作自动进行。
在应用程序代码中手动添加查询提示是Microsoft对SQL执行计划进行调优的唯一方法，这种方法永远无法自动进行。
调优打包的应用程序 对打包应用程序（如SAP、Siebel或PeopleSoft）进行调优是对调优的另一种挑战。
由于客户无权修改应用程序代码，任何时候如果在打包的应用程序中遇到了严重的性能问题，客户只能将其作为缺陷记录下来发给应用程序供应商，然后就只能等待数周、数月甚至更长时间，直到收到对该问题的修复代码。
在过去，这是数据库管理系统客户所能采用的唯一办法。
而如今，Oracle为客户提供了另一个办法。
其SQL配置文件特性（该特性是SQLTuningAdvisor的一部分）无需更改应用程序代码即可调优SQL语句。
如前所述，SQL配置文件包含SQL语句中引用的各种表之间数据关系的相关信息，通过向查询优化器提供此额外信息来对SQL语句进行调优。
由于SQL配置文件存储于数据字典中而不是应用程序代码中，它们使得Oracle能够透明地调优打包应用程序。
Oracle是当今市场中唯一具有该功能的商业数据库。
Oracle客户不必将缺陷记录下来，也不必等待性能问题得以纠正。
有了SQL配置文件生成特性，调优可以立即进行。
SQLServer确实也提供了对打包应用程序进行调优的能力，但是它的解决方案本质上是重复性的并且必须手动进行。
在SQLServer2005中引入并且集成到了SQLServer2008的ManagementStudion中的计划指南，是一些可与SQL语句相关联的查询提示，用这种方法无需直接修改应用程序代码。
这确实使打包应用程序的调优成为可能，但是仍然需要DBA来确定用于调优SQL语句的正确提示。
这个过程本质上是重复而耗时的，需要DBA具备SQL优化技术的深入知识和专业技能。
而Oracle的解决方案是自动、准确和可伸缩的方案。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第15页 执行计划稳定性 DBA的一个渴望是可预测性，对于查询性能来说尤其如此。
查询的性能取决于其执行计划的优化程度。
执行计划越有效，查询性能就越好。
然而，Oracle和SQLServer均使用的优化模式—基于开销的优化，在生成查询执行计划时却依赖于数据库环境。
因此，数据库环境中的变化，如底层对象、内存参数等优化器统计信息的变化，可能会突然改变查询执行计划，大多数情况下这可改善执行计划，但有时也可使执行计划变得很糟。
在SQLServer中这是一个严重的问题，因为该数据库服务器在默认情况下会不断地重新生成优化器统计信息，从而使执行计划可能会不断变化。
在这种情况下，DBA只能关闭优化器统计信息自动生成和更新功能以使执行计划不再改变。
但是这会引发一系列新的问题。
因为此时表和索引的统计信息可能会变得过时，优化器被迫基于过时的数据来生成执行计划，从而产生不良优化结果。
SQLServer没有真正的解决方案来解决执行计划稳定性问题，事实上，其不断更新优化器统计信息的默认行为使这一问题更为严重。
不同于SQLServer，Oracle提供冻结执行计划的功能，它允许DBA通过创建SQL计划基准（作为SQL计划管理解决方案的一部分）来冻结执行计划。
该功能在OracleDatabase11g中引入，旨在防止因突然更改SQL执行计划而使性能退化。
它为捕获、选择和改进SQL执行计划提供了基础。
SQL性能可因各种更改而受到影响，如新的优化器版本或对优化器统计信息或参数的更改。
SQL计划管理是这么一种机制，它不断地记录和评估SQL语句的执行计划并建立由一组已知为高效的现有执行计划组成的基准。
之后，无论系统中发生着什么变化，都使用这些SQL执行计划基准来保持相应SQL语句的性能。
SQL计划管理通常用于在以下情形改善或保持SQL性能： •要安装新的优化器版本的数据库升级。
这种情况常常会使小部分SQL语句的执行计划产生变化，大多数这类计划更改不会改变或改善性能。
而其中有些计划更改却可能导致性能退化。
这时使用SQL计划基准可显著降低因数据库升级而引发的性能退化的可能性。
•正在进行系统或数据更改。
这些情况可影响一些SQL语句的执行计划，有可能导致性能退化。
使用SQL计划基准将有助于降低性能退化的可能并稳定SQL性能。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第16页 •部署新的应用模块。
部署新的应用程序或应用模块意味着将新的SQL语句引入系统。
应用软件可以使用在新SQL语句的标准测试配置下产生的合适的SQL执行计划。
SQL计划基准会不断地发展以产生更好的性能。
在SQL计划基准的发展阶段，OracleDatabase11g可配置为对新的执行计划进行例行评估，即在后台执行这些计划，然后将性能更佳的计划纳入到SQL计划基准中。
将一个新计划与SQL计划基准中采纳的计划进行性能比较，确认该计划提供更佳的性能，经过这一过程后，该计划验证成功。
只是在最近，SQLServer2008才增加了一个相当于Oracle的Outlines的用于冻结查询计划的功能。
然而，它仍然缺乏能考虑到底层数据变化的全面的解决方案，因此DBA仍然要靠自己来想方设法稳定SQL性能。
管理资源 能够轻松而正确地进行系统和资源管理，这对于保持应用程序和数据库的性能、可伸缩性和可用性来说至关重要。
OracleDatabaseResourceManager允许根据业务优先级来在数据库用户和应用程序之间分配CPU资源，从而使管理员能够按企业目标来分配系统资源。
它能够自动限制批处理作业占用的资源，从而有助于确保在混合负载环境中，这类操作不会对联机用户产生负面影响。
此外，DatabaseResourceManager还能够对运行时间较长的并发操作的数量进行限制，并能阻止在特定时段执行占用大量资源的查询。
因此，DatabaseResourceManager能够极为轻松地提供可预测的服务级别，最大程度降低了人工干预，有助于提供几乎无限的系统可伸缩性同时无需牺牲性能
3。
3有关详情，可访问以下网站，参阅其中标题为Oracle数据库资源管理器的白皮书：/technology/products/manageability/database/pdf/twp03/twp_oracle%20database%2010g%20resource%20manager.pdf OracleDatabase11g和SQLServer2008技术比较：针对可管理性第17页 “Oracle真正应用测试使更改测试所需时间减少80%之多，使测试成本降低70%之多，通过减少意外停机次数而降低了风险，并且改善了IT运营的服务质量。
” DavidMitchell 高级副总裁 OVUM SQLServer2008最终发布了一个类似于OracleResourceManager的特性。
该特性名为ResourceGovernor，与其Oracle的对应特性在功能上是类似的。
据Microsoft所说，ResourceGovernor允许数据库管理员为不同的负载定义资源限制和优先级，从而使并发负载能够向最终用户提供稳定的性能。
尽管ResourceGovernor毫无疑问被视为SQLServer2008的最重要的特性之
一，却并非没有缺点。
首先，ResourceGoverner只有在其发现没有可用剩余内存时才限制用户对内存的使用，使用户占用的内存不超过之前分配的内存百分比，但是，如果存在可用内存，并且没有挂起的负载，它会允许用户占用超过其指定限额的内存。
这在设计上是特意为之，目的是能最好地利用内存，避免资源浪费。
但是这么做也可产生负作用。
举例来讲，如果某位用户在其他用户之前发起了一个查询，则SQLServer将开始利用所有的可用内存，而后来的所有其他用户只能忍受这种结果。
其次，ResourceGovernor只针对数据库引擎，并不针对SQLServer中任何其他服务。
这意味着，您无法控制对ReportingServices、AnalysisServices和IntegrationServices的使用。
最后，如果有多个实例运行于同一台计算机上，ResourceGovernor不能跨实例管理负载。
更改保证 IT经理们每天都要面对来自各个方面的更改之需。
企业合规组要求IT基础架构（如数据库和操作系统）始终跟上最新补丁级别。
应用程序需要通过补丁或重大升级来进行升级。
这些可能是为了满足业务流程变更或为了修复应用程序缺陷。
无论企业是因合规性还是业务流程方面的原因而改善基础架构或更改数据库，Oracle数据库凭借其真正应用测试解决方案提供了一个全面的更改管理框架。
负载测试 数据库重放是真正应用测试解决方案的一个组成部分，它通过在测试系统中确实重建生产负载环境来对系统更改进行实际的测试。
为此，需要以低到可忽略不计的性能开销在生产系统中捕获负载，然后在测试系统中以原始负载的时限、并发性和事务特点重放负载。
这可以对更改影响（包括不理想结果、新的争用点或性能回退）进行完全评估。
提供了大量分析和报告，用于帮助识别任何潜在的问题，如新的系统错误或性能降级。
由于能够准确捕获生产负载，可完全消除开发模拟负载或脚本的必要性，从而可节省大量成本和时间。
因此，以前使用负载模拟工具/脚本对复杂应用程序进行的需要花几个月才能完成的测试，现在借助数据库重放的帮助只需几天就可完成。
因此，使用数据库重放，企业可以降低其测试成本，同时仍然对系统更改整体成功充满高度的信心。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第18页 SQLServer没有提供全面的负载测试解决方案。
对此，Microsoft希望用户购买第三方产品来实现此目标。
SQLServer的Profiler提供了一个图形界面来生成和管理跟踪文件，然后分析和重放跟踪结果。
如果使用SQLProfiler来跟踪生产服务器，明智的做法是使跟踪在时间上更为集中有限，以便尽可能降低跟踪对您的服务器带来的负荷。
SQLProfiler的问题是它提供的负载测试并非实际负载测试。
它分析数据库中各种操作和事件产生的跟踪文件，在进行测试和诊断时利用该信息向数据库重新提交同样的调用。
该方法的困难之处在于，提交的这些调用并不具有原先的并发性和定时特征。
事实上，所有调用均以串联方式来提交。
另外，SQLProfiler在重放过程中不能保持多个会话间事务的相关性。
这使得SQLProfiler不是十分有用，因为它确实不能生成具有生产环境特征的负载来用于测试。
此外，SQLProfiler不具备数据库重放所能提供的诸如提高或降低重放速度等这类高级功能，数据库重放可通过对调用之间的思考时间进行控制来提高或降低重放速度。
与SQLProfiler不同，Oracle真正应用测试的数据库重放是一个成熟的解决方案，此方案的设计是为了满足市场的这种非常重大的需求—能够用真实发生的实际生产负载来对数据库系统进行测试。
确保SQL性能 SQL性能分析程序(SPA)是Oracle真正应用测试的第二个组件，它提供的功能类似于数据库重放，但其重点在于对任何影响SQL执行性能的更改导致的问题进行预测。
SPA对SQL执行计划和统计信息的更改提供细粒度的评估，为此，它顺次在更改前后执行SQL语句，然后自动比较它们的性能以确定性能变化。
这使得用户可以对更改的整体效果进行评估，从而能够在最终用户受到影响前纠正不良结果。
能够准确预测系统更改对SQL性能的潜在影响，这种能力使您能够预先对系统进行调优防止一些SQL语句出现性能退化，或者在SQL语句性能提高时能够验证并估量性能提高程度。
SQLServer未提供可与Oracle的SPA相媲美的解决方案。
其SQLProfiler可以捕获SQL语句，但是它不能发现SQL语句的性能变化，而且和SPA不同，它没有任何可显示出应用负载的性能差异的报告。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第19页 备份与恢复 备份文件管理 数据库备份的对象包括不同类型的多个文件，如数据文件、事务日志文件、重做日志文件、控制文件等。
随着常规备份的不断进行，这些文件可能会不断增多，对它们进行手动管理的工作可能会迅速变得繁重起来。
如果DBA手动管理备份文件，则他们需要确保在恢复时所需的所有不同类型的文件都确实得到了正确的备份；他们必须有一个可靠的备份跟踪机制以便确定这些文件是否变得多余因而可以被删除；他们必须密切监视备份位置以保证有足够的空间可用于新的备份，等等。
即使对于小型系统来说，手动完成这些工作都可能是繁重的事情。
OracleDatabase11g通过引入快速恢复区域特性来使所有备份文件的管理工作自动进行。
快速恢复区域是Oracle数据库中所有与恢复相关的文件的一个统一的存储位置。
通过定义初始化参数DB_RECOVERY_FILE_DEST，将所有的RMAN（恢复管理器）备份、归档日志、控制文件和数据文件副本自动写入到Oracle管理下的指定磁盘位置。
如果存在空间压力，快速恢复区域根据DBA指定的保留策略自动删除不再需要的过时备份和归档日志。
若您将保留策略设置为7天的恢复时窗，则Oracle会保留为将数据库恢复到过去7天的状态而需要的所有备份。
OracleDatabase11g的快速恢复区域特性使DBA能够从肩头卸下另一件单调繁重的任务，使介质恢复操作更为迅速、简单和可靠。
SQLServer也提供管理备份文件的功能，但它不如Oracle提供的功能成熟高级。
它提供的备份向导可对相关文件进行备份，但是，不象Oracle，它没有一种智能机制来自动清理备份位置。
在SQLServer中，DBA可以指定一个时段，备份位置中早于这个时段的所有文件均为过期文件因而可以删除。
这种方法太过单纯以至于不太有用。
在备份即包含完全备份又包含增量备份（如今，这是相当常见的备份策略）的混合环境下，SQLServer不具备识别这两种备份之间不同之处的智能，因而，即使系统处于空间压力之下，它也将保持多余的增量备份，只要这些备份不早于预定义的过期时间。
在系统即将用尽空间，须删除不需要的文件时，DBA实际上只能人为地将需要的文件与不需要的文件区分开来。
另外要记住的是，在SQLServer的术语中，一个实例一般包括若干数据库（一个SQLServer数据库可被视作相当于一个Oracle表空间）。
这使得事情愈加复杂，因为DBA不仅要跟踪单个数据库所需要的文件，还要在多个(SQLServer)数据库间使它们相互关联并维护它们以便确保在需要进行恢复操作时能够提供所有必备的文件。
这增加了DBA的负担，并且带来了因人为错误导致恢复失败的可能。
在SQLServer2008中，以备份压缩的方式增加了对数据库备份的改善。
通过压缩，联机保持备份需要更少的磁盘I/O、更少的存储空间，并且速度得到了一些提高。
然而，其数据库备份整体方法未变，从而该解决方案比不上OracleDatabase11g。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第20页 完备的备份 在Oracle中，备份是全面和非常完备的。
只要存在数据库的良好备份，DBA就可以在任何情况下恢复Oracle数据库。
在SQLServer中却不是这样。
如果SQLServer系统数据库msdb丢失，DBA即使执行过常规备份，也要在疯狂地搜索到原始安装CD之后才有可能恢复系统。
这是由于SQLServer备份是不完备的。
DBA首先要使用命令行实用程序rebuildm.exe，通过原始安装CD手动重建系统数据库msdb4。
只有在主数据库恢复之后，才能开始恢复应用数据库。
这使得完全恢复SQLServer实例的工作相当复杂，非常不直观，这不象Oracle，在Oracle中，只需使用恢复向导即可执行同样的操作。
甚至在恢复中断的数据库实例这一最为重要的DBA工作方面，SQLServer对其DBA造成了一个严重的可管理性障碍。
智能恢复 Oracle数据库以其DataRecoveryAdvisor(DRA)工具进一步证明了其优越的可管理性和可靠性。
DRA自动诊断数据故障，确定并提供合适的可选修复方法，并根据用户的请求执行修复。
DRA以一种智能方式提供可选修复方法，从而使管理员用于寻找数据库故障根本原因和制定行动计划的时间大为减少。
与SQLServer的修复技术相比，DRA使Oracle具有以下优势： •DRA可在早期发现、分析和修复数据故障，因而可减少因数据损坏而造成的损害。
•自动故障诊断对数据故障的症状进行判断，将它们与问题综述相关联，并将这些结果报告给用户。
•在存在多个故障的情况下，修复的正确次序并非总是显而易见。
DRA自动确定最好的修复方法，运行检查以确保在该环境中这些方法切实可行。
•执行数据修复的过程可能复杂且易于出错。
DRA使这一过程自动进行，此外，它还会对是否成功修复进行验证。
4SQLServer在线书籍：如何重建主数据库。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第21页 SQLServer重建事务日志、运行修复以纠正任何损坏、确保不打破数据逻辑完整性的手动过程过于复杂、易错和耗时。
这种手动过程迫使许多DBA为了保持SLA而仅仅重建事务日志就开始继续其日常操作—不进行检查、不进行修复、不进行根本原因分析。
5 从人为错误中恢复 众多可用性研究均已强调人为错误是造成应用中断的最主要的原因。
人们可以增强针对软硬件故障的防护措施，却几乎不可能使系统杜绝人为错误（如意外删除重要数据）。
再一次地，只有Oracle利用其闪回技术特性提供了从这类故障中进行恢复的简便、完备、非侵入性的方法。
闪回技术提供了一组新的特性来查看和来回回退数据。
使用闪回特性，可以查询模式对象的过往版本、查询历史数据、执行更改分析，或者执行自助修复，以便在数据库联机时从逻辑损坏中恢复。
利用Oracle数据库的闪回技术，您确实可以回到过去（根据需要回到过去的任意时间）以撤消您所犯下的错误！ 恢复已删除的表Oracle的闪回删除特性允许即时恢复被误删的表。
当用户删除一个表时，Oracle自动将该表放入“回收站”中。
该回收站是一个虚拟容器，所有被删除的对象都位于这里。
对象保留于回收站中，直到Oracle需要回收空间以容纳新的数据或者被删除对象的拥有者决定用新的PURGE命令永久删除它们。
只要被删除对象保留于回收站中，即可用一条简单的SQL语句将其恢复：FLASHBACKTABLETOBEFOREDROP;
5“快速发现数据库损坏并进行恢复的秘密武器”，PaulS.Randall，TechEd2006中的讲座。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第22页 从逻辑数据损坏中恢复 由于用户的错误（如一个批处理作业运行了两次），在数据库中可能会出现逻辑损坏。
在这种情况下，最常用的补救办法是将数据库恢复到造成该损坏的操作执行前的某个时间。
传统地，这意味着要先通过一个备份来恢复数据库，然后对其执行时间点介质恢复。
这种形式的恢复可能单调乏味并且常常要花费很长的时间。
这是SQLServer中唯一可用的方法。
而Oracle不仅提供了传统的介质恢复方法，还提供了明显更为快速和简单的基于其闪回技术的解决方案。
闪回支持任何粒度级（包括数据库、表、事务和行级）的恢复。
•闪回数据库：这是应对大范围数据损坏的最好的方法。
闪回数据库方法使用名为“闪回日志”的一种特殊类型的文件将Oracle数据库迅速回退到用户指定的某个过去的时间。
此文件随着数据块不断发生变化而捕获这些数据块的映像，因而保存有过去时间的数据块映像。
此文件越大，数据库可以回退到的时间点就越久远。
DBA可以根据其业务需要来规定该文件的大小。
使用FLASHBACKDATABASE命令来恢复数据库没有与恢复备份相伴的中断时间，并且能够非常轻松迅速地从人为错误造成的逻辑数据损坏中进行恢复。
•闪回表：对于只影响到少数表的数据损坏，这提供了一个更有针对性的恢复方法。
闪回表方法使DBA能够将一个或一组表迅速地联机恢复到一个指定的过去时间点。
它在恢复表时自动保持表的各种属性，如当前的索引、触发器和约束，并且不需要DBA发现和恢复应用的特定属性。
闪回表方法减少了对整个数据库执行更为复杂的恢复操作的需要。
•闪回事务：此特性支持更加细粒度的恢复，它可使导致损坏发生的特定事务倒退回去。
它提供了一种在事务级查看对数据库的更改和撤消这些更改的机制。
它可使数据库回退到这么一种状态，就好象这个事务，以及与该事务有关的任何事务，从来没有发生过。
•闪回版本查询：该方法允许在行级进行恢复。
它提供了这么一种机制，即不断查看在记录行一级对数据库进行的更改，使用户能够有选择性地撤消因人为错误而导致的意外更改。
•闪回数据归档（全面撤消）：此技术提供了一个极为安全、高效、易用和应用透明的历史数据管理解决方案，还提供了一个集中、安全、可查询的数据存储，这些功能具有最高的资源效率，同时降低了诸如SOX、HIPAA和BASEL-II等法规的相关合规性成本。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第23页 该闪回技术为Oracle所独有，SQLServer不具备可与之相媲美的技术。
在SQLServer中，对所有上述人为错误的纠正方法是整个数据库的时间点恢复。
这种恢复是一种脱机操作，它的速度很慢，并且可导致数据丢失。
与之相反的是，Oracle的闪回技术为用户提供了多种从人为错误中恢复的可选方法，而且这些方法不会牺牲任何数据，也不会降低系统的可用性。
此技术从损害中进行恢复的能力非常精确、高效，并且最值得一提的是，它是快速而易用的。
安装与配置 实例创建 创建实例是DBA的一项最基本和重要的任务。
Oracle有一个简便易用的GUI工具，DatabaseConfigurationAssistant(DBCA)，该工具用于创建数据库实例。
DBCA替用户执行所有必需的步骤，它只需要最少的用户输入，用户无需详细设计数据库的参数和结构。
此外，DBCA还根据用户输入提供关于一些数据库设置的建议，因而有助于数据库管理员根据数据库的具体用途（是用于数据仓储、OLTP还是混合负载应用）来进行正确的决策以得到最佳的数据库配置。
在SQLServer中，每次创建实例时，都需要全部重新安装所有的二进制文件和脚本。
而Oracle与此不同，其在同一台计算机上的多个实例共享二进制文件及其他相关文件。
结果是，只要多个实例需要共享同一台计算机，SQLServerDBA就得接受相当大量的空间被浪费的情况，因为每个实例都需要自己专用的二进制文件和脚本。
在SQLServer2008中，Microsoft声称已重新设计了更好的安装过程。
这些改进将计算机上的程序安装与SQLServer软件的配置相分离，这使得组织和软件合作伙伴可提供建议的安装配置。
然而，在SQLServer软件的配置过程中，在对数据库参数的设置方面没有提供任何帮助，因而增加了其DBA的负担。
数据库复制 为企业级数据库创建一个标准的定义是相当常见的做法。
使所有数据库遵循一个标准会大大简化对它们的管理，因为这样可以使用一致的管理和监视过程。
另外，为了建立开发和测试环境，DBA常常想要复制数据库。
Oracle数据库模板支持以XML格式保存数据库定义，有了这些模板，就能极为简便地完成上述两种任务。
模板定义包括数据库的所有特征，如初始化参数、重做日志设置等，可使用模板定义在本地或远程计算机上创建同样的数据库。
模板有两种类型，一类只包含数据库的结构，另一类即包含结构也包含数据。
此功能使得管理员既可以创建新的结构相同的数据库，又可以连同数据一起克隆一个数据库。
可通过对现有数据库的反向工程来创建一个模板。
这种功能极为有用，因为它可节省管理员在创建和测试脚本以便复制数据库这些方面所花的大量的时间和精力。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第24页 SQLServer没有可与之相媲美的特性。
它只有一种方法来创建新的SQLServer数据库，就是使用CopyDatabaseWizard。
此方法有许多缺点。
首先，这种方法不能只复制数据库的结构，只能连数据库结构带数据一起复制。
其次，要复制的数据库上不能有任何活动的会话，就是说，该数据库必须处于脱机状态，不能为用户所使用
6。
若SQLServerDBA只想复制数据库的结构（这种情况更为常见），则只能使用脚本或GUI工具手动重建该数据库及其所有对象。
这是非常笨拙和易错的方法，当然无法与Oracle提供的功能相提并论。
安装克隆 OracleEnterpriseManager为用户提供了一个将Oracle软件安装（又称为Oracle主目录）复制到多台主机上的方便灵活的方法。
在一个直观向导的指导下，用户可以指定源系统上的一个Oracle软件主目录，然后选择一个或多个目标主机以便将该主目录复制到这个（些）主机上。
通过“多播”技术，只需一次操作即可创建多个新的安装。
唯一的要求是，在所有相关系统上都要安装EnterpriseManager代理。
对Oracle主目录的克隆以一种智能的方式来进行，即，在克隆过程中对环境相关的主目录属性（如主目录名称、IP地址或监听器设置）进行自动调整。
此外，对于跟踪系统上所有Oracle安装的OracleUniversalInstaller(OUI)库，克隆过程中会对其进行自动更新。
克隆操作可作为EnterpriseManager作业在非工作时间调度执行以极大降低网络负载。
SQLServer不支持软件克隆。
用户只能在所有系统上手动安装SQLServer软件，然后只能用DatabaseCopy向导特性将数据库分别复制到新的位置。
不能克隆软件安装是SQLServer的另一个不足之处，它加剧了用户面临的可管理性挑战。
6SQLServer2008在线书籍，使用复制数据库向导管理数据库引擎。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第25页 软件维护 打补丁 管理员花费大量时间来进行软件维护操作，如应用软件补丁。
能够快速发现系统的相关补丁并在系统上应用它们对于维护系统的可靠性和性能来说至关重要。
OracleEnterpriseManager为管理员提供了强大的新的补丁管理工具。
其中一个新工具是CriticalPatchAdvisor，它会向用户提醒Oracle发布的重要补丁，并立即识别出企业中可能需要新补丁的那些系统。
这样，管理员就能够知道是否要打补丁以及何时要打补丁了。
之所以能够提供此功能，是因为Oracle收集企业管理下的所有数据库的详细配置信息。
收集的数据包含以下信息： •主机硬件规格，包括CPU的个数和时钟速度、内存、硬盘和网络信息 •操作系统参数设置、文件系统信息和安装的程序包和补丁•主机上安装的Oracle软件，包括版本和组件信息、补丁集和临时 补丁，以及软件配置设置这个全面的系统信息库存储于EnterpriseManagerRepository中，它是Oracle的许多配置管理解决方案（包括软件维护）的基础。
默认情况下这些配置数据每日刷新一次。
此外，用户只需单击一个按钮即可随时刷新这些数据。
在收到补丁提醒后，下一步是应用该补丁。
另一个工具，PatchWizard，有助于完成这一工作。
该工具搜索、下载并应用补丁。
利用PatchWizard，可以搜索到适用于特定目标数据库的所有补丁，如果需要，管理员还可以用该工具来查询企业中所有可应用特定补丁的数据库。
在定位到必要补丁后，可以使用EnterpriseManager来下载和部署它。
另外，EnterpriseManager还可以执行最终用户提供的脚本来安装补丁。
通过这些步骤，管理员可以最小的工作量在客户的整个企业中快速应用补丁。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第26页 EnterpriseManagerDatabaseControl11g有一个自动打补丁功能，这使得它可以为自己打补丁。
该打补丁的功能通过可定制的部署过程而得到支持。
其工作流包括整个打补丁周期，从通过Metalink获取补丁、准备补丁、关闭服务、安装补丁到启动数据库。
OracleDatabase11g提供基于特性的补丁包通告。
它将补丁元数据与正在使用的特性相关联（与已安装的相对）。
这可以使数据中心避免大量令人失望的停机时间，这是由于它基于当前使用的产品而避免了不必要的补丁应用。
SQLServer2008在这一方面几乎没有提供任何解决方案。
它让管理员自己来决定需要哪些补丁，并且在其最近引入的基于策略的管理框架（需要进行设置）中几乎没有对补丁应用提供什么帮助。
这种情况下，主动性强的管理员经常要浏览Microsoft网站以便发现重要补丁，或者定期与其支持组织联系以了解那里是否有他们要应用的补丁。
主动性不强的其他管理员有可能只是被动等待，直到出现问题才会采取行动来弥补已造成的损害及对问题作出补救。
这不仅会额外占用管理员的时间，还可能会影响系统的可用性、可靠性和性能。
故障诊断 Oracle数据库包含一个可以防止、检测、诊断和解决问题的高级故障诊断基础架构。
这一基础架构特别针对那些影响数据库运行的严重错误。
发生严重错误时，系统为错误分配一个事件号，通过此号可以立即捕获和标记该错误的诊断数据。
接着将诊断数据存储在自动诊断信息库(ADR)中，这是一个位于数据库之外的基于文件的信息库，可以通过事件号检索信息库中的诊断数据并对其进行分析。
DBA随时都可通过单击一个按钮来自动打包有关严重错误的所有诊断数据（跟踪、转储、运行状况检查报告、SQL测试用例等），将这些数据打包为一个适于通过事件打包服务特性传输给OracleSupport的zip文件。
EnterpriseManagerSupportWorkbench是与Oracle数据库诊断基础架构进行交互的界面，该界面易于使用，它将系统中与数据库运行相关的事件及时呈现给DBA，同时还给出了如何处理事件的有关信息。
另外，该界面帮助DBA查看多个Oracle产品（如Net、客户端、ASM、OracleRAC等）的诊断信息、执行运行状况检查、将事件数据打包发给Oracle支持以及处理事件。
SupportWorkbench提供了一个查看和诊断事件数据并将其打包发给OracleSupport的简单工作流界面，从而大大缩短了为用户解决问题的时间。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第27页 SQLServer没有提供用于故障诊断及解决的有竞争性的解决方案。
一旦发生数据库错误，没有工具可以自动收集Microsoft支持专家高效解决问题所必需的有关信息。
使用Oracle，如果有适用于眼前问题的补丁，则系统将自动下载并应用该补丁。
若是使用SQLServer，则解决问题的时间和工作量将明显加大。
跨平台可移植性 Oracle体系结构的主要特长之一就是它对不同平台的可移植性。
Oracle实际上可用于所有平台，迄今为止，与其任何竞争对手相比，它是可移植性最好的数据库。
这意味着Unix上的Oracle数据库与WindowsOS上运行的Oracle数据库具有相同的代码库，这就确保了不同平台上的Oracle数据库管理是相同的。
这样，无需对OracleDBA进行额外培训就可以管理任何和全部平台上的数据库。
广泛可移植性的另一个好处是，可以独立于平台设计应用程序，从而可以目标专一地以最佳方式满足业务需求。
SQLServer却无法达到这种情况，因为它只能运行于Windows平台。
因此，未来任何的业务发展都将受限于Windows平台。
如果业务的发展超过了Windows的承受能力，这意味着，需要投入大量的时间和金钱来将所有硬件和软件系统升级到Unix、将数据迁移到更加可伸缩的数据库、重写应用程序以便运行于新的数据库上以及聘用或重新培训DBA。
如果使用Oracle，永远不必担心业务发展超过硬件承受能力这种情况，因为Oracle数据和应用程序完全兼容所有主要的硬件和操作系统平台，可完全移植到这些硬件和平台上。
可伸缩性 Oracle数据库最值得骄傲的一个优点是它的可伸缩性。
Oracle数据库可以无缝地从数百个用户扩展到数千个用户。
另外，从部署和管理的角度看，OracleRealApplicationsCluster(RAC)提供了最透明的集群数据库解决方案。
可以动态向RAC数据库添加节点而不会影响现有的节点。
并且，由于RAC环境中的所有节点都访问同一个数据库，因此节点的添加或删除不会给DBA造成额外的工作。
然而，RAC最独特的方面在于，应用程序无需经过任何修改就可以从单个节点转移到RAC环境，这与其他数据库产品（包括SQLServer）不同，使用其他产品时，必须针对集群环境重写应用程序。
RAC的这一独特优势归功于自Oracle9i开始引进的已获得专利的缓存融合技术。
7 7有关RAC和缓存融合的详细信息，请参阅白皮书“Oracle真正应用集群：缓存融合提供可伸缩性”，可在以下位置获得该白皮书：/products/oracle9i/pdf/cache_fusion_rel2.pdf OracleDatabase11g和SQLServer2008技术比较：针对可管理性第28页 Microsoft建议通过以下两种方式来实现SQLServer的可伸缩模型：分布式数据库环境或联合数据库体系结构，在这些环境中，许多独立的数据库连接在一起而不使用公共数据字典，单个应用程序可以跨所有数据库访问数据。
这里假设要执行在SQLServer联合体系结构环境中添加一个节点这么一个简单的任务。
就是这样一个简单任务，DBA或系统管理员也必须进行以下所有工作： •添加硬件•配置新实例（设置实例特有的参数等）•创建新数据库•断开所有用户•从现有表卸载数据•重新定义分区表和索引•重新定义分区表或复制表上的触发器•重新定义分布式分区视图•重新加载数据使其分散在更多分区中•重新连接所有用户。
这是一组高度复杂和精细的管理任务，包括卸载并重新加载数据、重新定义视图、修改触发器等等。
此外，在执行这些任务的整个操作期间，所有数据库均不能使用。
而如果使用OracleRealApplicationClusters，添加节点时，管理员只要执行以下两项任务：•添加硬件•配置新实例（设置实例特有的参数等）。
DBA无需卸载并重新加载数据，无需修改任何模式定义，系统始终也没有脱机。
因此，与Oracle相比，SQLServer的伸缩性解决方案甚至对于基本的任务也存在管理性方面的欠缺。
有关SQLServer要注意的另一点是，当要管理、维护、备份和升级的数据库数量达到数十个以上时，其管理的复杂性将急剧上升。
例如，为了达到较高的TPC-C基准，Microsoft必须使用32个不同的数据库。
因此，Microsoft的方法是分散，而不是包容复杂性。
对DBA们来说，与实现和管理像Oracle这样的单个更具伸缩性的数据库相比，管理如此之多的数据库确实令他们十分烦恼。
SQLServerMagazine编辑BrianMoran对此说道：“Microsoft在推销SQLServer时只是强调它的易用性，而在涉及到与UNIX对手相比管理性方面的复杂性（还有费用较高）时却含糊其辞。
”8 8SQLServerMagazineUPDATE新闻编辑，2001年1月。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第29页 Oracle的可伸缩性优势并非仅局限于多节点RAC模型。
作为市场上可移植性最高的数据库，它可以运行于所有主要OS平台（包括大型SMP）。
然而，SQLServer却只能运行于Windows操作系统。
这意味着，在一个机箱内SQLServer的可伸缩性局限于小型Windows计算机上，而Oracle却不受这种限制，因为它可以运行于所有主要平台。
它可以基于大型64cpuSMP机柜轻松进行伸缩而不会有任何问题。
从可管理性角度看，这是一个很大的优势，因为应用程序会随着时间不断扩展，而OracleDBA只需向计算机中添加更多的CPU就能满足这一扩展，然而，如果使用SQLServer，不断扩展的应用程序可能很快就会超过小型Windows计算机的承受能力。
这使得DBA没有其他选择，只能添加更多的计算机，之后寄希望于针对联合体系结构重新设计应用程序。
即使可以实现这种扩展，但却是一个极其痛苦和耗时的工作。
为了弥补SQLServer可伸缩性的不足，DBA必须管理一个复杂的、实际难以管理的环境。
即使类似于添加新节点这样简单的任务，也必须对应用程序数据进行精细的重新分配，这需要深入了解应用程序逻辑和数据库布局。
这些只是SQLServerDBA日常必需应对的可管理性问题的一部分，而Oracle的可伸缩性体系结构使所有这些对其DBA来说不再成为问题。
总结 与SQLServer2008相比，OracleDatabase11g不仅功能丰富，而且易于管理。
随着软件管理成本快速超越购置成本，其易用性和可管理性已经成为影响采购决策的最重要因素。
Oracle是市场上能够同时兼具这两方面优势的唯一解决方案。
SQLServer2008缺少许多基本管理功能，而这些功能对实现任务关键应用程序的高效数据库管理却是至关重要的。
迄今为止，SQLServer始终遵循并充分采用了延迟赶超战略，一直在复制Oracle以往版本的一些特性及成功之处。
由于SQLServer的DBA往往别无选择，他们只能采取繁琐的方法，这些方法既不直观，又十分复杂，常常会带来管理噩梦。
Oracle在可管理性方面的全面及结构化方法，无疑将使其未来版本与其竞争对手相比始终处于领先地位。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第30页 甲骨文（中国）软件系统有限公司 北京总部 地址：北京市朝阳区建国门外大街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)23961175传真：(86.24)23961033 南京分公司 地址：南京市玄武区洪武北路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-60952500传真：86-21-60952555 公司网址：（英文）中文网址：（简体中文）销售中心：800-810-0161售后服务热线：800-810-0366培训服务热线：800-810-9931 欢迎访问：（英文）（简体中文） 版权©2010归Oracle公司所有。
未经允许，不得以任何形式和手段复制和使用。
本文的宗旨只是提供相关信息，其内容如有变动，恕不另行通知。
Oracle公司对本文内容的准确性不提供任何保证，也不做任何口头或法律形式的其他保证或条件，包括关于适销性或符合特定用途的所有默示保证和条件。
本公司特别声明对本文档不承担任何义务，而且本文档也不能构成任何直接或间接的合同责任。
未经Oracle公司事先书面许可，严禁将此文档为了任何目的，以任何形式或手段(无论是电子的还是机械的)进行复制或传播。
Oracle是Oracle公司和/或其分公司的注册商标。
其他名字均可能是各相应公司的商标。
这两家供应商已将增强其数据库服务器的可管理性作为自己的一项主要目标，他们不断在每个新推出的版本中增加新特性以使数据库管理更加轻松和经济高效。
但是，尽管SQLServer2008针对可管理性增加了一些新特性，但它仍然落后于OracleDatabase11g。
OracleDatabase11g是一个成熟的具有自我管理能力的数据库，它能够自动进行自我监视、自适应和自我修复。
Oracle数据库的自我管理解决方案使DBA的工作更为高效，有助于其组织在不降低服务级别目标的情况下降低管理成本。
SQLServer的最新版本意在赶上Oracle已通过其OracleDatabase11g最新版本引入的可管理性特性，Oracle发布该最新版本时引入的这些特性在当时显著扩大了两家竞争对手之间的差距。
管理工具 Oracle和SQLServer分别提供了OracleEnterpriseManager和SQLServerManagementStudio来管理和维护其系统，这两个工具均为GUI工具。
EnterpriseManager11g是Oracle提供的用于管理和监视基于Oracle和第三方组件的应用程序和系统的统
一、集成的解决方案。
该工具能够通过单点控制无缝地管理跨组织和地理边界的成百数千的系统。
EnterpriseManager具有基于web的体系结构，该体系结构强健、可靠、可伸缩，并且在当今互联网驱动的环境中易于部署和运营。
该工具提供一个基于HTML的控制台界面，通过该界面，管理员可从任何位置进行管理—只需一个Web浏览器即可。
其强健的分组和任务自动化功能提供的核心特性使以前耗时、易错的任务（如应用性能管理、基于策略的标准化和系统供应）能够可靠、迅速、安全地自动进行。
从以数据库为中心的角度来看，EnterpriseManager极大地简化了数据库的日常管理，将这种简洁性与一组丰富特性相结合可以管理所有操作系统平台上任何规模的环境。
通过提供以下能力，该工具使许多关键管理任务能够自动进行，从而提高了管理员的工作效率： OracleDatabase11g和SQLServer2008技术比较：针对可管理性第3页 •在数据库创建过程中配置和启动所有必要的框架组件进程，EnterpriseManager提供的功能随即可用。
一旦创建了新的数据库，EnterpriseManager即已完全配置并且可以使用了。
•在主页面上提供企业运行状况的统一概览。
它显示数据库的可用性、警报和作业状态、配置信息、重要补丁的软件维护公告，并且能够追溯所有这些方面的更多详细信息。
•系统监视和警报通知，目的是预测问题并且如有可能，使用“fix-it”作业自动纠正问题。
众多Oracle客户，如British、Boeing、Telstra、Fidelity和Shell，已围绕EnterpriseManager进行了标准化实施以管理他们的生产系统。
这些客户的经历生动地证明了Oracle的管理工具在提高管理员工作效率、提高每位DBA可以管理的数据库数量方面是多么的富有成效。
OracleEnterpriseManager能够提供深度管理，而SQLServerManagementStudio缺乏深度管理能力。
后者不具有基于HTML的控制台界面，因而，对于管理员想要通过其管理SQLServer数据库的所有系统，均需安装相应的客户端工具。
这大大限制了管理员随时随地管理其数据库的能力。
SQLServer的管理工具所存在的另一个缺陷是，它不能通过单个控制台提供对整个系统的端到端的管理和诊断。
SQLServer的管理工具不能监视有关操作系统、中间层应用服务器的度量信息。
Oracle和SQLServer之间的另一个不同之处是它们的管理模式。
OracleEnterpriseManager遵循的是基于异常的管理模式，在这种模式下，只有在发生或即将发生异常状况时才需要DBA的干预。
Oracle在其主页面上突出显示出问题区域，如空间压力、性能问题等，这样人们可立即发现并处理任何潜在的问题或异常。
而SQLServer的方式与此非常不同，在SQLServer的方式下，DBA只能靠自己来监视系统以发现潜在的问题。
例如，如果一条SQL语句运行了很长时间还没有结束，在OracleEnterpriseManager11g主页面的诊断汇总区域下会主动显示出这条语句。
相比之下，对于SQLServer，DBA必须先对该数据库开启监视计数器（这显然会对性能产生负面影响），重新运行该工作负载（这可能不会总是可行的，并且永远是不方便的），然后对跟踪文件进行分析以确定哪条SQL语句占用的资源最多。
只有这样DBA才能知道是否存在正在影响系统性能的任何问题SQL。
因此，与Oracle的管理工具不同，SQLServer的管理工具需要其用户投入相当多的时间来执行通常的管理工作，其管理方式本质上是被动的而不是主动的，并且缺乏Oracle提供的许多管理功能。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第4页 存储管理 数据库管理员在存储管理方面面临着诸多挑战。
数据库的规模在迅速增长，而人们还要求数据库正常运行时间也要不断增长，这种情况下，越来越难以安排时间来使数据库脱机以进行维护操作（如更改磁盘配置）。
此外，系统管理员查找并消除I/O热点或碎片问题的过程可能十分辛苦。
与此同时，降低成本的压力不再允许扩大DBA队伍以应对数据库的高速增长。
这种情况将导致所谓“管理空白”的产生。
DBA需要更好的工具以便能够提高工作效率并帮助使其手动任务自动进行。
自动存储管理(ASM)是Oracle数据库的一个特性，该特性首次在10g版数据库中引入，它通过使整个功能自动化进行而提供了应对上述存储管理挑战的解决方案。
管理员只需要将一组存储设备分配给一个数据库实例，所有其它工作则由OracleASM解决方案自动完成。
ASM将数据库文件自动存放于指定的磁盘组中，并将数据均匀分布于所有可用存储资源上以最大程度提高性能和利用率。
对数据库文件的这种均匀分布使得人们不必再手动进行I/O性能调优。
ASM还提供了三个镜像选项以防止磁盘故障：无镜像、双重镜像和三重镜像。
此外，有了ASM，DBA不必使数据库脱机即可更改存储配置。
在添加或删除磁盘后，ASM自动在磁盘组中重新均衡分布文件。
ASM特性专为简化存储管理工作而构建。
该功能可节省管理员的时间并提供高效管理动态数据库环境的灵活性。
SQLServer不具备Oracle所提供的诸如此类的任何存储管理功能。
存储管理只能通过SQLServer2008引入的共享与存储管理控制台手动进行，或者，只能购买另一个工具来提供此功能。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第5页 空间和对象管理 主动空间管理 Oracle通过其空间监视、通知和空间趋势特性提供主动空间管理。
Oracle数据库服务器并非通过使用外部工具对数据库进行轮询来监视空间的使用情况（本质上来讲，这种方法要占用大量资源），而是具有内置的智能，能够提供对数据库空间使用情况的非侵入性、及时的检查。
如果表空间的空间使用超过了用户定义的阈值，Oracle服务器会发出警报来预先警告相应人员（即DBA）数据库即将用尽其空间，这样DBA就可以采取纠正措施。
默认情况下，Oracle会在表空间占用达到85%时发出一个警告性的警报，在表空间占用达到97%时发出严重警报。
DBA可以覆盖指定表空间的这些默认值（以已使用空间百分比的形式，或以字节计的可用空闲空间总量的形式），还可以对整个数据库设置新的默认值。
一旦采取了纠正措施，警报即被服务器自动清除。
Oracle还提供了完善的警报通知系统。
DBA可通过电子邮件、寻呼机、EnterpriseManager，或者直接通过查询数据库服务器中的视图来接收警报。
Oracle空间管理的关键之处在于其效率。
数据库服务器跟踪空间使用情况，同时执行常规的空间管理操作，如分配新的extent。
一个后台进程将表空间的状态与指定的阈值相比较，以确定是否发出或清除一个警报。
出现状态转换时，执行相应的操作，触发或清除一个警报。
Oracle的主动空间管理在默认情况下处于启用状态，它对系统的性能影响是可以忽略不计的。
SQLServer也具有监视空间使用情况的功能，但是它在以下几个方面不同于Oracle。
首先，它使用SQLServer代理来监视空间的使用情况，这个代理的主要功能是作业调度和警报处理。
因此，其监视和警报机制基于对数据库元数据的轮询，这种技术本质上讲效率低下且开销过高。
其次，SQLServer的空间监视和警报基础架构不如Oracle的灵活。
SQLServer只允许用户在数据库一级设置用于警报的空间使用阈值。
这意味着，如果您有两个不同的文件组（也就是Oracle术语的表空间），一个用于表，另一个用于索引，而您想对它们分别设置两个不同的警报阈值，这是一个非常基本的要求，但是您却办不到。
而Oracle允许在数据库级或表空间级设置警报阈值。
这增加了监视的粒度，使OracleDBA能够更为灵活和精确地设置空间使用准则以满足服务级别协议的要求。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第6页 联机重新组织 OracleDatabase11g允许管理员联机执行几乎所有的段维护操作，即在执行段维护操作的同时，完全可以对数据进行查询、更新和删除。
Schemaevolution使得可以在数据表处于服务状态时对表定义进行修改。
可以对表进行重定位、碎片整理、重新组织，或者对其存储参数进行更改。
可以联机添加索引、重建索引或对其进行碎片整理。
SQLServer对联机操作的支持不如OracleDatabase11g广泛。
SQLServer只是在最近才增加了联机创建、重建、删除索引的功能。
这允许在对索引执行DDL操作时对底层表或集群索引数据和任何相关索引进行并发修改（DML操作）。
这是对早期SQLServer版本的重大改进，在早期版本中，索引创建/重建操作需要获得底层数据和相关索引的排它锁，从而在完成该索引操作之前阻止对其进行修改或查询
1。
Oracle许多年前就已提供了这一功能，而且目前SQLServer仍然不具备Oracle所提供的联机Schemaevolution、表重新组织以及表重新定义这些功能。
这些维护操作中有许多是经常进行的操作，可能花费数小时才能完成，因此SQLServer2008应用程序用户可能要忍受明显的数据不可用性带来的痛苦。
为了对付这一问题，SQLServerDBA必须精确巧妙地安排执行这些操作的时间，以便减少系统不可用之影响。
这极大地增加了其DBA的管理工作量。
而对于OracleDBA来说，在他们的日常操作中对此是一点也无需顾虑的。
行大小限制 除少数例外，SQLServer通常对记录行的大小加以8060字节(8KB)的限制。
但在某些情况下这一限制会放宽，具体来说，对于包含varchar、nvarchar、varbinary或sql_variant列的表该限制会放宽。
这些列中每一列的长度仍然必须在8KB的范围内，然而它们加在一起的宽度可以超过表的8,060字节行限制。
这适用于varchar、nvarchar、varbinary或sql_variant列，无论是在更新或插入数据时，还是在创建、更改这些列时都是如此
2。
对于不在上述例外情况之内的表，SQLServerDBA只能以某种方法来克服8KB行大小的限制。
在这种情况下，SQLServerDBA的通常做法是垂直地将该表划分为多个表。
这种做法尽管解决了8KB限制的问题，却造成了另一问题，它使得应用程序的设计达不到最佳。
这又是一个OracleDBA无需顾虑的方面。
Oracle允许一个记录行跨越多个页面（Oracle称之为块），对其行大小不加限制。
1面向数据库管理员的SQLServer2008测试版2概述，/prodtechnol/sql/2008/maintain/sqlydba.mspx2SQLServer2008在线书籍，数据库设计与创建，表设计。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第7页 处理空间用尽状况 数据加载、批处理更新之类的操作在空间用尽时会遇到错误。
遗憾的是，这些错误有时发生于操作即将完成之时。
Oracle通过其可恢复空间分配特性，以一种无中断的方式来处理这类错误。
当操作遇到空间用尽的情况时，该操作留滞于“挂起”状态，同时系统产生一个警报来将问题通知给管理员以便纠正该问题。
一旦错误状况得以纠正，这个被“挂起”的操作就立即自动恢复。
在问题是瞬时的情况下（例如，一个查询用尽了临时空间），可能不需要管理员的干预，因为一旦该瞬时问题消失，Oracle会自动恢复该操作。
实际上，任何类型的操作，不论是PL/SQL或Java存储过程、DML或DDL语句，还是导出/导入或加载器会话，均可运行于“可恢复”模式。
该功能为Oracle所独有，在SQLServer中没有类似的功能。
SQLServerDBA要花费大量的时间来监视操作进度和重新执行需要长时运行的失败的操作，而OracleDBA却因为此功能而节省了大量的这类时间。
在SQLServer中，如果操作在其运行过程中遇到空间用尽的状况，只能在解决了空间问题之后重新运行整个操作。
这种方式不仅浪费时间，还可能有碍数据库的正常性能，例如，DBA不得不在正常的工作负载时段重新运行失败的批处理作业，这有碍于数据库的正常性能。
通过以无中断的方式来处理空间用尽状况，Oracle的可恢复空间分配特性避免了SQLServer用户可遇到的所有这类问题。
性能管理 性能诊断 性能诊断是DBA使用的非常重要的功能，往往被认为是即复杂又耗时的。
OracleDatabase11g提供了自动性能诊断和监视技术，该技术内置于数据库服务器中，能够使整个性能诊断过程自动进行，并且在遇到性能问题时可提供详细信息及其纠正措施。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第8页 性能统计信息收集 OracleDatabase11g维护着一个容纳系统运行相关信息的信息库，该信息库名为自动负载信息库(AWR)。
这个基础架构是Oracle的性能诊断解决方案的一个关键构建块。
它自动运行以收集有关Oracle系统运行的性能数据并将这些数据存储于数据库中。
作为数据库内核的一部分，AWR以最佳方式捕获最为相关的数据。
对它的设计目标是轻型、可自我管理。
它自动地每小时捕获一次数据，每8天清除一次数据。
该数据捕获频度以及数据保留时长是可以配置的。
此外，AWR还可按需运行，以便随人们的意愿在特定时间捕获信息。
AWR捕获所有需要的数据，根据这些数据足以执行彻底的系统级或用户级性能分析。
通过主动捕获数据，使人们不再需要为了进行问题诊断而重新运行负载。
AWR为改善OracleDatabase11g中的性能诊断工具打下了基础。
正是在AWR提供的数据基础上，自动数据库诊断监视器（Oracle的性能诊断引擎）才能执行分析以发现和纠正性能问题。
性能对比分析 OracleDatabase11g还提供丰富的报告和性能基准功能以促进性能对比分析。
一个性能基准包含某特定时段的性能数据，该数据是受保护的，不会被清除。
之后可以使用该基准来与任何其他时段的性能相对比。
通常，您会在数据库的运行性能参数处于可接受范围时创建一个基准。
之后，如果您察觉到性能背离了其常规状态，您随时可以运行AWR比较时段报告，该报告将确切地告诉您，与基准时段相比发生了什么变化。
该报告指出两个时段之间所有不同的性能属性和配置设置，有助于迅速找出性能背离常规的原因。
活动会话历史记录(ASH)活动会话历史记录(ASH)是Oracle内核收集的、作为AWR快照一部分保存的另一类重要统计数据。
ASH抽样采集所有活动会话的当前状态，所谓活动会话就是连接到数据库并且在当时正在使用CPU，或者正在等待非空闲事件的会话。
ASH每秒对活动会话进行一次状态采集，采集到的数据被保存到系统全局区域(SGA)的循环缓冲区中。
ASH数据还会经由AWR快照处理写到永久存储中。
活动会话历史记录使我们能够“回到过去”并进行极为详细的分析，通常能使我们不必重放负载来收集额外的性能跟踪信息以作为性能诊断的一部分。
举例来讲，通过ASH报告，我们可以诊断瞬时性能问题、锁定问题、事务长时运行问题、高开销SQL语句、占用数据库CPU最多的用户、普遍性的性能问题（DB时间的多维聚合以进行偏差分析）。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第9页 自动性能诊断自动数据库诊断监视器(ADDM)是Oracle数据库的一个特性，它主动分析AWR中现有的大量性能统计信息，向DBA准确指出问题所在以及如何纠正该问题。
由于ADDM是数据库内核的一部分，不是一个外部工具，因此，与传统监视系统相比，其诊断开销可以忽略不计。
该代码工具的引入对OracleEnterpriseManager11g所支持的实时反应性的调优方法的功能提供了支持和进一步的增强。
ADDM每小时主动运行一次，并报告数据库的运行状况。
AWR在默认情况下对所有性能相关信息的保留时间为8天，这使DBA能够对该保留时段内发生的任何问题进行诊断。
DBA只需查看相关时段的ADDM报告并实施它提出的建议。
下面总结了ADDM具备的主要优势：
1.每小时一次的自动性能诊断报告。
2.基于时间的量化的问题影响以及建议。
3.查明根本原因，而不只是症状。
4.由于AWR中保留的数据十分完整，因此极大减少了为进行详细分 析而重放负载的需要。
在OracleDatabase11g中，提供了对RealApplicationClusters(RAC)数据库的集群级性能分析，从而增强了ADDM。
对于RAC环境，ADDM分析RAC集群，对当前影响整个数据库及其各个实例的问题加以报告。
ADDM针对全局资源执行数据库级分析，如高负载SQL、全局缓存互连流量、网络延迟问题、实例响应时间偏差、I/O容量等。
DBA能够限制ADDM分析只对RAC集群的一些指定的实例来进行。
这称作局部分析ADDM，它只能通过PL/SQLAPI来使用。
有了针对RAC的ADDM，对RAC数据库的性能分析就象对单个实例数据库的性能分析一样简便。
在OracleDatabase11g中，DBA可以通过过滤和只显示其感兴趣的ADDM结果来隐藏其他的ADDM结果。
为了在以后更好地理解这些结果的影响，每个结果都有一个便于搜索的描述性名称、一个指向该结果在24小时内出现的次数的链接，以及一个指向受影响的实例的链接。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第10页 对于ADDM的自我诊断功能，SQLServer完全不具备类似功能。
对于SQLServer来说，所有性能问题只能通过手动方式来监视和诊断。
在SQLServer的性能诊断过程中，DBA首先必须根据要分析的问题类型来决定使用哪种工具来监视性能。
对于内存、磁盘和CPU操作的监视，您可能会使用Windows操作系统的系统监视工具。
而为了诊断SQLServer中其他类型的问题，DBA必须从以下工具中进行选择： •SQLProfiler•SQLTrace•SQLServerManagementStudioActivityMonitor•SQLServerManagementStudioGraphicalShowplan•DatabaseConsoleCommands(DBCC)诊断过程的下一步是指定要监视的组件。
举例来说，如果使用SQLProfiler来跟踪一个服务器，DBA必须指定该跟踪去收集与其环境有关的特定事件的相关数据。
在指定要监视的组件后，下一步是确定要监视的组件的指标。
例如，在选择跟踪要包括哪些事件后，DBA应选择只包括这些事件的特定相关数据，以便降低执行该跟踪时对系统资源的需求。
只有在完成所有上述步骤之后，DBA才可以开始对该服务器进行实际监视。
之后，作为监视结果而生成的跟踪文件只能手动加以分析以找出性能问题的原因。
SQLServer的性能诊断过程不仅笨拙耗时，还需要专业的性能工程师查看和理解收集的数据，并且在对性能问题提出纠正建议方面毫无帮助。
SQLServer方法的另一个局限是，它在本质上是被动的。
举例来讲，如果SQLServer系统的运行速度减慢，DBA首先要使用SQLProfiler来启用跟踪，接着重新运行负载，之后才可以对诸如SQL性能不佳等性能问题进行任何的分析。
与之相反的是，如果Oracle系统的性能表现低于预期，DBA只需查看当前的ADDM报告即可找出真正的原因及其纠正措施。
在最新的SQLServer2008版本中，Microsoft增加了一个新的名为ManagementDataWarehouse的特性并且大力推广之。
这是一个新的集中式数据信息库，可配置的性能数据收集和新的报告和监视工具用它来存储性能数据。
为了对性能问题进行有效的诊断，DBA需要知道系统出现问题之前的状况。
在SQLServer2008中，这三个特性：DataCollector、ManagementDataWarehouse(MDW)和专业的性能报告被认为可以解决这一问题。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第11页 支撑SQLServer的MDW的理念远非创新性的理念。
它和Oracle的AWR有点相像，但Oracle的AWR在多年前即已通过OracleDatabase10g而推出。
因此，这一次，SQLServer又重演了通过复制其竞争对手以前版本中的特性来追赶Oracle的一幕。
另外，与Oracle的AWR/ASH框架相比，MDW本身还存在不足。
它不象Oracle那样是现成配置的，在默认配置下它每日对每个实例收集的数据量可达0.5GB之多。
可通过SQLServer的中心管理控制台ManagementStudio更改默认收集设置。
总之，Oracle在性能诊断方面优于SQLServer。
它提供的解决方案是如此的全面和强大，甚至连新手也能轻松纠正性能问题。
一直在模仿Oracle旧版本特性的SQLServer，现在仍然采用的是手动的调优方法，这种方法既被动，又需要专业技能，并且十分耗时。
识别和调优高负载SQL语句 DBA可能会花大量时间去发现占用大量资源的SQL语句并对其进行调优。
在这一方面，Oracle使这一工作可完全自动化进行。
ADDM可主动识别高负载的SQL语句。
OracleDBA只需查看ADDM报告（该报告每小时自动生成一次），看是否存在需要注意的高负载SQL语句。
除了ADDM之外，Oracle还在自动负载信息库(AWR)中每小时捕获一次高负载SQL语句。
这类语句会显示于EnterpriserManager11g的TopActivity页面上。
在SQLServer中，识别高负载SQL语句的过程要复杂得多。
DBA首先要通过SQLProfiler建立一个跟踪事件，启用相关事件，然后重新运行负载以便在跟踪文件中捕获到运行时统计信息。
在跟踪文件生成之后，DBA还得手动进行分析以便找出高负载SQL语句。
这对于SQLServer管理员来说是一个很大的可管理性问题，原因如下：首先，对占用大量资源的SQL语句进行监视是数据库管理员常见的管理工作，因此，如果为了获取该信息而花费超过数分钟的时间常常是不可接受的。
其次，如果系统繁忙，则生成的跟踪文件的大小可能很容易就迅速增长到非常之大，从而非常难于从中提取有意义的信息。
在使这件非常重要的DBA任务自动化进行这一方面，SQLServer非常明显地落后于Oracle。
接着要对SQL语句进行调优。
OracleDatabase11g提供的SQLTuning和essAdvisor使这一过程也能自动进行。
这些工具用一个或多个SQL语句作为输入，以一种特殊的调优模式调用查询优化器以对这些SQL语句进行全面的调优。
其中会执行四种分析： OracleDatabase11g和SQLServer2008技术比较：针对可管理性第12页 •统计分析：查询优化器需要最新的对象统计信息以产生良好的执行计划。
该分析过程会识别出统计信息陈旧或缺失的对象并收集缺失的统计信息。
应注意的是，OracleDatabase11g是自动进行统计信息收集的。
因而，只有在自动统计信息收集特性被人为禁用时，才会出现此类问题。
•SQL配置文件生成：这是以前在OracleDatabase10g中引入的一个新特性（请不要与SQLServer的SQLProfiler工具相混淆，SQLProfiler基本上是一个用于跟踪文件管理的GUI界面），该特性彻底改革了SQL调优方法。
由于该特性的出现，我们不再需要根据优化器提示手动对SQL语句进行调优，该特性会为我们进行语句调优，而无需对SQL代码进行任何更改。
在该分析过程中，一条SQL语句的配置文件称作一个SQL配置文件，对这条语句建立的SQL配置文件包含了该语句特定的辅助统计信息。
由于缺少查询中有关不同对象之间关系的信息，查询优化器有时生成的执行计划可能不是最佳的。
在过去，Oracle和SQLServer均需通过在代码中手动添加查询提示来处理此问题。
现在，由于有了SQL配置文件功能，Oracle不再需要这种手动过程了，因为SQL配置文件功能通过采样和部分执行技术来收集额外的信息。
另外，从OracleDatabase11g开始，SQLTuningAdvisor用建议的SQL配置文件产生的新执行计划对SQL语句进行测试执行。
这极大提高了SQLTuningAdvisor建议的准确性和可靠性。
•访问路径分析：索引、分区和物化视图可减少全表扫描的需要，从而极大地提高SQL语句的性能。
该分析过程可找出能够极大提高查询性能的新的索引、分区、物化视图(mv)和mv日志。
•SQL结构分析：SQL语句若存在结构问题则可能导致性能不佳。
这些问题可能是语句的语法、语义或设计问题。
该分析过程提出重构SQL语句的建议以便提高性能。
通过执行上述分析并提出合适的操作建议，OracleDatabase11g及其SQLTuning和essAdvisor提供了一个全面的SQL调优解决方案，该解决方案使得人们不必再进行费时费力代价高昂的手动调优过程。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第13页 在这一方面，SQLServer只提供了一个片面的解决方案。
除了手动添加查询提示外，它没有提供其他的SQL调优方法，在对结构不良的SQL查询进行重写这一方面也没有提供任何帮助。
所有这些均需手动完成，这需要深入了解SQLServer的优化技术。
它只在簇索引、非簇索引和索引视图的生成这一方面提供了帮助，这依靠的是它的DatabaseTuningAdvisor，DatabaseTuningAdvisor是其IndexTuningWizard的增强版本。
DatabaseTuningWizard提供了一些在IndexTuningWizard中所没有的新选项，如时限调优，通过这一选项，用户可以指定该advisor对语句进行分析所花时间的限制，另外，还提供了执行实例级调优的能力。
所有这些调优选项及其他一些调优选项早已是Oracle的SQLTuning和essAdvisor的组成部分。
虽然SQLServer的DatabaseTuningAdvisor有助于对物理数据库设计进行调优，但是它将SQL调优中更具挑战性和耗时的工作留给了DBA和应用开发人员。
SQLServer2008中最新增加的功能是针对查询性能稳定性和可预测性的计划冻结功能，该功能用于锁住查询计划，从而使组织能够在进行硬件服务器更换、服务器升级和生产部署时推广稳定的查询计划。
此特性非常类似于Oracle的Outlines，Outlines近来为SQL配置文件所代替，后者是解决SQL语句性能不佳问题的一个更为智能的方法。
比起SQLServer的解决方案，Oracle的调优解决方案不仅全面和简便，而且，它是通过查询优化器自身来进行实际调优的，并非通过外部工具（外部工具通过各种方法强迫或哄骗优化器产生更好的执行计划），这是它与SQLServer解决方案的另一个重大不同之处。
与其他供应商（包括Microsoft）提供的调优工具相比，这是Oracle的一个重大优势，因为由查询优化器自身执行的调优操作在质量、可靠性和有效性方面超过了任何的外部组件。
自动SQL调优 与以前的版本相比，OracleDatabase11g中的SQL调优过程已得到了进一步的增强和自动化。
现在，SQLTuningAdvisor在系统维护时段可作为一个维护任务而自动运行。
每次运行时，它会自动选择系统中高负载的SQL查询并就如何对这些查询进行调优给出建议。
该自动SQLTuningAdvisor可配置为自动执行SQL配置文件建议。
这意味着数据库会自动对高负载SQL进行调优，不需要用户的任何输入或干预。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第14页 您可以查看指定时段内（如前七日）自动SQL调优的运行结果汇总，也可以查看对所有处理过的SQL语句提出的建议的详细报告。
该自动SQLTuningAdvisor经配置可运行于任何维护时段，如果需要，也可完全禁用它。
SQLServer没有提供可与Oracle的自动SQL调优相匹敌的特性，这主要是因为其SQL调优工具只能提供索引建议。
SQLServer的调优工具不如Oracle的解决方案全面，特别是，它们不能帮助执行计划调优，这意味着它们无法使这种复杂的工作自动进行。
在应用程序代码中手动添加查询提示是Microsoft对SQL执行计划进行调优的唯一方法，这种方法永远无法自动进行。
调优打包的应用程序 对打包应用程序（如SAP、Siebel或PeopleSoft）进行调优是对调优的另一种挑战。
由于客户无权修改应用程序代码，任何时候如果在打包的应用程序中遇到了严重的性能问题，客户只能将其作为缺陷记录下来发给应用程序供应商，然后就只能等待数周、数月甚至更长时间，直到收到对该问题的修复代码。
在过去，这是数据库管理系统客户所能采用的唯一办法。
而如今，Oracle为客户提供了另一个办法。
其SQL配置文件特性（该特性是SQLTuningAdvisor的一部分）无需更改应用程序代码即可调优SQL语句。
如前所述，SQL配置文件包含SQL语句中引用的各种表之间数据关系的相关信息，通过向查询优化器提供此额外信息来对SQL语句进行调优。
由于SQL配置文件存储于数据字典中而不是应用程序代码中，它们使得Oracle能够透明地调优打包应用程序。
Oracle是当今市场中唯一具有该功能的商业数据库。
Oracle客户不必将缺陷记录下来，也不必等待性能问题得以纠正。
有了SQL配置文件生成特性，调优可以立即进行。
SQLServer确实也提供了对打包应用程序进行调优的能力，但是它的解决方案本质上是重复性的并且必须手动进行。
在SQLServer2005中引入并且集成到了SQLServer2008的ManagementStudion中的计划指南，是一些可与SQL语句相关联的查询提示，用这种方法无需直接修改应用程序代码。
这确实使打包应用程序的调优成为可能，但是仍然需要DBA来确定用于调优SQL语句的正确提示。
这个过程本质上是重复而耗时的，需要DBA具备SQL优化技术的深入知识和专业技能。
而Oracle的解决方案是自动、准确和可伸缩的方案。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第15页 执行计划稳定性 DBA的一个渴望是可预测性，对于查询性能来说尤其如此。
查询的性能取决于其执行计划的优化程度。
执行计划越有效，查询性能就越好。
然而，Oracle和SQLServer均使用的优化模式—基于开销的优化，在生成查询执行计划时却依赖于数据库环境。
因此，数据库环境中的变化，如底层对象、内存参数等优化器统计信息的变化，可能会突然改变查询执行计划，大多数情况下这可改善执行计划，但有时也可使执行计划变得很糟。
在SQLServer中这是一个严重的问题，因为该数据库服务器在默认情况下会不断地重新生成优化器统计信息，从而使执行计划可能会不断变化。
在这种情况下，DBA只能关闭优化器统计信息自动生成和更新功能以使执行计划不再改变。
但是这会引发一系列新的问题。
因为此时表和索引的统计信息可能会变得过时，优化器被迫基于过时的数据来生成执行计划，从而产生不良优化结果。
SQLServer没有真正的解决方案来解决执行计划稳定性问题，事实上，其不断更新优化器统计信息的默认行为使这一问题更为严重。
不同于SQLServer，Oracle提供冻结执行计划的功能，它允许DBA通过创建SQL计划基准（作为SQL计划管理解决方案的一部分）来冻结执行计划。
该功能在OracleDatabase11g中引入，旨在防止因突然更改SQL执行计划而使性能退化。
它为捕获、选择和改进SQL执行计划提供了基础。
SQL性能可因各种更改而受到影响，如新的优化器版本或对优化器统计信息或参数的更改。
SQL计划管理是这么一种机制，它不断地记录和评估SQL语句的执行计划并建立由一组已知为高效的现有执行计划组成的基准。
之后，无论系统中发生着什么变化，都使用这些SQL执行计划基准来保持相应SQL语句的性能。
SQL计划管理通常用于在以下情形改善或保持SQL性能： •要安装新的优化器版本的数据库升级。
这种情况常常会使小部分SQL语句的执行计划产生变化，大多数这类计划更改不会改变或改善性能。
而其中有些计划更改却可能导致性能退化。
这时使用SQL计划基准可显著降低因数据库升级而引发的性能退化的可能性。
•正在进行系统或数据更改。
这些情况可影响一些SQL语句的执行计划，有可能导致性能退化。
使用SQL计划基准将有助于降低性能退化的可能并稳定SQL性能。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第16页 •部署新的应用模块。
部署新的应用程序或应用模块意味着将新的SQL语句引入系统。
应用软件可以使用在新SQL语句的标准测试配置下产生的合适的SQL执行计划。
SQL计划基准会不断地发展以产生更好的性能。
在SQL计划基准的发展阶段，OracleDatabase11g可配置为对新的执行计划进行例行评估，即在后台执行这些计划，然后将性能更佳的计划纳入到SQL计划基准中。
将一个新计划与SQL计划基准中采纳的计划进行性能比较，确认该计划提供更佳的性能，经过这一过程后，该计划验证成功。
只是在最近，SQLServer2008才增加了一个相当于Oracle的Outlines的用于冻结查询计划的功能。
然而，它仍然缺乏能考虑到底层数据变化的全面的解决方案，因此DBA仍然要靠自己来想方设法稳定SQL性能。
管理资源 能够轻松而正确地进行系统和资源管理，这对于保持应用程序和数据库的性能、可伸缩性和可用性来说至关重要。
OracleDatabaseResourceManager允许根据业务优先级来在数据库用户和应用程序之间分配CPU资源，从而使管理员能够按企业目标来分配系统资源。
它能够自动限制批处理作业占用的资源，从而有助于确保在混合负载环境中，这类操作不会对联机用户产生负面影响。
此外，DatabaseResourceManager还能够对运行时间较长的并发操作的数量进行限制，并能阻止在特定时段执行占用大量资源的查询。
因此，DatabaseResourceManager能够极为轻松地提供可预测的服务级别，最大程度降低了人工干预，有助于提供几乎无限的系统可伸缩性同时无需牺牲性能
3。
3有关详情，可访问以下网站，参阅其中标题为Oracle数据库资源管理器的白皮书：/technology/products/manageability/database/pdf/twp03/twp_oracle%20database%2010g%20resource%20manager.pdf OracleDatabase11g和SQLServer2008技术比较：针对可管理性第17页 “Oracle真正应用测试使更改测试所需时间减少80%之多，使测试成本降低70%之多，通过减少意外停机次数而降低了风险，并且改善了IT运营的服务质量。
” DavidMitchell 高级副总裁 OVUM SQLServer2008最终发布了一个类似于OracleResourceManager的特性。
该特性名为ResourceGovernor，与其Oracle的对应特性在功能上是类似的。
据Microsoft所说，ResourceGovernor允许数据库管理员为不同的负载定义资源限制和优先级，从而使并发负载能够向最终用户提供稳定的性能。
尽管ResourceGovernor毫无疑问被视为SQLServer2008的最重要的特性之
一，却并非没有缺点。
首先，ResourceGoverner只有在其发现没有可用剩余内存时才限制用户对内存的使用，使用户占用的内存不超过之前分配的内存百分比，但是，如果存在可用内存，并且没有挂起的负载，它会允许用户占用超过其指定限额的内存。
这在设计上是特意为之，目的是能最好地利用内存，避免资源浪费。
但是这么做也可产生负作用。
举例来讲，如果某位用户在其他用户之前发起了一个查询，则SQLServer将开始利用所有的可用内存，而后来的所有其他用户只能忍受这种结果。
其次，ResourceGovernor只针对数据库引擎，并不针对SQLServer中任何其他服务。
这意味着，您无法控制对ReportingServices、AnalysisServices和IntegrationServices的使用。
最后，如果有多个实例运行于同一台计算机上，ResourceGovernor不能跨实例管理负载。
更改保证 IT经理们每天都要面对来自各个方面的更改之需。
企业合规组要求IT基础架构（如数据库和操作系统）始终跟上最新补丁级别。
应用程序需要通过补丁或重大升级来进行升级。
这些可能是为了满足业务流程变更或为了修复应用程序缺陷。
无论企业是因合规性还是业务流程方面的原因而改善基础架构或更改数据库，Oracle数据库凭借其真正应用测试解决方案提供了一个全面的更改管理框架。
负载测试 数据库重放是真正应用测试解决方案的一个组成部分，它通过在测试系统中确实重建生产负载环境来对系统更改进行实际的测试。
为此，需要以低到可忽略不计的性能开销在生产系统中捕获负载，然后在测试系统中以原始负载的时限、并发性和事务特点重放负载。
这可以对更改影响（包括不理想结果、新的争用点或性能回退）进行完全评估。
提供了大量分析和报告，用于帮助识别任何潜在的问题，如新的系统错误或性能降级。
由于能够准确捕获生产负载，可完全消除开发模拟负载或脚本的必要性，从而可节省大量成本和时间。
因此，以前使用负载模拟工具/脚本对复杂应用程序进行的需要花几个月才能完成的测试，现在借助数据库重放的帮助只需几天就可完成。
因此，使用数据库重放，企业可以降低其测试成本，同时仍然对系统更改整体成功充满高度的信心。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第18页 SQLServer没有提供全面的负载测试解决方案。
对此，Microsoft希望用户购买第三方产品来实现此目标。
SQLServer的Profiler提供了一个图形界面来生成和管理跟踪文件，然后分析和重放跟踪结果。
如果使用SQLProfiler来跟踪生产服务器，明智的做法是使跟踪在时间上更为集中有限，以便尽可能降低跟踪对您的服务器带来的负荷。
SQLProfiler的问题是它提供的负载测试并非实际负载测试。
它分析数据库中各种操作和事件产生的跟踪文件，在进行测试和诊断时利用该信息向数据库重新提交同样的调用。
该方法的困难之处在于，提交的这些调用并不具有原先的并发性和定时特征。
事实上，所有调用均以串联方式来提交。
另外，SQLProfiler在重放过程中不能保持多个会话间事务的相关性。
这使得SQLProfiler不是十分有用，因为它确实不能生成具有生产环境特征的负载来用于测试。
此外，SQLProfiler不具备数据库重放所能提供的诸如提高或降低重放速度等这类高级功能，数据库重放可通过对调用之间的思考时间进行控制来提高或降低重放速度。
与SQLProfiler不同，Oracle真正应用测试的数据库重放是一个成熟的解决方案，此方案的设计是为了满足市场的这种非常重大的需求—能够用真实发生的实际生产负载来对数据库系统进行测试。
确保SQL性能 SQL性能分析程序(SPA)是Oracle真正应用测试的第二个组件，它提供的功能类似于数据库重放，但其重点在于对任何影响SQL执行性能的更改导致的问题进行预测。
SPA对SQL执行计划和统计信息的更改提供细粒度的评估，为此，它顺次在更改前后执行SQL语句，然后自动比较它们的性能以确定性能变化。
这使得用户可以对更改的整体效果进行评估，从而能够在最终用户受到影响前纠正不良结果。
能够准确预测系统更改对SQL性能的潜在影响，这种能力使您能够预先对系统进行调优防止一些SQL语句出现性能退化，或者在SQL语句性能提高时能够验证并估量性能提高程度。
SQLServer未提供可与Oracle的SPA相媲美的解决方案。
其SQLProfiler可以捕获SQL语句，但是它不能发现SQL语句的性能变化，而且和SPA不同，它没有任何可显示出应用负载的性能差异的报告。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第19页 备份与恢复 备份文件管理 数据库备份的对象包括不同类型的多个文件，如数据文件、事务日志文件、重做日志文件、控制文件等。
随着常规备份的不断进行，这些文件可能会不断增多，对它们进行手动管理的工作可能会迅速变得繁重起来。
如果DBA手动管理备份文件，则他们需要确保在恢复时所需的所有不同类型的文件都确实得到了正确的备份；他们必须有一个可靠的备份跟踪机制以便确定这些文件是否变得多余因而可以被删除；他们必须密切监视备份位置以保证有足够的空间可用于新的备份，等等。
即使对于小型系统来说，手动完成这些工作都可能是繁重的事情。
OracleDatabase11g通过引入快速恢复区域特性来使所有备份文件的管理工作自动进行。
快速恢复区域是Oracle数据库中所有与恢复相关的文件的一个统一的存储位置。
通过定义初始化参数DB_RECOVERY_FILE_DEST，将所有的RMAN（恢复管理器）备份、归档日志、控制文件和数据文件副本自动写入到Oracle管理下的指定磁盘位置。
如果存在空间压力，快速恢复区域根据DBA指定的保留策略自动删除不再需要的过时备份和归档日志。
若您将保留策略设置为7天的恢复时窗，则Oracle会保留为将数据库恢复到过去7天的状态而需要的所有备份。
OracleDatabase11g的快速恢复区域特性使DBA能够从肩头卸下另一件单调繁重的任务，使介质恢复操作更为迅速、简单和可靠。
SQLServer也提供管理备份文件的功能，但它不如Oracle提供的功能成熟高级。
它提供的备份向导可对相关文件进行备份，但是，不象Oracle，它没有一种智能机制来自动清理备份位置。
在SQLServer中，DBA可以指定一个时段，备份位置中早于这个时段的所有文件均为过期文件因而可以删除。
这种方法太过单纯以至于不太有用。
在备份即包含完全备份又包含增量备份（如今，这是相当常见的备份策略）的混合环境下，SQLServer不具备识别这两种备份之间不同之处的智能，因而，即使系统处于空间压力之下，它也将保持多余的增量备份，只要这些备份不早于预定义的过期时间。
在系统即将用尽空间，须删除不需要的文件时，DBA实际上只能人为地将需要的文件与不需要的文件区分开来。
另外要记住的是，在SQLServer的术语中，一个实例一般包括若干数据库（一个SQLServer数据库可被视作相当于一个Oracle表空间）。
这使得事情愈加复杂，因为DBA不仅要跟踪单个数据库所需要的文件，还要在多个(SQLServer)数据库间使它们相互关联并维护它们以便确保在需要进行恢复操作时能够提供所有必备的文件。
这增加了DBA的负担，并且带来了因人为错误导致恢复失败的可能。
在SQLServer2008中，以备份压缩的方式增加了对数据库备份的改善。
通过压缩，联机保持备份需要更少的磁盘I/O、更少的存储空间，并且速度得到了一些提高。
然而，其数据库备份整体方法未变，从而该解决方案比不上OracleDatabase11g。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第20页 完备的备份 在Oracle中，备份是全面和非常完备的。
只要存在数据库的良好备份，DBA就可以在任何情况下恢复Oracle数据库。
在SQLServer中却不是这样。
如果SQLServer系统数据库msdb丢失，DBA即使执行过常规备份，也要在疯狂地搜索到原始安装CD之后才有可能恢复系统。
这是由于SQLServer备份是不完备的。
DBA首先要使用命令行实用程序rebuildm.exe，通过原始安装CD手动重建系统数据库msdb4。
只有在主数据库恢复之后，才能开始恢复应用数据库。
这使得完全恢复SQLServer实例的工作相当复杂，非常不直观，这不象Oracle，在Oracle中，只需使用恢复向导即可执行同样的操作。
甚至在恢复中断的数据库实例这一最为重要的DBA工作方面，SQLServer对其DBA造成了一个严重的可管理性障碍。
智能恢复 Oracle数据库以其DataRecoveryAdvisor(DRA)工具进一步证明了其优越的可管理性和可靠性。
DRA自动诊断数据故障，确定并提供合适的可选修复方法，并根据用户的请求执行修复。
DRA以一种智能方式提供可选修复方法，从而使管理员用于寻找数据库故障根本原因和制定行动计划的时间大为减少。
与SQLServer的修复技术相比，DRA使Oracle具有以下优势： •DRA可在早期发现、分析和修复数据故障，因而可减少因数据损坏而造成的损害。
•自动故障诊断对数据故障的症状进行判断，将它们与问题综述相关联，并将这些结果报告给用户。
•在存在多个故障的情况下，修复的正确次序并非总是显而易见。
DRA自动确定最好的修复方法，运行检查以确保在该环境中这些方法切实可行。
•执行数据修复的过程可能复杂且易于出错。
DRA使这一过程自动进行，此外，它还会对是否成功修复进行验证。
4SQLServer在线书籍：如何重建主数据库。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第21页 SQLServer重建事务日志、运行修复以纠正任何损坏、确保不打破数据逻辑完整性的手动过程过于复杂、易错和耗时。
这种手动过程迫使许多DBA为了保持SLA而仅仅重建事务日志就开始继续其日常操作—不进行检查、不进行修复、不进行根本原因分析。
5 从人为错误中恢复 众多可用性研究均已强调人为错误是造成应用中断的最主要的原因。
人们可以增强针对软硬件故障的防护措施，却几乎不可能使系统杜绝人为错误（如意外删除重要数据）。
再一次地，只有Oracle利用其闪回技术特性提供了从这类故障中进行恢复的简便、完备、非侵入性的方法。
闪回技术提供了一组新的特性来查看和来回回退数据。
使用闪回特性，可以查询模式对象的过往版本、查询历史数据、执行更改分析，或者执行自助修复，以便在数据库联机时从逻辑损坏中恢复。
利用Oracle数据库的闪回技术，您确实可以回到过去（根据需要回到过去的任意时间）以撤消您所犯下的错误！ 恢复已删除的表Oracle的闪回删除特性允许即时恢复被误删的表。
当用户删除一个表时，Oracle自动将该表放入“回收站”中。
该回收站是一个虚拟容器，所有被删除的对象都位于这里。
对象保留于回收站中，直到Oracle需要回收空间以容纳新的数据或者被删除对象的拥有者决定用新的PURGE命令永久删除它们。
只要被删除对象保留于回收站中，即可用一条简单的SQL语句将其恢复：FLASHBACKTABLE
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第22页 从逻辑数据损坏中恢复 由于用户的错误（如一个批处理作业运行了两次），在数据库中可能会出现逻辑损坏。
在这种情况下，最常用的补救办法是将数据库恢复到造成该损坏的操作执行前的某个时间。
传统地，这意味着要先通过一个备份来恢复数据库，然后对其执行时间点介质恢复。
这种形式的恢复可能单调乏味并且常常要花费很长的时间。
这是SQLServer中唯一可用的方法。
而Oracle不仅提供了传统的介质恢复方法，还提供了明显更为快速和简单的基于其闪回技术的解决方案。
闪回支持任何粒度级（包括数据库、表、事务和行级）的恢复。
•闪回数据库：这是应对大范围数据损坏的最好的方法。
闪回数据库方法使用名为“闪回日志”的一种特殊类型的文件将Oracle数据库迅速回退到用户指定的某个过去的时间。
此文件随着数据块不断发生变化而捕获这些数据块的映像，因而保存有过去时间的数据块映像。
此文件越大，数据库可以回退到的时间点就越久远。
DBA可以根据其业务需要来规定该文件的大小。
使用FLASHBACKDATABASE命令来恢复数据库没有与恢复备份相伴的中断时间，并且能够非常轻松迅速地从人为错误造成的逻辑数据损坏中进行恢复。
•闪回表：对于只影响到少数表的数据损坏，这提供了一个更有针对性的恢复方法。
闪回表方法使DBA能够将一个或一组表迅速地联机恢复到一个指定的过去时间点。
它在恢复表时自动保持表的各种属性，如当前的索引、触发器和约束，并且不需要DBA发现和恢复应用的特定属性。
闪回表方法减少了对整个数据库执行更为复杂的恢复操作的需要。
•闪回事务：此特性支持更加细粒度的恢复，它可使导致损坏发生的特定事务倒退回去。
它提供了一种在事务级查看对数据库的更改和撤消这些更改的机制。
它可使数据库回退到这么一种状态，就好象这个事务，以及与该事务有关的任何事务，从来没有发生过。
•闪回版本查询：该方法允许在行级进行恢复。
它提供了这么一种机制，即不断查看在记录行一级对数据库进行的更改，使用户能够有选择性地撤消因人为错误而导致的意外更改。
•闪回数据归档（全面撤消）：此技术提供了一个极为安全、高效、易用和应用透明的历史数据管理解决方案，还提供了一个集中、安全、可查询的数据存储，这些功能具有最高的资源效率，同时降低了诸如SOX、HIPAA和BASEL-II等法规的相关合规性成本。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第23页 该闪回技术为Oracle所独有，SQLServer不具备可与之相媲美的技术。
在SQLServer中，对所有上述人为错误的纠正方法是整个数据库的时间点恢复。
这种恢复是一种脱机操作，它的速度很慢，并且可导致数据丢失。
与之相反的是，Oracle的闪回技术为用户提供了多种从人为错误中恢复的可选方法，而且这些方法不会牺牲任何数据，也不会降低系统的可用性。
此技术从损害中进行恢复的能力非常精确、高效，并且最值得一提的是，它是快速而易用的。
安装与配置 实例创建 创建实例是DBA的一项最基本和重要的任务。
Oracle有一个简便易用的GUI工具，DatabaseConfigurationAssistant(DBCA)，该工具用于创建数据库实例。
DBCA替用户执行所有必需的步骤，它只需要最少的用户输入，用户无需详细设计数据库的参数和结构。
此外，DBCA还根据用户输入提供关于一些数据库设置的建议，因而有助于数据库管理员根据数据库的具体用途（是用于数据仓储、OLTP还是混合负载应用）来进行正确的决策以得到最佳的数据库配置。
在SQLServer中，每次创建实例时，都需要全部重新安装所有的二进制文件和脚本。
而Oracle与此不同，其在同一台计算机上的多个实例共享二进制文件及其他相关文件。
结果是，只要多个实例需要共享同一台计算机，SQLServerDBA就得接受相当大量的空间被浪费的情况，因为每个实例都需要自己专用的二进制文件和脚本。
在SQLServer2008中，Microsoft声称已重新设计了更好的安装过程。
这些改进将计算机上的程序安装与SQLServer软件的配置相分离，这使得组织和软件合作伙伴可提供建议的安装配置。
然而，在SQLServer软件的配置过程中，在对数据库参数的设置方面没有提供任何帮助，因而增加了其DBA的负担。
数据库复制 为企业级数据库创建一个标准的定义是相当常见的做法。
使所有数据库遵循一个标准会大大简化对它们的管理，因为这样可以使用一致的管理和监视过程。
另外，为了建立开发和测试环境，DBA常常想要复制数据库。
Oracle数据库模板支持以XML格式保存数据库定义，有了这些模板，就能极为简便地完成上述两种任务。
模板定义包括数据库的所有特征，如初始化参数、重做日志设置等，可使用模板定义在本地或远程计算机上创建同样的数据库。
模板有两种类型，一类只包含数据库的结构，另一类即包含结构也包含数据。
此功能使得管理员既可以创建新的结构相同的数据库，又可以连同数据一起克隆一个数据库。
可通过对现有数据库的反向工程来创建一个模板。
这种功能极为有用，因为它可节省管理员在创建和测试脚本以便复制数据库这些方面所花的大量的时间和精力。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第24页 SQLServer没有可与之相媲美的特性。
它只有一种方法来创建新的SQLServer数据库，就是使用CopyDatabaseWizard。
此方法有许多缺点。
首先，这种方法不能只复制数据库的结构，只能连数据库结构带数据一起复制。
其次，要复制的数据库上不能有任何活动的会话，就是说，该数据库必须处于脱机状态，不能为用户所使用
6。
若SQLServerDBA只想复制数据库的结构（这种情况更为常见），则只能使用脚本或GUI工具手动重建该数据库及其所有对象。
这是非常笨拙和易错的方法，当然无法与Oracle提供的功能相提并论。
安装克隆 OracleEnterpriseManager为用户提供了一个将Oracle软件安装（又称为Oracle主目录）复制到多台主机上的方便灵活的方法。
在一个直观向导的指导下，用户可以指定源系统上的一个Oracle软件主目录，然后选择一个或多个目标主机以便将该主目录复制到这个（些）主机上。
通过“多播”技术，只需一次操作即可创建多个新的安装。
唯一的要求是，在所有相关系统上都要安装EnterpriseManager代理。
对Oracle主目录的克隆以一种智能的方式来进行，即，在克隆过程中对环境相关的主目录属性（如主目录名称、IP地址或监听器设置）进行自动调整。
此外，对于跟踪系统上所有Oracle安装的OracleUniversalInstaller(OUI)库，克隆过程中会对其进行自动更新。
克隆操作可作为EnterpriseManager作业在非工作时间调度执行以极大降低网络负载。
SQLServer不支持软件克隆。
用户只能在所有系统上手动安装SQLServer软件，然后只能用DatabaseCopy向导特性将数据库分别复制到新的位置。
不能克隆软件安装是SQLServer的另一个不足之处，它加剧了用户面临的可管理性挑战。
6SQLServer2008在线书籍，使用复制数据库向导管理数据库引擎。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第25页 软件维护 打补丁 管理员花费大量时间来进行软件维护操作，如应用软件补丁。
能够快速发现系统的相关补丁并在系统上应用它们对于维护系统的可靠性和性能来说至关重要。
OracleEnterpriseManager为管理员提供了强大的新的补丁管理工具。
其中一个新工具是CriticalPatchAdvisor，它会向用户提醒Oracle发布的重要补丁，并立即识别出企业中可能需要新补丁的那些系统。
这样，管理员就能够知道是否要打补丁以及何时要打补丁了。
之所以能够提供此功能，是因为Oracle收集企业管理下的所有数据库的详细配置信息。
收集的数据包含以下信息： •主机硬件规格，包括CPU的个数和时钟速度、内存、硬盘和网络信息 •操作系统参数设置、文件系统信息和安装的程序包和补丁•主机上安装的Oracle软件，包括版本和组件信息、补丁集和临时 补丁，以及软件配置设置这个全面的系统信息库存储于EnterpriseManagerRepository中，它是Oracle的许多配置管理解决方案（包括软件维护）的基础。
默认情况下这些配置数据每日刷新一次。
此外，用户只需单击一个按钮即可随时刷新这些数据。
在收到补丁提醒后，下一步是应用该补丁。
另一个工具，PatchWizard，有助于完成这一工作。
该工具搜索、下载并应用补丁。
利用PatchWizard，可以搜索到适用于特定目标数据库的所有补丁，如果需要，管理员还可以用该工具来查询企业中所有可应用特定补丁的数据库。
在定位到必要补丁后，可以使用EnterpriseManager来下载和部署它。
另外，EnterpriseManager还可以执行最终用户提供的脚本来安装补丁。
通过这些步骤，管理员可以最小的工作量在客户的整个企业中快速应用补丁。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第26页 EnterpriseManagerDatabaseControl11g有一个自动打补丁功能，这使得它可以为自己打补丁。
该打补丁的功能通过可定制的部署过程而得到支持。
其工作流包括整个打补丁周期，从通过Metalink获取补丁、准备补丁、关闭服务、安装补丁到启动数据库。
OracleDatabase11g提供基于特性的补丁包通告。
它将补丁元数据与正在使用的特性相关联（与已安装的相对）。
这可以使数据中心避免大量令人失望的停机时间，这是由于它基于当前使用的产品而避免了不必要的补丁应用。
SQLServer2008在这一方面几乎没有提供任何解决方案。
它让管理员自己来决定需要哪些补丁，并且在其最近引入的基于策略的管理框架（需要进行设置）中几乎没有对补丁应用提供什么帮助。
这种情况下，主动性强的管理员经常要浏览Microsoft网站以便发现重要补丁，或者定期与其支持组织联系以了解那里是否有他们要应用的补丁。
主动性不强的其他管理员有可能只是被动等待，直到出现问题才会采取行动来弥补已造成的损害及对问题作出补救。
这不仅会额外占用管理员的时间，还可能会影响系统的可用性、可靠性和性能。
故障诊断 Oracle数据库包含一个可以防止、检测、诊断和解决问题的高级故障诊断基础架构。
这一基础架构特别针对那些影响数据库运行的严重错误。
发生严重错误时，系统为错误分配一个事件号，通过此号可以立即捕获和标记该错误的诊断数据。
接着将诊断数据存储在自动诊断信息库(ADR)中，这是一个位于数据库之外的基于文件的信息库，可以通过事件号检索信息库中的诊断数据并对其进行分析。
DBA随时都可通过单击一个按钮来自动打包有关严重错误的所有诊断数据（跟踪、转储、运行状况检查报告、SQL测试用例等），将这些数据打包为一个适于通过事件打包服务特性传输给OracleSupport的zip文件。
EnterpriseManagerSupportWorkbench是与Oracle数据库诊断基础架构进行交互的界面，该界面易于使用，它将系统中与数据库运行相关的事件及时呈现给DBA，同时还给出了如何处理事件的有关信息。
另外，该界面帮助DBA查看多个Oracle产品（如Net、客户端、ASM、OracleRAC等）的诊断信息、执行运行状况检查、将事件数据打包发给Oracle支持以及处理事件。
SupportWorkbench提供了一个查看和诊断事件数据并将其打包发给OracleSupport的简单工作流界面，从而大大缩短了为用户解决问题的时间。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第27页 SQLServer没有提供用于故障诊断及解决的有竞争性的解决方案。
一旦发生数据库错误，没有工具可以自动收集Microsoft支持专家高效解决问题所必需的有关信息。
使用Oracle，如果有适用于眼前问题的补丁，则系统将自动下载并应用该补丁。
若是使用SQLServer，则解决问题的时间和工作量将明显加大。
跨平台可移植性 Oracle体系结构的主要特长之一就是它对不同平台的可移植性。
Oracle实际上可用于所有平台，迄今为止，与其任何竞争对手相比，它是可移植性最好的数据库。
这意味着Unix上的Oracle数据库与WindowsOS上运行的Oracle数据库具有相同的代码库，这就确保了不同平台上的Oracle数据库管理是相同的。
这样，无需对OracleDBA进行额外培训就可以管理任何和全部平台上的数据库。
广泛可移植性的另一个好处是，可以独立于平台设计应用程序，从而可以目标专一地以最佳方式满足业务需求。
SQLServer却无法达到这种情况，因为它只能运行于Windows平台。
因此，未来任何的业务发展都将受限于Windows平台。
如果业务的发展超过了Windows的承受能力，这意味着，需要投入大量的时间和金钱来将所有硬件和软件系统升级到Unix、将数据迁移到更加可伸缩的数据库、重写应用程序以便运行于新的数据库上以及聘用或重新培训DBA。
如果使用Oracle，永远不必担心业务发展超过硬件承受能力这种情况，因为Oracle数据和应用程序完全兼容所有主要的硬件和操作系统平台，可完全移植到这些硬件和平台上。
可伸缩性 Oracle数据库最值得骄傲的一个优点是它的可伸缩性。
Oracle数据库可以无缝地从数百个用户扩展到数千个用户。
另外，从部署和管理的角度看，OracleRealApplicationsCluster(RAC)提供了最透明的集群数据库解决方案。
可以动态向RAC数据库添加节点而不会影响现有的节点。
并且，由于RAC环境中的所有节点都访问同一个数据库，因此节点的添加或删除不会给DBA造成额外的工作。
然而，RAC最独特的方面在于，应用程序无需经过任何修改就可以从单个节点转移到RAC环境，这与其他数据库产品（包括SQLServer）不同，使用其他产品时，必须针对集群环境重写应用程序。
RAC的这一独特优势归功于自Oracle9i开始引进的已获得专利的缓存融合技术。
7 7有关RAC和缓存融合的详细信息，请参阅白皮书“Oracle真正应用集群：缓存融合提供可伸缩性”，可在以下位置获得该白皮书：/products/oracle9i/pdf/cache_fusion_rel2.pdf OracleDatabase11g和SQLServer2008技术比较：针对可管理性第28页 Microsoft建议通过以下两种方式来实现SQLServer的可伸缩模型：分布式数据库环境或联合数据库体系结构，在这些环境中，许多独立的数据库连接在一起而不使用公共数据字典，单个应用程序可以跨所有数据库访问数据。
这里假设要执行在SQLServer联合体系结构环境中添加一个节点这么一个简单的任务。
就是这样一个简单任务，DBA或系统管理员也必须进行以下所有工作： •添加硬件•配置新实例（设置实例特有的参数等）•创建新数据库•断开所有用户•从现有表卸载数据•重新定义分区表和索引•重新定义分区表或复制表上的触发器•重新定义分布式分区视图•重新加载数据使其分散在更多分区中•重新连接所有用户。
这是一组高度复杂和精细的管理任务，包括卸载并重新加载数据、重新定义视图、修改触发器等等。
此外，在执行这些任务的整个操作期间，所有数据库均不能使用。
而如果使用OracleRealApplicationClusters，添加节点时，管理员只要执行以下两项任务：•添加硬件•配置新实例（设置实例特有的参数等）。
DBA无需卸载并重新加载数据，无需修改任何模式定义，系统始终也没有脱机。
因此，与Oracle相比，SQLServer的伸缩性解决方案甚至对于基本的任务也存在管理性方面的欠缺。
有关SQLServer要注意的另一点是，当要管理、维护、备份和升级的数据库数量达到数十个以上时，其管理的复杂性将急剧上升。
例如，为了达到较高的TPC-C基准，Microsoft必须使用32个不同的数据库。
因此，Microsoft的方法是分散，而不是包容复杂性。
对DBA们来说，与实现和管理像Oracle这样的单个更具伸缩性的数据库相比，管理如此之多的数据库确实令他们十分烦恼。
SQLServerMagazine编辑BrianMoran对此说道：“Microsoft在推销SQLServer时只是强调它的易用性，而在涉及到与UNIX对手相比管理性方面的复杂性（还有费用较高）时却含糊其辞。
”8 8SQLServerMagazineUPDATE新闻编辑，2001年1月。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第29页 Oracle的可伸缩性优势并非仅局限于多节点RAC模型。
作为市场上可移植性最高的数据库，它可以运行于所有主要OS平台（包括大型SMP）。
然而，SQLServer却只能运行于Windows操作系统。
这意味着，在一个机箱内SQLServer的可伸缩性局限于小型Windows计算机上，而Oracle却不受这种限制，因为它可以运行于所有主要平台。
它可以基于大型64cpuSMP机柜轻松进行伸缩而不会有任何问题。
从可管理性角度看，这是一个很大的优势，因为应用程序会随着时间不断扩展，而OracleDBA只需向计算机中添加更多的CPU就能满足这一扩展，然而，如果使用SQLServer，不断扩展的应用程序可能很快就会超过小型Windows计算机的承受能力。
这使得DBA没有其他选择，只能添加更多的计算机，之后寄希望于针对联合体系结构重新设计应用程序。
即使可以实现这种扩展，但却是一个极其痛苦和耗时的工作。
为了弥补SQLServer可伸缩性的不足，DBA必须管理一个复杂的、实际难以管理的环境。
即使类似于添加新节点这样简单的任务，也必须对应用程序数据进行精细的重新分配，这需要深入了解应用程序逻辑和数据库布局。
这些只是SQLServerDBA日常必需应对的可管理性问题的一部分，而Oracle的可伸缩性体系结构使所有这些对其DBA来说不再成为问题。
总结 与SQLServer2008相比，OracleDatabase11g不仅功能丰富，而且易于管理。
随着软件管理成本快速超越购置成本，其易用性和可管理性已经成为影响采购决策的最重要因素。
Oracle是市场上能够同时兼具这两方面优势的唯一解决方案。
SQLServer2008缺少许多基本管理功能，而这些功能对实现任务关键应用程序的高效数据库管理却是至关重要的。
迄今为止，SQLServer始终遵循并充分采用了延迟赶超战略，一直在复制Oracle以往版本的一些特性及成功之处。
由于SQLServer的DBA往往别无选择，他们只能采取繁琐的方法，这些方法既不直观，又十分复杂，常常会带来管理噩梦。
Oracle在可管理性方面的全面及结构化方法，无疑将使其未来版本与其竞争对手相比始终处于领先地位。
OracleDatabase11g和SQLServer2008技术比较：针对可管理性第30页 甲骨文（中国）软件系统有限公司 北京总部 地址：北京市朝阳区建国门外大街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)23961175传真：(86.24)23961033 南京分公司 地址：南京市玄武区洪武北路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-60952500传真：86-21-60952555 公司网址：（英文）中文网址：（简体中文）销售中心：800-810-0161售后服务热线：800-810-0366培训服务热线：800-810-9931 欢迎访问：（英文）（简体中文） 版权©2010归Oracle公司所有。
未经允许，不得以任何形式和手段复制和使用。
本文的宗旨只是提供相关信息，其内容如有变动，恕不另行通知。
Oracle公司对本文内容的准确性不提供任何保证，也不做任何口头或法律形式的其他保证或条件，包括关于适销性或符合特定用途的所有默示保证和条件。
本公司特别声明对本文档不承担任何义务，而且本文档也不能构成任何直接或间接的合同责任。
未经Oracle公司事先书面许可，严禁将此文档为了任何目的，以任何形式或手段(无论是电子的还是机械的)进行复制或传播。
Oracle是Oracle公司和/或其分公司的注册商标。
其他名字均可能是各相应公司的商标。
声明：
该资讯来自于互联网网友发布，如有侵犯您的权益请联系我们。
