智能基础结构：
oracle能够运用自身的一套智能的基础结构，在运行中随时对自身信息进行监控，调整。以达到最优的运行效果。自我管理的基础结构包括以下四个方面：
自动负载资料库（AWR）自动维护任务服务器告警顾问工具框架
自动负载资料库是oracle内置的一个资料库，oracle会按照固定的周期对oracle的运行信息和负载信息进行快照，并且将快照存储在AWR中，一共系统和用户使用其中的统计信息，来调整数据库的各个参数以达到最优效果。快照的默认周期是60分钟，用户可以自己改变这个频率，快照在AWR中存储的时间是7天，过了7天候将自动被清空。
自动维护任务是通过分析AWR中的数据信息，oracle决定是否执行常规的维护任务，如刷新优化器的统计信息（这个优化器就是必须用自动维护任务的一些基础结构才能刷新）oracle通过使用调度器在预定义的维护窗口内进行维护任务，这个维护窗口可以理解为一个抽象的窗口，就是在指定的时间内进行维护操作的一个平台，这个窗口有开始时间，结束时间，频率等属性。。。
在出现问题oracle自己解决不了的时候，服务器告警将会及时发出警告，这个告警不仅能及时通知用户，还能提出处理建议，帮助迅速解决问题。
Oracle 数据库中包含了多个针对不同数据库子系统的顾问工具（advisor），用于决定如何进一步优化各个子系统。举例来说，SQL 调优顾问工具（SQL Tuning Advisor）及 SQL 数据存取顾问工具（SQL Access Advisor）能够为更快地执行
SQL 语句提供建议。用户可以根据内存顾问工具（Memory advisor）的建议调整各个内存组件的容量，而不必反复尝试调整值是否正确（trial-and-error technique）。数据段顾问工具（Segment Advisor）用于解决和空间相关的问题，例如进行空间回收（wasted-space reclamation）及分析空间增长趋势。还原管理顾问工具（Undo Advisor）能够指导用户正确地设置还原表空间的容量。本章还将详细论述各种顾问工具。
性能诊断及故障处理：
oracle数据库的自动性能诊断监视器（automatic database diagnostic monitor）能够根据自动负载资料库（awr）每次捕获的信息及时作出处理，迅速生出性能诊断信息，确定系统中出现或者潜在的问题，ADDM一时间为性能统计标准，在分析了问题后，会给出处理问题的建议，花费的时间等评估信息。
ADDM 集中分析数据库中消耗时间最多的操作，并依照一个完善的问题分类树（problem classification tree）进行深入分析。ADDM 能够检测出的通用问题包括：
- CPU 瓶颈
- 连接管理（connection management）问题
- 过量的解析操作（excessive parsing）
- 锁竞争（lock contention）
- I/O 性能问题
- Oracle 内存结构过小；例如 PGA，数据库缓存，重做日志缓存等
- 执行 SQL 语句造成的负载过高
- 执行 PL/SQL 及 Java 程序时间过长
- 检查点（checkpoint）负载过高及原因；例如重做日志文件（log file）过小，或 MTTR 设置不适当
- 与 RAC 相关的问题
使用了 ADDM 后，用户不必手工收集大量诊断数据，并花费大量时间对数据进行分析，再设法找到解决系统性能问题的办法。用户只需轻点鼠标，参考 ADDM 的建议即可。
应用调优及sql调优：
Oracle 数据库中的 SQL 语句调优过程是完全自动化的。ADDM 能够识别出消耗系统资源异常高并导致系统性能问题的 SQL 语句。此外 AWR 也能自动地捕获系统中消耗 CPU 或共享内存较高的语句。因此在 Oracle 数据库中，对造成高负载的 SQL 语句的识别是完全自动的，无须用户干预。当识别出消耗资源较高的 SQL 后，Oracle 数据库能自动地使用自动调优优化器（Automatic
Tuning Optimizer）对其进行分析并给出建议的执行计划。而用户可以通过 SQL 调优顾问工具（SQL Tuning Advisor）来使用 Oracle 的自动 SQL 调优（Automatic SQL Tuning）功能。SQL 调优顾问工具接收一个或多个 SQL 语句作为输入，输出经过调优的 SQL 执行计划及调优建议。用户需要做的工作只是调用 SQL 调优顾问工具。 在 Oracle 中 SQL 语句的执行计划是由查询优化器（query
optimizer）给出的，而非其它使用预定义的探索方式（pre-defined heuristics）来优化 SQL 的外部工具。这种模式以下几个优势：a）调优工作是由最终负责生成执行计划（execution plan）及保证 SQL 执行性能的系统组件完成的，b）调优过程是完全基于成本的（cost-based），且修改了查询优化器的任何参数后都会直接影响调优结果，c）调优过程能够 参考 SQL 语句以往执行所产生的统计信息，并根据每个 SQL 语句的特性设置查询优化器，d）调优过程能够根据查询优化器的需要收集系统中其他有意义的统计信息。
自动调优优化器提出的调优建议可以被分为以下几类：
- 统计信息分析：自动调优优化器将检查查询中使用的每个对象，如发现没有统计信息或信息过于陈旧，优化器将建议重新收集相关的统计信息。如果优化器的建议没有被执行，她还能自动地收集信息以补充缺失的统计信息或修正陈旧的统计信息。由于 Oracle 数据库能够自动地收集优化器所需的统计信息，通常此类问题不会出现，除非自动收集统计信息的功能被用户禁止。
- SQL 档案（SQL Profiling）：自动调优优化器能够验证其调优结果，并收集额外信息修正调优结果中的错误。自动调优优化器还能依据 SQL 语句执行的历史情况，收集依据为一个 SQL 而定制的优化器设置信息（customized optimizer setting）（例如，首行（first rows）模式或所有行（all rows）模式）。自动调优优化器利用其收集的额外信息为
SQL 语句建立 SQL 档案。此时查询优化器（如运行在普通模式下）就可以使用 SQL 档案来生成执行计划了。用户使用 SQL 档案功能后，无需修改 SQL 语句也能对查询进行调优，这相当于将 SQL 语句的调优方案固化在数据库中，此功能有助于对预制的应用程序（packaged application）中的 SQL 语句进行调优。 - 数据存取路径（Access Path）分析：自动调优优化器能够预测新的索引是否能显著提高查询中某个表的存取效率，如有可能将建议用户创建索引。
- SQL 结构分析：自动调优优化器能够识别执行计划较差的 SQL 语句，并提出重构 SQL 语句的建议。自动调优优化器的建议既可能针对语法（syntactic），也可能针对语义（semantic）。
SQL 数据存取顾问工具（SQL Access Advisor）能够分析方案对象在某种工作负载下的数据访问情况，并在需要时向用户建议创建，保留，或移除索引，函数索引，物化视图等对象，以满足 此工作负载的需求。如果用户对一个单独语句进行调优，顾问工具在提出调优建议时只考虑对当前语句的影响。如果用户需要对整个系统的负载进行调优，顾问工具在提出调优建议时将考虑对整个系统的影响。SQL
数据存取顾问工具在生成调优建议时，除了考虑调优对查询性能的提高之外，还会考虑添加了新数据库对象（例如索引或物化视图）后对插入，更新及删除等数据操作活动的影响。如果 SQL 数据存取顾问工具已经挑选出了数个执行计划，但仍在寻找其他可行的方案，用户可以异步地终止这个过程，并使用当前发现的最好的方案。SQL 数据存取顾问工具拥有易用的用户接口，无需用户掌握大量的系统知识。SQL 数据存取顾问工具不会对生产系统产生很大的影响，因为用户可以将在生产系统中收集的数据迁移到其他安装了SQL
数据存取顾问工具的计算机上进行分析。
内存调优管理：
Oracle 提供了以下顾问工具来协助调整内存分配，以优化数据库性能。
共享池顾问工具（Shared Pool Advisor）通过跟踪库缓存（library cache）使用共享池的情况来决定最优的共享池容量。库缓存可用的内存容量决定了 Oracle 实例的解析（parse）效率。共享池顾问工具收集了关于库缓存的统计信息，供用户预测共享池的容量改变对共享池内对象保存时间的影响。
数据库缓存顾问工具（Buffer Cache Advisor）的作用是决定数据库缓存的最优容量。当用户配置一个新的实例时，一般难以确定数据库缓存的最佳容量。通常，用户需要首先设置一个预估的容量，然后通过观察实例在预期负载下的统计信息来决定之前预估的容量是否适当。用户观察数据库缓存活动的统计指标有多个。例如 V$DB_CACHE_ADVICE 视图及数据库缓存命中率（buffer
cache hit ratio）。
java 池顾问工具（Java Pool Advisor）能够记录 Java 程序使用库缓存的情况，并预测改变 Java 池容量对解析效率的影响
数据流池（Streams Pool Advisor）顾问工具能够决定数据流池的最佳容量。用户可以通过对 V$STREAMS_POOL_ADVICE 视图进行查询，了解 Oracle 预测的在各种STREAMS_POOL_SIZE 参数值下数据流池的使用情况。用户依据视图中的信息为数据流及逻辑备用数据库（logical
standby）设定 STREAMS_POOL_SIZE 参数。自动负载资料库（Automatic Workload Repository）能够提供基于数据流 CPU 使用情况和V$STREAMS_POOL_ADVICE 视图的报表，协助用户调整数据流性能。
程序全局区顾问工具（Program Global Area Advisor）能够对每个服务进程（server process）的内存分配进行调整。在自动 PGA 内存管理模式下，Oracle 能够动态地控制为各个 SQL 工作区（database area）所分配的 PGA 内存容量，使其总 PGA 容量满足PGA_AGGREGATE_TARGET 参数的限制。对于需要大量内存的
SQL 操作，Oracle 优先保证其工作区能够从 PGA 中分配足够的内存，从而保证这类操作的性能。Oracle 还将保证其余的工作区尽量工作在一次交换（one-pass）模式下。如果 PGA_AGGREGATE_TARGET 参数设置的过低，Oracle 将使某些工作区采取多次交换（multipass）的方式执行，从而减少 PGA 的消耗，确保 PGA 容量满足限制。当用户配置新实例时，很难确定恰当的 PGA_AGGREGATE_TARGET 参数值。用户可以通过以下步骤使此参数更为合理：
- 首先估计一个 PGA_AGGREGATE_TARGET 参数值。
- 使实例运行在预期的负载下，通过 Oracle 收集的 PGA 统计信息来监控系统性能，从而决定当前参数值是否适当。
- 根据 PGA 顾问工具的统计数据来调整 PGA_AGGREGATE_TARGET 参数的值。
空间管理：
自动撤销管理，之前版本的 Oracle 使用回滚段（rollback segment）来存储撤销信息（undo）。回滚段的空间管理十分复杂。而采用自动撤销管理（automatic undomanagement）将大大降低管理回滚段的复杂性，管理员只需专注于控制还原信息经过多长时间才能被覆盖即可。Oracle 强烈建议用户使用撤销表空间（undo tablespace）来管理撤销信息，而不要继续使用回滚段。
撤销管理顾问工具（Undo Advisor）能够提高事物的可管理性，尤其是系统采用了自动撤销管理时。撤销管理顾问工具能够根据可用的撤销表空间容量确定最佳的撤销信息保存周期（undo retention）。撤销管理顾问工具也能根据用户所需的撤销信息保存周期建议最佳的撤销表空间容量。
采用了自动文件管理（Oracle-managedfile）后，用户无需直接管理组成 Oracle 数据库的各个文件。Oracle 能够使用标准的文件系统接口自动地创建或删除文件。这使数据库文件创建删除之类的常规管理工作能够自动地执行。
可用空间管理：Oracle 既可以使用位图（bitmap）来管理表的可用空间（free space），也可以使用传统的数据字典方式进行管理。采用位图方式对表的可用空间进行管理能够消除大量的空间调整工作，同时还能提高表在高负载下的工作性能。Oracle 还能够自动地扩展数据文件（data file），即数据文件的容量能够根据其中所存储的数据量而自动地增长。因此数据库管理员无需手工地监控所有数据文件的空间使用情况。
主动空间管理：Oracle 数据库能够定期地进行检查，从而实现对空间使用情况的监控，这种检查不会中断正常的数据库操作。Oracle 在空间分配及回收操作期间对系统的空间使用情况进行监控，如果发现可用空间低于预设的阈值将向用户发出告警。空间监控是 Oracle 的内置功能，因此不会对系统性能产生影响，且各种类型的表空间均可使用。用户通过企业管理器（Enterprise Manager）或 SQL 语句均可使用系统的空间监控功能。由于监控是与数据库空间分配及释放同时进行的，用户可以随时得到及时准确的空间使用情况。
空间回收：
Oracle 数据库能够对数据段（segment）进行收缩（shrinking）从而优化空间利用率，且执行收缩操作时无需额外空间（in-place）来重组数据。收缩操作可以释放数据段中的未用空间以供其他数据段使用，且能提高查询及 DML 操作的性能。
执行数据段收缩（segment shrink）时，首先需要集中（compact）数据段内的数据，之后再释放段内的未用空间。从数据段中释放的空间将被返还给表空间，供表空间内的其他对象使用。如果表内的数据存储 的较为分散，将会影响全表扫描（full table scan）的性能。执行了收缩操作后，表内的数据将被集中，且数据段的高水位线（high water mark）将被降低。这将使全表扫描需要访问的数据块（block）更少，扫描更迅速。
数据段收缩属于联机操作，当表的数据段被收缩时，此表依然可以进行查询或 DML 操作。此外，数据段收缩无需额外的存储空间。本地收缩（in-place）与通过联机重定义（online tableredefinition）的方式收缩相比更有优势。用户可以在夜间定期调度作业来执行数据库对象的收缩操作，而无需为数据库提供额外的存储空间。
在采用了自动段空间管理（automatic segment space management）的表空间中，数据段收缩可以作用于堆表（heap-organized table），索引表（index-organized table，IOT），索引表的行溢出段（Row OverflowArea），LOB 对象，LOB 段，物化视图，及允许行移动（row movementenabled）的索引。如果对带有索引的表进行数据段收缩操作，当数据行发生移动时 Oracle 能够自动地维护索引。但用户自定义的触发器不会被触发，因为数据段收缩属于物理操作，对应用程序没有影响。
提示：
只有允许行移动的表才能够进行数据段收缩操作。如果应用程序中显示地使用了对象的 ROWID，那么这个对象就不能进行收缩，因为应用程序需要通过物理位置来定位对象内的数据行。
Oracle 数据库能够自动地运行数据段顾问工具（Segment Advisor）对数据库进行评估，确定哪些数据段应该进行收缩操作。数据段顾问工具能够针对每个数据库对象进行容量增长趋势分析，预测数据库对象在七天之后是否依然存在可用空间。之后就可以对满足条件的对象进行数据段收缩以回收空间。
提示：
数据段顾问工具不会评估还原表空间及临时表空间。
数据段顾问工具除了可以使用 AWR 中已有的统计信息，也可以直接对对象进行采样使统计信息更为准确。这种操作将消耗大量系统资源，但能提供更为精确的分析结果
。数据段收缩有助于减少行链接（row chaining），但 Oracle 建议采用对象联机重定义（online redefinition）来消除行链接。数据段顾问工具能够检测出某些超过阈值的行链接情况。例如，如果一个更新操作导致某行的容量超过了一个数据块的最大容量，数据段顾问工具将建议对数据段进行重组以提高 I/O 性能。
备份与恢复：
系统恢复管理器：Oracle 系统恢复管理器（Recovery Manager，RMAN）能够简化备份（backup）与系统恢复（recovery）操作，使之自动化，并提升其性能。RMAN 能够实现完全备份（one time backup configuration），能够根据用户定义的系统恢复窗口（recovery window）管理备份数据及归档日志（archived log），能够实现可重启的（restartable）备份（backup）与数据库恢复（restore），并可对系统恢复及数据库恢复进行测试。RMAN
根据系统恢复窗口来决定备份数据何时过期。在备份数据过期前，用户可以使用这些数据将数据库恢复到系统恢复窗口内的某一时间点时的状态，从而修复受逻辑错误影响的数据库对象。RMAN 还可以自动地令系统恢复窗口之外的备份数据过期。即使 RMAN 资料库（RMAN repository）不可用，用户还可以使用系统自动备份的控制文件数据进行数据库恢复或系统恢复。
DBCA 能够自动地调度磁盘备份程序（on disk backup procedure）。用户只需设定备份程序运行的时间窗口即可。用户可以使用初始化参数 DB_RECOVERY_FILE_DEST 设定一个统一的位置，存储和 Oracle 数据库恢复相关的文件，这个位置被称为快速恢复区（flash recovery area）。发生介质故障（media failure）时对数据库进行完全恢复所需的文件，例如控制文件（control
file），归档重做日志文件（archived log file），闪回日志（Flashback log），RMAN 备份数据等，都保存在快速恢复区。
为快速恢复区分配足够的空间，才能保证 Oracle 数据库恢复工作更迅速，更简单，且自动化。快速恢复功能（flash recovery）以智能化的方式管理着其所需的文件，从而使备份空间利用率最高，并能避免扩展备份空间时出现空间不足的问题。快速恢复功能可以根据用户设定的 RMAN 保留周期策略（RMAN
retention policy）自动地将快速恢复区中失效的备份文件及归档重做日志文件删除。
用户可以采用增量备份（incremental backup）方式，只对上次备份后修改过的数据块进行备份。当启用了数据块修改跟踪（block change tracking）功能后，Oracle 将记录所有经过修改的数据块的物理位置。RMAN 能够自动地使用修改记录文件，以确定进行增量备份时需要读取哪些数据块，并能够直接访问数据块来进行备份。这减少了周期性备份所需的时间，节约了网络备份时所需的网络带宽，并缩小了备份文件所占用的存储空间。
用户可以使用增量备份的结果更新旧的备份数据。Oracle 具有增量地更新备份数据的功能，用户可以将 RMAN 增量备份数据融入备份的数据文件中，从而得到经过增量更新的备份数据文件。此功能使用户免于重复地执行全库备份操作。用户只需对数据库进行一次全库备份，之后不断地用增量备份数对原备份进行更新即可。采用增量更新备份的策略有助于缩短数据库介质恢复的时间。
限时恢复
用户可以使用限时恢复（mean time to recover，MTTR）功能设定数据库实例错误（system failure）恢复所允许的最大时间（以秒为单位），从而更好地控制数据库停止服务的时间。限时恢复功能与动态初始化参数（dynamic initialization parameter）相结合，能够帮助用户提高数据库的可用性。当用户设定了最大的实例故障恢复时限后，Oracle
将自动且透明地确保系统在此时限内恢复正常，恢复所需时间与前台的应用程序无关。限时恢复功能可以使出现实例故障的系统以最快的速度恢复。
联机的重做日志文件（logfile）越小，DBRWs 进程执行增量检查点操作就越频繁，系统中的物理写入操作也越多。这将影响数据库的运行性能。如果用户设置了FAST_START_MTTR_TARGET 参数，那么较小的重做日志文件会导致增量检查点操作更频繁，甚至超出 MTTR
的需要。
重做日志文件容量顾问工具（Logfile Size Advisor）能够根据当前的FAST_START_MTTR_TARGET 参数设置及 MTTR 统计信息来确定重做日志文件的最优容量。如果重做日志文件的容量不会导致增量检查点操作的执行频率超出 MTTR 的需要，那么这个容量就是最优容量。
MTTR 顾问工具能够统计 MTTR 造成的额外的物理写入操作，从而协助用户评估不同 MTTR 设置对系统性能的影响。MTTR 顾问工具启用，且系统在正常负载下运行一段时间后，用户可以查询 V$MTTR_TARGET_ADVICE 视图，获得其他 MTTR 设置与当前 MTTR
设置下数据库缓存写入操作的比率。例如，比率值为 1.2 表示某一 MTTR 设置将比当前设置增加 20% 的数据库缓存写入操作。
通过查看不同 MTTR 设置及对应的数据库缓存写入操作比率，用户可以确定哪个设置能够同时满足数据库恢复及系统性能的需求。V$MTTR_TARGET_ADVICE 视图中还有不同 MTTR 设置下总物理写入操作的比率（包括直接写入（direct write）），及总体 I/O 操作的比率（包括读取操作）。
配置管理
企业管理器能够持续地监控其所管理的 Oracle 系统的配置情况，例如配置参数设置，安全设置，存储及空间使用情况，以及推荐功能的使用情况（recommended feature usage）。Oracle 能够自动地标识存在配置问题的系统，并给出详细的问题描述。例如，如果企业管理器发现某个数据库没有使用自动还原管理（automatic undo management）或本地管理的表空间（locally
managed tablespace）等新功能，她将会提醒用户及时启用。自动系统配置监控能够确保各个系统配置最优，减轻数据库管理员的工作负担，保证了数据库的可用性，安全性，即高性能。
负载管理
数据库资源管理器概述:数据库资源管理器（Database Resource Manager）能够安排 Oracle 系统内各项操作的优先级。例如，联机用户的优先级较高，因此能够及时获得系统资源从而缩短响应时间，而批处理作业或报表之类的用户优先级较低，因此可能适当等待。数据库资源管理器能够更精细地对 资源进行控制，且其中还提供了自动消费者组切换（automatic consumer
group switching），最大活动会话控制（maximum active sessions control），查询执行时间估计，及消费者组还原池容量限额（undo pool quotas for consumer group）等功能。
管理员可以为每个消费者组设定最大并发活动会话数量。当达到限制值后，数据库资源管理器能够将后续的所有请求加入队列，等待现有活动会话结束后再执行。
数据库资源管理器能够解决许多操作系统无法很好管理的资源分配问题：
- 过度的系统开销（overhead）。当系统内 Oracle 服务进程（server process）数量过多时，服务进程间的操作系统上下文切换（operating system context switching）将导致系统开销过度。
- 低效率的调度（Inefficient scheduling）。操作系统不会调度拥有闩锁（hold latch）Oracle 进程，这样效率较低。
- 不恰当的资源分配（inappropriate allocation of resource）。在操作系统中，对所有活动进程的资源分配是均等的，无法调整不同任务的优先级。
- 无法管理数据库特有的资源（database-specific resource）。
用户可以使用 Oracle 的数据库资源管理器完成以下工作：
- 无论系统的负载情况如何或用户数量多少，都能保证特定用户至少拥有一定的处理资源（processing resource）。
- 通过分配 CPU 时间的百分比（percentages of CPU time）将处理资源在不同用户及应用间分配。例如，在数据仓库系统中，应将更多的 CPU 时间分配给 ROLAP（关系型联机分析处理（relational on-line analytical processing））应用，而不是批处理作业（batch job）。
- 限制某用户组内各成员执行操作时的并行度（degree of parallelism）。
- 创建活动会话池（active session pool）。活动会话池中的会话个数 是由某用户组被允许的最大用户会话数决定的。超出最大会话数量限制的会话将入队等待执行，用户也可以设定一个超时值，超时的入队作业将被终止（terminate）。
- 根据管理员定义的条件，自动地将某个用户从一个用户组切换到另一组。例如，如果某一用户组成员所创建的会话的执行时间超过了设定值，此用户将被自动地切换到具备不同资源需求的用户组中。
- 阻止执行时间可能会超过预设限制的操作执行。
- 创建还原池（undo pool）。池内的还原空间（undo space）可供某一用户组的成员使用。
- 使一实例按照某种预定的策略分配资源。用户可以动态地切换资源分配策略 —— 例如从日间策略切换到夜间策略 —— 且无需关闭再重起实例。
- 找出导致数据库无法进入静默状态（quiesce）的会话。
数据库资源管理器能够平衡用户间的资源消耗，并根据任务的重要程度分配资源，从业务需求的角度实现系统资源的合理分配。
系统资源将依据数据库管理员定义的资源计划（resource plan）分配给用户。
- 资源计划（resource plan）指定了资源如何分配给不同的用户（或资源消费者组）。
- 管理员使用资源消费者组（resource consumer group）将资源需求类似的用户会话归类。资源消费者组与用户角色（user role）不同，同一数据库用户的不同会话可以属于不同的资源消费者组。
- 资源分配策略（resource allocation method）是分配特定资源时使用的策略。资源分配策略供资源计划及资源消费者组使用。
- 管理员使用资源计划指令（resource plan directive）为资源消费者组设定资源计划，或为资源分配策略设定参数从而在资源消费者组间分配资源。
服务概述
服务（service）表示一组具备相同属性，相同服务级阈值（service level threshold），及相同优先级的应用程序。一个应用系统的功能可以被划分为多组负载节点（workload），并以服务来进行标识。例如，在 Oracle E*Business 套件中可以按功能划分服务，例如总帐功能，应收帐款功能，订单功能等。Oracle Email Server 可以分别将 iMAP 进程，postman，垃圾收集，监视器等功能定义为服务。一个服务可以跨一个数据库的多个实例，还可以跨一个集群的多个数据库，而一个实例也能够支持多个服务。
支持某一服务的实例数量对应用系统来说是透明的。对于应用系统来说服务是一个进行管理的整体标识，通过服务用户可以将一组负载节点作为整体来管理。
中间层应用程序（middle tier application）及客户端程序通过设定 TNS 连接参数（connect data）中的服务名（service name）来选择一个服务。例如，用户可以为 Web 服务器或应用服务器设定一个服务作为其数据源。在 Net Easy*Connection 工具中，连接参数包括服务名及网络地址。例如，服务名：IP。
在数据库服务器端的应用，例如调度器（Scheduler），并行查询（parallel query），及 Oracle 数据流高级队列（Oracle Streams Advanced Queuing）均使用服务名来定义其负载节点属性。对于调度器来说，每个作业（job）都属于一个作业类（job class），而每个作业类都利用一个服务来运行。对于并行查询及并行
DML 操作来说，查询协调器（query coordinator）首先连接到一个服务，所有并行查询子进程将继承使用查询协调器所连接的服务。对于 Oracle 数据流高级队列来说，数据流队列需要通过服务来访问。运行于一个服务内的应用，将继承此服务的阈值及属性，也可以被看作是此服务的组成部分。
数据库资源管理器（Database Resource Manager）将服务分别与资源消费者组（resource consumer group）及优先级相绑定。这样，数据库的服务可以按照其重要程度的顺序进行管理。例如，管理员可以为优先级较高的联机用户应用和优先级较低的内部报表应用分别指定不同的服务。类似地，管理员还可以定义多个具有不同优先级的服务，依次接收来自同一应用的请求。
管理员在规划系统的服务时，应考虑各个服务间执行的优先级。这样数据库资源管理器能够首先保证优先级最高的服务，并依次类推。
通过服务进行工作负载管理
用户可以通过自动负载资料库（Automatic Workload Repository）对系统负载性能（performance of workload）进行多角度的分析。自动负载资料库能够自动地记录服务的响应时间及CPU 消耗矩阵，与性能统计及资源统计有关的等待事件，基于阈值的告警，以及各项性能指标。
在数据库服务端，服务（service）内的某个操作（operation）可以用服务（service），模块（module），及动作（action）这三种标签（tag）来标识。（模块及动作标签需要由应用程序来设定）通过对客户端的监控，就能够获得服务，模块，及动作级的汇总信息及跟踪信息，从而确定系统内高负载的操作。在 Oracle 企业管理器中可以设置用于服务质量控制的阈值（响应时间及
CPU 消耗），还能够对高负载服务进行监控，并可下钻（drill down）查看每个服务中高负载的模块及动作。
有时通过监控会话获取的信息对于性能管理没有意义，管理员应该使用自动负载资料库中的服务汇总信息（service aggregation）。例如，如果系统使用了连接池（connection pool）或事务处理监视器（transaction processing monitor，TP monitor），会话是被所有用户共享的，依据会话无法进行准确的统计。
用户可以使用服务，模块，及动作这三种标签为业务活动及处理流程划定边界。用户可以根据上述汇总级别对运行于同一级别的一组 SQL 语句进行整体调优（例如服务级，模块级，或动作级）。用户可以使用收集的服务汇总信息管理服务质量，评估资源消耗，调整服务间的优先级，并找出系统中需要进一步调优的位置。在 RAC 系统中，多个实例的处理能力可以作为一个服务供用户使用。
在一个服务的多个实例间进行负载平衡，可以采用连接时（connect time routing）或运行时（runtime routing）平衡算法。用于管理服务端连接负载（server-side connection load）的数据结构中还含了服务性能信息。连接可以依据服务当前的性能而分布到多个实例上。在进行负载均衡时加入服务性能作为判断依据，就能依据各节点的处理能力及当前负载合理分配
新负载，同时还能避免将负载分配给停机或故障的节点。
自动负载资料库中将持续记录服务性能信息。中间层服务器或 RAC 的事务处理监视器在进行运行时平衡时可以利用这些信息。例如，Oracle JDBC 连接池能够依据服务当前性能信息在运行时将服务请求分配到服务可用的实例上。
通过服务实现高可用性
RAC 通过服务（service）确保了数据库操作不会被异常事件所中断。服务与支撑 RAC 的 Oracle 集群组件高可用性框架（Clusterware high availability framework）是紧密相连的。当发生实例故障（failure）时，服务能够利用未受影响的节点继续工作。而受实例故障影响的节点能够被 Oracle 集群快速地恢复，且进行恢复工作的会话能够被自动地分布到系统的可用节点上。
当发生有计划停机（planned outage）时，RAC 提供了重定位（relocate），禁用，及启用服务的接口。重定位指将服务迁移到其他实例上，用户还可以选择是否在重定位时断开现有的会话连接。为了避免对硬件进行维护或修理时 Oracle 集群系统中出现不可预料的错误，在有计划停机开始前，准备进行维护的节点上的服务将被禁用。这些节点上的服务将在维护结束后被重新启用。
利用上述基于服务的功能，再结合基于服务的方案预编译功能（schema pre-compilation）（DBMS_SCHEMA_COPY），能够大大缩短有计划停机造成的服务中断时间。例如，在进行应用系统升级，操作系统升级，硬件升级或修理，轮换升级（rolling upgrade）各节点上的
Oracle 补丁，或修改初始化参数时，都可以将一个或多个节点隔离。
Oracle 通过 RAC 提供的无间断服务能力能够扩展到应用程序及中间层服务器。当服务的状态发生了改变（例如，启动，停止，或重启动），服务的新状态将以事件或调用（callout）的形式通知相关的系统组件。应用程序可以根据通知信息快速检测数据库故障，停止使用连接池中受故障影响的连接，并在故障组件修复后恢复使用。例如， 当某个实例开始提供服务后，应用程序将被事件或调用触发立即开始使用此服务。
当某实例上的服务停止时，正在使用此实例上服务的应用程序能够同过事件获知并及时停止操作。这使客户端不必等待 TCP 超时。Oracle JDBC 连接池及透明应用故障恢复（Transparent Application Failover，TAF）中都集成了服务状态事件。
在 Oracle Data Guard 环境中，生产节点（production site）为业务提供生产服务（production service）。而备用节点（standby site）则可以为只读的报表功能提供服务。RAC 与 Data Guard 代理（Data Guard Broker）是集成的，因此当进行故障恢复（failover），结点切换（switchover），或修改保护模式（protection mode change）时，生产服务将从原来的生产节点迁移到新建的生产节点上。在这个过程中，Data
Guard 负责管理整个迁移工作，并控制 Oracle 集群组件对各节点的服务进行管理。而当 Data Guard 的迁移工作完成后，Oracle 集群组件将恢复对高可用性管理的控制。
自动存储管理：
在现今的大型数据库系统中，要求有计划的停机时间尽可能地短，且 DBA 常常需要管理多个数据库，其中每个库所使用的数据文件都在不断增长。自动存储管理（Automatic Storage Management）能够完成某些手工存储管理任务，从而提高了 DBA 的工作效率。
自动存储管理垂直地集成了文件系统（file system）及专为 Oracle 数据文件定制的卷管理器（volume manager）。自动存储管理支持条带化（stripe）存储且能够对所有数据进行镜像（stripe and mirror everything，SAME），从而提高了系统性能，同时减少了手工 I/O 调整工作（即自动将数据文件分布到不同物理磁盘以避免出现热点（hotspot））。用户可以利用自动存储管理功能管理一个动态的数据库系统，当增加数据库容量时无需关闭数据库就能够调整存储分配。自动存储管理支持条带化及镜像，因此能利用低成本的模块化存储（modular
storage）实现更高的性能及更好的可靠性。
用户可以使用自动存储管理创建一个存储池，并令自动存储管理来管理数据库文件的命名及在存储池中的位置。用户可以使用以下 SQL 语句修改存储分配设置（添加或移除磁盘）：CREATE DISKGROUP，ALTER DISKGROUP，及 DROP
DISKGROUP。
用户也可以使用企业管理器（Enterprise Manager）来管理磁盘组（disk group）。Oracle 数据库在创建或删除数据文件时，能够自动地管理磁盘组中的存储空间。用户在设置磁盘组时，可以定义故障恢复组（failure group）实现冗余，防止磁盘组中某些组件（磁盘控制器（disk controller）或磁盘阵列（disk array））损坏造成数据丢失。自动存储管理使用故障恢复组来存储数据镜像，她能够智能地选择存储数据镜像的磁盘，防止单一设备故障造成的数据丢失。
Oracle 数据库为存储资源管理提供了一个简化的接口。使用自动存储管理后，用户不再需要手工调整 I/O 性能。自动存储管理使用一组磁盘组作为存储资源，同时支持冗余设置以实现高度的数据保护。自动存储管理无需中断数据库操作就能进行存储分配，还能自动地实现负载均衡。自动存储管理将数据文件分布在所有可用的存储设备上，从而优化系统性能及资源利用效率。自动存储管理能够使大量手工存储管理工作自动化，为数据库管理员节约时间提高效率，使管理员有能力管理更多或规模更大的数据库。不同版本的数据库及自动存储管理服务能够相互操作。具体来说，10.1.x.y
及 10.2.x.y 版本的数据库实例及自动存储管理实例的任意组合都能够透明地相互操作。
自动存储管理基本概念
本节定义了与自动存储管理（Automatic Storage Management）相关的一些基本概念。
磁盘组
磁盘组（disk group）是由一组自动存储管理磁盘（Automatic Storage Management disk）构成的逻辑管理单位。磁盘组的数据结构信息存储在磁盘组内部，因此将占用一些磁盘组空间。自动存储管理磁盘可以在数据库运行时添加到磁盘组或从磁盘组中移除。自动存储管理能够在磁盘组的磁盘间均衡的分布数据，以使各磁盘的 I/O 负载平衡，此功能在磁盘组配置发生变化时依然有效。
每个自动存储管理文件（Automatic Storage Management file）只能存在于一个磁盘组内。但一个磁盘组可以存储属于不同数据库的数据文件，一个数据库也能够使用多个磁盘组提供的存储资源。管理员可以为数据库指定一个或多个默认的磁盘组来存储其数据文件。
磁盘组可以在创建数据库的同时创建，也可以根据新应用的需要而创建。当数据库服务器的配置修改后，相应的磁盘组配置也可以被修改。
大部分数据库都会使用多个磁盘组。使用多个磁盘组的原因如下：
- 应将不同容量或不同性能的磁盘划分为不同的磁盘组
- 应根据外部冗余能力（external redundancy）来划分磁盘组；具备相同外部冗余能力的磁盘应划入同一磁盘组，而外部冗余能力不同的磁盘不应划为同一磁盘组。
- 将数据库区（database area）与快速恢复区（flash recovery area）放置在不同的磁盘组
磁盘组的类型
磁盘组有三种类型：正常冗余（normal redundancy），高冗余（high redundancy），及外部冗余（external redundancy）。对于正常冗余和高冗余的磁盘组来说，自动存储管理（Automatic Storage Management）将根据磁盘组模板（disk group template）中设定的属性为磁盘组内的每个数据文件提供冗余支持。与正常冗余相比，高冗余对数据的保护程度更高。对于外部冗余来说，自动存储管理不为磁盘组提供冗余支持。磁盘组内的磁盘应自己实现冗余（例如，使用磁盘阵列（storage
array）），否则当磁盘组内的磁盘出现故障时可能出现数据丢失（例如，测试系统可以采用这种配置）。
自动存储管理文件
当数据库需要存储空间时，自动存储管理（Automatic Storage Management）将创建文件。自动存储管理创建的文件的名称由前缀和数字后缀构成。用户可以为自动存储管理文件设定易于理解的别名。通过 V$ASM_ALIAS 数据字典视图可以查询自动存储管理文件的别名。只有在 ASM 实例中才能查询 V$ASM_ALIAS 视图。用户可以通过数据库实例中的某些V$ 视图（V$DATAFILE，V$LOGFILE，V$CONTROLFILE 等）查询出
ASM 文件名。但通常来说，用户没必要了解 ASM 文件名。
当创建 ASM 文件时，一些属性将被永久地赋予此文件。文件的属性包括其保护策略（protection policy）（即镜像）及条带化策略（striping policy）。自动存储管理文件对于操作系统及外部工具是不可见的，只有数据库实例，RMAN，及其他 Oracle 提供的工具可以访问
自动存储管理模板
自动存储管理模板（Automatic Storage Management template）即自动存储管理文件创建时使用的一组文件属性集合。模板将大量复杂的文件属性归纳为一个单一的名称，因而简化了文件创建工作。各种 Oracle 文件类型都有一个默认的模板。每个磁盘组（disk group）都能保存其自身使用的模板的定义。不同的磁盘组可以拥有属性不同的同名模板。
用户可以修改默认模板的属性，也可以创建自定义模板。即将特定的文件创建属性保存为模板。如果用户需要修改一个已有的自动存储管理文件（Automatic Storage Management file）的属性，只能通过 RMAN 将原有文件复制到具备新属性的文件中去。
自动存储管理磁盘
一个磁盘组（disk group）内最小的存储分配单位为自动存储管理磁盘（Automatic Storage Management disk，ASM disk）。一个 ASM 磁盘可以是一个物理磁盘，也可以是磁盘阵列（storage array）内的一个逻辑单元号（Logical Unit Number，LUN），或网络接入存储（Network Attached Storage，NAS）文件服务器（filer）中的一个文件。ASM
磁盘应相互独立，从而获得最佳的 I/O 性能。例如，使用磁盘阵列时，用户可以赋给一对互为镜像的物理磁盘一个逻辑单元号，做为一个 ASM 磁盘。如果用户在磁盘阵列中将一个物理磁盘条带化（striped）并赋予两个逻辑单元号，这有可能影响 I/O 性能。
当使用网络接入存储文件服务器时，作为 ASM 磁盘的文件容量必须是 1 MB 的整数倍。为获得最佳性能，属于同一磁盘组的网络接入存储文件应该各自独立地分布在不同的物理磁盘上。
用户指定的设备不应包含不能被覆盖（overwritten）的数据。例如，在某些操作系统中，某些磁盘分区（partition）的头部包含分区表（partition table）。这样的分区不应被指定为 ASM 磁盘。
自动存储管理在对 ASM 磁盘执行 I/O 操作时，总是通过唯一的逻辑路径（single logical path）。因此，如果用户在 ASM 中使用了多路径驱动器（multi-pathing driver），那么必须为 ASM 磁盘指定一个唯一的逻辑路径，从而保证 ASM 定位字符串（ASM discovery string）（即 ASM_DISKSTRING 初始化参数）中每个
ASM 磁盘对应唯一的逻辑路径
在集群（cluster）内，每个 ASM 磁盘必须对集群内的所有 ASM 实例均可见，但每个节点上保存的 ASM 磁盘路径不必完全相同，只要每个实例上的 ASM_DISKSTRING 初始化参数中包含此实例所用的 ASM 磁盘路径即可。
在集群（cluster）的所有节点上，ASM 磁盘的名称都是相同的。ASM 磁盘名称由管理员设定，或在磁盘被添加到磁盘组时由 ASM 自动生成。一个 ASM 磁盘除了磁盘名称之外，还需设定摘要信息，因为不同的主机可能使用不同的操作系统名称表示同一个磁盘。
自动存储管理提供了镜像功能，以便减少磁盘故障造成数据丢失的可能性。这十分必要，如果一个 ASM 磁盘的未镜像的数据丢失可能导致磁盘组内的多个文件损坏
故障恢复组
故障恢复组（failure group）是由管理员指定的一组磁盘构成的。故障恢复组中的自动存储管理磁盘（Automatic Storage Management disk）用于存储数据的冗余备份。使用了故障恢复组后，数据及数据的冗余备份将分别存储在不同磁盘上，从而避免了磁盘故障造成数据及冗余备份同时丢失。
故障恢复组的构成是与设备相关的。用户要根据系统中各组件的容错要求来设定故障恢复组。例如，系统中有五块磁盘及一个 SCSI 控制器（SCSI controller）。如果 SCSI 控制器发生故障将导致所有磁盘失效。在此种情况下，用户应将每个磁盘放入不同的故障恢复组。再例如，系统中有两个 SCSI 控制器，每个控制器上连接了两块磁盘，如果用户需要对 SCSI 控制器进行容错，就应使用每个 SCSI 控制器下的磁盘分别创建故障恢复组。
默认情况下，自动存储管理（Automatic Storage Management）使用一块磁盘构成一个故障恢复组。用户也可以在创建磁盘组（disk group）或向磁盘组中添加磁盘时设定一组磁盘作为故障恢复组。自动存储管理优化文件分布以降低设备故障造成数据丢失的可能性。
磁盘组的故障恢复组属性是保存在磁盘组内部的。一个磁盘组可以使用多个故障恢复组。当用户需要修改一个磁盘的故障恢复组时，需要先将磁盘从磁盘组中删除，之后将磁盘再次添加到原磁盘组中，并在添加时赋予新的故障恢复组属性。
自动存储管理实例
自动存储管理实例（Automatic Storage Management instance）是一种特殊的 Oracle 实例，其功能是管理磁盘组（disk group）内的磁盘。数据库实例必须通过为其配置的自动存储管理实例才能存取自动存储管理文件（Automatic Storage Management file）。如果创建数据库时使用了数据库配置助理（Database Configuration Assistant），此工具能够自动地配置数据库所需自动存储管理实例。
自动存储管理实例不能用于挂载数据库。自动存储管理实例只负责管理数据库实例的数据存储分布（data layout）。数据库实例能够直接对磁盘组中的磁盘进行 I/O 操作，而无须经过自动存储管理实例。
多个数据库实例可以共享同一个磁盘组。对于只含有一个节点（single node）的系统来说，通常只使用一个自动存储管理实例来管理此节点所需的所有磁盘组。而在 RAC 系统中，通常每个节点都拥有一个自动存储管理实例，她们相互协调共同管理 RAC 所使用的所有磁盘组。
所有和自动存储管理有关的命令都将被提交给自动存储管理实例，而非使用自动存储管理文件的数据库实例。
自动存储管理实例后台进程
使用自动存储管理文件（Automatic Storage Management file）的数据库实例中包含名为 ASMB 的后台进程，其功能是与自动存储管理实例（Automatic Storage Management instance）进行通信。此外还有名为 RBAL 的进程负责启用实例所使用的所有自动存储管理磁盘（Automatic Storage Management disk）。
使用自动存储管理的优势
- 自动存储管理（Automatic Storage Management）使数据库管理工作更为简单。
- 管理员无须设定及管理数据文件名称。管理员在创建数据文件时只需指定磁盘组即可。新创建的数据文件都能自动地获得一个唯一的名称。这避免了使用同一磁盘组的数据库使用相同的文件名。使用磁盘组命名（disk group naming）也避免了用不同名称为同一文件命名。
- 在很多情况下，自动存储管理能够代替外部卷管理器（external volume manager）及文件系统（file system）的功能。
- 自动存储管理包含了多种存储可靠性功能（storage reliability feature），例如镜像（mirroring）。存储可靠性策略（storage reliability policy）是针对每个文件的，而非针对整个磁盘组。因此，同一磁盘组内的不同文件可以采取不同的保护方式，例如镜像，奇偶检验（parity），或不采取保护措施。
- 自动存储管理能够提高系统性能。
- 自动存储管理能够将数据库文件分布在磁盘组内的所有磁盘中，从而提高系统性能。她拥有裸设备（raw disk）的 I/O 性能，但管理相对裸设备而言更为容易。
- 与逻辑卷管理器（logical volume manager）不同，自动存储管理的维护操作无须数据库停机即可执行。管理员可以动态地添加磁盘，或将使用中的磁盘移除。
- 自动存储管理减少了手工设置磁盘属性的工作。文件创建时的属性可以来自磁盘组中的预定义模板，因此提高了管理效率。
智能基础结构：
oracle能够运用自身的一套智能的基础结构，在运行中随时对自身信息进行监控，调整。以达到最优的运行效果。自我管理的基础结构包括以下四个方面：
自动负载资料库（AWR）自动维护任务服务器告警顾问工具框架
自动负载资料库是oracle内置的一个资料库，oracle会按照固定的周期对oracle的运行信息和负载信息进行快照，并且将快照存储在AWR中，一共系统和用户使用其中的统计信息，来调整数据库的各个参数以达到最优效果。快照的默认周期是60分钟，用户可以自己改变这个频率，快照在AWR中存储的时间是7天，过了7天候将自动被清空。
自动维护任务是通过分析AWR中的数据信息，oracle决定是否执行常规的维护任务，如刷新优化器的统计信息（这个优化器就是必须用自动维护任务的一些基础结构才能刷新）oracle通过使用调度器在预定义的维护窗口内进行维护任务，这个维护窗口可以理解为一个抽象的窗口，就是在指定的时间内进行维护操作的一个平台，这个窗口有开始时间，结束时间，频率等属性。。。
在出现问题oracle自己解决不了的时候，服务器告警将会及时发出警告，这个告警不仅能及时通知用户，还能提出处理建议，帮助迅速解决问题。
Oracle 数据库中包含了多个针对不同数据库子系统的顾问工具（advisor），用于决定如何进一步优化各个子系统。举例来说，SQL 调优顾问工具（SQL Tuning Advisor）及 SQL 数据存取顾问工具（SQL Access Advisor）能够为更快地执行
SQL 语句提供建议。用户可以根据内存顾问工具（Memory advisor）的建议调整各个内存组件的容量，而不必反复尝试调整值是否正确（trial-and-error technique）。数据段顾问工具（Segment Advisor）用于解决和空间相关的问题，例如进行空间回收（wasted-space reclamation）及分析空间增长趋势。还原管理顾问工具（Undo Advisor）能够指导用户正确地设置还原表空间的容量。本章还将详细论述各种顾问工具。
性能诊断及故障处理：
oracle数据库的自动性能诊断监视器（automatic database diagnostic monitor）能够根据自动负载资料库（awr）每次捕获的信息及时作出处理，迅速生出性能诊断信息，确定系统中出现或者潜在的问题，ADDM一时间为性能统计标准，在分析了问题后，会给出处理问题的建议，花费的时间等评估信息。
ADDM 集中分析数据库中消耗时间最多的操作，并依照一个完善的问题分类树（problem classification tree）进行深入分析。ADDM 能够检测出的通用问题包括：
- CPU 瓶颈
- 连接管理（connection management）问题
- 过量的解析操作（excessive parsing）
- 锁竞争（lock contention）
- I/O 性能问题
- Oracle 内存结构过小；例如 PGA，数据库缓存，重做日志缓存等
- 执行 SQL 语句造成的负载过高
- 执行 PL/SQL 及 Java 程序时间过长
- 检查点（checkpoint）负载过高及原因；例如重做日志文件（log file）过小，或 MTTR 设置不适当
- 与 RAC 相关的问题
使用了 ADDM 后，用户不必手工收集大量诊断数据，并花费大量时间对数据进行分析，再设法找到解决系统性能问题的办法。用户只需轻点鼠标，参考 ADDM 的建议即可。
应用调优及sql调优：
Oracle 数据库中的 SQL 语句调优过程是完全自动化的。ADDM 能够识别出消耗系统资源异常高并导致系统性能问题的 SQL 语句。此外 AWR 也能自动地捕获系统中消耗 CPU 或共享内存较高的语句。因此在 Oracle 数据库中，对造成高负载的 SQL 语句的识别是完全自动的，无须用户干预。当识别出消耗资源较高的 SQL 后，Oracle 数据库能自动地使用自动调优优化器（Automatic
Tuning Optimizer）对其进行分析并给出建议的执行计划。而用户可以通过 SQL 调优顾问工具（SQL Tuning Advisor）来使用 Oracle 的自动 SQL 调优（Automatic SQL Tuning）功能。SQL 调优顾问工具接收一个或多个 SQL 语句作为输入，输出经过调优的 SQL 执行计划及调优建议。用户需要做的工作只是调用 SQL 调优顾问工具。 在 Oracle 中 SQL 语句的执行计划是由查询优化器（query
optimizer）给出的，而非其它使用预定义的探索方式（pre-defined heuristics）来优化 SQL 的外部工具。这种模式以下几个优势：a）调优工作是由最终负责生成执行计划（execution plan）及保证 SQL 执行性能的系统组件完成的，b）调优过程是完全基于成本的（cost-based），且修改了查询优化器的任何参数后都会直接影响调优结果，c）调优过程能够 参考 SQL 语句以往执行所产生的统计信息，并根据每个 SQL 语句的特性设置查询优化器，d）调优过程能够根据查询优化器的需要收集系统中其他有意义的统计信息。
自动调优优化器提出的调优建议可以被分为以下几类：
- 统计信息分析：自动调优优化器将检查查询中使用的每个对象，如发现没有统计信息或信息过于陈旧，优化器将建议重新收集相关的统计信息。如果优化器的建议没有被执行，她还能自动地收集信息以补充缺失的统计信息或修正陈旧的统计信息。由于 Oracle 数据库能够自动地收集优化器所需的统计信息，通常此类问题不会出现，除非自动收集统计信息的功能被用户禁止。
- SQL 档案（SQL Profiling）：自动调优优化器能够验证其调优结果，并收集额外信息修正调优结果中的错误。自动调优优化器还能依据 SQL 语句执行的历史情况，收集依据为一个 SQL 而定制的优化器设置信息（customized optimizer setting）（例如，首行（first rows）模式或所有行（all rows）模式）。自动调优优化器利用其收集的额外信息为
SQL 语句建立 SQL 档案。此时查询优化器（如运行在普通模式下）就可以使用 SQL 档案来生成执行计划了。用户使用 SQL 档案功能后，无需修改 SQL 语句也能对查询进行调优，这相当于将 SQL 语句的调优方案固化在数据库中，此功能有助于对预制的应用程序（packaged application）中的 SQL 语句进行调优。 - 数据存取路径（Access Path）分析：自动调优优化器能够预测新的索引是否能显著提高查询中某个表的存取效率，如有可能将建议用户创建索引。
- SQL 结构分析：自动调优优化器能够识别执行计划较差的 SQL 语句，并提出重构 SQL 语句的建议。自动调优优化器的建议既可能针对语法（syntactic），也可能针对语义（semantic）。
SQL 数据存取顾问工具（SQL Access Advisor）能够分析方案对象在某种工作负载下的数据访问情况，并在需要时向用户建议创建，保留，或移除索引，函数索引，物化视图等对象，以满足 此工作负载的需求。如果用户对一个单独语句进行调优，顾问工具在提出调优建议时只考虑对当前语句的影响。如果用户需要对整个系统的负载进行调优，顾问工具在提出调优建议时将考虑对整个系统的影响。SQL
数据存取顾问工具在生成调优建议时，除了考虑调优对查询性能的提高之外，还会考虑添加了新数据库对象（例如索引或物化视图）后对插入，更新及删除等数据操作活动的影响。如果 SQL 数据存取顾问工具已经挑选出了数个执行计划，但仍在寻找其他可行的方案，用户可以异步地终止这个过程，并使用当前发现的最好的方案。SQL 数据存取顾问工具拥有易用的用户接口，无需用户掌握大量的系统知识。SQL 数据存取顾问工具不会对生产系统产生很大的影响，因为用户可以将在生产系统中收集的数据迁移到其他安装了SQL
数据存取顾问工具的计算机上进行分析。
内存调优管理：
Oracle 提供了以下顾问工具来协助调整内存分配，以优化数据库性能。
共享池顾问工具（Shared Pool Advisor）通过跟踪库缓存（library cache）使用共享池的情况来决定最优的共享池容量。库缓存可用的内存容量决定了 Oracle 实例的解析（parse）效率。共享池顾问工具收集了关于库缓存的统计信息，供用户预测共享池的容量改变对共享池内对象保存时间的影响。
数据库缓存顾问工具（Buffer Cache Advisor）的作用是决定数据库缓存的最优容量。当用户配置一个新的实例时，一般难以确定数据库缓存的最佳容量。通常，用户需要首先设置一个预估的容量，然后通过观察实例在预期负载下的统计信息来决定之前预估的容量是否适当。用户观察数据库缓存活动的统计指标有多个。例如 V$DB_CACHE_ADVICE 视图及数据库缓存命中率（buffer
cache hit ratio）。
java 池顾问工具（Java Pool Advisor）能够记录 Java 程序使用库缓存的情况，并预测改变 Java 池容量对解析效率的影响
数据流池（Streams Pool Advisor）顾问工具能够决定数据流池的最佳容量。用户可以通过对 V$STREAMS_POOL_ADVICE 视图进行查询，了解 Oracle 预测的在各种STREAMS_POOL_SIZE 参数值下数据流池的使用情况。用户依据视图中的信息为数据流及逻辑备用数据库（logical
standby）设定 STREAMS_POOL_SIZE 参数。自动负载资料库（Automatic Workload Repository）能够提供基于数据流 CPU 使用情况和V$STREAMS_POOL_ADVICE 视图的报表，协助用户调整数据流性能。
程序全局区顾问工具（Program Global Area Advisor）能够对每个服务进程（server process）的内存分配进行调整。在自动 PGA 内存管理模式下，Oracle 能够动态地控制为各个 SQL 工作区（database area）所分配的 PGA 内存容量，使其总 PGA 容量满足PGA_AGGREGATE_TARGET 参数的限制。对于需要大量内存的
SQL 操作，Oracle 优先保证其工作区能够从 PGA 中分配足够的内存，从而保证这类操作的性能。Oracle 还将保证其余的工作区尽量工作在一次交换（one-pass）模式下。如果 PGA_AGGREGATE_TARGET 参数设置的过低，Oracle 将使某些工作区采取多次交换（multipass）的方式执行，从而减少 PGA 的消耗，确保 PGA 容量满足限制。当用户配置新实例时，很难确定恰当的 PGA_AGGREGATE_TARGET 参数值。用户可以通过以下步骤使此参数更为合理：
- 首先估计一个 PGA_AGGREGATE_TARGET 参数值。
- 使实例运行在预期的负载下，通过 Oracle 收集的 PGA 统计信息来监控系统性能，从而决定当前参数值是否适当。
- 根据 PGA 顾问工具的统计数据来调整 PGA_AGGREGATE_TARGET 参数的值。
空间管理：
自动撤销管理，之前版本的 Oracle 使用回滚段（rollback segment）来存储撤销信息（undo）。回滚段的空间管理十分复杂。而采用自动撤销管理（automatic undomanagement）将大大降低管理回滚段的复杂性，管理员只需专注于控制还原信息经过多长时间才能被覆盖即可。Oracle 强烈建议用户使用撤销表空间（undo tablespace）来管理撤销信息，而不要继续使用回滚段。
撤销管理顾问工具（Undo Advisor）能够提高事物的可管理性，尤其是系统采用了自动撤销管理时。撤销管理顾问工具能够根据可用的撤销表空间容量确定最佳的撤销信息保存周期（undo retention）。撤销管理顾问工具也能根据用户所需的撤销信息保存周期建议最佳的撤销表空间容量。
采用了自动文件管理（Oracle-managedfile）后，用户无需直接管理组成 Oracle 数据库的各个文件。Oracle 能够使用标准的文件系统接口自动地创建或删除文件。这使数据库文件创建删除之类的常规管理工作能够自动地执行。
可用空间管理：Oracle 既可以使用位图（bitmap）来管理表的可用空间（free space），也可以使用传统的数据字典方式进行管理。采用位图方式对表的可用空间进行管理能够消除大量的空间调整工作，同时还能提高表在高负载下的工作性能。Oracle 还能够自动地扩展数据文件（data file），即数据文件的容量能够根据其中所存储的数据量而自动地增长。因此数据库管理员无需手工地监控所有数据文件的空间使用情况。
主动空间管理：Oracle 数据库能够定期地进行检查，从而实现对空间使用情况的监控，这种检查不会中断正常的数据库操作。Oracle 在空间分配及回收操作期间对系统的空间使用情况进行监控，如果发现可用空间低于预设的阈值将向用户发出告警。空间监控是 Oracle 的内置功能，因此不会对系统性能产生影响，且各种类型的表空间均可使用。用户通过企业管理器（Enterprise Manager）或 SQL 语句均可使用系统的空间监控功能。由于监控是与数据库空间分配及释放同时进行的，用户可以随时得到及时准确的空间使用情况。
空间回收：
Oracle 数据库能够对数据段（segment）进行收缩（shrinking）从而优化空间利用率，且执行收缩操作时无需额外空间（in-place）来重组数据。收缩操作可以释放数据段中的未用空间以供其他数据段使用，且能提高查询及 DML 操作的性能。
执行数据段收缩（segment shrink）时，首先需要集中（compact）数据段内的数据，之后再释放段内的未用空间。从数据段中释放的空间将被返还给表空间，供表空间内的其他对象使用。如果表内的数据存储 的较为分散，将会影响全表扫描（full table scan）的性能。执行了收缩操作后，表内的数据将被集中，且数据段的高水位线（high water mark）将被降低。这将使全表扫描需要访问的数据块（block）更少，扫描更迅速。
数据段收缩属于联机操作，当表的数据段被收缩时，此表依然可以进行查询或 DML 操作。此外，数据段收缩无需额外的存储空间。本地收缩（in-place）与通过联机重定义（online tableredefinition）的方式收缩相比更有优势。用户可以在夜间定期调度作业来执行数据库对象的收缩操作，而无需为数据库提供额外的存储空间。
在采用了自动段空间管理（automatic segment space management）的表空间中，数据段收缩可以作用于堆表（heap-organized table），索引表（index-organized table，IOT），索引表的行溢出段（Row OverflowArea），LOB 对象，LOB 段，物化视图，及允许行移动（row movementenabled）的索引。如果对带有索引的表进行数据段收缩操作，当数据行发生移动时 Oracle 能够自动地维护索引。但用户自定义的触发器不会被触发，因为数据段收缩属于物理操作，对应用程序没有影响。
提示：
只有允许行移动的表才能够进行数据段收缩操作。如果应用程序中显示地使用了对象的 ROWID，那么这个对象就不能进行收缩，因为应用程序需要通过物理位置来定位对象内的数据行。
Oracle 数据库能够自动地运行数据段顾问工具（Segment Advisor）对数据库进行评估，确定哪些数据段应该进行收缩操作。数据段顾问工具能够针对每个数据库对象进行容量增长趋势分析，预测数据库对象在七天之后是否依然存在可用空间。之后就可以对满足条件的对象进行数据段收缩以回收空间。
提示：
数据段顾问工具不会评估还原表空间及临时表空间。
数据段顾问工具除了可以使用 AWR 中已有的统计信息，也可以直接对对象进行采样使统计信息更为准确。这种操作将消耗大量系统资源，但能提供更为精确的分析结果
。数据段收缩有助于减少行链接（row chaining），但 Oracle 建议采用对象联机重定义（online redefinition）来消除行链接。数据段顾问工具能够检测出某些超过阈值的行链接情况。例如，如果一个更新操作导致某行的容量超过了一个数据块的最大容量，数据段顾问工具将建议对数据段进行重组以提高 I/O 性能。
备份与恢复：
系统恢复管理器：Oracle 系统恢复管理器（Recovery Manager，RMAN）能够简化备份（backup）与系统恢复（recovery）操作，使之自动化，并提升其性能。RMAN 能够实现完全备份（one time backup configuration），能够根据用户定义的系统恢复窗口（recovery window）管理备份数据及归档日志（archived log），能够实现可重启的（restartable）备份（backup）与数据库恢复（restore），并可对系统恢复及数据库恢复进行测试。RMAN
根据系统恢复窗口来决定备份数据何时过期。在备份数据过期前，用户可以使用这些数据将数据库恢复到系统恢复窗口内的某一时间点时的状态，从而修复受逻辑错误影响的数据库对象。RMAN 还可以自动地令系统恢复窗口之外的备份数据过期。即使 RMAN 资料库（RMAN repository）不可用，用户还可以使用系统自动备份的控制文件数据进行数据库恢复或系统恢复。
DBCA 能够自动地调度磁盘备份程序（on disk backup procedure）。用户只需设定备份程序运行的时间窗口即可。用户可以使用初始化参数 DB_RECOVERY_FILE_DEST 设定一个统一的位置，存储和 Oracle 数据库恢复相关的文件，这个位置被称为快速恢复区（flash recovery area）。发生介质故障（media failure）时对数据库进行完全恢复所需的文件，例如控制文件（control
file），归档重做日志文件（archived log file），闪回日志（Flashback log），RMAN 备份数据等，都保存在快速恢复区。
为快速恢复区分配足够的空间，才能保证 Oracle 数据库恢复工作更迅速，更简单，且自动化。快速恢复功能（flash recovery）以智能化的方式管理着其所需的文件，从而使备份空间利用率最高，并能避免扩展备份空间时出现空间不足的问题。快速恢复功能可以根据用户设定的 RMAN 保留周期策略（RMAN
retention policy）自动地将快速恢复区中失效的备份文件及归档重做日志文件删除。
用户可以采用增量备份（incremental backup）方式，只对上次备份后修改过的数据块进行备份。当启用了数据块修改跟踪（block change tracking）功能后，Oracle 将记录所有经过修改的数据块的物理位置。RMAN 能够自动地使用修改记录文件，以确定进行增量备份时需要读取哪些数据块，并能够直接访问数据块来进行备份。这减少了周期性备份所需的时间，节约了网络备份时所需的网络带宽，并缩小了备份文件所占用的存储空间。
用户可以使用增量备份的结果更新旧的备份数据。Oracle 具有增量地更新备份数据的功能，用户可以将 RMAN 增量备份数据融入备份的数据文件中，从而得到经过增量更新的备份数据文件。此功能使用户免于重复地执行全库备份操作。用户只需对数据库进行一次全库备份，之后不断地用增量备份数对原备份进行更新即可。采用增量更新备份的策略有助于缩短数据库介质恢复的时间。
限时恢复
用户可以使用限时恢复（mean time to recover，MTTR）功能设定数据库实例错误（system failure）恢复所允许的最大时间（以秒为单位），从而更好地控制数据库停止服务的时间。限时恢复功能与动态初始化参数（dynamic initialization parameter）相结合，能够帮助用户提高数据库的可用性。当用户设定了最大的实例故障恢复时限后，Oracle
将自动且透明地确保系统在此时限内恢复正常，恢复所需时间与前台的应用程序无关。限时恢复功能可以使出现实例故障的系统以最快的速度恢复。
联机的重做日志文件（logfile）越小，DBRWs 进程执行增量检查点操作就越频繁，系统中的物理写入操作也越多。这将影响数据库的运行性能。如果用户设置了FAST_START_MTTR_TARGET 参数，那么较小的重做日志文件会导致增量检查点操作更频繁，甚至超出 MTTR
的需要。
重做日志文件容量顾问工具（Logfile Size Advisor）能够根据当前的FAST_START_MTTR_TARGET 参数设置及 MTTR 统计信息来确定重做日志文件的最优容量。如果重做日志文件的容量不会导致增量检查点操作的执行频率超出 MTTR 的需要，那么这个容量就是最优容量。
MTTR 顾问工具能够统计 MTTR 造成的额外的物理写入操作，从而协助用户评估不同 MTTR 设置对系统性能的影响。MTTR 顾问工具启用，且系统在正常负载下运行一段时间后，用户可以查询 V$MTTR_TARGET_ADVICE 视图，获得其他 MTTR 设置与当前 MTTR
设置下数据库缓存写入操作的比率。例如，比率值为 1.2 表示某一 MTTR 设置将比当前设置增加 20% 的数据库缓存写入操作。
通过查看不同 MTTR 设置及对应的数据库缓存写入操作比率，用户可以确定哪个设置能够同时满足数据库恢复及系统性能的需求。V$MTTR_TARGET_ADVICE 视图中还有不同 MTTR 设置下总物理写入操作的比率（包括直接写入（direct write）），及总体 I/O 操作的比率（包括读取操作）。
配置管理
企业管理器能够持续地监控其所管理的 Oracle 系统的配置情况，例如配置参数设置，安全设置，存储及空间使用情况，以及推荐功能的使用情况（recommended feature usage）。Oracle 能够自动地标识存在配置问题的系统，并给出详细的问题描述。例如，如果企业管理器发现某个数据库没有使用自动还原管理（automatic undo management）或本地管理的表空间（locally
managed tablespace）等新功能，她将会提醒用户及时启用。自动系统配置监控能够确保各个系统配置最优，减轻数据库管理员的工作负担，保证了数据库的可用性，安全性，即高性能。
负载管理
数据库资源管理器概述:数据库资源管理器（Database Resource Manager）能够安排 Oracle 系统内各项操作的优先级。例如，联机用户的优先级较高，因此能够及时获得系统资源从而缩短响应时间，而批处理作业或报表之类的用户优先级较低，因此可能适当等待。数据库资源管理器能够更精细地对 资源进行控制，且其中还提供了自动消费者组切换（automatic consumer
group switching），最大活动会话控制（maximum active sessions control），查询执行时间估计，及消费者组还原池容量限额（undo pool quotas for consumer group）等功能。
管理员可以为每个消费者组设定最大并发活动会话数量。当达到限制值后，数据库资源管理器能够将后续的所有请求加入队列，等待现有活动会话结束后再执行。
数据库资源管理器能够解决许多操作系统无法很好管理的资源分配问题：
- 过度的系统开销（overhead）。当系统内 Oracle 服务进程（server process）数量过多时，服务进程间的操作系统上下文切换（operating system context switching）将导致系统开销过度。
- 低效率的调度（Inefficient scheduling）。操作系统不会调度拥有闩锁（hold latch）Oracle 进程，这样效率较低。
- 不恰当的资源分配（inappropriate allocation of resource）。在操作系统中，对所有活动进程的资源分配是均等的，无法调整不同任务的优先级。
- 无法管理数据库特有的资源（database-specific resource）。
用户可以使用 Oracle 的数据库资源管理器完成以下工作：
- 无论系统的负载情况如何或用户数量多少，都能保证特定用户至少拥有一定的处理资源（processing resource）。
- 通过分配 CPU 时间的百分比（percentages of CPU time）将处理资源在不同用户及应用间分配。例如，在数据仓库系统中，应将更多的 CPU 时间分配给 ROLAP（关系型联机分析处理（relational on-line analytical processing））应用，而不是批处理作业（batch job）。
- 限制某用户组内各成员执行操作时的并行度（degree of parallelism）。
- 创建活动会话池（active session pool）。活动会话池中的会话个数 是由某用户组被允许的最大用户会话数决定的。超出最大会话数量限制的会话将入队等待执行，用户也可以设定一个超时值，超时的入队作业将被终止（terminate）。
- 根据管理员定义的条件，自动地将某个用户从一个用户组切换到另一组。例如，如果某一用户组成员所创建的会话的执行时间超过了设定值，此用户将被自动地切换到具备不同资源需求的用户组中。
- 阻止执行时间可能会超过预设限制的操作执行。
- 创建还原池（undo pool）。池内的还原空间（undo space）可供某一用户组的成员使用。
- 使一实例按照某种预定的策略分配资源。用户可以动态地切换资源分配策略 —— 例如从日间策略切换到夜间策略 —— 且无需关闭再重起实例。
- 找出导致数据库无法进入静默状态（quiesce）的会话。
数据库资源管理器能够平衡用户间的资源消耗，并根据任务的重要程度分配资源，从业务需求的角度实现系统资源的合理分配。
系统资源将依据数据库管理员定义的资源计划（resource plan）分配给用户。
- 资源计划（resource plan）指定了资源如何分配给不同的用户（或资源消费者组）。
- 管理员使用资源消费者组（resource consumer group）将资源需求类似的用户会话归类。资源消费者组与用户角色（user role）不同，同一数据库用户的不同会话可以属于不同的资源消费者组。
- 资源分配策略（resource allocation method）是分配特定资源时使用的策略。资源分配策略供资源计划及资源消费者组使用。
- 管理员使用资源计划指令（resource plan directive）为资源消费者组设定资源计划，或为资源分配策略设定参数从而在资源消费者组间分配资源。
服务概述
服务（service）表示一组具备相同属性，相同服务级阈值（service level threshold），及相同优先级的应用程序。一个应用系统的功能可以被划分为多组负载节点（workload），并以服务来进行标识。例如，在 Oracle E*Business 套件中可以按功能划分服务，例如总帐功能，应收帐款功能，订单功能等。Oracle Email Server 可以分别将 iMAP 进程，postman，垃圾收集，监视器等功能定义为服务。一个服务可以跨一个数据库的多个实例，还可以跨一个集群的多个数据库，而一个实例也能够支持多个服务。
支持某一服务的实例数量对应用系统来说是透明的。对于应用系统来说服务是一个进行管理的整体标识，通过服务用户可以将一组负载节点作为整体来管理。
中间层应用程序（middle tier application）及客户端程序通过设定 TNS 连接参数（connect data）中的服务名（service name）来选择一个服务。例如，用户可以为 Web 服务器或应用服务器设定一个服务作为其数据源。在 Net Easy*Connection 工具中，连接参数包括服务名及网络地址。例如，服务名：IP。
在数据库服务器端的应用，例如调度器（Scheduler），并行查询（parallel query），及 Oracle 数据流高级队列（Oracle Streams Advanced Queuing）均使用服务名来定义其负载节点属性。对于调度器来说，每个作业（job）都属于一个作业类（job class），而每个作业类都利用一个服务来运行。对于并行查询及并行
DML 操作来说，查询协调器（query coordinator）首先连接到一个服务，所有并行查询子进程将继承使用查询协调器所连接的服务。对于 Oracle 数据流高级队列来说，数据流队列需要通过服务来访问。运行于一个服务内的应用，将继承此服务的阈值及属性，也可以被看作是此服务的组成部分。
数据库资源管理器（Database Resource Manager）将服务分别与资源消费者组（resource consumer group）及优先级相绑定。这样，数据库的服务可以按照其重要程度的顺序进行管理。例如，管理员可以为优先级较高的联机用户应用和优先级较低的内部报表应用分别指定不同的服务。类似地，管理员还可以定义多个具有不同优先级的服务，依次接收来自同一应用的请求。
管理员在规划系统的服务时，应考虑各个服务间执行的优先级。这样数据库资源管理器能够首先保证优先级最高的服务，并依次类推。
通过服务进行工作负载管理
用户可以通过自动负载资料库（Automatic Workload Repository）对系统负载性能（performance of workload）进行多角度的分析。自动负载资料库能够自动地记录服务的响应时间及CPU 消耗矩阵，与性能统计及资源统计有关的等待事件，基于阈值的告警，以及各项性能指标。
在数据库服务端，服务（service）内的某个操作（operation）可以用服务（service），模块（module），及动作（action）这三种标签（tag）来标识。（模块及动作标签需要由应用程序来设定）通过对客户端的监控，就能够获得服务，模块，及动作级的汇总信息及跟踪信息，从而确定系统内高负载的操作。在 Oracle 企业管理器中可以设置用于服务质量控制的阈值（响应时间及
CPU 消耗），还能够对高负载服务进行监控，并可下钻（drill down）查看每个服务中高负载的模块及动作。
有时通过监控会话获取的信息对于性能管理没有意义，管理员应该使用自动负载资料库中的服务汇总信息（service aggregation）。例如，如果系统使用了连接池（connection pool）或事务处理监视器（transaction processing monitor，TP monitor），会话是被所有用户共享的，依据会话无法进行准确的统计。
用户可以使用服务，模块，及动作这三种标签为业务活动及处理流程划定边界。用户可以根据上述汇总级别对运行于同一级别的一组 SQL 语句进行整体调优（例如服务级，模块级，或动作级）。用户可以使用收集的服务汇总信息管理服务质量，评估资源消耗，调整服务间的优先级，并找出系统中需要进一步调优的位置。在 RAC 系统中，多个实例的处理能力可以作为一个服务供用户使用。
在一个服务的多个实例间进行负载平衡，可以采用连接时（connect time routing）或运行时（runtime routing）平衡算法。用于管理服务端连接负载（server-side connection load）的数据结构中还含了服务性能信息。连接可以依据服务当前的性能而分布到多个实例上。在进行负载均衡时加入服务性能作为判断依据，就能依据各节点的处理能力及当前负载合理分配
新负载，同时还能避免将负载分配给停机或故障的节点。
自动负载资料库中将持续记录服务性能信息。中间层服务器或 RAC 的事务处理监视器在进行运行时平衡时可以利用这些信息。例如，Oracle JDBC 连接池能够依据服务当前性能信息在运行时将服务请求分配到服务可用的实例上。
通过服务实现高可用性
RAC 通过服务（service）确保了数据库操作不会被异常事件所中断。服务与支撑 RAC 的 Oracle 集群组件高可用性框架（Clusterware high availability framework）是紧密相连的。当发生实例故障（failure）时，服务能够利用未受影响的节点继续工作。而受实例故障影响的节点能够被 Oracle 集群快速地恢复，且进行恢复工作的会话能够被自动地分布到系统的可用节点上。
当发生有计划停机（planned outage）时，RAC 提供了重定位（relocate），禁用，及启用服务的接口。重定位指将服务迁移到其他实例上，用户还可以选择是否在重定位时断开现有的会话连接。为了避免对硬件进行维护或修理时 Oracle 集群系统中出现不可预料的错误，在有计划停机开始前，准备进行维护的节点上的服务将被禁用。这些节点上的服务将在维护结束后被重新启用。
利用上述基于服务的功能，再结合基于服务的方案预编译功能（schema pre-compilation）（DBMS_SCHEMA_COPY），能够大大缩短有计划停机造成的服务中断时间。例如，在进行应用系统升级，操作系统升级，硬件升级或修理，轮换升级（rolling upgrade）各节点上的
Oracle 补丁，或修改初始化参数时，都可以将一个或多个节点隔离。
Oracle 通过 RAC 提供的无间断服务能力能够扩展到应用程序及中间层服务器。当服务的状态发生了改变（例如，启动，停止，或重启动），服务的新状态将以事件或调用（callout）的形式通知相关的系统组件。应用程序可以根据通知信息快速检测数据库故障，停止使用连接池中受故障影响的连接，并在故障组件修复后恢复使用。例如， 当某个实例开始提供服务后，应用程序将被事件或调用触发立即开始使用此服务。
当某实例上的服务停止时，正在使用此实例上服务的应用程序能够同过事件获知并及时停止操作。这使客户端不必等待 TCP 超时。Oracle JDBC 连接池及透明应用故障恢复（Transparent Application Failover，TAF）中都集成了服务状态事件。
在 Oracle Data Guard 环境中，生产节点（production site）为业务提供生产服务（production service）。而备用节点（standby site）则可以为只读的报表功能提供服务。RAC 与 Data Guard 代理（Data Guard Broker）是集成的，因此当进行故障恢复（failover），结点切换（switchover），或修改保护模式（protection mode change）时，生产服务将从原来的生产节点迁移到新建的生产节点上。在这个过程中，Data
Guard 负责管理整个迁移工作，并控制 Oracle 集群组件对各节点的服务进行管理。而当 Data Guard 的迁移工作完成后，Oracle 集群组件将恢复对高可用性管理的控制。
自动存储管理：
在现今的大型数据库系统中，要求有计划的停机时间尽可能地短，且 DBA 常常需要管理多个数据库，其中每个库所使用的数据文件都在不断增长。自动存储管理（Automatic Storage Management）能够完成某些手工存储管理任务，从而提高了 DBA 的工作效率。
自动存储管理垂直地集成了文件系统（file system）及专为 Oracle 数据文件定制的卷管理器（volume manager）。自动存储管理支持条带化（stripe）存储且能够对所有数据进行镜像（stripe and mirror everything，SAME），从而提高了系统性能，同时减少了手工 I/O 调整工作（即自动将数据文件分布到不同物理磁盘以避免出现热点（hotspot））。用户可以利用自动存储管理功能管理一个动态的数据库系统，当增加数据库容量时无需关闭数据库就能够调整存储分配。自动存储管理支持条带化及镜像，因此能利用低成本的模块化存储（modular
storage）实现更高的性能及更好的可靠性。
用户可以使用自动存储管理创建一个存储池，并令自动存储管理来管理数据库文件的命名及在存储池中的位置。用户可以使用以下 SQL 语句修改存储分配设置（添加或移除磁盘）：CREATE DISKGROUP，ALTER DISKGROUP，及 DROP
DISKGROUP。
用户也可以使用企业管理器（Enterprise Manager）来管理磁盘组（disk group）。Oracle 数据库在创建或删除数据文件时，能够自动地管理磁盘组中的存储空间。用户在设置磁盘组时，可以定义故障恢复组（failure group）实现冗余，防止磁盘组中某些组件（磁盘控制器（disk controller）或磁盘阵列（disk array））损坏造成数据丢失。自动存储管理使用故障恢复组来存储数据镜像，她能够智能地选择存储数据镜像的磁盘，防止单一设备故障造成的数据丢失。
Oracle 数据库为存储资源管理提供了一个简化的接口。使用自动存储管理后，用户不再需要手工调整 I/O 性能。自动存储管理使用一组磁盘组作为存储资源，同时支持冗余设置以实现高度的数据保护。自动存储管理无需中断数据库操作就能进行存储分配，还能自动地实现负载均衡。自动存储管理将数据文件分布在所有可用的存储设备上，从而优化系统性能及资源利用效率。自动存储管理能够使大量手工存储管理工作自动化，为数据库管理员节约时间提高效率，使管理员有能力管理更多或规模更大的数据库。不同版本的数据库及自动存储管理服务能够相互操作。具体来说，10.1.x.y
及 10.2.x.y 版本的数据库实例及自动存储管理实例的任意组合都能够透明地相互操作。
自动存储管理基本概念
本节定义了与自动存储管理（Automatic Storage Management）相关的一些基本概念。
磁盘组
磁盘组（disk group）是由一组自动存储管理磁盘（Automatic Storage Management disk）构成的逻辑管理单位。磁盘组的数据结构信息存储在磁盘组内部，因此将占用一些磁盘组空间。自动存储管理磁盘可以在数据库运行时添加到磁盘组或从磁盘组中移除。自动存储管理能够在磁盘组的磁盘间均衡的分布数据，以使各磁盘的 I/O 负载平衡，此功能在磁盘组配置发生变化时依然有效。
每个自动存储管理文件（Automatic Storage Management file）只能存在于一个磁盘组内。但一个磁盘组可以存储属于不同数据库的数据文件，一个数据库也能够使用多个磁盘组提供的存储资源。管理员可以为数据库指定一个或多个默认的磁盘组来存储其数据文件。
磁盘组可以在创建数据库的同时创建，也可以根据新应用的需要而创建。当数据库服务器的配置修改后，相应的磁盘组配置也可以被修改。
大部分数据库都会使用多个磁盘组。使用多个磁盘组的原因如下：
- 应将不同容量或不同性能的磁盘划分为不同的磁盘组
- 应根据外部冗余能力（external redundancy）来划分磁盘组；具备相同外部冗余能力的磁盘应划入同一磁盘组，而外部冗余能力不同的磁盘不应划为同一磁盘组。
- 将数据库区（database area）与快速恢复区（flash recovery area）放置在不同的磁盘组
磁盘组的类型
磁盘组有三种类型：正常冗余（normal redundancy），高冗余（high redundancy），及外部冗余（external redundancy）。对于正常冗余和高冗余的磁盘组来说，自动存储管理（Automatic Storage Management）将根据磁盘组模板（disk group template）中设定的属性为磁盘组内的每个数据文件提供冗余支持。与正常冗余相比，高冗余对数据的保护程度更高。对于外部冗余来说，自动存储管理不为磁盘组提供冗余支持。磁盘组内的磁盘应自己实现冗余（例如，使用磁盘阵列（storage
array）），否则当磁盘组内的磁盘出现故障时可能出现数据丢失（例如，测试系统可以采用这种配置）。
自动存储管理文件
当数据库需要存储空间时，自动存储管理（Automatic Storage Management）将创建文件。自动存储管理创建的文件的名称由前缀和数字后缀构成。用户可以为自动存储管理文件设定易于理解的别名。通过 V$ASM_ALIAS 数据字典视图可以查询自动存储管理文件的别名。只有在 ASM 实例中才能查询 V$ASM_ALIAS 视图。用户可以通过数据库实例中的某些V$ 视图（V$DATAFILE，V$LOGFILE，V$CONTROLFILE 等）查询出
ASM 文件名。但通常来说，用户没必要了解 ASM 文件名。
当创建 ASM 文件时，一些属性将被永久地赋予此文件。文件的属性包括其保护策略（protection policy）（即镜像）及条带化策略（striping policy）。自动存储管理文件对于操作系统及外部工具是不可见的，只有数据库实例，RMAN，及其他 Oracle 提供的工具可以访问
自动存储管理模板
自动存储管理模板（Automatic Storage Management template）即自动存储管理文件创建时使用的一组文件属性集合。模板将大量复杂的文件属性归纳为一个单一的名称，因而简化了文件创建工作。各种 Oracle 文件类型都有一个默认的模板。每个磁盘组（disk group）都能保存其自身使用的模板的定义。不同的磁盘组可以拥有属性不同的同名模板。
用户可以修改默认模板的属性，也可以创建自定义模板。即将特定的文件创建属性保存为模板。如果用户需要修改一个已有的自动存储管理文件（Automatic Storage Management file）的属性，只能通过 RMAN 将原有文件复制到具备新属性的文件中去。
自动存储管理磁盘
一个磁盘组（disk group）内最小的存储分配单位为自动存储管理磁盘（Automatic Storage Management disk，ASM disk）。一个 ASM 磁盘可以是一个物理磁盘，也可以是磁盘阵列（storage array）内的一个逻辑单元号（Logical Unit Number，LUN），或网络接入存储（Network Attached Storage，NAS）文件服务器（filer）中的一个文件。ASM
磁盘应相互独立，从而获得最佳的 I/O 性能。例如，使用磁盘阵列时，用户可以赋给一对互为镜像的物理磁盘一个逻辑单元号，做为一个 ASM 磁盘。如果用户在磁盘阵列中将一个物理磁盘条带化（striped）并赋予两个逻辑单元号，这有可能影响 I/O 性能。
当使用网络接入存储文件服务器时，作为 ASM 磁盘的文件容量必须是 1 MB 的整数倍。为获得最佳性能，属于同一磁盘组的网络接入存储文件应该各自独立地分布在不同的物理磁盘上。
用户指定的设备不应包含不能被覆盖（overwritten）的数据。例如，在某些操作系统中，某些磁盘分区（partition）的头部包含分区表（partition table）。这样的分区不应被指定为 ASM 磁盘。
自动存储管理在对 ASM 磁盘执行 I/O 操作时，总是通过唯一的逻辑路径（single logical path）。因此，如果用户在 ASM 中使用了多路径驱动器（multi-pathing driver），那么必须为 ASM 磁盘指定一个唯一的逻辑路径，从而保证 ASM 定位字符串（ASM discovery string）（即 ASM_DISKSTRING 初始化参数）中每个
ASM 磁盘对应唯一的逻辑路径
在集群（cluster）内，每个 ASM 磁盘必须对集群内的所有 ASM 实例均可见，但每个节点上保存的 ASM 磁盘路径不必完全相同，只要每个实例上的 ASM_DISKSTRING 初始化参数中包含此实例所用的 ASM 磁盘路径即可。
在集群（cluster）的所有节点上，ASM 磁盘的名称都是相同的。ASM 磁盘名称由管理员设定，或在磁盘被添加到磁盘组时由 ASM 自动生成。一个 ASM 磁盘除了磁盘名称之外，还需设定摘要信息，因为不同的主机可能使用不同的操作系统名称表示同一个磁盘。
自动存储管理提供了镜像功能，以便减少磁盘故障造成数据丢失的可能性。这十分必要，如果一个 ASM 磁盘的未镜像的数据丢失可能导致磁盘组内的多个文件损坏
故障恢复组
故障恢复组（failure group）是由管理员指定的一组磁盘构成的。故障恢复组中的自动存储管理磁盘（Automatic Storage Management disk）用于存储数据的冗余备份。使用了故障恢复组后，数据及数据的冗余备份将分别存储在不同磁盘上，从而避免了磁盘故障造成数据及冗余备份同时丢失。
故障恢复组的构成是与设备相关的。用户要根据系统中各组件的容错要求来设定故障恢复组。例如，系统中有五块磁盘及一个 SCSI 控制器（SCSI controller）。如果 SCSI 控制器发生故障将导致所有磁盘失效。在此种情况下，用户应将每个磁盘放入不同的故障恢复组。再例如，系统中有两个 SCSI 控制器，每个控制器上连接了两块磁盘，如果用户需要对 SCSI 控制器进行容错，就应使用每个 SCSI 控制器下的磁盘分别创建故障恢复组。
默认情况下，自动存储管理（Automatic Storage Management）使用一块磁盘构成一个故障恢复组。用户也可以在创建磁盘组（disk group）或向磁盘组中添加磁盘时设定一组磁盘作为故障恢复组。自动存储管理优化文件分布以降低设备故障造成数据丢失的可能性。
磁盘组的故障恢复组属性是保存在磁盘组内部的。一个磁盘组可以使用多个故障恢复组。当用户需要修改一个磁盘的故障恢复组时，需要先将磁盘从磁盘组中删除，之后将磁盘再次添加到原磁盘组中，并在添加时赋予新的故障恢复组属性。
自动存储管理实例
自动存储管理实例（Automatic Storage Management instance）是一种特殊的 Oracle 实例，其功能是管理磁盘组（disk group）内的磁盘。数据库实例必须通过为其配置的自动存储管理实例才能存取自动存储管理文件（Automatic Storage Management file）。如果创建数据库时使用了数据库配置助理（Database Configuration Assistant），此工具能够自动地配置数据库所需自动存储管理实例。
自动存储管理实例不能用于挂载数据库。自动存储管理实例只负责管理数据库实例的数据存储分布（data layout）。数据库实例能够直接对磁盘组中的磁盘进行 I/O 操作，而无须经过自动存储管理实例。
多个数据库实例可以共享同一个磁盘组。对于只含有一个节点（single node）的系统来说，通常只使用一个自动存储管理实例来管理此节点所需的所有磁盘组。而在 RAC 系统中，通常每个节点都拥有一个自动存储管理实例，她们相互协调共同管理 RAC 所使用的所有磁盘组。
所有和自动存储管理有关的命令都将被提交给自动存储管理实例，而非使用自动存储管理文件的数据库实例。
自动存储管理实例后台进程
使用自动存储管理文件（Automatic Storage Management file）的数据库实例中包含名为 ASMB 的后台进程，其功能是与自动存储管理实例（Automatic Storage Management instance）进行通信。此外还有名为 RBAL 的进程负责启用实例所使用的所有自动存储管理磁盘（Automatic Storage Management disk）。
使用自动存储管理的优势
- 自动存储管理（Automatic Storage Management）使数据库管理工作更为简单。
- 管理员无须设定及管理数据文件名称。管理员在创建数据文件时只需指定磁盘组即可。新创建的数据文件都能自动地获得一个唯一的名称。这避免了使用同一磁盘组的数据库使用相同的文件名。使用磁盘组命名（disk group naming）也避免了用不同名称为同一文件命名。
- 在很多情况下，自动存储管理能够代替外部卷管理器（external volume manager）及文件系统（file system）的功能。
- 自动存储管理包含了多种存储可靠性功能（storage reliability feature），例如镜像（mirroring）。存储可靠性策略（storage reliability policy）是针对每个文件的，而非针对整个磁盘组。因此，同一磁盘组内的不同文件可以采取不同的保护方式，例如镜像，奇偶检验（parity），或不采取保护措施。
- 自动存储管理能够提高系统性能。
- 自动存储管理能够将数据库文件分布在磁盘组内的所有磁盘中，从而提高系统性能。她拥有裸设备（raw disk）的 I/O 性能，但管理相对裸设备而言更为容易。
- 与逻辑卷管理器（logical volume manager）不同，自动存储管理的维护操作无须数据库停机即可执行。管理员可以动态地添加磁盘，或将使用中的磁盘移除。
- 自动存储管理减少了手工设置磁盘属性的工作。文件创建时的属性可以来自磁盘组中的预定义模板，因此提高了管理效率。