【DG】Oracle_Data_Guard官方直译

【DG】Oracle Data Guard官方直译

---

---

1 Oracle Data Guard 介绍 

 

Oracle Data Guard概念和管理10g版本2

 

Oracle Data Guard 确保企业数据的高可用性、数据保护以及灾难恢复。Data Guard 提供了一套全面的服务来创建、维护、管理和监控一个或多个备数据库，使得生产 Oracle 数据库从灾难和数据损坏中得以幸存。Data Guard 维护这些备数据库作为生产数据库的事务一致性拷贝。然后，如果生产数据库因为计划的或计划外的中断而变得不可用。Data Guard 能切换任何备数据为生产角色，从而最小化中断引起的宕机时间。Data Guard 能与传统的备份、恢复和 cluster 技术一起使用，以提供高级别的数据保护和数据可用性。 

使用Data Guard，管理员能通过将资源密集的备份和报表操作转移到备系统上，来提高生产数据库的性能。 

本章包括下面描述Oracle Data Guard 亮点的主题： z Data Guard 配置

 z Data Guard 服务

 z Data Guard Broker

z Data Guard 保护模式

 z Data Guard 和互补技术

 z Data Guard 益处总结 

 

 

1.1 Data Guard 配置 

Data Guard 配置包含一个生产数据库和一个或更多备数据库。在 Data Guard 配置中的数据库可以通过 Oracle Net 连接并可以分布在不同地理位置。数据库所处位置是没有限制的，只要它们能互相通讯。例如，你能有一个备数据库与生产数据库处于同一系统上，并且有两个备数据库在异地的其它系统上。 

你能使用SQL 命令行工具或 Data Guard broker 工具来管理主和备数据库，包括命令行工具（DGMGRL）和在 Oracle 企业管理器中集成的图形化用户工具。 

 

1.1.1 主数据库 

Data Guard 配置包含一个生产数据库，也称为主数据库，作为主角。这是大多数你的应用访问的数据库。 

主数据库能是单实例Oracle 数据库或 Oracle Real Application Clusters 数据库。 

 

1.1.2 备数据库 

备数据库是主数据库的一个事务一致性拷贝。使用主数据库的备份拷贝，你能创建最多九个备数据库，并将其合并到一个Data Guard 配置中。一旦创建，Data Guard 自动维护每个备数据库，从主数据库传送重做数据然后应用重做到备数据库。 

类似于主数据库，备数据库也可以是单实例Oracle 数据库或 Oracle Real Application

Clusters 数据库。 

备数据库可以是物理备数据库或逻辑备数据库： z 物理备数据库通过基于块对块的与主数据库同样的磁盘数据库结构，提供主数据库的完全一致的物理拷贝。数据库方案，包括索引，是相同的。物理备数据库与主数据库保持同步，通过重做应用，恢复从主数据库收到的重做数据并将重做应用到物理备数据库。 

除了灾难恢复，物理备数据库只能在有限的范围内用于业务目的。 

z 逻辑备数据库 

包含与生产数据库同样的逻辑信息，尽管数据的物理组织和结构可以是不同的。逻辑备数据库通过SQL 应用与主数据库保持同步，其将从主数据库收到的重做中的数据转换成 SQL 语句，然后在备数据库上执行 SQL 语句。 

逻辑备数据库能用于灾难恢复需求以外的业务目的。这允许用户在任何时间访问逻辑备数据库，进行查询和报表。同时，使用逻辑备数据库，你能升级Oracle 数据库软件和补丁集而几乎没有宕机时间。这样，逻辑备数据库能并发用于数据保护、报表、和数据库升级。 

 

1.1.3 配置举例 

图1－1 显示典型的 Data Guard 配置，包含一个主数据库，传送重做数据到一个备数据库。备数据库异地于主数据库以用于灾难恢复和备份操作。你能配置备数据库与主数据库在同一位置。然而，为了灾难恢复的目的，Oracle 建议你配置备数据库在异地位置。 

图1－1 显示典型的 Data Guard 配置，在其中重做被应用到备数据库的备重做日志文件中。 

图1－1 典型的Data Guard 配置 

 

 

 

1.2 Data Guard 服务 

下面小节解释了Data Guard 如何管理重做数据的传送、重做数据的应用、以及更改数据库角色： 

z 重做传输服务 

控制从生产数据自动传输重做数据到一个或更多归档的目的地。 

z 日志应用服务 

在备数据库上应用重做数据，与主数据库维持事务同步。重做数据能从归档重做日志文件，或者，如果允许实时应用，当备重做日志写满时直接从其中应用，而不需要将重做数据首先归档到备数据库。 

z 角色转换 使用切换或故障转移操作，从备数据库更改数据的角色到主数据库，或者从主数据

库到备数据库。 

 

1.2.1 重做传输服务 

重做传输服务控制重做数据从生产数据库自动传输到一个或更多归档的目的地。重做传输服务执行下述任务： z 从主数据库传送重做数据到配置中的备系统 z 管理解决归档重做日志文件由于网络故障中断的过程 z 强制数据库保护模式（在 1.4 节中描述） z 自动探测在备系统上丢失或损坏的归档重做日志文件，并且自动从主数据库或其它备数据库检索替代的归档重做日志文件 

 

1.2.2 日志应用服务 

从主数据库传送的重做数据写到备系统上的备重做日志文件中，如果配置了，然后再归档到归档重做日志文件。日志应用服务自动应用备数据库上的重做数据，以维持与主数据库的一致性。其同时也允许对数据的只读访问。 

物理与逻辑备数据库的主要区别是日志应用服务应用归档重做数据的方式： 

z 对于物理备数据库，Data Guard 使用重做应用技术，使用 Oracle 数据库的标准恢复技术在备数据库上应用重做数据，如图 1－2 所示。 

图1－2 物理备数据库的自动更新 

 

z 对于逻辑备数据库，Data Guard 使用 SQL 应用技术，首先将收到的重做数据转换为 SQL 语句，然后在逻辑备数据库执行生成的 SQL 语句，如图 1－3 所示。 

图1－3 逻辑备数据库的自动更新 
 

 

1.2.3 角色转换 

Oracle 数据库操作在两种角色之一：主或备。使用 Data Guard，你能使用切换或故障转移操作更改数据库的角色。 

切换是在主数据库与其备数据库之一进行的角色反转。切换确保不丢失数据。这是对于主系统计划维护的典型操作。在切换期间，主数据库转换到备角色，备数据库转换到主角色。转换发生不需要重建任何数据库。 

故障转移是当主数据库不可用时。故障转移只有在主数据库的灾难故障的情况下执行，并且故障转移导致备数据库转换到主角色。数据库管理员能配置 Data Guard 以确保不丢失数据。 

在本文档中描述的角色转换是使用SQL 语句手工执行。你也能使用 Oracle Data Guard broker 来简化角色转换，并使用 Oracle 企业管理器或 DGMGRL 命令行界面来自动化故障转移，如 1.3 节所述。 

 

 

1.3 Data Guard Broker

Data Guard Broker 是一个分布式的管理构架，用于自动化 Data Guard 配置的创建、维护、和监控。你能使用 Oracle Enterprise Manager 图形化用户界面（GUI）或 Data Guard 命令行界面（DGMGRL）来： 

z 创建和允许 Data Guard 配置，包括设置重做传输服务和日志应用服务 z 从配置中的任何系统管理整个 Data Guard 配置 

z 管理和监控包含 Real Application Clusters 主或备数据库的 Data Guard 配置 

z 通过允许你使用 Oracle 企业管理器中的单次点击或在 DGMGRL 命令行界面中的单条命令简化切换和故障转移 

z 当主数据库变得不可用时允许快速启动故障转移来自动转移故障。当允许快速启动故障转移时，由 Data Guard broker 决定是否需要故障转移，并自动启动故障转移到指定的目标备数据库，不需要 DBA 的介入并且不丢失数据。 

另外，Oracle 企业管理器自动化及简化了： 

z 从主数据库的备份拷贝中创建物理或逻辑备数据库 

z 添加新的或现有的备数据库到现有的 Data Guard 配置 

z 监控日志应用速度，捕获诊断信息，以及使用集中化的监控、测试、和性能工具快速发现问题。 

 

1.3.1 使用 Oracle 企业管理器 

Oracle 企业管理器，也称为企业管理器，提供了一个基于 web 的界面，用于查看、监控、和管理Data Guard配置中的主和备数据库。企业管理器的易于使用的界面结合了broker 的集中管理和 Data Guard 配置的监控，增强了对于高可用性、站点保护、和企业的数据保护的 Data Guard 解决方案。 

从企业管理器中央控制台，所有的管理操作能在本地或异地执行。你能查看Oracle 数据库的主页，包括主和备数据库以及实例，创建或添加现有的备数据库，气筒和停止实例，监控实例性能，查看事件，调度作业，以及执行备份和恢复操作。查看 Oracle Data Guard

Broker 和 Oracle 企业管理器联机帮助系统。 

图1－4 显示了在企业管理器中的 Data Guard 管理概要页面。 

 

 

1.3.2 使用 Data Guard 命令行界面 

Data Guard 命令行界面（DGMGRL）允许你从 DGMGRL 提示符或脚本中控制和监控 Data Guard 配置。你能使用 DGMGRL 执行大多数所需的行动来管理和监控配置中的数据库。查看 Oracle Data Guard Broker 以获得完整的 DGMGRL 参考信息和举例。 

 

 

1.4 Data Guard 保护模式 

在一些情况下，业务不允许丢失数据。在另外一些情况下，数据库的可用性比丢失数据更为重要。一些应用需要最强的数据库性能并且能容忍丢失少量的数据。下面的描述概述了三种不同的数据保护模式。 

最大保护  这种保护模式确保如果主数据库故障不会发生数据丢失。要提供这种级别的保护，恢复每个事务所需的重做数据必须在事务提交之前同时写到本地联机重做日志和至少一个备数据库上的备重做日志。要确保不发生数据丢失，如果故障导致主数据库无法写重做流到至少一个事务一致性备数据库的备重做日志时，主数据库会关闭。 

最大可用性  这种保护模式提供了可能的最高级别的数据保护，而不用与主数据库的可用性相折衷。与最大保护模式相同，在恢复事务所需的重做写到本地联机重做日志和至少一个事务一致性备数据库上的备重做日志之前，事务将不会提交。与最大保护模式不同的是，如果故障导致主数据库无法写重做流到异地备重做日志时，主数据库不会关闭。替代地，主数据库以最大性能模式运行直到故障消除，并且解决所有重做日志文件中的中断。当所有中断解决之后，主数据库自动继续以最大可用性模式运行。 

这种模式确保如果主数据库故障，但是只有当第二次故障没有阻止完整的重做数据集从主数据库发送到至少一个备数据库时，不发生数据丢失。 

最大性能  这种保护模式（默认）提供了可能的最高级别的数据保护，而不影响主数据库的性能。这是通过允许事务在恢复该事务所需重做数据在写到本地联机重做日志后立即提交而实现的。主数据库的重做数据流也写到至少一个备数据库，但是那个重做流相对于创建重做数据的事务是异步写的。 

当所用的网络连接有足够的带宽，这种模式提供了近似于最大可用性模式的数据保护级别，并且对主数据库性能的影响最小。 

最大保护和最大可用性模式需要备重做日志文件配置在配置中的至少一个备数据库上。所有三种保护模式需要在LOG_ARCHIVE_DEST_n 初始化参数上指定特定的日志传输属性以发送重做数据到至少一个备数据库。查看 5.6 节以获得数据保护模式的完整信息。

 

 

1.5 Data Guard 和互补技术 

Oracle数据库提供了几种独特的技术互补Data Guard确保业务关键系统以比使用其中任何单种技术更高级别的可用性和数据保护运行。下面的列表总结了一些 Oracle 高可用性技术： 

z Oracle Real Application Clusters（RAC） 

RAC 允许多个独立服务器通过内部连接共享访问一个 Oracle 数据库，提供了高可用性、可扩展性、和在故障时的冗余性。RAC 和 Data Guard 一起提供了系统级别、站点级别、和数据级别的保护，导致了高级别的可用性和灾难恢复而不丢失数据： 

{ RAC 通过提供从故障的快速和自动恢复来处理系统故障，如节点故障和实例崩溃。其也提供了对应用的增加的可扩展性。 

{ Data Guard 通过保持不共享磁盘的主和备数据库的事务一致性来处理站点故障，允许从站点灾难和数据损坏中恢复。 

可能有许多不同的使用RAC 和 Data Guard 的架构，依赖于本地和异地站点的使用以及节点和逻辑与物理备数据库的结合的使用。查看附录 D，“Data Guard 和 Real Application Clusters”和 Oracle 数据库高可用性概述以获得 RAC 和 Data Guard 的整合。 

z Flashback 数据库 

Flashback 数据库特性提供了从逻辑数据损坏和用户错误中的快速恢复。通过允许你闪回时间点，可能已经被错误更改或删除的前面版本的业务信息能被再次访问。这种特性： 

{ 消除了还原备份并前滚更改到错误或损坏出现的时间的需求。替代地，

Flashback 数据库能回滚 Oracle 数据库到一个前面的时间点，而不用还原数据文件。 

{ 提供了延迟重做的应用的选项，以保护用户错误或逻辑损坏。因此，备数据库能近地与主数据库同步，从而减少了故障转移和切换的时间。 

{ 避免在故障转移后完全重建原始主数据库。故障的主数据库能闪回到故障转移前的时间点，并转换成新的主数据库的备数据库。 

查看Oracle 数据库备份和恢复高级用户指南以获得 Flashback 数据库的信息，以及 6.2.2 节以获得延迟重做数据的应用的信息。 

z 恢复管理器（RMAN） 

RMAN 是一种 Oracle 工具，简化了备份、还原、和恢复数据库文件。与 Data Guard 相同，RMAN 是一种 Oracle 数据库的特性，不需要额外的安装。Data Guard 能很好地与 RMAN 集成，允许你： 

{ 使用恢复管理器 DUPILCATE 命令来从你的主数据库的备份中创建备数据库。 { 用物理备数据库取代生产数据库来进行备份，减少生产数据库的负载并允许有效地使用备站点的系统资源。此外，备份能在物理备数据库在应用重做时进行。 

{ 通过自动删除用于在执行备份后输入的归档重做日志文件，帮助管理归档重做日志文件。 

查看附录 F，“使用恢复管理器创建备数据库”和 Oracle 数据库备份和恢复基础。 

 

 

1.6 Data Guard 益处总结 

Data Guard 提供了这些益处： 

z 灾难恢复，数据保护，和高可用性 

Data Guard 提供了一个有效的、广泛的灾难恢复及高可用性解决方案。易于管理的切换和故障转移能力允许角色在主和备数据库之间转换，最小化了主数据库在计划和非计划中断的宕机时间。 

z 完全的数据保护 

Data Guard 能确保没有数据丢失，即使面对无法预料的灾难。备数据库提供了对数据损坏和用户错误的保护。在主数据库上的存储级别的物理损坏不会蔓延到备数据库。类似地，导致主数据库永久损害的逻辑损坏或用户错误能被解决。最后，重做数据在应用到备数据库时要验证。 

z 系统资源的有效使用 

由从主数据库收到的重做数据更新的备数据库表，能用于其它任务如备份、报表、总结、和查询，从而减少了主数据库用于执行这些任务所需的工作负载，节省了宝贵的CPU 和 I/O 循环。在逻辑备数据库中，用户能在不是从主数据库更新的方案的表上执行常规的数据操作。逻辑备数据库能在表被从主数据库更新时保持打开，并且表同时能被只读访问。最后，在维护的表上能创建额外的索引和物化视图，以获得更好的查询性能并适合特定的业务需求。 

z 灵活保护数据，平衡可用性与性能需求 

Oracle Data Guard 提供了最大保护、最大可用性、和最大性能模式，以帮助企业平衡数据可用性与系统性能需求。 

z 自动探测和解决中断 

如果在主和一个或更多备数据库之间的连接丢失了（例如，由于网络问题），在主数据库上生成的重做数据无法发送到那些备数据库。一旦重新建立连接，Data Guard 能自动探测丢失的归档重做日志文件（称之为中断），然后自动传输丢失的归档重做日志到备数据库。备数据库与主数据库同步，不需要 DBA 的手工介入。 

z 集中和简单的管理 

Data Guard broker 提供了一个图形化的用户界面和一个命令行界面来自动化管理和操作在 Data Guard 配置中的跨多个数据库的任务。Broker 也监控在单个 Data Guard 配置中的所有系统。 

z 与 Oracle 数据库集成 

Data Guard 是 Oracle 数据库企业版中的一个特性，不需要单独地安装。 

z 自动角色转换 

当允许快速启动故障转移时，在主站点灾难的情况下，Data Guard broker 自动故障转移到一个同步的备站点上，不需要 DBA 的介入。另外，角色转换自动通知应用。 

 

 

2 Data Guard 入门 

 

Data Guard 配置包含一个主数据库和最多九个相关的备数据库。本章描述了 Data Guard 入门的下述考虑： z 备数据库类型 

z 管理 Data Guard 配置的用户界面 

z Data Guard 操作的先决条件 z 备数据库目录结构考虑 z 联机重做日志、归档重做日志、和备重做日志 

 

 

2.1 备数据库类型 

备数据库是一个 Oracle 生产数据库的事务一致性拷贝，初始从主数据库的备份拷贝创建。一旦创建并配置备数据库后，Data Guard 通过传输主数据库重做数据到备系统自动维护备数据库，在那里重做数据应用到备数据库。 

备数据库可用是两种类型之一：物理备数据库或逻辑备数据库。如果需要，任何一种类型的备数据能承担主数据库的角色并接管生产过程。Data Guard 配置能包括物理备数据库，逻辑备数据库，或两种类型的组合。 

 

2.1.1 物理备数据库 

以基于块对块的与主数据库同样的磁盘数据库结构，物理备数据库物理等同于主数据库。数据库方案、包括索引，是同样的。 

Data Guard 通过执行重做应用，维护物理备数据库。当没有执行恢复的时候，物理备数据库能以只读模式打开，或者如果允许 Flashback 数据库则可以临时以读/写模式打开。 

z 重做应用 

物理备数据库通过使用Oracle 恢复机制，从归档重做日志文件或直接从备系统上的备重做日志文件应用重做数据来维护。恢复操作使用数据块地址应用重做块中的更改到数据块中。数据库在应用重做时不能打开。 

z 只读打开 

物理备数据库能以只读模式打开，使得你能在数据库上执行查询。当以只读模式打开时，备数据库能继续接受重做数据，但是从日志文件的重做数据的应用会延迟，直到数据库继续重做应用。 

虽然物理备数据库不能在同一时间重做应用和以只读模式打开，但是你能在两者之间切换。例如，你能执行重做应用，然后以只读模式打开以运行报表应用，再将其改回以执行重做应用任何未应用的归档重做日志文件。你能在必要时重复这个循环，在重做应用和只读之间切换。 

物理备数据库可用于执行备份。此外，物理备数据库将继续接受重做数据，即使归档重做日志文件或备重做日志文件没有在那个时刻被应用。 

z 读/写打开 

为了诸如创建一个克隆数据库或读/写报表的目的，物理备数据库也能为读/写访问打开。当以读/写模式打开时，备数据库不会从主数据库接受重做数据并且无法提供灾难保护。 

物理备数据库能临时地以读/写模式打开，以用于开发、报表、或测试目的，然后闪回到过去的点以回复到物理备数据库。当数据库闪回之后，Data Guard 自动同步备数据库与主数据库，而不需要从主数据库的备份拷贝重建物理备数据库。 

 

物理备数据库的益处 

物理备数据库提供以下益处： z 灾难回复和高可用性 

物理备数据库提供了强壮的和有效的灾难回复以及高可用性解决方案。易于管理的切换和故障转移能力允许在主和物理备数据库之间容易地进行角色转换，最小化主数据库由于计划的或计划外的断电而导致的宕机时间。 

z 数据保护 使用物理备数据库，Data Guard 能确保没有数据丢失，即使面对不可预见的灾难。

物理备数据库支持主数据库能支持的所有数据类型和所有DDL 和 DML 操作。其同时提供了对数据损坏和用户错误的保护。在主数据库上的存储级别的物理损坏不会蔓延到备数据库。类似地，造成主数据库永久损害的逻辑损坏或用户错误也能被解决。最后，重做数据在应用到备数据库时要验证。 

z 减少主数据库的工作负载 

Oracle 回复管理器（RMAN）能使用物理备数据库进行非负载备份，从而节省了主数据库的宝贵 CPU 和 I/O 循环。物理备数据库也能以只读模式打开，用于报表和查询。 

z 性能 物理备数据库使用的重做应用技术使用低级别的恢复机制应用更改，绕过了所有

SQL 级别代码层；因此，这是应用海量重做数据最有效的机制。 

 

2.1.2 逻辑备数据库 

逻辑备数据库最初创建为主数据库的等同拷贝，但是以后能更改为不同的结构。逻辑备数据库通过执行SQL 语句来更新。这允许用户在任何时间访问备数据库进行查询和报表。这样，逻辑备数据库能并发用于数据保护和报表操作。 

Data Guard 通过转换日志文件中的数据到 SQL 语句然后在逻辑备数据库上执行 SQL 语句，自动应用从归档重做日志文件或备重做日志文件中的信息到逻辑备数据库。因为逻辑备数据库是使用 SQL 语句更新的，其必须保持打开。虽然逻辑备数据库是以读/写模式打开的，但是用于重新生成 SQL 的目标表只能用于只读操作。当那些表被更新时，他们能同时用于其它任务如报表、统计、和查询。此外，这些任务能通过在维护表上创建额外的索引和物化视图进行优化。 

逻辑备数据库在数据类型、表的类型、和DDL 与 DML 操作类型上有一些限制。4.1.1 节描述了不支持的数据类型和表的存储属性。 

 

逻辑备数据库的益处 

逻辑备数据库提供了与物理备数据类似的灾难恢复，高可用性，和数据保护益处。它同时还提供下述专门的益处： 

z 备硬件资源的有效利用逻辑备数据库能用于灾难恢复需求以外的其它业务用途。它能在 Data Guard 配置中保护的数据库方案之上主动创建额外的方案，并且用户能在任何时间对这些方案执行正常的 DDL 或 DML 操作。因为由 Data Guard 保护的逻辑备表能存储在主数据库以外的不同物理层次，所以能创建额外的索引和物化视图以提高查询性能并满足特定的业务需求。 

z 减少主数据库的工作负载 

逻辑备数据库能在表被主数据库更新的同时保持打开，并且这些表同时可用于读访问。这使得逻辑备数据库是进行查询、统计、和报表活动的极好选择，从而减少了主数据库执行这些任务的负载并节省了宝贵的CPU 和 I/O 循环。 

 

 

2.2 管理 Data Guard 配置的用户界面 

你能使用下述界面来配置、实施、和管理Data Guard 配置： z Oracle 企业管理器 

企业管理器提供了一个Data Guard broker 的 GUI 界面，能自动化许多任务，包括创建、配置、和监控 Data Guard 环境。查看 Oracle Data Guard Broker 和 Oracle 企业管理器联机帮助以获得 GUI 及其向导相关的信息。 

z SQL*Plus 命令行界面 

个别SQL*Plus 语句使用 STANDBY 关键词来指定备数据库上的操作。其它 SQL 语句不包含备－特定语法，但是它们对于在备数据库上执行操作是有用的。查看第 15 章以获得相关语句的列表。 

z 初始化参数 

个别初始化参数用于定义Data Guard 环境。查看第 13 章以获得相关初始化参数的列表。 

z Data Guard broker 命令行界面（DGMGRL） 

DGMGRL 命令行界面是使用 Oracle 企业管理器的替代选项。如果你想从批处理程序或脚本使用 broker 来管理 Data Guard 配置，DGMGRL 命令行界面是很有用的。查看

Oracle Data Guard Broker 以获得完整信息。 

 

 

2.3 Data Guard 操作的先决条件 

下面小节描述了使用Data Guard 的操作需求： z 硬件和操作系统需求 z Oracle 软件需求 

 

2.3.1 硬件和操作系统需求 

下面列表描述了使用Data Guard 的硬件和操作系统需求： 

z Data Guard 配置中的所有成员必须运行在同一平台建立的 Oracle 映像上。 

例如，这意味着在Intel 系统上的 32 位 Linux 上的主数据库的 Data Guard 配置可以有配置在 Intel 系统上的 32 位 Linux 上的备数据库。然而，在 64 位 HP-UX 系统上的主数据库也能配置在 32 位 HP-UX 系统上的备数据库，只要两个服务器都运行 32 位的映像。 

z 主和备系统的硬件（例如，CPU 的数量、内存大小、存储配置）可以是不同的。 

如果备系统比主系统要小，你可能必须限制在切换或故障转移后备系统上的工作量。备系统必须有足够的可用资源来接收和应用所有从主数据库来的重做数据。逻辑

备数据库需要额外的资源以转换重做数据为SQL 语句并在逻辑备数据库上执行 SQL。 

z 在主和备位置运行的操作系统必须是相同的，但是操作系统版本不需要一样。另外，备数据库能使用与主数据库不同的目录结构。 

 

2.3.2 Oracle 软件需求 

下面列表描述了使用Data Guard 的 Oracle 软件需求： 

z Oracle Data Guard 只是作为 Oracle 数据库企业版的一个特性。在 Oracle 数据库标准版中没有这个特性。着意味着在 Data Guard 配置中必须在主数据库和所有备数据库上必须安装同样版本的 Oracle 数据库企业版。 

 

注： 

可以使用运行Oracle 数据库标准版的数据库来模拟备数据库环境。你能通过使用操作系统拷贝工具或自定义脚本定时从一个数据到另一个发送归档重做日志文件，手工传送归档重做日志文件。后果是这种配置无法提供 Data Guard 所具有的易于使用、易于管理、高性能、和灾难恢复能力。 

 

 

z 使用 Data Guard SQL 应用，你将能够执行 Oracle 数据库软件的滚动升级，从补丁集版本 n（最低地，这必须是版本 10.1.0.3）到下面的数据库 10.1.0.(n+1)补丁集版本。在滚动升级期间，你能在升级的同时在主和逻辑备数据上运行不同版本的

Oracle 数据库，一次升级一个。要获得完整的信息，查看第 11 章，“使用 SQL 应用来升级 Oracle 数据库”和应用 Oracle 数据库 10g 补丁集版本的自述文件。 

z 在 Data Guard 配置中所有数据库上的 COMPATIBLE 初始化参数必须设为同样的值。 

z 如果你当前在 Oracle8i 数据库软件上运行 Oracle Data Guard，查看 Oracle 数据库升级指南以获得升级 Oracle Data Guard 的完整信息。 

z 主数据库必须运行在 ARCHIVELOG 模式。查看 Oracle 数据库管理员指南以获得更多信息。 

z 主数据库可以是单实例数据库或多实例 Real Application Clusters 数据库。备数据库可以是单实例数据库或多实例 Real Application Clusters（RAC）数据库，并且这些备数据库可以是物理和逻辑类型的混合。查看 Oracle 数据库高可用性概述以获得更多配置和使用 Oracle Data Guard 与 RAC 的信息。 

z 每个主数据库和备数据库必须有自己的控制文件。 

z 如果备数据库与主数据库位于同样的系统上，备数据库的归档目录必须使用与主数据库不同的目录结构。否则，备数据库可能覆盖主数据库的文件。 

z 要保护在主数据库上的不记日志的直接写，无法传送到备数据库，在执行用于创建备数据库的数据文件备份之前在主数据库上打开 FORCE LOGGING。只要需要备数据库就保持数据库在 FORCE LOGGING 模式。 

z 你用于管理主和备数据库实例的用户帐户必须有 SYSDBA 系统权限。 

Oracle 建议当你在 Data Guard 配置中设置 Oracle 自动存储管理（ASM）和 Oracle 管理文件（OMF）时，必须在主和备数据库上对称地设置。就是说，如果在 Data Guard 配置中的任何数据库使用 ASM、OMF、或两者都，则在配置中的每个数据库都必须相应地使用 ASM、OMF、或两者都。查看在 12.12 节中的场景以获得更多信息。 

 

注： 

    因为一些执行包括基于时间的数据更新的应用无法处理从多个时区输入的数据，所以考虑设置主与远程备系统的时区相一致，以确保在角色转换之后维持记录的时间顺序。 

 

 

 

2.4 备数据库目录结构考虑 

不同备数据库的目录结构是很重要的，因为它决定备数据文件、归档重做日志文件、和备重做日志文件的路径名称。如果可能，主和备系统上的数据文件、日志文件、和控制文件应该拥有同样的名字和路径名称，并且使用Optimal Flexible Architecture（OFA）命名协定。在备数据库上的归档目录在站点之间也应该是同样的，包括大小和结构。这种策略允许其它操作如备份、切换、和故障转移执行同样的步骤集合，减少维护的复杂性。 

否则，你必须设置文件名转换参数（如表 2－1 中所示）或者重命名数据文件。不过，如果你需要使用不同目录结构的系统或将备和主数据库放在同一系统上，你能这么做以最小化额外的管理。 

在图 2－1 中举例说明了三种基本的配置选项。这些包括： 

z 备数据库与主数据库处于同一系统上，并使用与主系统不同的目录结构。这在图 2

－1 中举例为 Standby1。 

如果你有备数据库在与主数据库相同的系统上，你必须使用不同的目录结构。否则，备数据库会视图覆盖主数据库的文件。 

z 在分离系统上的备数据库使用与主系统相同的目录结构。这在图 2－1 中举例为

Standby2。这是建议的模式。 

z 在分离系统上的备数据库使用与主系统不同的目录结构。这在图 2－1 中举例为

Standby3。 

 

注： 

    如果在 Data Guard 配置中的任何数据库使用 ASM、OMF、或两者都，则在配置中的每个数据库应该相应地使用 ASM、OMF、或两者都。查看第 12 章以获得如何在 Data Guard 配置中设置 OMF 的场景描述。 

 

 

表2－1 备数据库位置和目录选项 

备系统	目录结构	结果
与主系统相同	不同与主系统 （需要）	z z	你必须设置 DB_UNIQUE_NAME 初始化参数。  你能手工重命名文件或在备数据库上设置 DB_FILE_NAME_CONVERT 和 LOG_FILE_NAME_CONVERT 初始化参数，以自动化更新备数据库控制文件中的主数据库数据文件与归档重做日志文件和备重做日志文件的路径名称。（见 3.1.4 节）
		z	备数据库不保护摧毁主和备数据库所在系统的灾难，但是它提供了计划维护的切换能力。
分离系统	与主系统相同	z	你不需要重命名在备数据库控制文件中的主数据库文件、归档重做日志文件、和备重做日志文件，如果你需要新的命名方式（例如，要将文件分布到不同磁盘上），你还是可以这么做。
		z	通过将备数据库放在分离的物理媒质上，你能保护主数据库上的数据不受摧毁主系统的灾难影响。
分离系统	不同与主系统	z	你可以手工重命名文件或在备数据库上设置 DB_FILE_NAME_CONVERT 和 LOG_FILE_NAME_CONVERT 初始化参数来自动化重命名数据文件。（见 3.1.4 节）
		z	通过将备数据库放在分离的物理媒质上，你能保护主数据库上的数据不受摧毁主系统的灾难的影响。

 

 

2.5 联机重做日志、归档重做日志、和备重做日志 

Data Guard 恢复操作的最关键结构是联机重做日志、归档重做日志、和备重做日志。从主数据库传送的重做数据由备系统上的远程文件服务（RFS）进程接收，RFS 进程写重做数据到归档日志文件或备重做日志文件中。重做数据可以在重做写到归档重做日志文件或备重做日志文件之后应用，或者，如果允许实时应用的话，当备重做日志文件写满后直接应用。 

本文档假设你已经理解联机重做日志和归档重做日志之后的概念。2.5.1 节通过提供了 Data Guard 配置相关的信息补充了基本概念。2.5.2 节提供了使用备重做日志文件的详细信息。 

查看Oracle 数据库管理员指南以获得更多重做日志和归档日志的信息，并且 6.2.1 节提供了实时应用的信息。 

 

2.5.1 联机重做日志和归档重做日志 

重做的传送是维护主和备数据库的事务一致性所必须的。联机重做日志和归档重做日志在Data Guard 环境中是需要的： z 联机重做日志 

Oracle 主数据库和逻辑备数据库的每个实例都有联机重做日志以保护实例故障情况下的数据库。物理备数据库不使用联机重做日志，因为物理备数据库不打开用于读/ 写 I/O。不允许对物理备数据库进行更高并且不会生成新的重做数据。 

z 归档重做日志 

归档重做日志是必须的，因为归档是用于使备数据库与主数据库保持事务一致性的方法。主数据库、以及物理和逻辑备数据库都使用归档重做日志。Oracle 数据库默认设置以 ARCHIVELOG 模式运行，所以归档（ARCn）进程自动拷贝每个写满的联机重做日志文件到一个或更多归档重做日志文件。 不像物理备数据库，逻辑备数据库是打开的数据库，能生成日志数据并有多个日

志文件，包括联机重做日志文件、归档重做日志文件、和备重做日志文件（如果配置）。 

联机重做日志文件的大小和日志切换的频率都能影响主站点上归档重做日志文件的生成。Oracle 数据库高可用性概述提供了日志组大小的推荐值。 

Oracle 数据库在每次日志切换时会视图进行检查点。因此，如果联机重做日志文件的尺寸太小了，频繁的日志切换会导致频繁的检查点并且负面影响备数据库的系统性能。 

 

同时查看： 

    Oracle 数据库管理员指南以获得配置重做日志、归档日志、和日志组的更多细节。 

 

 

2.5.2 备重做日志 

备重做日志类似与联机重做日志，除了备重做日志是用于存储从其它数据库接收的重做数据。 

如果你希望实施下述，则需要备重做日志： z 数据保护的最大保护和最大可用性级别（在 1.4 节中描述，在 5.6 节中详述） z 实时应用（在 6.2 节中描述） z 级联目标（在附录 E 中描述） 

备重做日志提供了一些优点： 

z 备重做日志文件能存放在裸设备上，这在主与备数据库都处于 Real Application

Clusters 环境中时很重要。 

z 备重做日志文件能使用多个成员进行多重，提高归档重做日志文件的可靠性。 

z 在故障转移期间，Data Guard 能从备重做日志文件比单独重归档重做日志文件恢复和应用更多的重做数据。 

z 在主数据库上的归档（ARCn）进程或日志写（LGWR）进程能直接传送数据到远程备重做日志文件，潜在地消除了注册部分归档重做日志文件的需求（例如，在备数据库崩溃后的恢复）。查看第 5 章以获得更多信息。 

3.1.3 节描述了如何配置备重做日志文件。 

 

 

3 创建物理备数据库 

 

本章逐步指导你创建物理备数据库。它包括下述主要主题： z 为备数据库创建准备主数据库 z 创建物理备数据库的逐步指导 z 创建后的步骤 

在本章中描述的步骤以最高性能模式配置备数据库，这是默认的数据保护模式。第 5 章提供了配置不同数据保护模式的相关信息。在本章中的讨论假设你在服务器参数文件

（SPFILE）中指定了初始化参数，替代了文本初始化参数文件（PFILE）。 

同时查看： z Oracle 数据库管理员指南以获得创建和使用服务器参数文件相关信息 

z Oracle Data Guard Broker 和企业管理器联机帮助系统以获得使用图形用户界面自动创建物理备数据库相关信息 

 

 

3.1 为备数据库创建准备主数据库 

在你创建备数据库之前，你必须首先确保正确地配置好主数据库。 

表3－1 提供了你在主数据库上执行的为物理备数据库创建准备的任务的检查列表。每小节还有相关参考更详细地描述任务。 

表3－1 为物理备数据库创建准备主数据库 

参考	任务
3.1.1 节	允许强制记日志
3.1.2 节	创建口令文件
3.1.3 节	配置备重做日志
3.1.4 节	设置主数据库初始化参数
3.1.5 节	允许归档

 

 

注： 

    只要执行这些准备任务一次。在你完成这些步骤之后，数据库就准备好以主数据库为一个或更多备数据库服务了。 

 

 

3.1.1 允许强制记日志 

在数据库创建之后使用下面的SQL 语句将主数据库置于 FORCE LOGGING 模式： 

SQL> ALTER DATABASE FORCE LOGGING;

 

这条语句可能需要相当长的时间才能完成，因为它会等待所有未记日志的直接写I/O 完成。 

 

3.1.2 创建口令文件如果没有已经存在的口令文件则创建一个。在Data Guard 配置中的每个数据库必须使用口令文件，并且对于 SYS 用户的口令文件在每个系统上必须相同，以确保重做数据传输成功。查看 Oracle 数据库管理员指南。 

 

3.1.3 配置备重做日志 

最大保护和最大可用性模式是需要备重做日志的，并且对于所有数据库推荐LGWR

ASYNC 传送模式。Data Guard 从备重做日志比单独从归档重做日志文件能恢复和应用更多重做数据。 

你应该在创建备数据库的时候，计划备重做日志配置并创建所有所需的日志组和组成

员。为了提高可用性，考虑多重备重做日志文件，类似于多重联机重做日志文件的方式。 

执行下述步骤来配置备重做日志。 

 

第1 步 确保主和备数据库上的日志文件尺寸是相同的。 

当前备重做日志文件的尺寸必须与当前主数据库联机重做日志文件的尺寸完全符合。例如，如果主数据库使用两个联机重做日志组，其日志文件是200K，则备重做日志组也应该是 200K 大小的日志文件。 

 

第2 步 确定备重做日志文件组的适当数目。 

最少地，配置应该比主数据库上的联机重做日志文件组的数目多一个备重做日志文件组。然而，推荐的备重做日志文件组数目依赖于主数据库上的线程数。使用下面的等式来确定备重做日志文件组的适当数目。 

（每个线程的日志文件的最大数目＋1）×线程最大数目 

使用这个等式减少了主实例的日志写（LGWR）进程因为在备数据库上无法分配备重做日志文件而被锁住的可能性。例如，如果主数据库每个线程有 2 个日志文件，并有 2 个线程，则在备数据库上需要有 6 个备重做日志文件组。 

 

注： 

    逻辑备数据库根据工作负载可能需要更多的备重做日志文件（或额外的 ARCn 进程）。这是因为逻辑备数据库也写联机重做日志文件，这优先于备重做日志文件。因此，备重做日志文件可能没有联机重做日志文件归档速度快。同样，查看 5.7.3.1 节。 

 

 

第3 步 检验相关数据库参数和设置。 

检验在SQL CREATE DATABASE 语句上的 MAXLOGFILES 和 MAXLOGMEMBERS 子句使用的值，不会限制你能添加的重做日志文件组和成员。唯一覆盖由 MAXLOGFILES 和 MAXLOGMEMBERS 子句指定的限制的方法就是重建主数据库或控制文件。 

查看Oracle 数据库 SQL 参考和你的操作系统相关 Oracle 文档，以获得默认的

MAXLOGFILES 和 MAXLOGMEMBERS 子句的有效值。 

 

第4 步 创建备重做日志文件组。 

要创建新的备重做日志文件组，你必须拥有ALTER DATABASE 系统权限。备数据库开始使用新创建的备重做数据，下一时刻在主数据库上发生日志切换。例子 3－1 和例子 3 －2 显示了如何使用 ALTER DATABASE 语句和不同的 ADD STANDBY LOGFILE GROUP 子句创建一个新的备重做日志文件组。 

例子3－1 添加一个备重做日志文件组到一个指定的线程下面的语句添加一个新的备重做日志文件组到一个备数据库，并指派到THREAD 5： SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 5

  2> ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M; 

THREAD 子句只有在你想添加一个或更多备重做日志文件组到指定的主数据库线程。

如果你没有包括THREAD 子句并且配置使用 Real Application Clusters（RAC），Data Guard 会在运行时当不同 RAC 实例需要时自动指派备重做日志文件组到线程。 

例子3－2 添加一个备重做日志文件组到一个指定的组号 

你也能使用GROUP 子句指定标识组的号码： 

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10

  2> ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M;

 

使用组号能使得管理备重做日志文件组更容易。然而，组号必须在1 到 MAXLOGFILES 子句的值之间。不要跳过日志文件组号（就是说，不要编号组为 10、20、30、等等），否则你会使用备数据库控制文件中的额外空间。 

 

注： 

    虽然备重做日志只有在数据库运行在备角色时才使用，Oracle 建议你在主数据库上创建一个备重做日志，使得主数据库能快速切换到备角色而不需要额外的 DBA 干涉。考虑使用 Oracle 企业管理器来在你的主和备数据库上自动配置备重做日志。 

 

 

第5 步 检验备重做日志文件组已创建 

要检验备重做日志文件组已创建并正确地运行，在主数据库上调用一个日志切换，然

后查询备数据库上的V$STANDBY_LOG 视图或 V$LOGFILE 视图。例如： 

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM

V$STANDBY_LOG;

 

GROUP#     THREAD#    SEQUENCE# ARC STATUS     

--------- -------- ---------- --- ----------

         3          1           16 NO   ACTIVE              4          0            0 YES UNASSIGNED

         5          0            0 YES UNASSIGNED

 

3.1.4 设置主数据库初始化参数 

在主数据库上，你定义当数据库处于主角色时控制重做传输服务的初始化参数。当主

数据库转换到备角色时，你需要添加额外的参数来控制接收重做数据和日志应用服务。 

例子3－3 显示了你在主数据库上维护的主角色初始化参数，这个例子表现了主数据库位于 Chicago，一个物理备数据库位于 Boston 的 Data Guard 配置。在例子 3－3 中所示的参数对于 Chicago 数据库当它运行在主或备数据库角色时都是有效的。配置举例使用下面表中所示的名字： 

数据库	DB_UNIQUE_NAME	Oracle 网络服务名
主	chicago	chicago
物理备	boston	boston

 

例子3－3 主数据库：主角色初始化参数 

DB_NAME=chicago

DB_UNIQUE_NAME=chicago

LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'

CONTROL_FILES='/arch1/chicago/control1.ctl',

'/arch2/chicago/control2.ctl'

LOG_ARCHIVE_DEST_1=

'LOCATION=/arch1/chicago/ 

  VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

  DB_UNIQUE_NAME=chicago'

LOG_ARCHIVE_DEST_2=

'SERVICE=boston LGWR ASYNC

  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 

  DB_UNIQUE_NAME=boston'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

LOG_ARCHIVE_FORMAT=%t_%s_%r.arc

LOG_ARCHIVE_MAX_PROCESSES=30

 

这些参数控制重做传输服务如何传送重做数据到备系统和本地文件系统上的重做数据

的归档。注意到举例指定了LGWR 进程和异步（ASYNC）网络传输来传送 LOG_ARCHIVE_DEST_2 初始化参数上的重做数据。这些是推荐的设置并且需要备重做日志文件（查看 3.1.3 节，“配置备重做日志”）。 

例子3－4 显示了在主数据库上额外的备角色初始化参数。这些参数在主数据库转换到

备角色时起效果。例子3－4 主数据库：备角色初始化参数 

FAL_SERVER=boston

FAL_CLIENT=chicago

DB_FILE_NAME_CONVERT='boston','chicago'

LOG_FILE_NAME_CONVERT=

'/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chica go/' 

STANDBY_FILE_MANAGEMENT=AUTO

 

如例子 3－4 中所示指定初始化参数设置主数据库来解决中断，从新的主数据库转换新的数据文件和日志文件路径名，并在这个数据库处于备角色时归档收到的重做数据。使用上述主和备角色集的初始化参数，在角色转换后不需要更改任何参数。 

下面表提供了在例子 3－3 和例子 3－4 中所示的每个参数设置相关的简短解释。 

 

参数 推荐设置 

 

DB_NAME	指定一个 8 字符名字。对于所有备数据库使用相同名字。
DB_UNIQUE_NAME	为每个数据库指定一个唯一的名字。这个名字与数据库绑定不会更改，即使主和备数据库交换角色。
LOG_ARCHIVE_CONFIG	在这个参数上指定 DG_CONFIG 属性，以在 Data Guard 配置中列出主和备数据库的 DB_UNIQUE_NAME；这允许动态

添加备数据库到Data Guard 配置，该配置有运行在最大保护或最大可用性模式的 Real Application Clusters 主数据库。默认地，LOG_ARCHIVE_CONFIG 参数运行数据库发送和接收重做；在角色转换之后，你可能需要使用 SEND、NOSEND、

RECEIVE、或 NORECEIVE 关键词再次指定这些设置 

CONTROL_FILES	指定在主数据库上的控制文件的路径名。例子 3－3 显示了如何为两个控制文件指定。推荐使用控制文件的第二个拷贝，使得实例能在拷贝好的控制文件到坏的控制文件位置之后很容易地重启。
LOG_ARCHIVE_DEST_n	指定重做数据在主和备系统上归档的位置。在例子 3－3 中： z LOG_ARCHIVE_DEST_1 归档由主数据库生成的重做数据，从本地联机重做日志文件到在 /arch1/chicago/目录的本地归档重做日志文件。  z LOG_ARCHIVE_DEST_2 只对于主角色有效。这个目的地传送重做数据到远程物理备目的地 boston。 注：如果配置了闪回恢复区域（使用 DB_RECOVERY_FILE_DEST 初始化参数）并且你没有使用 LOCATION 属性显式配置本地归档目的地，Data Guard 自动使用 LOG_ARCHIVE_DEST_10 初始化参数作为本地归档的默认目的地。查看 5.2.3 节以获得更多信息。也查看第 14 章以获得完整的 LOG_ARCHIVE_DEST_n 信息。
LOG_ARCHIVE_DEST_STATE_n	指定 ENABLE 以运行重做传输服务传送重做数据到指定的目的地。
REMOTE_LOGIN_PASSWORDFILE 在主和备数据库上为 SYS 都设置同样的口令。推荐的设置为 EXCLUSIVE 或 SHARED。  LOG_ARCHIVE_FORMAT 使用线程（%t），序列号（%s），和重置日志 ID（%r）指定归档重做日志文件的格式。查看 5.7.1 节以获得其它例子。 LOG_ARCHIVE_MAX_PROCESSES 指定你需要 Oracle 软件初始化调用归档（ARCn）进程的最 =integer 大数目（从 1 到 30）。默认值是 4。查看 5.3.1.2 节以获得 ARCn 处理的更多信息。  FAL_SERVER 指定 FAL 服务器（典型地这是运行在主角色的数据库）的 Oracle 网络服务名。当 chicago 数据库运行在备角色，它使用 boston 数据库作为 FAL 服务器，如果 boston 无法自动发送丢失的日志文件，可以从那里取得（请求）丢失的归档重做日志文件。查看 5.8 节。  FAL_CLIENT 指定 chicago 数据库的 Oracle 网络服务名。FAL 服务器 （boston）拷贝丢失的归档重做日志文件到 chicago 备数据库。查看 5.8 节。  DB_FILE_NAME_CONVERT 在备位置后面指定主数据库文件的路径名和文件名位置。这

个参数将主数据库的数据文件路径名转换成备数据文件路径名。如果备数据库与主数据库处于同一系统上或如果数据文件在备站点上的目录结构与主站点不同，则需要这个参数。注意这个参数只是用于转换物理备数据库的路径名。这个参数可以指定多对路径。 

LOG_FILE_NAME_CONVERT	在备位置后面指定主数据库联机重做日志文件的位置。这个参数将主数据库日志文件的路径名转换成备数据库上的路径名。如果备数据库与主数据库处于同一系统上或如果数据文件在备站点上的目录结构与主站点不同，则需要这个参数。这个参数可以指定多对路径。
STANDBY_FILE_MANAGEMENT	设置为 AUTO 使得当在主数据库上添加或删除数据文件时，相应的更改会自动应用到备数据库。

警告：     为可能需要更改的额外参数检查初始化参数文件。例如，如果在备数据库上的目录位置与在主数据库上指定的不同，你可能需要更改转储目的地参数

（BACKGROUND_DUMP_DEST，CORE_DUMP_DEST，USER_DUMP_DEST）。另外，如果没有已经存在，你可能必须在备系统上创建目录。 

 

 

3.1.5 允许归档 

如果没有允许归档，执行下面的语句将主数据库置于ARCHIVELOG 模式并允许自动归档： 

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE ARCHIVELOG;

SQL> ALTER DATABASE OPEN;

 

查看Oracle 数据库管理员指南以获得归档相关信息。 

 

 

3.2 创建物理备数据库的逐步指导 

本节描述了你执行创建物理备数据库的任务。 

表3－2 提供了你执行创建物理备数据库的任务和你执行每个任务的数据库的检查列表。每个小节还有参考以更详细地描述任务。 

表3－2 创建物理备数据库 

参考	任务	数据库
3.2.1 节	创建主数据库数据文件的备份拷贝	主
3.2.2 节	为备数据库创建控制文件	主
3.2.3 节	为备数据库准备初始化参数文件	主
3.2.4 节	从主系统拷贝文件到备系统	主
3.2.5 节	设置环境以支持备数据库	备
3.2.6 节	启动物理备数据库	备
3.2.7 节	检验物理备数据库正确执行	备

 

3.2.1 创建主数据库数据文件的备份拷贝你能使用主数据库的任何备份拷贝来创建物理备数据库，只要你有必要的归档重做日志文件来完全恢复数据库。Oracle 推荐你使用恢复管理工具（RMAN）。 

查看Oracle 高可用性体系结构以获得备份推荐和 Oracle 数据库备份和恢复高级用户指南来执行 RMAN 备份操作。 

 

3.2.2 为备数据库创建控制文件 

如果备份过程需要你关闭主数据库，执行下面的SQL*Plus 语句来启动主数据库： 

SQL> STARTUP MOUNT;

 

然后，为备数据库创建控制文件，并打开主数据库允许用户访问，如下面举例所示： 

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl';

SQL> ALTER DATABASE OPEN;

 

 

注： 

    对于主和备数据库你不能使用单个控制文件。 

 

 

3.2.3 为备数据库准备初始化参数文件 

执行下面的步骤来创建备初始化参数文件。 

 

第1 步 拷贝主数据库参数文件到备数据库。 

从主数据库使用的服务器参数文件（SPFILE）创建一个文本初始化参数文件；文本初始化参数文件能拷贝到备位置并修改。例如： 

SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;

 

后面，在3.2.5 节，在修改这个文件以包含适用于物理备数据库的参数值之后，你将这个文件转换回服务器参数文件。 

 

第2 步 在物理备数据库上设置初始化参数 

虽然在你从主系统拷贝来的文本初始化参数文件中的大多数初始化参数设置也适用于物理备数据库，但是需要进行一些修改。 

例子3－5 显示了备初始化参数文件中部分，对于物理备数据库进行的修改。与例子 3 －3 和例子 3－4 中不同的参数值以粗体所示。在例子 3－5 中所示的参数在 boston 数据库运行于主或备数据库角色时都是有效的。 

例子3－5 为物理备数据库修改初始化参数 

.

.

.

DB_NAME=chicago

DB_UNIQUE_NAME=boston

LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'

CONTROL_FILES='/arch1/boston/control1.ctl',

'/arch2/boston/control2.ctl'

DB_FILE_NAME_CONVERT='chicago','boston' LOG_FILE_NAME_CONVERT='/arch1/chicago/','/arch1/boston/','/arch2/ chicago/','/arch2/boston/' LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc

LOG_ARCHIVE_DEST_1=

'LOCATION=/arch1/boston/

  VALID_FOR=(ALL_LOGFILES,ALL_ROLES) 

  DB_UNIQUE_NAME=boston'

LOG_ARCHIVE_DEST_2=

'SERVICE=chicago LGWR ASYNC

  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 

  DB_UNIQUE_NAME=chicago'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

STANDBY_FILE_MANAGEMENT=AUTO

FAL_SERVER=chicago

FAL_CLIENT=boston

.

.

.

 

注意该例子假设使用LGWR 进程来传送重做数据到本地和在 LOG_ARCHIVE_DEST_2

初始化参数上的远程目的地。另外，确保在主和备数据库上设置COMPATIBLE 初始化参数为相同值。如果该值不同，

重做传输服务可能无法从主数据库传送重做数据到备数据库。在Data Guard 配置中，

COMPATIBLE 必须设为最小值 9.2.0.1.0。然而，如果你想利用新的 Oracle 数据库 10g 的特性，设置 COMPATIBLE 参数为 10.2.0.0 或更高。 

使用SHOW PARAMETERS命令来检查没有其它的参数需要更改总是一个很好的习惯。下面的表提供了在例子 3－5 中所示的与主数据库不同设置的参数设置的简要解释。 

 

参数 推荐设置 

 

DB_UNIQUE_NAME 为这个数据库指定唯一的名字。这个名字与数据库绑定不会更改，即使主和备数据库交换角色。 

CONTROL_FILES 指定在主数据库上的控制文件的路径名。例子 3－3 显示了如何为两个控制文件指定。推荐使用控制文件的第二个拷贝，使得实例能在拷贝好的控制文件到坏的控制文件位置之后很容易地重启。 

DB_FILE_NAME_CONVERT 在备位置后面指定主数据库文件的路径名和文件名位置。这个参数将主数据库的数据文件路径名转换成备数据文件路径名。如果备数据库与主数据库处于同一系统上或如果数据文件在备站点上的目录结构与主站点不同，则需要这个参数。 

LOG_FILE_NAME_CONVERT 在备位置后面指定主数据库联机重做日志文件的位置。这个参数将主数据库日志文件的路径名转换成备数据库上的路径名。如果备数据库与主数据库处于同一系统上或如果数据文件在备站点上的目录结构与主站点不同，则需要这个参数。 

LOG_ARCHIVE_DEST_n 指定重做数据归档的位置。在例子 3－5 中： 

z LOG_ARCHIVE_DEST_1 归档从主数据库收到的重做数据到/arch1/boston/目录中的归档重做日志文件。 

z LOG_ARCHIVE_DEST_2 当前被忽略，因为这个目的地只对主角色有效。如果发生了切换并且这个实例成为主数据库，则会传送重做数据到远程 chicago 目的地。 

注：如果配置了闪回恢复区域（使用DB_RECOVERY_FILE_DEST 初始化参数）并且你没有使用 LOCATION 属性显式配置本地归档目的地，Data Guard 自动使用 LOG_ARCHIVE_DEST_10 初始化

参数作为本地归档的默认目的地。查看5.2.3 节以获得更多信息。

也查看第 14 章以获得完整的 LOG_ARCHIVE_DEST_n 信息。 

FAL_SERVER	指定 FAL 服务器（典型地这是运行在主角色的数据库）的 Oracle 网络服务名。当 boston 数据库运行在备角色，它使用 chicago 数据库作为 FAL 服务器，如果 chicago 无法自动发送丢失的日志文件，可以从那里取得（请求）丢失的归档重做日志文件。查看 5.8 节。
FAL_CLIENT	指定 boston 数据库的 Oracle 网络服务名。FAL 服务器（chicago）拷贝丢失的归档重做日志文件到 boston 备数据库。查看 5.8 节。

警告：     为可能需要更改的额外参数检查初始化参数文件。例如，如果在备数据库上的目录位置与在主数据库上指定的不同，你可能需要更改转储目的地参数

（BACKGROUND_DUMP_DEST，CORE_DUMP_DEST，USER_DUMP_DEST）。另外，如果没有已经存在，你可能必须在备系统上创建目录。 

 

 

3.2.4 从主系统拷贝文件到备系统 

使用操作系统拷贝工具将下面的二进制文件从主系统拷贝到备系统： z 在 3.2.1 节中创的备份数据文件 z 在 3.2.2 节中创建的备控制文件 z 在 3.2.3 节中创建的初始化参数 

 

3.2.5 设置环境以支持备数据库 

执行下面的步骤以创建一个基于Windows 的服务，创建一个口令文件，设置 Oracle 网络环境，以及创建一个 SPFILE。 

 

第1 步 创建一个基于 Windows 的服务。 

如果备系统是运行在基于Windows 的系统上，使用 ORADIM 工具来创建 Windows 服务和口令文件。例如： 

WINNT> oradim -NEW -SID boston -INTPWD password -STARTMODE manual

 

查看Oracle 数据库 Microsoft Windows(32-Bit)平台指南以获得使用 ORADIM 工具的相关信息。 

 

第2 步 创建一个口令文件。 

 

在Windows 以外的平台上，创建一个口令文件，然后为 SYS 用户设置与在主数据库上的 SYS 用户相同的口令。为了成功传输重做，在 Data Guard 配置中的每个数据库上的 SYS 用户的口令都必须相同。查看 Oracle 数据库管理员指南。 

 

第3 步 为主和备数据库配置监听。 

在主和备站点上，使用Oracle 网络管理器为相关数据库配置监听。 

要启动监听（获得新的定义），在主和备系统上输入下面的LSNRCTL 工具命令： 

% lsnrctl stop

% lsnrctl start

 

查看Oracle 数据库网络服务管理员指南。 

 

第4 步 创建 Oracle 网络服务名。 

在主和备系统上，使用Oracle 网络管理器来为主和备数据库创建网络服务名，为重做传输服务所使用。 

Oracle 网络服务名必须解析一个连接描述符，使用当你为主和备数据库配置监听器时指定的同样的协议、主机地址、端口、和服务。连接描述符也必须指定使用专用服务器。 

查看Oracle 数据库网络服务管理员指南和 Oracle 数据库管理员指南。 

 

第5 步 为备数据库创建一个服务器参数文件。 

在一个空闲的备数据库上，使用SQL CREATE 语句来从步骤 2 中编辑的文本初始化参数文件，为备数据库创建一个服务器参数文件。例如： 

SQL> CREATE SPFILE FROM PFILE='initboston.ora';

 

3.2.6 启动物理备数据库 

执行下面的步骤来启动物理备数据库和重做应用。 

 

第1 步 启动物理备数据库。 

在备数据库上，执行下面的SQL 语句来启动和安装数据库： 

SQL> STARTUP MOUNT;

 

第2 步 启动重做应用。 

在备数据库上，执行下面的命令来启动重做应用： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM

SESSION;

 

该语句包含DISCONNECT FROM SESSION 选项，使得重做应用运行在后台会话中。

查看6.3 节，“应用重做数据到物理备数据库”以获得更多信息。 

 

第3 步 测试归档操作到物理备数据库。 

在这个例子中，直到日志切换之后，重做数据到远程备位置的传输才会发生。默认地，当联机重做日志文件满的时候，日志切换发生。要强制日志切换，使得重做数据立即传送，在主数据库上使用下面的ALTER SYSTEM 语句。例如： 

SQL> ALTER SYSTEM SWITCH LOGFILE;

 

3.2.7 检验物理备数据库正确执行 

一旦你创建物理备数据库并设立重做传输服务，你可能需要检查数据库更改成功地被

从主数据库传送到备数据库。要在备数据库上看到接收到重做数据，你首先应该在备数据库上确认现有的归档重做

日志文件，在主数据库上强制日志切换并归档一些联机重做日志文件，然后再次检查备数据库。下面的步骤显示如何执行这些任务。 

 

第1 步 确认现有的归档重做日志文件。 

在备数据库上，查询V$ARCHIVED_LOG 视图以确认归档重做日志中现有的文件。例

如： 

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

2 FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

 

SEQUENCE# FIRST_TIME           NEXT_TIME

---------- ------------------ ------------------            8 11-JUL-02 17:50:45 11-JUL-02 17:50:53

9 11-JUL-02 17:50:53 11-JUL-02 17:50:58

10 11-JUL-02 17:50:58 11-JUL-02 17:51:03

 

3 rows selected.

 

第2 步 强制日志切换以归档当前的联机重做日志文件。 

打开主数据库，执行ALTER SYSTEM SWITCH LOGFILE 语句以强制日志切换并归档

当前联机重做日志文件组： 

SQL> ALTER SYSTEM SWITCH LOGFILE;

 

第3 步 在备数据库上检查新的重做数据已归档。 

在备数据库上，查询V$ARCHIVED_LOG 视图来检查重做数据已收到并归档到被数据

库： 

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

  2>  FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

 

SEQUENCE# FIRST_TIME         NEXT_TIME

---------- ------------------ ------------------

8 11-JUL-02 17:50:45 11-JUL-02 17:50:53

9 11-JUL-02 17:50:53 11-JUL-02 17:50:58

10 11-JUL-02 17:50:58 11-JUL-02 17:51:03

11 11-JUL-02 17:51:03 11-JUL-02 18:34:11 4 rows selected.

 

归档的重做日志文件现在可以应用到物理被数据库上了。 

 

第4 步 检查新归档的重做日志文件已应用。 

在备数据库上，查询V$ARCHIVED_LOG 视图来检查归档重做日志文件已应用。 

SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG

  2  ORDER BY SEQUENCE#;

 

SEQUENCE# APP

--------- ---

8 YES

9 YES

10 YES

11 YES

 

4 rows selected.

 

查看5.9.1 节，“监控日志文件归档信息”和 8.5.4 节，“监控在物理备数据库上的日志应用服务”来检查重做传输服务和日志应用服务正确工作。 

 

 

3.3 创建后的步骤 

在这个时候，物理备数据库已运行并能够提供最大性能级别的数据保护。下面的列表描述了你能在物理备数据库上进行的额外准备： z 升级数据包含模式 

Data Guard 配置初始化是设置为最大性能模式（默认）。查看 5.6 节以获得数据保护模式和如何升级或降级当前保护模式的相关信息。 

z 允许 Flashback 数据库 

Flashback 数据库消除了在故障转移之后重建主数据库的需求。Flashback 数据库允许你将数据库返回到最近的过去时间的状态，比传统的基于时间点的恢复要快很多，因为它不需要从备份中恢复数据文件，也不需要大量地应用重做数据。你能在主数据库上、备数据库上、或两者都允许 Flashback 数据库。查看 12.4 节和 12.5 节以获得显示如何在 Data Guard 环境中使用 Flashback 数据库的场景。同时，查看 Oracle 数据库备份和恢复高级用户指南以获得 Flashback 数据库的更多相关信息。 

 

 

4 创建逻辑备数据库 

 

本章逐步指导你创建逻辑备数据库。它包括下述主要主题： z 创建逻辑备数据库的先决条件 z 创建逻辑备数据库的逐步指导 z 创建后的步骤 

 

 

同时查看： z Oracle 数据库管理员指南以获得创建和使用服务器参数文件相关信息 

z Oracle Data Guard Broker 和 Oracle 企业管理器联机帮助系统以获得使用图形用户界面自动创建逻辑备数据库相关信息 

 

 

 

4.1 创建逻辑备数据库的先决条件 

在你创建逻辑备数据库之前，你必须首先确保正确地配置好主数据库。表 4－1 提供了你在主数据库上执行的为逻辑备数据库创建准备的任务的检查列表。每小节还有相关参考更详细地描述任务。 

表4－1 为逻辑备数据库创建准备主数据库 

参考	任务
4.1.1 节	确定对于表的数据类型和存储属性的支持
4.1.2 节	确保在主数据库中的表行能被唯一标识

 

4.1.1 确定对于表的数据类型和存储属性的支持 

在设置逻辑备数据库之前，确保逻辑备数据库能维护在你的主数据库中的数据类型和表。查看附录 C 以获得数据类型和存储类型考虑的完整列表。 

 

4.1.2 确保在主数据库中的表行能被唯一标识 

在逻辑备数据库中的物理组织不同于主数据库，即使逻辑备数据库是从主数据库的备份拷贝中创建。这样，由主数据库生成的重做记录中包含的ROWID 无法用于标识在逻辑备数据库中相应的行。 

Oracle 使用主键或唯一约束/索引补充记录来逻辑地标识在逻辑备数据库中被更改的行。当允许数据库范围的主键和唯一约束/索引补充记录时，每个 UPDATE 语句也写必要的列值到重做日志，以在逻辑备数据库中唯一地标识被更改的行。 

z 如果表定义了主键，则主键与被更改的列一起记录，作为 UPDATE 语句的一部分来标识更改的行。 

z 如果没有主键，则最短的非空唯一约束/索引与更改的行一起记录，作为 UPDATE 语句的一部分来标识更改的行。 

z 如果即没有主键也没有非空唯一约束/索引，则所有有界限大小的列作为 UPDATE 语句的一部分记录，以标识更改的行。换一句话说，记录所有列除了：LONG、LOB、

LONG RAW、对象类型、和集合。 

Oracle 推荐你在主数据库中添加一个主键或非空唯一索引，只要可能，确保 SQL 应用能有效地应用重做数据库更新到逻辑备数据库。 

执行下面的步骤来确保SQL 应用能唯一地标识在逻辑备数据库中被复制的每个表的行。 

 

第1 步 在主数据库中找到没有唯一逻辑标识符的表。 

查询DBA_LOGSTDBY_NOT_UNIQUE 视图来显示 SQL 应用可能无法唯一标识的表的列表。例如： 

SQL> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE

  2> WHERE (OWNER, TABLE_NAME) NOT IN 

  3> (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) 

  4> AND BAD_COLLUMN = 'Y'

 

第2 步 添加一个禁用主键 RELY 约束 

如果你的应用确保表中的行是唯一的，则你能在表上创建一个禁止的主键RELY 约束。这能避免在主数据库上维护主键的开销。 

要在主数据库表上创建一个禁止的RELY 约束，使用带 RELY DISABLE 子句的 ALTER TABLE 语句。下面的例子在名为 mytab 的表上创建了一个禁止的 RELY 约束，每一行都能使用 id 和 name 列唯一标识： 

SQL> ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;

 

当你指定RELY 约束时，系统将假设行是唯一的。因为你告诉系统依靠该信息，但是在每次更改表时不会去确认，所以对于将唯一标识表中的每一行的禁止的 RELY 约束，你必须小心查询列。如果这样的唯一性不存在，则 SQL 应用将无法正确地维护该表。 

要提高SQL 应用的性能，在逻辑备数据库上添加一个唯一约束/索引到列上以标识行。如果添加失败会导致 SQL 应用在表上进行的 UPDATE 或 DELETE 语句时进行全表扫描。 

 

同时查看： 

z 查看 Oracle 数据库参考以获得 DBA_LOGSTDBY_NOT_UNIQUE 视图的相关信息 z Oracle 数据库 SQL 参考以获得 ALTER TABLE 语句语法和创建 RELY 约束相关信息 

z 9.6.1 节，“创建主键 RELY 约束”以获得 RELY 约束和你增加逻辑备数据库性能所采取措施相关信息 

 

 

 

4.2 创建逻辑备数据库的逐步指导 

本小节描述了你创建逻辑备数据库所执行的任务。 

表－2 提供了你创建逻辑备数据库和指定在哪个数据库上执行每个任务的任务列表。

每小节还有相关参考更详细地描述任务。 

表－2 创建逻辑备数据库 

 

参考 任务 数据库 

4.2.4 节 转换到逻辑备数据库 备 

4.2.5 节 打开逻辑备数据库 备 

4.2.6 节 检查逻辑备数据库正确执行 备 

 

 

4.2.1 创建物理备数据库 

你创建逻辑备数据库，首先创建物理备数据库然后将其转换成逻辑备数据库。遵循第 3 章，“创建物理备数据库”中的指导来创建物理备数据库。 

 

4.2.2 在物理备数据库上停止重做应用 

你能在将新的物理备数据库转换成逻辑备数据库之前在上面运行任何长度时间的重做应用。然而，在转换到逻辑备数据库之前，在物理备数据库上停止重做应用。停止重做应用是必要的，可以避免应用在包含LogMiner 字典的重做之后的更改（在 4.2.3.2 节，“在重做数据中建立字典”中描述）。 

要停止重做应用，在物理备数据库上执行下面的语句。如果数据库是包含多个实例的

RAC 数据库，则你在执行这个命令之前必须首先停止除了一个以外的所有 RAC 实例： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

 

4.2.3 准备主数据库以支持逻辑备数据库 

本小节包含下面主题： z 为角色转换准备主数据库 z 在重做数据中建立字典 

 

4.2.3.1 为角色转换准备主数据库 

在3.1.4 节，“设置主数据库初始化参数”中，你设置多个备角色初始化参数以在主数据库转换到物理备角色时起作用。如果你计划转换主数据库到逻辑备角色，则你还必须在主数据库上包含LOG_ARCHIVE_DEST_3 目的地，如例子 4－1 中所示，使得在角色转换之后不需要更改参数。这个参数只有在主数据库转换到备角色时才起作用。 

例子4－1 主数据库：逻辑备角色初始化参数 

LOG_ARCHIVE_DEST_3=

'LOCATION=/arch2/chicago/

  VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) 

  DB_UNIQUE_NAME=chicago'

LOG_ARCHIVE_DEST_STATE_3=ENABLE

 

要动态设置LOG_ARCHIVE_DEST_3 参数，使用 SQL ALTER SYSTEM SET 语句并包含 SCOPE=BOTH 子句，使得更改立即起作用并在数据库关闭并再次启动后还保持。 

下面的表描述了由例子 4－1 中所示初始化参数定义的归档进程。 

当 chicago 数据库运行在主角色	当 chicago 数据库运行在逻辑备角色
LOG_ARCHIVE_DEST_3 被忽略；LOG_ARCHIVE_DEST_3 只有在 chicago 运行在被角色时才有效。	归档从主数据库接收到的重做数据到 /arch2/chicago/上的本地归档重做日志文件。

4.2.3.2 在重做数据中建立字典 

LogMiner 必须建立到重做数据中，使得 SQL 应用的 LogMiner 组件能正确地解释它在重做中看到的更改。作为建立 LogMiner Multiversioned Data Dictionary 的一部分，追加的记录自动设置以记录主键和唯一约束/索引列。追加的记录信息确保每次更新包含足够的信息以逻辑地标识由语句更改的每一行。 

要建立LogMiner 字典，执行下面语句： 

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

 

DBMS_LOGSTDBY.BUILD 过程等待所有现有的事务完成。在主数据库上执行的长时间运行的事务将会影响这条命令的完成时间。 

DBMS_LOGSTDBY.BUILD 过程使用 Flashback 查询来获得数据字典的一致性快照，然后数据字典记录到重做流中。Oracle 推荐在主和逻辑备数据库上设置 UNDO_RETENTION 初始化参数都为 3600。 

 

同时查看： 

    在 Oracle 数据库 PL/SQL 包和类型参考中的 DBMS_LOGSTDBY.BUILD PL/SQL 包和在

Oracle 数据库参考中的 UNDO_RETENTION 初始化参数 

 

 

4.2.4 转换到逻辑备数据库 

本小节描述了如何准备物理备数据库来转换到逻辑备数据库。包含下面主题： z 转换到逻辑备数据库 z 创建新的口令文件 

z 为逻辑备数据库调整初始化参数 

 

4.2.4.1 转换到逻辑备数据库 

重做日志包含转换你的物理备数据库到逻辑备数据库必要的信息。要继续应用重做数据到物理备数据库指导其准备好转换为逻辑备数据库，执行下面的SQL 语句： 

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name;

 

对于db_name，指定一个数据库名字以标识新的逻辑备数据库。如果你在执行这条语句的时候使用服务器参数文件（spfile），则数据库会使用新的逻辑备数据库相关的适当信息更

新该文件。如果你没有使用spfile，则数据库会发出一条信息提示你在关闭数据库后设置

DB_NAME 参数的名字。 

该语句等待应用重做数据，直到在日志文件中找到LogMiner 字典。这可能会花费几分钟，依赖于在 4.2.3.2 节，“在重做数据中建立字典”中生成的重做多久才能传送到备数据库，以及需要应用多少重做数据库。如果字典建立没能在主数据库上成功执行，这条命令将永远不会完成。你能通过在另外的 SQL 会话中执行 ALTER DATABASE RECOVER MANANGED

STANDBY DATABASE CANCEL 语句来取消该 SQL 语句。 

 

4.2.4.2 创建新的口令文件 

因为转换过程对于逻辑备数据库更改了数据库名字（原先以DB_NAME 初始化参数设置），所以你必须重建口令文件。查看 Oracle 数据库管理员指南以获得创建安全认证方案上的更多信息。 

4.2.4.3 为逻辑备数据库调整初始化参数在逻辑备数据库上，关闭实例并执行STARTUP MOUNT 语句来启动并安装数据库。不

要打开数据库；它对于用户访问应该保持关闭，直到后面的创建过程。例如： 

SQL> SHUTDOWN;

SQL> STARTUP MOUNT;

 

你需要修改LOG_ARCHIVE_DEST_n 参数，因为不像物理备数据库，逻辑备数据库是

打开的数据库，生成重做数据并有多个日志文件（联机重做日志文件，归档重做日志文件，和备重做日志文件）。指定分开的本地目的地是一个很好的习惯： z 存储由逻辑备数据库生成的重做数据的归档重做日志文件。在例子 4－2 中，这配置为 LOG_ARCHIVE_DEST_1=LOCATION=/arch1/boston 目的地。 

z 存储从主数据库接收到的重做数据的归档重做日志文件。在例子 4－2 中，这配置为 LOG_ARCHIVE_DEST_3=LOCATION=/arch2/boston 目的地。 

例子4－2 显示了为逻辑备数据库修改的初始化参数更改。所示的参数对于 boston 逻辑

备数据库是有效的，不管其是运行在主还是备数据库角色。 

例子4－2 为逻辑备数据库修改初始化参数 

LOG_ARCHIVE_DEST_1=

  'LOCATION=/arch1/boston/

   VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)

   DB_UNIQUE_NAME=boston'

LOG_ARCHIVE_DEST_2=

  'SERVICE=chicago LGWR ASYNC

   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)

   DB_UNIQUE_NAME=chicago'

LOG_ARCHIVE_DEST_3=

  'LOCATION=/arch2/boston/

   VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)

   DB_UNIQUE_NAME=boston'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

LOG_ARCHIVE_DEST_STATE_3=ENABLE

 

下面的表描述了由例子 4－2 中所示的初始化参数定义的归档过程。 

	当 boston 数据库运行在主角色时	当 boston 数据库运行在逻辑备角色时
LOG_ARCHIVE_DEST_1	指导由主数据库生成的重做数据从 本地联机重做日志文件到 /arch1/boston/中的本地归档重做日志文件的归档	指导由逻辑备数据库生成的重做数据 从本地联机重做日志文件到 /arch1/boston/中的本地归档重做日志文件的归档
LOG_ARCHIVE_DEST_2	指导重做数据到远程逻辑备数据库 chicago 的传输。	被忽略；LOG_ARCHIVE_DEST_2 只有在 boston 运行在主角色时才有效。
LOG_ARCHIVE_DEST_3	被忽略；LOG_ARCHIVE_DEST_3 指导从主数据库接收到的重做数据到 只有在 boston 运行在被角色时才有 /arch2/boston/中的本地归档重做日志文效。 件的归档。

 

注： 

    一旦物理备数据库转换到逻辑备数据库，DB_FILE_NAME_CONVERT 初始化参数就无法兑现了。如果必要，你应该注册一个忽略处理器，通过转换主数据库数据文件的名字到备数据库数据文件路径名，给 SQL 应用提供一个替代的 DDL 串来执行。查看 Oracle 数据库

PL/SQL 包和类型参考中的 DBMS_LOGSTDBY 包以获得更多的 SKIP 过程相关信息。 

 

 

4.2.5 打开逻辑备数据库 

新的数据库与你的主数据库在逻辑上是一样的，但是它在事务上与主数据库不一致，因而对于恢复操作是不相容的。 

要打开新的逻辑备数据库，你必须通过执行下面的语句以RESETLOGS 选项来打开： 

SQL> ALTER DATABASE OPEN RESETLOGS;

 

因为这是数据库第一次打开，所以数据的全局名自动调整以符合新的DB_NAME 初始化参数。 

执行下面的语句来开始应用重做数据库到逻辑备数据库。例如： 

SQL>  ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

 

4.2.6 检查逻辑备数据库正确执行 

为了帮助检查逻辑备数据库正确执行，查看下面小节： z 5.9.1 节，“监控日志文件归档信息” 

z 6.4.3 节，“在逻辑备数据库上监控 SQL 应用” z 第 9 章，“管理逻辑备数据库” 

 

 

4.3 创建后的步骤 

在这个时候，逻辑备数据库已经运行并能提供最大性能级别的数据保护。下面的列表描述了你能在逻辑备数据库上进行的额外的准备： z 升级数据保护模式 

Data Guard 配置初始设置为最大性能模式（默认）。查看 5.6 节，“设置数据保护模式”以获得数据保护模式和如何升级或降级当前保护模式相关的信息。 

z 允许 Flashback 数据库 

Flashback 数据库消除了在故障转移之后重建主数据库的需求。Flashback 数据库允许你将数据库返回到最近的过去时间的状态，比传统的基于时间点的恢复要快很多，因为它不需要从备份中恢复数据文件，也不需要大量地应用重做数据。你能在主数据库上、备数据库上、或两者都允许 Flashback 数据库。查看 12.4 节，“在故障转移后使

用Flashback 数据库”和 12.5 节，“在执行 open resetlogs 语句后使用 Flashback 数据库” 以获得显示如何在 Data Guard 环境中使用 Flashback 数据库的场景。同时，查看 Oracle 数据库备份和恢复高级用户指南以获得 Flashback 数据库的更多相关信息。 

 

 

5 重做传输服务 

 

本章描述了如何配置重做传输服务从一个生产数据库传送重做到一个或更多目的地。

它包含下面主题： z 重做传输服务介绍 z 发送重做数据到哪里 z 如何发送重做数据 z 应该何时发送重做数据 z 如果出现错误如何应对 z 设置数据保护模式 z 管理日志文件 z 管理归档中断 z 核查 

 

 

5.1 重做传输服务介绍 

重做传输服务控制从数据库目的地到一个或更多目的地的重做数据的自动化转移。重做传输服务也管理解决由于网络故障导致归档重做日志文件中断的过程。 

重做传输服务能传送重做数据到本地和远程目的地。远程目的地能包括任何下面类型：物理和逻辑备数据库，归档重做日志档案资料库，Oracle Change Data Capture 分段运输数据库，和 Oracle Streams 下游捕获数据库。 

图－1 显示了一个简单的 Data Guard 配置，重做传输服务归档重做数据到在主数据库上的本地目的地，同时也传送到在远程备数据库目的地上的归档重做日志文件或备重做日志文件。 

图5－1 传送重做数据 

 

 

 

z 如何发送重做数据 z 设置闪回恢复区域 

 

5.2.1 目的地类型 

重做传输服务支持多种类型的目的地： z Oracle Data Guard 备数据库 

备数据库目的地既能是物理备数据库也能是逻辑备数据库。1.1.2 节讨论了备数据库。 

z 归档重做日志档案资料库 

这种类型目的地允许离站点归档重做数据。归档日志档案资料库是使用物理备控制文件、启动实例、并安装数据库创建的。这个数据库不包含数据文件并且不能用于切换或故障转移。这种替代方法作为短时间内，可能是一天，保留归档重做日志的方法是很有用的，然后日志文件能够被删除，。这避免了另外全配置的备数据库的绝大多数存储和处理过程代价。 

Oracle 推荐使用归档重做日志档案资料库作为归档重做日志文件的临时存储。这能通过在运行于最大性能模式的 Data Guard 配置中为基于归档的传输（使用

LOG_ARCHIVE_DEST_n 参数上的 ARCH 属性）配置档案资料库目的地来完成。对于无数据丢失的环境，你应该使用全配置的备数据库，在 Data Guard 配置中使用 LGWR、

SYNC、和 AFFIRM 传输设置以及运行在最大保护模式或最大可用性模式。 

z Oracle Streams 实时下游捕获数据库 

这种目的地类型允许Oracle Streams 在远程下游数据库上配置一个捕获进程。

Streams 下游捕获进程使用重做传输服务来传送重做数据到下游数据库，在那里 Streams 捕获进程捕获在远程目的地上的备重做日志文件和归档重做日志文件中的更改。查看

Oracle Streams 概念和管理以获得更多信息。 

z Oracle Change Data Capture 分段运输数据库 

这种目的地类型远程支持在分段运输数据库上的Oracle Change Data Capture

Asynchronous AutoLog 配置。使用重做传输服务将重做数据从源数据库拷贝到分段运输数据库上。Change Data Capture 配置捕获从重做数据中的更改。查看 Oracle 数据库数据仓库指南以获得更多信息。 

为了讨论目的，本指南称生产数据库为主数据库，归档目的地为备数据库（如1.1 节中定义）。如果你使用 Oracle Change Data Capture，分别将术语源和分段运输数据库替换为主和备数据库。如果你使用 Oracle Streams，分别将术语源和下游捕获数据库替换为主和备数据库。 

 

5.2.2 使用 LOG_ARCHIVE_DEST_n 参数配置目的地 

LOG_ARCHIVE_DEST_n 初始化参数最多定义 10（n=1,2,3,…10）个目的地，每个必须指定 LOCATION 或 SERVICE 属性来指定归档重做数据到哪里。 

LOCATION和SERVICE属性描述了本地磁盘位置或代表一个重做传输服务将会传送重做数据的备目的地的Oracle网络服务名。使用SERVICE属性指定远程目的地允许Data Guard 维护一个主数据库的事务一致性远程拷贝，以用于灾难恢复。 

对于你定义的每个LOG_ARCHIVE_DEST_n 初始化参数，指定相应的

LOG_ARCHIVE_DEST_STATE_n 参数。LOG_ARCHIVE_DEST_STATE_n（n 是从 1 到 10 的整数）初始化参数指定相应的目的地当前是开（允许）还是关（禁止）。表 5－1 描述了

LOG_ARCHIVE_DEST_STATE_n 参数属性。 

表5－1 LOG_ARCHIVE_DEST_STATE_n 初始化参数属性 

属性	描述
ENABLE	重做传输服务能传送重做数据到这个目的地。这是默认值。
DEFER	重做传输服务将不会传送重做数据到这个目的地。这是有效但没有使用的目的地。
ALTERNATE	这个目的地没有被允许，但是如果到其相关的目的地的连接故障了则它将变成允许。
RESET	与 DEFER 的功能相同，但是如果以前发生故障则为目的地清理任何错误信息。

 

例子5－1 提供了使用 LOCATION 属性的一个目的地的例子。 

例子5－1 指定本地归档目的地 

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

 

图5－2 显示了这个简单的配置，包含单个本地目的地，看起来是什么样的。日志写进程写重做数据到联机重做日志文件。当每个联机重做日志写满时，发生日志切换并且 ARCn 进程归档写满的联机重做日志文件到归档重做日志文件。写满的联机重做日志文件现在又可以重用了。 

图5－2 当没有备数据库时的主数据库归档 

 

 

很重要的一点是在图 5－2 中所示的配置没有包括备数据库，因而不提供灾难恢复保护。要使得这个简单配置变为提供灾难恢复的 Data Guard 配置，通过指定 SERVICE 属性在远程目的地添加一个备数据库。 

例子5－2 显示了允许重做传输服务在本地目的地 chicago 归档联机重做日志并传送重做数据到使用 Oracle 网络服务名 boston 远程备数据库的初始化参数。该例子对于所有的其它 LOG_ARCHIVE_DEST_n 属性使用了默认值。 

例子5－2 指定远程归档目的地 

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_2='SERVICE=boston'

LOG_ARCHIVE_DEST_STATE_2=ENABLE

 

这些初始化参数设置了使用归档（ARCn）进程归档本地和远程目的地的 Data Guard 配

置。这种配置提供了最大性能级别的数据保护。 

虽然你能仅仅通过在LOG_ARCHIVE_DEST_n 参数上指定 LOCATION 或 SERVICE 属

性创建Data Guard 配置，但是你也能选择指定更多的属性来进一步定义每个目的地的行为。第 14 章提供了所有 LOG_ARCHIVE_DEST_n 参数属性的参考信息。 

 

5.2.2.1 更改目的地属性你能使用ALTER SYSTEM SET 语句动态更新 LOG_ARCHIVE_DEST_n 和 LOG_ARCHIVE_DEST_STATE_n 参数的大多数属性。 

更改在主数据库上的下一次日志切换生效。例如，要延迟日志传输服务传送重做数据

到名为boston 的远程备数据库，在主数据库上执行下面的语句： 

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=boston 

  2> VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)';

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

 

5.2.2.2 使用 V$ARCHIVE_DEST 查看属性查询V$ARCHIVE_DEST 视图以查看 LOG_ARCHIVE_DEST_n 初始化参数的当前设

置。 

 

5.2.3 设置闪回恢复区 

Oracle 数据库允许你配置一块磁盘区域称为闪回恢复区，是一个目录或Oracle 存储管理磁盘，用于恢复相关文件的默认存储区域。 

要配置闪回恢复区，使用DB_RECOVERY_FILE_DEST 初始化参数。如果你创建一个

闪回恢复区但没有设置任何其它的本地归档目的地，则LOG_ARCHIVE_DEST_10 被隐式地设置为 USE_DB_RECOVERY_FILE_DEST（意味着归档重做日志文件将会被设置到闪回恢复区）。（查看 Oracle 数据库备份和恢复基础来配置闪回恢复区，以及 Oracle 数据库管理员指南以获得 Oracle 存储管理器和 Oracle 管理文件更多相关信息。） 

 

注：     存储在闪回恢复区的归档重做日志文件的文件名是由 Oracle 管理文件（OMF）自动生成的；这些文件名不是基于由 LOG_ARCHIVE_FORMAT 初始化参数指定的格式。 

 

 

本小节包含下述主题： 

z 使用 LOG_ARCHIVE_DEST_10 目的地 z 使用其它 LOG_ARCHIVE_DEST_n 目的地 z 使用 STANDBY_ARCHIVE_DEST 目的地 z 在主和备数据之间共享闪回恢复区 

注：     主数据库不能写重做数据到逻辑备数据库的闪回恢复区。 

 

 

查看Oracle 数据库备份和恢复基础来配置闪回恢复区，以及 10.3.4 节以获得在闪回恢

复区设置归档重做日志文件的删除策略。 

 

5.2.3.1 使用 LOG_ARCHIVE_DEST_10 目的地如果已经配置了闪回恢复区并且没有定义本地目的地，Data Guard 隐式使用 LOG_ARCHIVE_DEST_10 目的地作为闪回恢复区。 

当使用LOG_ARCHIVE_DEST_10 参数时，Data Guard 自动使用所有

LOG_ARCHIVE_DEST_10 属性的默认值。要覆盖默认值，你能通过显式指定 LOG_ARCHIVE_DEST_10 参数动态设置大多数属性。例如，下面的 ALTER SYSTEM SET 语句在 LOG_ARCHIVE_DEST_10 初始化参数上指定了多个属性。 

SQL> ALTER SYSTEM SET

LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST LGWR

MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'

 

当设置LOG_ARCHIVE_DEST_n 属性时，LOG_ARCHIVE_DEST_n 参数的 TEMPLATE 属性将会覆盖闪回恢复区的所有其它配置，归档重做日志文件将会使用由 TEMPLATE 属性指定的目录和文件名。 

 

5.2.3.2 使用其它 LOG_ARCHIVE_DEST_n 目的地你能显式设置一个或更多LOG_ARCHIVE_DEST_n 目的地来指向闪回恢复区。例如，

你能选择地： z 配置 LOG_ARCHIVE_DEST_10 以外的目的地例如，现有的 Data Guard 配置可能已经使用 LOG_ARCHIVE_DEST_10 目的地用

作其它目的，或者你可能想释放LOG_ARCHIVE_DEST_10 目的地用作其它用途。要配置其它归档目的地以指向闪回恢复区，你必须指定

LOCATION=USE_DB_RECOVERY_FILE_DEST 属性来定义新的目的地。例如： SQL> ALTER SYSTEM SET

LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH

MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'

 

隐式的配置（使用LOG_ARCHIVE_DEST_10 来使用闪回恢复区）将会被清除。 z 配置 LOG_ARCHIVE_DEST_10 以外的目的地，用于角色转化之后例如，你能配置一个目的地，当数据库操作于备角色时对于备重做日志归档有效，

另一个目的地，当数据库操作于主角色时对于联机重做日志归档有效。 

要配置LOG_ARCHIVE_DEST_10 以外的 LOG_ARCHIVE_DEST_n 目的地，你必须显式指定两个目的地： 

LOG_ARCHIVE_DEST_9='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH

MANDATORY REOPEN=5 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)'

LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH

MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'

 

5.2.3.3 使用 STANDBY_ARCHIVE_DEST 目的地在物理备数据库上，你能定义STANDBY_ARCHIVE_DEST 参数来指向闪回恢复区。

例如： 

STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'

 

 

注： 

    由在逻辑备数据库（SQL 应用）上的 STANDBY_ARCHIVE_DEST 参数指向的闪回恢复区是被忽略的。 

 

 

5.2.3.4 在主和备数据库之间共享闪回恢复区你能在数据库之间共享闪回恢复区，每个数据库共享的闪回恢复区有唯一的数据库名，由DB_UNIQUE_NAME 初始化参数指定。下面的例子显式了如何在主和备数据库上指定初始化参数，将会在/arch/oradata 位置共

享闪回恢复区。虽然DB_UNIQUE_NAME 参数没有在例子 5-3 中指定，它默认为 PAYROLL，这是为 DB_NAME 初始化参数指定的名字。例子5－3 对于共享恢复区的主数据库初始化参数 

DB_NAME=PAYROLL

LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'

DB_RECOVERY_FILE_DEST='/arch/oradata' DB_RECOVERY_FILE_DEST_SIZE=20G

 

例子5－4 对于共享恢复区的备数据库初始化参数 

DB_NAME=PAYROLL

DB_UNIQUE_NAME=boston

LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'

STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'

DB_RECOVERY_FILE_DEST='/arch/oradata' DB_RECOVERY_FILE_DEST_SIZE=5G

 

查看Oracle 数据库备份和恢复高级用户指南以获得在多个数据库中共享闪回恢复区的

更多相关信息。 

 

 

5.3 如何发送重做数据 

在主数据库上，Oracle Data Guard 使用归档进程（ARCn）或日志写进程（LGWR）来收集事务重做数据并传送到备目的地。虽然你不能同时使用归档和日志写进程来发送重做数据到同一目的地，但是你能选择为一些目的地使用日志写进程，而使用归档进程发送重做数据到另外一些目的地。本节包含下述主题： 

z 使用归档进程（ARCn）来归档重做数据 z 使用日志写进程（LGWR）来归档重做数据 z 提供安全重做数据传输 

在网络中断之后，为了自动解决中断和重新同步，Data Guard 也使用取归档日志（FAL）客户端和服务器来发送归档重做日志文件到备目的地。FAL进程和中断解决在5.8节中讨论。 

 

5.3.1 使用归档进程（ARCn）来归档重做数据 

默认地，重做传输服务在主数据库上使用ARCn 进程来归档联机重做日志文件。在 Data Guard 配置中，ARCn 归档进程只支持最大性能级别的数据保护。你必须使用 LGWR 进程来传送重做数据到操作在其它保护模式中的备位置。（查看 5.6 节以获得 Data Guard 数据保护模式的更多相关信息。） 

下面小节讨论了这些主题： z 控制 ARCn 归档行为的初始化参数 z ARCn 归档过程 

 

5.3.1.1 控制 ARCn 归档行为的初始化参数 

下面的描述讲述了如何使用LOG_ARCHIVE_DEST_n 和

LOG_ARCHIVE_MAX_PROCESSES 初始化参数。 

允许ARCn 进程归档到本地或远程目的地 

你在初始化参数LOG_ARCHIVE_DEST_n 上指定属性来控制重做数据从主数据库自动传递到其它目的地。因为 ARCn 归档处理是默认的归档行为，所以在

LOG_ARCHIVE_DEST_n 参数上指定 ARCH 属性是可选的。然而，你必须指定 LOCATION 属性以归档到本地目的地或 SERVICE 属性以远程归档（如 5.2.2 节中描述）。 

指定要调用的ARCn 进程的数目 

LOG_ARCHIVE_MAX_PROCESSES 初始化参数指定了 ARCn 进程的最大数目。默认地，当主数据库实例启动时调用 4 个归档进程，并且 Oracle 数据库动态调整进程的数目以平衡归档工作负载。因此，归档进程的实际数目可能随时变化。 

如果你预期到繁重的归档工作负载，你能通过设置初始化参数

LOG_ARCHIVE_MAX_PROCESSES 增加归档进程的最大数目，最多 30。这个初始化参数

是动态的，可以使用ALTER SYSTEM 命令来更改，增加或减少归档进程的最大数目。例如： 

ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES = 20;

 

5.3.1.2 ARCn 归档过程 

   图 5－3 显示了在 Data Guard 配置中的归档出来的一个例子，主数据库位于 Chicago，一个物理备数据库位于 Boston。 

当在主数据库上出现日志切换时发生归档:

z 在主数据库上，在 ARC0 进程成功归档本地联机重做日志到本地目的地

（LOG_ARCHIVE_DEST_1）后，ARC1 进程从本地归档重做日志文件(替代联机重做日志文件)传送重做到远程备目的地（LOG_ARCHIVE_DEST_2）。 

z 在远程目的地，远程文件服务进程（RFS）将从备重做日志文件会依次写重做数据到归档重做日志文件。日志应用服务使用重做引用（MRP 进程^注1）或 SQL 应用（LSP 进程^注2）来应用重做到备数据库。 

因为联机重做日志文件是首先本地归档的，所以，如果ARCn 可能同时归档到备数据库和本地目的地，LGWR 进程重用联机重做日志文件比它也要早很多。 

如图 5－3 所示，你需要至少 2 个 ARCn 进程来分离本地归档与远程归档。这能通过设置 LOG_ARCHIVE_MAX_PROCESSES（默认设置是 4，但是最大值是 30）初始化参数来完成。 

 

图5－3 在归档到远程目的地之前归档到本地目的地 

 

 

在默认的ARCn归档过程将本地归档与远程归档分离，所以节点可能有这样的策略，在备份主数据库上的归档重做日志文件之后立即将其删除，则必须确保备目的地在主数据库上删除归档重做日志文件之前接收到相应的重做数据。你能查询 V$ARCHIVED_LOG 视图来检查备目的地是否接收到重做数据。 

 

5.3.2 使用日志写进程（LGWR）来归档重做数据 

你能选择允许重做传输服务使用LGWR 进程来传送重做数据到远程目的地。 

使用LGWR 进程不同与 ARCn 过程（在 5.3 节中描述），因为代替等待联机重做日志在主数据库上切换然后突然写整个归档重做日志到远程目的地，LGWR 进程在备节点上选择一个备重做日志文件，反映主数据库的当前联机重做日志文件的日志序列号（和大小）。然后，只要重做在主数据库上生成，它也传送到远程目的地。到远程目的地的传输可以是同步的或异步的，基于在 LOG_ARCHIVE_DEST_n 参数上设置 SYNC 或 ASYNC 属性。对于 Data Guard 配置中的最大保护和最大可用性模式，同步 LGWR 过程是必需的。（查看 5.6 节以获得 Data Guard 数据保护模式的相关信息。）本小节包含下述主题： z LGWR 归档过程相关的 LOG_ARCHIVE_DEST_n 属性 z LGWR SYNC 归档过程 

z LGWR ASYNC 归档过程 

 

5.3.2.1 LGWR 归档过程相关的 LOG_ARCHIVE_DEST_n 属性下面小节描述了LGWR、SYNC、和 ASYNC 属性。 

允许重做传输服务使用LGWR 进程 

你必须指定在LOG_ARCHIVE_DEST_n 参数上的 LGWR 和 SERVICE 属性以允许日志传输服务使用 LGWR 进程来传送重做数据到远程归档目的地。 

指定异步或同步网络传输 

LGWR 进程在传输重做数据到远程目的地的同时同步写本地联机重做日志文件： 

z SYNC 属性同步执行所有的网络 I/O，与每次向联机重做日志文件写操作协作，并等待网络 I/O 完成。5.3.2.2 节显示了在 Data Guard 配置中的同步网络传输的例子。

这是默认网络传输设置。 

z ASYNC 属性异步执行所有网络 I/O，控制立即回到执行应用或用户，而不用等待网络 I/O 完成。5.3.2.3 节显示了在 Data Guard 配置中的异步网络传输的例子。 

 

注： 

    如果你配置一个目的地来使用 LGWR 进程，但是由于某些原因 LGWR 进程变得无法归

档到目的地了，则重做传输将会回复到使用ARCn 进程来完成归档操作。 

 

 

5.3.2.2 LGWR SYNC 归档过程 

例子5－5 显示了为同步网络传输配置 LGWR 进程的主角色 LOG_ARCHIVE_DEST_n 参数。 

例子5－5 LGWR 同步归档相关的初始化参数 

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'

LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR SYNC NET_TIMEOUT=30'

LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE

 

在LOG_ARCHIVE_DEST_n 参数上指定 SYNC 属性是可选的，因为这是 LGWR 归档过程的默认值。推荐使用 NET_TIMEOUT 属性，因为它控制 LGWR 进程在中断网络连接之前等待网络服务进程状态的时间长短。如果 NET_TIMEOUT 秒还没有响应，则 LGWR 进程就返回错误信息。 

图5－4显示了使用LGWR进程在写重做数据到主数据库上的联机重做日志文件的同时传送重做数据到备系统的 Data Guard 配置。 

z 在主数据库上，LGWR 进程提交重做数据到一个或多个网络服务（LNSn）进程，该进程然后并行发起网络 I/O 到多个远程目的地。主数据库上的事务不会提交，直到恢复事务所需的重做数据被所有 LGWR SYNC 目的地接收到。 

z 在备系统上，远程文件服务（RFS）通过网络从 LGWR 进程接收重做数据，并写重做数据到备重做日志文件。 

在主数据库上的日志切换触发在备数据库上的日志切换，导致备数据库上的ARCn 进程归档备重做日志文件到备数据库上的归档重做日志文件。然后，重做应用（MRP 进程）或 SQL 应用（LSP 进程）应用重做数据到备数据库。如果允许实时应用，Data Guard 在当前备重做日志文件由 RFS 进程写满的同时直接从其恢复重做数据。 

 

图5－4 LGWR SYNC 归档到使用备重做日志文件的远程目的地 

 

 

 

5.3.2.3 LGWR ASYNC 归档过程例子5－6 显示了为异步网络传输配置 LGWR 进程的主角色 LOG_ARCHIVE_DEST_n

参数。 

例子5－6 LGWR 异步归档相关的初始化参数 

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'

LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

 

图5－5 显示了 LNSn 进程从联机重做日志文件收集重做数据并通过 Oracle 网络传送到

备数据上的RFS 进程。 

当指定了LGWR 和 ASYNC 属性，日志写进程写到本地联机重做日志文件，当网络服

务（LNSn）进程（每个目的地一个）异步传送重做到远程目的地。LGWR 进程继续处理下一个请求而不用等待 LNS 网络 I/O 完成。如果重做传输服务传送重做数据到多个远程目的地，LNSn 进程（每个目的地一个）并

行发起到所有目的地的网络I/O。 

当一个联机重做日志文件写满了，如通常一样，就出现日志切换并且归档进程本地归

档日志文件。 

 

注： 

    从 Oracle 数据库 10g 版本 10.2 开始，在同时配置 LGWR 和 ASYNC 属性的

LOG_ARCHIVE_DEST_n 目的地上，没有必要指定 NET_TIMEOUT 属性。这是因为在版本 10.2 中日志写进程永远不会为任何原因等待 LNSn。因此，不需要指定 NET_TIMOUT 属性。

 

 

图5－5 使用网络服务（LNSn）进程的LGWR ASYNC 归档 

 

    不要使用 LOG_ARCHIVE_DEST 或 LOG_ARCHIVE_DUPLEX_DEST 初始化参数来指定闪回恢复区目的地。 

 

 

5.3.3 提供安全重做数据传输 

Data Guard 提供了一个安全的环境并防止重做数据在传递到备数据时发生可能的篡改。 

重做传输服务使用认证的网络会话来传递重做数据。这些会话使用包含在口令文件中的SYS 用户口令来认证。在 Data Guard 配置中的所有数据库都必须使用口令文件，并且包含在这个口令文件中的 SYS 口令在所有系统上都必须相同。这种认证即使在没有安装 Oracle 高级安全的时候也能执行，以在运输重做的时候提供一定级别的安全。 

 

注： 

    要进一步保护重做（例如，要对跨网络的重做运输进行加密重做或计算完整性校验和，不允许在网络上的重做篡改），Oracle 推荐你安装和使用 Oracle 高级安全。查看 Oracle 数据库高级安全管理员指南。 

 

 

在主数据库和每个备数据库上执行下面的步骤： 

1． 在主和所有备数据库上创建口令文件（使用 orapwd 工具）。例如： 

ORAPWD FILE=orapw PASSWORD=mypassword ENTRIES=10

 

这个例子创建了有10 个条目的口令文件，在那里 SYS 的口令是 mypassword。为了成功传输重做数据，确保你对于每个主和备数据库设置同样的 SYS 用户帐户口令。 2． 设置 REMOTE_LOGIN_PASSWORDFILE 初始化参数为 EXCLUSIVE 或 SHARED，

以允许Oracle 检查口令文件并指定多少数据库能使用该口令文件。例如： 

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

 

查看Oracle 数据库参考以获得这个参数的更多相关信息。 

 

 

5.4 应该何时发送重做数据 

本节包含下述主题： z 使用 VALID_FOR 属性指定基于角色的目的地 z 为主和备数据库指定唯一名字 

 

5.4.1 使用 VALID_FOR 属性指定基于角色的目的地 

VALID_FOR 属性允许你在一个服务器参数文件（SPFILE）中同时为主和备数据库角色配置目的地属性，使得你的 Data Guard 配置在角色转换之后能正确操作。这通过消除在角色转换之后允许和禁止角色相关参数文件的需求，简化了切换和故障转移。 

当你指定LOG_ARCHIVE_DEST_n 参数的 VALID_FOR 属性，它确定重做传输服务何时能传送重做数据到基于下述要素的目的地： z 数据库是否当前运行在主或备角色 

z 是否需要联机重做日志文件，备重做数据文件，或者两者的归档，依赖于数据库的当前角色 

要为每个LOG_ARCHIVE_DEST_n 目的地配置这些要素，你使用一对关键词指定这个属性：VALID_FOR=（redo_log_type, database_role）。redo_log_type 关键词标识了归档目的地对于下述是有效的：ONLINE_LOGFILE、STANDBY_LOGFILE、或 ALL_LOGFILES。

database_role 关键词标识了当前数据库必须处于的角色，处于这些角色，目的地才是有效的：

PRIMARY_ROLE、STANDBY_ROLE、或 ALL_ROLES。 

如果你没有为目的地指定VALID_FOR 属性，默认地，归档联机重做日志和备重做日志对于目的地是允许的，不管数据库是什么角色。这种默认行为等同于在 VALID_FOR 属性上设置（ALL_LOGFILES, ALL_ROLES）关键词对。例如： 

LOG_ARCHIVE_DEST_1='LOCATION=/ARCH1/CHICAGO/

VALID_FOR=(ALL_LOGFILES,ALL_ROLES)'

 

虽然（ALL_LOGFILES, ALL_ROLES）关键词对是默认值，但是不推荐对于每个目的地。例如，逻辑备数据库，不像物理备数据库，是生成重做数据并且有多种日志文件（联机重做日志文件、归档重做日志文件、和备重做日志文件）的打开数据库。在大多数情况下，由逻辑备数据库生成的联机重做日志文件于从主数据库接收重做的备重做日志文件是位于同一目录的。 

因此，推荐你为每个目的地定义VALID_FOR 属性，使得你的 Data Guard 配置正确操作，包括在角色转换之后。查看 12.1 节中的场景以获得对于不同 Data Guard 配置的

VALID_FOR 属性的例子。 

如果你选择不使用VALID_FOR 属性来配置目的地，你必须对于每个数据库维护两个数据库服务器参数文件（SPFILEs）：一个对于数据库处于主角色时，一个对于备角色。查看第 12 章以获得更多配置例子。 

 

5.4.2 为主和备数据库指定唯一名字 

DB_UNIQUE_NAME 属性允许你在配置目的地时指定唯一数据库名字。这使得动态添

加备数据库到包含Real Applications Clusters 主数据库的 Data Guard 配置成为可能，当那个主数据库操作于最大保护或最大可用性级别的保护时。如果已经定义了

LOG_ARCHIVE_CONFIG 参数，则需要初始化参数 DB_UNIQUE_NAME。 

 

注： 

    如果在远程目的地的备数据库没有使用 DB_UNIQUE_NAME 初始化参数确定，备数据库必须在主实例启动之前可访问。 

 

 

LOG_ARCHIVE_DEST_n 参数的 DB_UNIQUE_NAME 属性和

LOG_ARCHIVE_CONFIG 参数的 DG_CONFIG 属性一起指定了 Data Guard 配置的每个数据库的唯一名字。你提供的名字必须符合为使用 DB_UNIQUE_NAME 初始化参数的每个数据库的定义。 

例如，下面的初始化参数显示了对在第 3 章中描述的 Data Guard 配置中的主数据库

（chicago）的 DB_UNIQUE_NAME 和 LOG_ARCHIVE_CONFIG 定义。 

DB_NAME=chicago

DB_UNIQUE_NAME=chicago 

LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago, boston)'

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES)'

LOG_ARCHIVE_DEST_2=

'SERVICE=boston LGWR ASYNC

  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)  

  DB_UNIQUE_NAME=boston' 

 

对于使用SERVICE 属性指定的远程目的地，需要 DB_UNIQUE_NAME 属性。在例子

中，LOG_ARCHIVE_DEST_2 参数为远程目的地指定了 DB_UNIQUE_NAME=boston；重做传输服务在远程目的地检查这个信息。如果名字不符合，则到那个目的地的连接被拒绝。 

LOG_ARCHIVE_CONFIG 参数也有 SEND、NOSEND、RECEIVE、和 NORECEIVE 属性： 

z SEND 允许数据库发送重做数据到远程目的地 z RECEIVE 允许备数据库从其它数据库接收重做 

要禁止这些设置，使用NOSEND 和 NORECEIVE 关键词。 

例如，要确保主数据库永远不会收到任何归档重做数据，在主数据库上设置

LOG_ARCHIVE_CONFIG 初始参数为 NORECEIVE，如下： 

LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG=(chicago,boston)'

 

然而，紧记指定NOSEND 或 NORECEIVE 属性会在角色转换之后限制数据库实例的能力。例如，如果使用 NOSEND 属性设置的备数据库转换到主角色，它将不能够传送重做数据到其它备数据库，直到你重置该参数值为 SEND。类似地，有 NORECEIVE 属性指定的数据库不能从主数据库接收重做。 

默认地，LOG_ARCHIVE_CONFIG 参数允许主数据库发送重做数据到备数据库并允许备数据库从主数据库接收重做以用于归档。这等同于在 LOG_ARCHIVE_CONFIG 参数上同时设置 SEND 和 RECEIVE 属性。 

 

注： 

    LOG_ARCHIVE_CONFIG 初始化参数替代了 REMOTE_ARCHIVE_ENABLE 初始化参数，不赞成使用该参数。不要在一个 SPFILE 或文本初始化参数文件中同时指定两个参数。

 

 

 

5.5 如果出现错误如何应对 

要处理归档故障，你能使用LOG_ARCHIVE_DEST_n 参数的 REOPEN，

MAX_FAILURES，和 ALTERNATE 属性来指定当向目的地的归档过程故障时应该采取什么措施。这些措施包括： 

z 在指定时间周期后重试向归档目的地的归档操作，直到限制数目的次数 z 使用一个预备的或替代的目的地 

z 控制视图重建连接的次数并重新开始发送重做数据到故障的目的地 

 

5.5.1 重试归档操作 

使用REOPEN 属性来决定是否并且何时 ARCn 进程或 LGWR 进程在错误过后试图再次传送重做数据到故障的目的地。 

使用REOPEN=seconds 属性来指定在错误过后到归档进程再次尝试访问故障的目的地之前必须经过的最小秒数。默认值是 300 秒。对 REOPEN 属性设置的值应用到所有错误，而不仅仅是连接错误。你能通过指定 REOPEN=0 关闭该选项，这会防止目的地在故障发生后被重试。 

如果传送到预备目的地失败了并且REOPEN 属性设置为零（0），重做传输服务将会尝试在下次重做数据归档时发送重做数据到预备目的地。 

 

5.5.2 使用预备目的地 

ALTERNATE 属性定义一个预备的归档目的地，能够在原始归档目的地故障时被使用。如果没有指定预备目的地，目的地在故障时不会自动更改到其它目的地。 

图5－6 显示了重做数据归档到本地磁盘设备的场景。如果原始目的地设备变满了或不可用了，归档操作会自动重指向预备目的地设备。 

 

 

 

 

 

 

 

 

 

 

图5－6 向预备目的地设备的归档操作 

 

 

REOPEN 属性优先于 ALTERNATE 属性。预备目的地只有在如果下面条件之一为真时才使用： z REOPEN 属性指定为零（0）值。 

z 非零 REOPEN 属性以及非零 MAX_FAILURE 计数被超过。 

ALTERNATE 属性优先于 MANDATORY 属性。这意味者即使当前目的地是强制的，目的地也会故障转移到有效的预备目的地。 

 

同时查看： 

    ALTERNATE 属性 

 

 

5.5.3 控制重试尝试的次数 

使用MAX_FAILURE 属性来指定重做传输服务尝试传送重做数据到故障目的地的连续次数的最大数目。要限制与故障目的地重新建立通讯的连续尝试的次数，联合使用 REOPEN 属性与 MAX_FAILURE 属性。一旦超过指定的连续尝试次数，目的地就被视为与 REOPEN 属性设置为零等同。 

当你使用MAX_FAILURE 属性时需要 REOPEN 属性。例子 5－7 显示了如何设置重试时间 60 秒和重试限制 3 次。 

例子5－7 设置重试时间和限制 

LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=60 MAX_FAILURE=3' 

 

 

5.6 设置数据保护模式 

Data Guard 提供三种数据保护模式：最大保护、最大可用性、和最大性能。你选择的数

据保护级别控制了如果主数据库丢失其到备数据库的连接之后的行为。本节包含下述主题： z 选择 Data Guard 保护模式 

z 设置 Data Guard 配置的数据保护模式 

 

5.6.1 选择数据保护模式要决定使用合适的数据保护模式，回顾下面的数据保护模式的描述会帮助评估你的对于数据可用性的业务需求与对于响应时间和性能的用户需要之间的对比。同时，查看5.6.2 节以获得设置数据保护模式相关信息。 

 

5.6.1.1 最大保护模式 

这种保护模式确保如果主数据库故障不会发生数据丢失。要提供这种级别的保护，恢复每个会话所需的重做数据必须在事务提交之前同时写到本地联机重做日志和至少一个备数据库备重做日志。要确不能发生保数据丢失，如果故障导致主数据库无法向至少一个远程备重做日志写其重做流，则主数据库会关闭。对于多实例RAC 数据库，如果无法写重做记录到至少一个适当配置的数据库实例，则 Data Guard 关闭主数据库。最大保护模式需要至少一个备实例有一个备重做日志并且在 LOG_ARCHIVE_DEST_n 参数上对于这个目的地使用 LGWR、SYNC、和 AFFIRM 属性。 

 

5.6.1.2 最大可用性模式 

这种保护模式提供了可能的最高级别的数据保护，而不用与主数据库的可用性相妥协。如同最大保护模式，事务将不会提交，直到恢复该事务所需的重做写到本地联机重做日志和至少一个远程备重做日志。不同于最大保护模式，如果故障导致主数据库无法写其重做流到远程备重做日志，主数据库不需要关闭。替代地，主数据库操作于最大性能模式直到解除故障并且解决所有重做日志文件中的中断。当解决所有中断后，主数据库自动继续操作于最大可用性模式。 

这种模式确保即使主数据库故障也不会发生数据丢失，但是只有在第二次故障没有阻止完整的重做数据集从主数据库发送到至少一个备数据库的情况下。 

如同最大保护模式，最大可用性模式需要你： z 至少在一个备数据库上配置备重做日志文件。 

z 为至少 1 个备数据库设置 LOG_ARCHIVE_DEST_n 参数的 LGWR、SYNC、和

AFFIRM 属性。 

 

5.6.1.3 最大性能模式 

这种保护模式（默认）提供了可能的最高级别的数据保护，而不用影响主数据库的性能。这是通过允许事务在恢复该事务所需的重做数据一写到本地联机重做日志就提交来实现的。主数据库的重做数据流也写到至少一个备数据库，但是那个重做流相对于创建重做数据的事务的提交是异步写的。 

当使用足够带宽的网络链接，这种模式提供了接近最大可用性模式而对主数据库性能影响最小的数据保护级别。 

最大性能模式允许你在LOG_ARCHIVE_DEST_n 参数上对于备数据库目的地设置

LGWR 和 ASYNC 属性，或设置 ARCH 属性。如果主数据库故障，你能通过设置 LGWR 和

ASYNC 属性来减少备目的地上未接收到的数据量。 

 

5.6.2 设置 Data Guard 配置的数据保护模式 

要设置重做传输服务和指定对于Data Guard 配置的数据保护级别，执行下述步骤。 

 

第1 步 在主数据库上配置 LOG_ARCHIVE_DEST_n 参数。 

在主数据库上，适当配置LOG_ARCHIVE_DEST_n 参数属性。每种 Data Guard 数据保护模式在配置中需要至少一个备数据库，以满足在表 5－2 中列出的最小需求集。 

表5－2 对于数据保护模式的最小需求 

	最大保护	最大可用性	最大性能
重做归档进程	LGWR	LGWR	LGWR 或 ARCH
网络传输模式	SYNC	SYNC	当使用 LGWR 进程时为 SYNC 或 ASYNC。 如果使用 ARCH 进程则 SYNC
磁盘写选项	AFFIRM	AFFIRM	AFFIRM 或 NOAFFIRM
是否需要备重做日志？	是	是	否，但是推荐

 

 

注： 

    Oracle 推荐运行在最大保护模式的 Data Guard 配置包含至少两个满足表 5－2 中所列需求的备数据库。那样的话，数据库能在备数据库之一不能从主数据库接收重做数据时继续进行。 

 

 

下面的例子显示了如何配置最大可用性模式： 

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=chicago

  2> OPTIONAL LGWR SYNC AFFIRM 

  3> VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)

  4> DB_UNIQUE_NAME=chicago';

 

如果没有已经在SPFILE 中指定，你也应该使用 DB_UNIQUE_NAME 初始化参数指定

唯一名字，以及在使用DG_CONFIG 属性的 LOG_ARCHIVE_CONFIG 上列出所有数据库。

例如： 

SQL> ALTER SYSTEM SET

LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'

 

这将会允许动态添加一个备数据库到一个拥有运行在最大保护或最大可用性模式中的

Real Application Cluster 主数据的 Data Guard 配置。 

    

第1 步 如果你升级保护模式，执行这个步骤。只有你升级保护模式才执行这个步骤（例如，从最大性能到最大可用性模式）。否则，

跳到步骤 3。 

假定这个例子是升级Data Guard 配置从最大性能模式到最大可用性模式。关闭主数据

库并重启到安装模式： 

SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;

     对于 Real Application Clusters 数据库，关闭所有的主实例但只启动并安装一个主实例。 

 

第2 步 设置数据保护模式。 

要指定一种数据保护模式，在主数据库上执行SQL ALTER DATABAE SET STANDBY

DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}语句。例如，下面的语句指定了最大可用性模式： 

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY; 第 3 步 打开主数据库。 

如果你执行步骤 1 来升级保护模式，打开数据库： 

SQL> ALTER DATABASE OPEN;

 如果你是降级保护模式，则数据库已经打开。 

 

第4 步 在备数据库上配置 LOG_ARCHIVE_DEST_n 参数。 

在备数据库上，配置LOG_ARCHIVE_DEST_n 参数属性使得配置能在切换过后继续操

作在新的保护模式。 

例如： 

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=boston

  2> OPTIONAL LGWR SYNC AFFIRM

  3> VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)

  4> DB_UNIQUE_NAME=boston';

 

第5 步 确认配置操作在新的保护模式。 

查询V$DATABASE 视图以确认 Data Guard 配置操作在新的保护模式。例如： 

SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;

 

PROTECTION_MODE                   PROTECTION_LEVEL

---------------------             ---------------------

MAXIMUM AVAILABILITY              MAXIMUM AVAILABILITY

 查看第 15 章和 Oracle 数据库 SQL 参考以获得 SQL 语句相关信息。 

 

 

5.7 管理日志文件 

本节包含下述主题： z 为归档重做日志文件指定预备目录 z 重用联机重做日志文件 z 管理备重做日志文件 z 为控制文件的增长和重用而计划 

z 在多个备数据库之间共享日志文件 

 

5.7.1 为归档重做日志文件指定预备目录 

典型地，当从主数据库接收到重做数据，重做数据是写到归档重做日志中的，存储在

你使用LOG_ARCHIVE_DEST_n 参数的 LOCATION 属性指定的目录。作为选择，你能在备数据库上指定 STANDBY_ARCHIVE_DEST 初始化参数来指示一个预备的目录，归档重做日志文件能在从主数据库接收后存放在那里。如果同时指定了两个参数，STANDBY_ARCHIVE_DEST 初始化参数覆盖了 LOG_ARCHIVE_DEST_n 参数指定的目录位置。 

归档重做日志文件在备数据库上存储的位置由下述规则列表决定。当数据库实例启动时，归档重做日志文件以列表中顺序评估： 

1. 如果在备数据库上指定了 STANDBY_ARCHIVE_DEST 初始化参数，则使用那个位置。 

2. 如果 LOG_ARCHIVE_DEST_n 参数包含了 VALID_FOR=(STANDBY_LOGFILE, *) 属性，则使用对这个目的地指定的位置。 

3. 如果 COMPATIBLE 参数设为 10.0 或更高，并且没有一个 LOG_ARCHIVE_DEST_n 参数包含 VALID_FOR=(STANDBY_LOGFILE, *)属性，则使用任意一个有效的 LOG_ARCHIVE_DEST_n 参数。 

4. 如果没有指定任何一个初始化参数，则归档重做日志文件存储在对于

STANDBY_ARCHIVE_DEST 初始化参数的默认位置。 

要查看STANDBY_ARCHIVE_DEST 初始化参数的隐式默认值，查询

V$ARCHIVE_DEST 视图： 

SQL> SELECT DEST_NAME, DESTINATION FROM V$ARCHIVE_DEST 

  2> WHERE DEST_NAME='STANDBY_ARCHIVE_DEST';

 

DEST_NAME

----------------------------------------------------------------- DESTINATION

-----------------------------------------------------------------

STANDBY_ARCHIVE_DEST

/oracle/dbs/arch

 

重做传输服务联合使用STANDBY_ARCHIVE_DEST 初始化参数与 LOG_ARCHIVE_FORMAT 参数指定的值来在备站点生成归档重做日志文件的文件名。例如： 

STANDBY_ARCHIVE_DEST='/arc_dest/arls' 

LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc

 

在上面的例子中，%s 相应于序列号，%r 相应于重置日志 ID。这些一起确保跨多数据

库化身的归档重做日志文件能有唯一名字。%t 是 Real Application Clusters 配置所需要的，相应于线程号。 

对于物理备数据库，重做传输服务在备数据库控制文件中存储全限定文件名，并且重

做应用使用这个信息在备数据库上执行恢复。 

 

注： 

    如果你指定了 LOG_ARCHIVE_DEST_n 参数的 TEMPLATE 属性，它会覆盖由

STANDBY_ARCHIVE_DEST 和 LOG_ARCHIVE_FORMAT 参数生成的文件名。查看第 14 章以获得 TEMPLATE 属性相关信息。 

 

 

要显示在备系统上的归档重做日志文件的列表，在备数据库上查询

V$ARCHIVED_LOG 视图： 

SQL> SELECT NAME FROM V$ARCHIVED_LOG;

NAME                                                                            

----------------------------------------------------------------- /arc_dest/log_1_771.arc                                        /arc_dest/log_1_772.arc                                       

/arc_dest/log_1_773.arc                                       

/arc_dest/log_1_774.arc                                       

/arc_dest/log_1_775.arc

 

5.7.2 重用联机重做日志文件 

你能使用设置LOG_ARCHIVE_DEST_n 参数的 OPTIONAL 或 MANDATORY 属性来指定重用联机重做日志文件的策略。默认地，远程目的地被设置为 OPTIONAL。可选目的地的归档操作可以失败，并且即使传送重做数据和写日志内容没有成功，联机重做日志文件也能被重用。如果强制目的地的归档操作失败了，联机重做日志文件不能被覆盖，直到向强制目的地的失败归档完成。 

默认地，即使你指定所有的目的地都为可选的，也有一个本地目的地是强制的。 

例子5－8 显示了如何设置强制本地归档目的地，并允许那个目的地。当指定

MANDATORY 属性时，也要考虑在 5.5 节中描述的 REOPEN 和 MAX_FAILURE 属性来处理故障情况。 

例子5－8 设置强制归档目的地 

LOG_ARCHIVE_DEST_3 = 'LOCATION=/arc_dest MANDATORY'

 

5.7.3 管理备重做日志文件 

本小节包含下述主题： z 确定备重做日志文件组配置是否适当 z 添加备重做日志成员到现有的组 

 

5.7.3.1 确定备重做日志文件组配置是否适当 

检验备重做日志有合适数目的日志文件组，最简单的方法是检查RFS 进程跟踪文件和数据库警告日志。如果两个日志都包含显示 RFS 进程频繁地因为归档没有完成而等待组，则添加更多日志文件组到备重做日志。额外的备重做日志文件组给归档操作足够的时间在

RFS 进程重用备重做日志文件之前完成。 

 

注意： 

    不管何时你添加一个联机重做日志文件组到主数据库，你必须添加一个相应的备重做日志文件组到备数据库。如果备重做日志文件组的数目不适当，主数据库如果操作于最大保护模式将会关闭，如果操作于最大可用性模式将会切换到最大性能模式。 

 

 

5.7.3.2 添加备重做日志成员到现有的组 

在一些案例中，可能没有必要创建一个完整的备重做日志文件组。一个组可能已经存在，但可能不完整，因为一个或更多成员被删除了（例如，因为磁盘故障）。在这个案例中，你能添加新的成员到现有的组。 

要添加新成员到一个备重做日志文件组，使用带ADD STANDBY LOGFILE MEMBER 子句的 ALTER DATABASE 语句。下面的语句添加一个新成员到 2 号备重做日志文件组： 

SQL> ALTER DATABASE ADD STANDBY LOGFILE MEMBER

'/disk1/oracle/dbs/log2b.rdo' 

  2> TO GROUP 2; 使用新成员的全限定文件名来指出文件应该创建在何处。否则，文件将会被创建在数据库的默认或当前目录，依赖于你的操作系统。 

 

5.7.4 为控制文件的增长和重用而计划 

本小节描述： z 设置包含控制文件的磁盘容量的大小 z 指定控制文件中记录的重用 

 

5.7.4.1 设置包含控制文件的磁盘卷的大小 

随着生成的归档重做日志文件和进行的RMAN 备份，Oracle 添加新的记录到控制文件的可重用部分。如果没有可用于重用的记录（因为所有的记录还处于由

CONTROL_FILE_RECORD_KEEP_TIME 指定的天数之内），则控制文件会扩展，新的记录被添加到控制文件中。 

最大的控制文件大小是20000 个数据库块。如果 DB_BLOCK_SIZE 等于 8192，则最大的控制文件大小是 156MB。如果控制文件是存储在预先创建的卷中，则包含主与备控制文件的卷应该大小能容纳最大尺寸的控制文件。如果控制文件卷太小并且不能扩展，则在控制文件中的现有记录在它们的预期的重用之前将被覆盖。这种行为通过在警告日志中的下述信息来指出： 

krcpwnc: following controlfile record written over:

 

5.7.4.2 指定控制文件中记录的重用 

CONTROL_FILE_RECORD_KEEP_TIME 初始化参数指定了控制文件中可重用的记录能被重用之前必须经过的最小天数。适当地设置这个参数预防重做传输服务覆盖控制文件中的可重用记录，并且确保重做信息在备数据库上保持可用。 

z 设置 CONTROL_FILE_RECORD_KEEP_TIME 为一个值，允许所有在磁盘上的备份信息保留在控制文件中。CONTROL_FILE_RECORD_KEEP_TIME 指定记录在成为候选于重用之前在控制文件中保留的天数。 

z 设置 CONTROL_FILE_RECORD_KEEP_TIME 为一个值，比你打算保留在磁盘上最早的备份文件稍微长一点，由备份区域的大小来确定。 

例如，如果备份区域大小设置为维护每7 天进行的两个全备份，每天的增量备份和归档重做日志文件也是这样，则设置 CONTROL_FILE_RECORD_KEEP_TIME 的值为 21 或 30。比这个更旧的记录将被重用。然而，备份元数据在 RMAN 恢复目录中将还是可用的。 

如果对备数据库设置了应用延迟（在6.2.2 节中描述），确保你指定一个足够大的值。这个参数的值的范围从 0 到 365 天。默认值是 7 天。 

查看Oracle 数据参考以获得 CONTROL_FILE_RECORD_KEEP_TIME 初始化参数的更多相关细节，和 Oracle 数据库备份和恢复高级用户指南。 

 

5.7.5 在多个备数据库之间共享日志文件目的地 

使用LOG_ARCHIVE_DEST_n 初始化参数的 DEPENDENCY 属性来定义一个归档目的地代表多个目的地接收重做数据，而不是传送重做数据到每个单独的目的地。 

图－7 显示了一个 Data Guard 配置，在这里面主数据库传送重做数据到一个归档目的地，同时共享其归档重做日志文件给一个逻辑备数据库和一个物理备数据库。这些目的地依赖于向父目的地的归档操作的成功。 

图5－7 使用依赖目的地的Data Guard 配置 

 

 

指定目的地依赖性在下面的情况下可能是很有用的： z 当你在同一系统配置一个物理备数据库和一个逻辑备数据库时。 

z 当你在同一系统配置备数据库和主数据库时。因此，归档重做日志文件对于备数据库是隐式可访问的。 

z 当使用集群文件系统来提供远程备数据库对于主数据库的归档重做日志文件的访问时。 

z 当使用操作系统相关的网络文件系统时，提供远程备数据库对于主数据库归档重做日志文件的访问。 

例如，假设有两个备数据库stby1 和 stdby2 位于硬件的同一片上。不需要使用网络带宽和磁盘空间来发送同一重做数据到两个目的地。如果你使用 DEPENDENCY 属性来指定其中一个目的地作为一个依赖目的地，数据库能共享同一归档重做日志文件。那就是说，主数据库发送要归档的重做到没有定义为依赖目的地的目的地。如果重做数据成功到达那个目的地，主数据库认为其归档到了两个目的地。例如： 

LOG_ARCHIVE_DEST_1='LOCATION=DISK1 MANDATORY'

LOG_ARCHIVE_DEST_2='SERVICE=stdby1 OPTIONAL'

LOG_ARCHIVE_DEST_3='SERVICE=stdby2 OPTIONAL

DEPENDENCY=LOG_ARCHIVE_DEST_2'

 

使用这些定义的参数，主数据库传送重做数据到stdby1 而不到 stdby2。stdby2 数据库改为从运输到 stdby1 的归档重做日志文件来恢复重做。 

 

同时查看： 

    DEPENDENCY 属性数据库到备数据库的自动归档临时停止，就会出现归档中断。当网络再次可用时，从主数据库到故障的备数据库的重做数据的自动传输继续。 

Data Guard 不需要 DBA 的手工干预来探测和解决这样的中断。下面的小节描述了中断探测和解决。 

 

 

5.8.1 何时发现归档中断？ 

无论何时主数据库本地归档一个日志，但是备站点没有接受到该日志就会发生归档中断。每分钟，主数据库调查其备数据库以查看是否在归档重做日志文件的序列中有中断。 

 

5.8.2 如何解决中断？ 

中断恢复通过轮询机制解决。对于物理和逻辑备数据库、Oracle Change Data Capture、和 Oracle Streams，Data Guard 通过自动从主数据库检索丢失的归档重做日志文件来执行中断探测和解决。不需要额外的配置设置来调查备数据库，来探测任何中断或解决中断。 

这里很重要的考虑是自动中断恢复是依主数据库的可用性而定的。如果主数据库不可用了，并且你配置了多个物理备数据库，你能设置额外的初始化参数使得重做应用能从其它备数据库解决归档中断，如5.8.3 节中描述。 

查看12.11 节以获得显示如何手工解决中断的场景。 

 

注： 

    在 Oracle 数据库 10g 版本 1 以前，FAL 客户端和服务器用于从主数据库解决中断。 

 

 

 

5.8.3 使用取归档日志（FAL）来解决归档中断 

取归档日志（FAL）客户端和服务期解决在主数据库生成的与物理备数据库接收到的归档重做日志文件的范围中探测到的中断。 

z FAL 客户单自动请求归档重做日志文件的传递。 z FAL 服务期服务从 FAL 客户端来的 FAL 请求。 

FAL 机制处理下述类型的归档中断和问题： 

z 当创建一个物理或逻辑备数据库时，FAL 机制能自动检索在主数据库的热备期间生成的任何归档重做日志文件。 

z 当有在备数据库上已经有接收到的归档重做日志文件的问题时，FAL 机制能自动

检索归档重做日志文件来解决任何下述情况： 

{ 当归档重做日志文件在应用到备数据之前被从磁盘删除。 

{ 当归档重做日志文件因为磁盘损坏不能应用。 

{ 当归档重做日志文件在重做数据应用到被数据库之前，意外被不是归档重做日志文件的其它文件替换（例如，一个文本文件）。 

z 当你有多个物理备数据库，FAL 机制能从其它物理备数据库自动检索丢失的归档重做日志文件。 

FAL 客户端和服务期使用在备数据库上设置的 FAL_CLIENT 和 FAL_SERVER 初始化参数来配置。在初始化参数文件中定义的 FAL_CLIENT 和 FAL_SERVER 初始化参数只针对于物理备数据库，如下表中所示： 

参数	功能	语法
FAL_SERVER	指定备数据库应该用于连接 FAL 服务器的网络服务名。它可以在一个列表中包含多个值。	语法  FAL_SERVER=net_service_name  例子  FAL_SERVER=standby2_db,standby3_db
FAL_CLIENT	指定 FAL 服务器应该用于连接到备数据库的网络服务名。	语法  FAL_CLIENT=net_service_name  例子  FAL_CLIENT=standby1_db

 

 

5.8.4 手工探测和解决归档中断 

在一些情况下，自动中断恢复可能不会发生，你将会需要手工执行中断恢复。例如，

如果你使用逻辑备数据库并且主数据库不可用时，你将需要手工执行中断恢复。下面的小节描述了如何查询适当的视图以确定哪个日志文件丢失了并且执行手工恢复。 

在物理备数据库： 

要确定在你的物理备数据库上是否有归档中断，查询V$ARCHIVE_GAP 视图，如下面

例子所示： 

SQL> SELECT * FROM V$ARCHIVE_GAP;

    THREAD#  LOW_SEQUENCE#  HIGH_SEQUENCE#

-----------  -------------  --------------             1                7                10

 

前面例子的输出指出你的物理备数据库当前丢失日志文件从线程1 的序号 7 到序号 10。在你确定中断后，在主数据库上执行下面的 SQL 语句来在你的主数据库上定位归档重做日

志文件（假设在主数据库上的本地归档目的地是LOG_ARCHIVE_DEST_1）： 

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1    2> AND SEQUENCE# BETWEEN 7 AND 10;

NAME

-----------------------------------------------------------------

/primary/thread1_dest/arcr_1_7.arc

/primary/thread1_dest/arcr_1_8.arc

/primary/thread1_dest/arcr_1_9.arc

 

拷贝这些日志文件到你的物理备数据库并在你的物理备数据库上使用ALTER

DATABASE REGISTER LOGFILE 语句来注册它们。例如： SQL> ALTER DATABASE REGISTER LOGFILE

'/physical_standby1/thread1_dest/arcr_1_7.arc';

SQL> ALTER DATABASE REGISTER LOGFILE '/physical_standby1/thread1_dest/arcr_1_8.arc';

 

在你在物理备数据库上注册这些日志文件之后，你能重启重做应用。 

注： 

    物理备数据库上的 V$ARCHIVE_GAP 固定视图只返回当前妨碍重做应用继续的下一个中断。在解决中断并重启重做应用后，再次在物理备数据库上查询 V$ARCHIVE_GAP 固定视图来确定下一个中断序号，如果有的话。重复这个过程直到没有更多的中断。 

 

 

在逻辑备数据库： 

要确定是否有归档中断，在逻辑备数据库上查询DBA_LOGSTDBY_LOG 视图。例如，

下面的查询指出在归档重做日志文件的序号中有中断，因为它在逻辑备数据上对于THREAD1 显示有两个文件。（如果没有中断的话，查询应该每个线程只显示一个文件。）输

出显示最高的注册文件是序列号10，但是在所示文件序列号 6 有中断： 

SQL> COLUMN FILE_NAME FORMAT a55

SQL> SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L

  2> WHERE NEXT_CHANGE# NOT IN

  3> (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# =

THREAD#)

  4> ORDER BY THREAD#,SEQUENCE#;

 

   THREAD#  SEQUENCE# FILE_NAME

--------- ---------- ---------------------------------------------

          1           6 /disk1/oracle/dbs/log-1292880008_6.arc

          1          10 /disk1/oracle/dbs/log-1292880008_10.arc

 

拷贝丢失的日志文件，序列号7、8 和 9，到逻辑备系统，并在你的逻辑备数据库上使用 ALTER DATABASE REGISTER LOGICAL LOGFILE 语句来注册它们。 

例如： 

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE

'/disk1/oracle/dbs/log-1292880008_10.arc';

 

在你在逻辑备数据库上注册这些日志文件之后，你能重启SQL 应用。 

 

注： 

    在逻辑备数据库上的 DBA_LOGSTDBY_LOG 视图只返回当前妨碍 SQL 应用继续的下一个中断。在解决指定的中断并重启 SQL 应用之后，再次在逻辑备数据库上查询 DBA_LOGSTDBY_LOG 视图以确定下一个中断序号，如果有的话。重复这个过程直到没有更多的中断。 

 

 

 

5.9 核查 

本节包含下述主题： z 监控日志文件归档信息 

z 监控重做传输服务的性能 

 

5.9.1 监控日志归档信息 

本小节描述使用视图来对主数据库监控重做日志归档活动。查看Oracle Data Guard Broker 和 Oracle 企业管理器联机帮助以获得图形用户界面的更多相关信息，用于自动化包含在监控 Data Guard 环境中的许多任务。 

 

第1 步 确定重做日志文件的状态。 

在主数据库上属性下面的查询以确定所有联机重做日志文件的状态： 

SQL> SELECT THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$LOG;

 

第2 步 确定最近的归档重做日志文件。 

在主数据库上输入下面的查询以确定最近的归档线程和序列号： 

SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#;

 

第3 步 确定在每个目的地的最近的归档重做日志文件。 

在主数据库上输入下面的查询以确定哪个归档重做日志文件是最近地传送到每个归档

目的地： 

SQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ#

  2> FROM V$ARCHIVE_DEST_STATUS

  3> WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE'; 

DESTINATION          STATUS  ARCHIVED_THREAD#  ARCHIVED_SEQ#

------------------  ------  ----------------  ------------- /private1/prmy/lad   VALID                    1              947 standby1               VALID                    1              947

 

最近写的归档重做日志文件对于每个列出的归档目的地应该是相同的。如果不同，则VALID 以外的状态可能确定在向那个目的地的归档操作过程中遇到了错误。 

 

第4 步 找出归档重做日志文件是否已经被接收到。你能在主数据库上执行一个查询来找出归档重做日志文件是否在一个特定的站点没有

被接收到。每个目的地有一个相关的ID 号。你能在主数据库上查询 V$ARCHIVE_DEST 固定视图的 DEST_ID 列来确定每个目的地的 ID 号。 

假设当前本地目的地是1，远程备目的地之一的 ID 是 2。要确定在备目的地上哪个日

志文件丢失了，执行下面的查询： 

SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM

  2> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1)

  3> LOCAL WHERE

  4> LOCAL.SEQUENCE# NOT IN

  5> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND

  6> THREAD# = LOCAL.THREAD#);

 

  THREAD#  SEQUENCE#

---------  ---------   1         12

  1         13

  1         14

 

查看附录 A 以获得监控主数据库的归档状态的细节。 

 

第5 步 在备站点跟踪传送日志的过程。 

要查看重做数据传输到备目的地的过程，在主和备初始化参数文件中设置

LOG_ARCHIVE_TRACE 参数。查看附录 G 以获得完整的细节和例子。 

 

5.9.2 监控重做传输服务的性能 

本小节描述了监控重做传输服务的性能的等待事件，这些服务由主数据库上的

LOG_ARCHIVE_DEST_n 初始化参数上的 ARCH、LGWR、SYNC、和 ASYNC 属性指定。 

下面的小节描述了等待事件和由V$SYSTEM_EVENT 视图显示的相关时间信息。 

z ARCn 进程等待事件 z LGWR SYNC 等待事件 

z LGWR ASYNC 等待事件 

 

5.9.2.1 ARCn 进程等待事件 

对于ARCn 归档过程，表 5－3 显示了多个等待事件，当为传输模式使用 ARCH 时，监控产生或删除 RFS 连接和发送重做数据到备数据库所花的时间。查看 5.3.1 节以获得 ARCn 归档过程的相关信息。 

表5－3 对配置ARCH 属性的目的地的等待事件 

等待事件	通过…监控所需时间的数量
ARCH 等待 ATTACH	所有 ARCn 进程产生一个 RFS 连接。
ARCH 等待 SENDREQ	所有 ARCn 进程既打开和关闭远程归档重做日志文件，也写接收到重做数据到磁盘。
ARCH 等待 DETACH	所有 ARCn 进程删除一个 RFS 连接。

 

5.9.2.2 LGWR SYNC 等待事件 

对于LGWR SYNC 归档过程，表 5－4 显示了多个等待事件，监控 LGWR 进程在主数据库上花费时间： z 在主数据库上完成写联机重做日志文件 z 传送重做数据到远程备目的地 z 等待要写到备重做日志文件的重做数据 

z 从远程备目的地接收应答 

查看5.3.2 节以获得 LGWR SYNC 归档过程相关信息。 

表5－4 对配置LGWR SYNC 属性的目的地的等待事件 

等待事件	通过…监控所需时间的数量
LGWR 等待 LNS	LGWR 进程等待从 LNSn 进程接收信息。
LNS 等待 ATTACH	所有网络服务生成一个 RFS 连接。
LNS 等待 SENDREQ	所有网络服务既打开和关闭远程归档重做日志文件，也写接收到重做数据到磁盘。
LNS 等待 DETACH	所有网络服务删除一个 RFS 连接。

 

5.9.2.3 LGWR ASYNC 等待事件 

对于LGWR ASYNC 归档过程，表 5－5 显示了多个等待事件，监控在主数据库上写重做数据到联机重做日志文件所花的事件。查看 5.3.2 节以获得 LGWR ASYNC 归档过程的相关信息。 

表5－5 对配置LGWR ASYNC 属性的目的地的等待事件 

等待事件	通过…监控所需时间的数量
LNS 等待 DETACH	所有网络服务删除一个 RFS 连接。
LNS 等待 ATTACH	所有网络服务生成一个 RFS 连接。
LNS 等待 SENDREQ	所有网络服务既打开和关闭远程归档重做日志文件，也写接收到重做数据到磁盘。
真 ASYNC 控制文件 TXN 等待	LNSn 进程在其生命周期内获得控制文件事务的控制权。
真 ASYNC 等待 ARCH 日志	LNSn 进程等待看到归档重做日志（如果 LNSn 进程正在归档一个当前日志文件并且该日志被切换）。
等待 ASYNC 目的地活动	LNSn 进程等待一个不活动的目的地变为活动。
真 ASYNC 日志文件尾等待	LNSn 进程在达到文件的逻辑结尾后等待重做的下一位。

 

注释： 

注1：管理恢复进程（MRP）应用归档重做日志文件到物理备数据库，并在开始的时候自动确定并行恢复进程的最优数量。生成的并行恢复子进程数量基于备服务器上可用的

CPU 数量。 

注2：逻辑备进程（LSP）使用并行执行（Pnnn）进程来应用归档重做日志文件到逻辑备数据库，使用 SQL 接口。 

 

 

6 日志应用服务 

 

本章描述重做数据如何应用到备数据库。包含下述主题： z 日志应用服务介绍 z 日志应用服务配置选项 z 应用重做数据到物理备数据库 z 应用重做数据到逻辑备数据库 

 

 

6.1 日志应用服务介绍 

日志应用服务自动应用重做到备数据库，以维护与主数据库的同步并允许对数据库的事务一致性访问。 

默认地，日志应用服务在应用归档重做日志文件到备数据库之前等待完全的归档重做日志文件到达备数据库。5.3.1 节和 5.3.2 节描述了从主数据库传送的重做数据如何被备系统上的远程文件服务进程（RFS）接收，在那里 RFS 进程写重做数据到归档重做日志文件或备重做日志文件。然而，如果你使用备重做日志文件，你能允许实时应用，这允许 Data Guard 从正在被 RFS 进程写的当前备重做日志文件恢复重做数据。实时应用在 6.2.1 节中更详细地描述。 

日志应用服务使用下面的方法来维护物理和逻辑备数据库： z 重做应用（只有物理备数据库） 

使用媒质恢复来保持主和物理备数据库同步。 

 

注意：     你也能以只读模式打开物理备数据库，允许用户查询备数据库用作报表用途。当打开的时候，还是接收重做数据的；然而，重做应用停止并且物理备数据库没有与主数据库保持同步。如果在此时间发生故障，会延长故障转移操作完成所需的时间。查看 8.2 节，“打开备数据库以用于只读或读/写访问”以获得更多信息。 

 

 

z SQL 应用（只有逻辑备数据库） 

从主数据库接收的重做重组SQL 语句并在逻辑备数据库上执行 SQL 语句。 

逻辑备数据库能以读/写模式打开，但是由逻辑备数据库维护的目标表只能以只读模式打开以用于报表用途（倘若数据库 guard 适当设置）。SQL 应用允许你使用逻辑备数据库用于报表活动，即使当 SQL 语句被应用时。 

本章的小节更详细地描述了重做应用、SQL 应用、实时应用、和延迟应用。 

 

 

6.2 日志应用服务配置选项 

本节包含下述主题： z 使用实时应用来立即应用重做数据 

z 对归档重做日志文件的应用指定时间延迟 

 

6.2.1 使用实时应用来立即应用重做数据 

如果允许了实时应用特性，日志应用服务能在接收重做数据时应用，而不用等待当前备重做日志文件归档。这导致更快的切换和故障转移时间，因为备重做日志文件在故障转移或切换开始的时候已经应用到备数据库。 

使用ALTER DATABASE 语句来允许实时应用特性，如下： 

z 对于物理备数据库，执行 ALTER DATABASE RECOVER MANAGED STANDBY

DATABASE USING CURRENT LOGFILE 语句。 

z 对于逻辑备数据库，执行 ALTER DATABASE START LOGICAL STANDBY APPLY

IMMEDIATE 语句。 

使用实时应用需要备重做日志文件。 

图6－1 显示了使用本地目的地和备目的地的 Data Guard 配置。当远程文件服务（RFS）进程在备数据上写重做数据到备重做日志文件时，日志应用服务能从正在被写的备重做日志文件恢复重做。 

图6－1 使用实时应用应用重做数据到备目的地 

 

 

6.2.2 对归档重做日志文件的应用指定时间延迟 

在一些情况下，你可能想在重做数据从主站点接收到它应用到备数据库的时间之间创建一个时间延迟。你能指定时间间隔（分钟）来保护损坏或错误的数据的应用到备数据库，当你设置DELAY 间隔，它不是延迟重做数据的传输到备数据库。替代地，你指定的时间延迟从重做数据完整地归档到备目的地开始。 

 

注： 

    如果你定义对一个允许实时应用的目的地的延迟，则该延迟被忽略。 

 

 

指定时间延迟 

你能使用LOG_ARCHIVE_DEST_n 初始化参数的 DELAY=minutes 属性，在主和备数据库上设置时间延迟来延迟应用归档重做日志文件到备数据库。默认地，没有时间延迟。如果你指定 DELAY 而没有指定一个值，则默认的延迟间隔是 30 分钟。 

取消时间延迟 

你能取消指定的延迟间隔，如下： 

z 对于物理备数据库，使用 RECOVER MANAGED STANDBY DATABASE 字句的

NODELAY 关键词： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY； 

 

z 对于逻辑备数据库，指定下面的 SQL 语句： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY； 

 

这些命令导致日志应用在时间间隔过期之前，立即开始应用归档重做日志文件到备数据库。同时，查看： 

z 12.8 节，“使用带时间延迟的物理备数据库” 

z Oracle 数据库 SQL 参考，ALTER DATABASE RECOVER MANAGED STANDBY 

DATABASE 语句的 DELAY 属性 

 

6.2.2.1 使用 Flashback 数据库作为设置时间延迟的另一选择 

作为设置应用延迟的另一选择，你能使用Flashback 数据库来从损坏或错误数据的应用中恢复到备数据库。Flashback 数据库能快速、简单地闪回备数据库到一个任意的时间点。 

查看第 12 章以获得显示如何使用带 Flashback 数据库的 Data Guard，以及 Oracle 数据库备份和恢复基础以获得允许及使用 Flashback 数据库的更多相关信息。 

 

 

6.3 应用重做数据到物理备数据库 

默认地，重做数据从归档重做日志文件应用。当执行重做应用时，物理备数据库能使用实时应用特性来从正在被RFS 进程写的备重做日志文件直接应用重做。注意当物理备数据库以只读模式打开时日志应用服务不能应用重做数据。 

本节包含下述主题： z 开始重做应用 z 停止重做应用 

z 在物理备数据库上监控重做应用 

 

6.3.1 开始重做应用 

要在物理备数据库上开始日志应用服务，确保物理备数据库是启动并安装的，然后使用SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 语句来开始重做应用。 

你能指定重做应用作为前台会话或后台进程运行，并允许它实时应用。 

z 要在前台开始重做应用，执行下面的 SQL 语句： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE；如果你开始一个前台会话，控制不会返回到命令提示符，直到恢复被其它会话取消了。 

z 要在后台开始重做应用，在 SQL 语句中包括 DISCONNECT 关键词。例如： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT； 

 

这条语句开始了一个分离的服务进程并立即返回控制到用户。当管理恢复进程在后台执行恢复，执行RECOVER 语句的前台进程能继续执行其它任务。这不会断开当前的 SQL 会话。 

z 要开始实时应用，在 SQL 语句上包含 USING CURRENT LOGFILE 字句。例如： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT

LOGFILE； 

 

6.3.2 停止重做应用 

要停止重做应用，在其它窗口执行下面的SQL 语句： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL； 

 

6.3.3 在物理备数据库上监控重做应用 

要监控在物理备数据库上的日志应用服务，查看8.5.4 节。你也能使用 Oracle 企业管理器监控备数据库。同时，查看 Oracle 数据库参考以获得视图的完整参考信息。 

 

 

6.4 应用重做数据到逻辑备数据库 

SQL 应用从归档重做日志或备重做日志转换数据到 SQL 语句，然后在逻辑备数据库上执行这些 SQL 语句。因为逻辑备数据库保持打开，维护的表能同时用于其它任务，如报表、总结、和查询。 

本节包含下述主题： z 开始 SQL 应用 

z 在逻辑备数据库上停止 SQL 应用 z 在逻辑备数据库上监控 SQL 应用 

 

6.4.1 开始 SQL 应用 

要开始SQL 应用，启动逻辑备数据库并执行下面语句： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

 

要在逻辑备数据库上开始实时应用，在逻辑备数据库上立即应用从备重做日志文件的重做数据，如下面语句所示包含IMMEDIATE 关键词： 

SQL>  ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

 

6.4.2 在逻辑备数据库上停止 SQL 应用 

要停止SQL 应用，在逻辑备数据库上执行下面语句： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

 
当你执行该语句，SQL 应用等待直到它提交了所有在应该过程中完成的事务。这样，

该命令可能不能立即停止SQL 应用进程。如果你想立即停止 SQL 应用，执行下面语句： 

SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY;

 

6.4.3 在逻辑备数据上监控 SQL 应用 

要监控SQL 应用，查看 9.2 节。你也能使用 Oracle 企业管理器监控备数据库。查看附录 A，“解决 Data Guard 故障”和 Oracle Data Guard Broker。 

同时，查看在8.5.4.3节中的V$ARCHIVE_DEST_STATUS固定视图的相关讨论和Oracle 数据库参考以获得视图相关的完整参考信息。 

7 角色转换 

 

Data Guard 配置包含一个数据库作为主角色以及一个或更多数据库作为备角色。典型地，每个数据库的角色不会更改。然而，如果 Data Guard 是用于维护对主数据库停机响应的服务，你必须在配置中发起当前主数据库和一个备数据库之间的角色转换。要查看数据库的当前角色，查询 V$DATABASE 视图中的 DATABASE_ROLE 列。 

在Data Guard 配置中的备数据库的数量、位置、和类型（物理或逻辑），以及重做数据以哪种方式从主数据库传送到每个备数据库，决定了你用于响应主数据库停机可用的角色管理选项。 

本章描述了如何在Data Guard 配置中管理角色转换。包含下述主题： z 角色转换介绍 z 包含物理备数据库的角色转换 z 包含逻辑备数据库的角色转换 

z 在角色转换之后使用闪回数据库 

在本章中描述的角色转换使用SQL 语句手工调用。你也能使用 Oracle Data Guard broker 来简化角色转换和自动化故障转移。 

 

同时查看： 

Oracle Data Guard Broker 以获得使用 Oracle Data Guard broker 的相关信息： 

z 通过允许你使用在Oracle企业管理器中单键点击或DGMGRL命令行界面中的单条命令简化切换和故障转移。 

z 当主数据库变得不可用时，允许快速启动故障转移来自动故障转移。当允许快速启动故障转移时，Data Guard broker 确定是否需要故障转移并自动发起故障转移到指定的目标备数据库，而不需要 DBA 介入也没有数据丢失。 

 

 

 

7.1 角色转换介绍 

数据库操作于下面互斥的角色之一：主或备。Data Guard 允许你通过执行本章中描述的

SQL 语句或通过使用任何一个 Data Guard broker 界面，来动态更改这些角色。Oracle Data

Guard 支持下述角色转换： 

z 切换 

允许主数据库切换角色到它的备数据库之一。在切换期间没有数据丢失。在切换之后，每个数据库继续以其新的角色参与在Data Guard 配置中。 

z 故障转移 

更改备数据库到主角色响应主数据库的故障。如果主数据库在故障之前没有操作在最大保护模式或最大可用性模式，可能发生数据丢失。如果在主和备数据库上都允许Flashback 数据库，一旦故障的原因更正了，故障的数据库可用恢复作为新的主数据库的备库。 

7.1.1 节，“准备角色转换（故障转移或切换）”帮助你选择最佳地减小宕机时间和数据丢失风险的角色转换。切换和故障转移在 7.1.3 节，“切换”和 7.1.4 节，“故障转移”中相应地更详细地描述。 

 

7.1.1 准备角色转换（故障转移或切换） 

在开始任何角色转换之前，执行下述准备： 

z 对每个数据库检查初始化参数是否正确配置。查看第 3 章，“创建物理备数据库” 和第 4 章，“创建逻辑备数据库”以获得在主和备数据库上如何配置初始化参数，使得 Data Guard 配置在角色转换之后正确操作。 

同时，查看3.1.3 节，“配置备重做日志”以获得在创建物理备数据库时手工添加重做日志文件的相关信息。 

 

注：     你必须在每个备数据库上定义 LOG_ARCHIVE_DEST_n 和

LOG_ARCHIVE_DEST_STATE_n 参数，使得当切换或故障发生时，所有备站点继续从新的主数据库接收重做数据。查看 5.4.1 节，“使用 VALID_FOR 属性指定基于角色的目的地”和第 14 章，“LOG_ARCHIVE_DEST_n 参数属性”以获得使用 LOG_ARCHIVE_DEST_n 

VALID_FOR 属性来定义基于角色的目的地，以为将来的角色转换做准备。 

 

 

z 检验将成为新的主数据库的备数据库是操作于 ARCHIVELOG 模式。 

z 确保存在于备数据库的临时文件符合在主数据库上的临时文件。 

z 删除任何在应用重做中的延迟，这可能会影响将会成为新的主数据库的备数据库。 

z 检验在 Real Application Clusters 配置中的备数据库上除了一个 RAC 实例以外都关

闭。 

对于Real Application Clusters 数据库，在角色转换过程中备数据库上只有一个 RAC 实例能联机。在开始角色转换之前关闭所有其它实例。然后，在角色转换完成后，将这些实例联机。 

 

注： 

    即使在切换期间备数据库上只有一个 RAC 实例是打开的，所有其它备数据库实例在打开时，还将自动经历一个正确转换到它们的新角色的过程。 

 

 

7.1.2 为角色转换选择目标备数据库 

对于使用多个备数据库的Data Guard 配置，当为角色转换选择目标备数据库时需要考虑许多因素。包括如下： z 备数据库的本地性。 

z 备数据库的能力（硬件规格——如 CPU 数目、可用 I/O 带宽、等等）。 

z 执行角色转换所需的时间。这受离备数据库后面多远（用重做数据的应用衡量），以及你有多大的灵活性（用应用可用性与数据丢失的折衷衡量）的影响。 

Data Guard 提供了 V$DATAGUARD_STATS 视图，能用于估计每个备数据库的生存能力，用备数据库中数据的流通衡量，以及如果所有可用的重做数据库应用到备数据库，执行角色转换所需的时间。例如： 

SQL> COLUMN NAME FORMAT A18

SQL> COLUMN VALUE FORMAT A16

SQL> COLUMN TIME_COMPUTED FORMAT A24

SQL> SELECT * FROM V$DATAGUARD_STATS;

NAME                  VALUE               TIME_COMPUTED

------------------ ----------------  ------------------------ apply finish time  +00 00:00:02.4    15-MAY-2005 10:32:49        second(1)

       interval apply lag            +00 0:00:04       15-MAY-2005 10:32:49        second(0)        interval transport lag       +00 00:00:00      15-MAY-2005 10:32:49        second(0)

       interval

 

这显示了对于这个备数据库，没有传输延迟，日志应用服务没有应用在过去的4 秒中

生成的重做（apply lag），日志应用服务将使用 2.4 秒来完成应用未应用的重做（apply finish time）。在每个统计的时间在 TIME_COMPUTED 列中显示。如果配置包含物理和逻辑备数据库，考虑选择物理备数据库作为目标备数据库。向物理备数据库的切换或故障转移是更可取的，因为在角色转换完成后，配置中的所有数据库对于新的主数据库作为备数据库是可行的。然而切换或故障转移到逻辑备数据库将会使其它物理备数据库对于原主数据库无效。然后在能够重允许物理备数据库之前，你将需要从新的主数据库的备份重建物理备数据库。 

 

7.1.3 切换 

切换典型地用于在计划的停机期间减少主数据库宕机时间，如操作系统或硬件升级，或Oracle 数据库软件和补丁集的滚动升级（在第 11 章，“使用 SQL 应用来升级 Oracle 数据库”）。 

切换以两个阶段发生。在第一个阶段，现有的主数据库经历向备角色的转换。在第二个阶段，备数据库经历向主角色的转换。 

图7－1 显示了在数据库角色切换前的两站点 Data Guard 配置。主数据库位于 San

Francisco，备数据库位于 Boston。 

图7－1 在切换前的Data Guard 配置 

 

 

图7－2 显示了在原主数据库切换到备数据库后，但是在原备数据库成为新的主数据库之前的 Data Guard 环境。在这个步骤，Data Guard 配置临时有两个备数据库。 

图7－2 在切换到新的主数据库之前的备数据库 

 

 

图7－3 显示了在切换发生后的 Data Guard 环境。原备数据库成为新的主数据库。主数据库现在位于 Boston，备数据库现在位于 San Francisco。 

图7－3 切换后的Data Guard 环境 

 

 

准备切换 

确保满足在7.1.1 节中列出的先决条件，另外，下面的先决条件必须对切换满足： 

z 对于包含物理备数据库的切换，检验主数据库实例是否打开和备数据库实例是否安装。 

你计划更改到主角色的备数据库在你开始切换之前必须是安装的。理想地，物理备数据库在数据库角色在切换时也将活动地应用重做。如果物理备数据库打开用于只读访问时，切换还将发生，但是需要额外的时间。查看6.3 节，“应用重做数据到物理备数据库”以获得重做应用的更多信息。 

z 对于包含逻辑备数据库的切换，检验主和备数据库实例是否打开以及 SQL 应用是否活动。查看 6.4 节，“应用重做数据到逻辑备数据库”以获得 SQL 应用相关的更多信息。 

z 对于包含在 Real Applications Cluster 中的主数据库的切换，除了一个实例以外所有实例都必须关闭。一旦切换成功执行，你能将所有其它实例联机。 

当数据库从一个角色转换到另一个，DB_ROLE_CHANGE 系统事件会触发。你能写一个触发器关联这个系统事件，以在切换发生后管理任务。当数据库第一次在切换过后打开时该事件触发，不管其新的角色（就是说，不管切换导致其第一次作为主数据库、作为逻辑备、或作为只读模式中的物理备而打开）。你能查询 V$DATABASE 视图的 DATABASE_ROLE 列来确定数据库的当前角色。查看在 Oracle 数据库应用开发指南－基础中的系统管理事件表，以获得更多细节。 

 

7.1.4 故障转移 

只有当主数据库变得不可用，并且没有可能在合理的时间期间内还原以提供服务，才典型地会使用故障转移。在故障转移期间执行的特定操作基于在故障转移中包括的是逻辑或物理备数据库，在故障转移的时候Data Guard 配置的状态，和用于开始故障转移使用的特定 SQL 语句而不同。 

图7－4显示了从San Francisco的主数据库故障转移到Boston的物理备数据库的故障转移的结果。 

图7－4 故障转移到备数据库 

 

 

准备故障转移 

如果可能，在执行故障转移之前，你应该传递尽可能多的可用的和未应用的主数据库重做数据到备数据库。 

确保满足在7.1.1 节，“准备角色转换（故障转移或切换）”中列出的先决条件。另外，对于故障转移，下面的先决条件必须满足： 

z 如果故障转移中包括当前运行在最大保护模式的备数据库，首先通过在备数据库上执行下面语句将其置于最大性能模式： 

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

 

然后，如果有合适的备数据库可用，你能在故障转移完成之后在新的主数据库上重新设置期望的保护模式。 

这是必须的，因为你不能故障转移到一个处于最大保护模式中的备数据库。另外，如果处于最大保护模式中的主数据库还与备数据库有活动联系，执行ALTER

DATABASE 语句来更改备数据库从最大保护模式到最大性能模式将不会成功。因为故障转移将原主数据库从 Data Guard 配置中删除了，所以这些特性服务于保护操作于最大保护模式中的主数据库不受非故意的故障转移的影响。 

 

注： 

不要故障转移到备数据库以测试备数据库是否被正确更新。替代地： z 查看 3.2.7 节，“检验物理备数据库正确执行” z 查看 4.2.6 节，“检验逻辑备数据库正确执行” 

 

 

当数据库从一个角色转换到另一个，DB_ROLE_CHANGE 系统事件会触发。你能写一个触发器关联这个系统事件，以在故障转移发生后管理任务。当数据库第一次在故障转移过后打开时该事件触发，不管其新的角色（在故障转移到物理备数据库的情况下，系统事件在数据库第一次在故障转移操作后打开时触发）。你能查询 V$DATABASE 视图的

DATABASE_ROLE 列来确定数据库的当前角色。查看在 Oracle 数据库应用开发指南－基础中的系统管理事件表，以获得更多细节。 

要执行包含物理备数据库的故障转移，查看7.2.2 节，“包含物理备数据库的故障转移”。要执行包含逻辑备数据库的故障转移，查看 7.3.2 节，“包含逻辑备数据库的故障转移”。要使用 Data Guard Broker 执行故障转移。查看在 Oracle Data Guard Broker 中的“切换和故障转移操作”相关章节。 

 

 

7.2 包含物理备数据库的角色转换 

本节描述如何执行包含物理备数据库的切换和故障转移。 

 

7.2.1 包含物理备数据库的切换 

本小节描述如何执行切换。切换必须在当前主数据库上发起，并且在目标备数据库上完成。下面的步骤描述如何执行切换。 

 

第1 步 检验是否可能执行切换。 

在当前主数据库上，在主数据库上查询V$DATABASE 固定视图的

SWITCHOVER_STATUS 列，以检验是否可能执行切换。例如： SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS 

----------------- 

TO STANDBY 

1 row selected 

 

在SWITCHOVER_STATUS 列中的 TO STANDBY 值指出可能切换主数据库到备角色。如果 TO STANDBY 值没有显示，则检查 Data Guard 配置是否正确起作用（例如，检查所有的 LOG_ARCHIVE_DEST_n 参数值被正确指定）。 

如果在SWITCHOVER_STATUS 列中的值是 SESSIONS ACTIVE，执行在 A.4 节，“切换到备数据库的问题”中描述的步骤，来确定并终止可能阻碍切换处理的活动用户或 SQL

会话。如果，在执行这些步骤之后，SWITCHOVER_STATUS 列还是显示 SESSION ACTIVE，你能通过添加 WITH SESSION SHUTDOWN 子句到步骤 2 中描述的 ALTER DATABASE

COMMIT TO SWITCHOVER TO PHYSICAL STANDBY 语句来成功执行切换。 

查看Oracle 数据库参考以获得 V$DATABASE 视图的 SWITCHOVER_STATUS 列的其它有效值的相关信息。 

 

第2 步 在主数据库上发起切换。 

要更改当前主数据库到物理备数据库角色，在主数据库上使用下面SQL 语句： 

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY; 在这个语句完成后，主数据库转换到备数据库。当前控制文件在切换前备份到当前 SQL 会话跟踪文件。这使得有可能重构当前控制文件，如果必要的话。 

 

第3 步 关闭并重启前主实例。 

关闭前主实例，并重启和安装数据库： 

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

 

在切换过程的这个点，两个数据库都配置为备数据库（查看图 7－2）。 

 

第4 步 检验 V$DATABASE 视图中的切换状态。 

在你更改主数据库到物理备角色，以及配置中的备数据库接收到切换通知之后，你应该检验目标备数据库是否处理切换通知，通过查询目标备数据库上的V$DATABASE 固定视图的 SWITCHOVER_STATUS 列。 

例如： 

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; 

SWITCHOVER_STATUS 

----------------- 

TO_PRIMARY 

1 row selected

 

如果SWITCHOVER_STATUS 列中的值是 SESSION ACTIVE，执行在 A.4 节，“切换到备数据库的问题”中描述的步骤，来确定并终止可能阻碍切换处理的活动用户或 SQL 会话。

如果，在执行这些步骤之后，SWITCHOVER_STATUS 列还是显示 SESSION ACTIVE，你能处理到步骤 5，并过添加 WITH SESSION SHUTDOWN 子句到切换语句。查看 Oracle 数据库参考以获得 V$DATABASE 视图的 SWITCHOVER_STATUS 列的其它有效值的相关信息。 

 

第5 步 切换目标物理备数据库角色到主角色。 

当备数据库实例安装在重做应用模式或对只读访问打开时，你能将物理备数据库从备角色切换到主角色。必须是这些模式之一，主数据库的切换请求才能被调度。在备数据库处于适当的模式，在你希望更改主角色的物理备数据库上，执行下面的SQL 语句： 

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

 

第6 步 完成备数据库到主角色的转换。 

你执行的任务依赖于物理备数据库是否曾经以只读模式打开过： 

z 如果物理备数据库自从上次启动过后没有以只读模式打开过，执行SQL ALTER

DATABASE OPEN 语句来打开新的主数据库： 

SQL> ALTER DATABASE OPEN;

 

然后，跳到步骤7。 

z 如果物理备数据库自从上次启动过后曾经以只读模式打开，你必须关闭目标备数据库并重启： 

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP;

 

目标物理备数据库现在经历到主数据库角色的转换。查看5.4.1 节，“指定有 VALID_FOR 属性的基于角色的目的地”和第 14 章，“LOG_ARCHIVE_DEST_n 参数属性”以获得使用 LOG_ARCHIVE_DEST_n VALID_FOR 属性来确保 Data Guard 配置在角色转换后正确操作的相关信息。 

 

 

注： 

    不需要关闭并重启在切换的时候联机的其它备数据库（不包括在切换中的）。这些备数据库在切换完成后将继续正常起作用。 

 

 

第7 步 如果必要，在备数据库上重启日志应用服务。 

对于新的物理备数据库和Data Guard 配置中的每个其它物理或逻辑备数据库，如果日志应用服务没有预先配置在切换过程中持续打开，使用合适的命令来重启日志应用服务。查看第 6 章，“日志应用服务”以获得如何配置及启动日志应用服务的相关信息。 

 

第8 步 开始发送重做数据到备数据库。在新的主数据库上执行下面语句： 

SQL> ALTER SYSTEM SWITCH LOGFILE;

 

7.2.2 包含物理备数据库的故障转移 

本小节描述如何执行包含物理备数据库的故障转移。 

在包含物理备数据库的故障转移过程中： z 在所有情况中，在故障转移后，原主数据库不能再参与在 Data Guard 配置中。 

z 在大多数情况中，其它逻辑或物理备数据库不直接参与配置中剩余的故障转移，并不必须关闭或重启。 

z 在一些情况中，可能有必要在配置新的主数据库之后重建所有备数据库。 

这些情况在下面的故障转移步骤中的适当位置描述。 

在开始故障转移之前，执行在7.1.4 节，“故障转移”中记录的尽可能多的步骤来为故障转移准备挑选的备数据库，然后进行 7.2.2 节，“包含物理备数据库的故障转移”作为故障转移步骤。 

 

注： 

    Oracle 推荐你只使用在下面小节中描述的故障转移步骤和命令来执行故障转移。不要使用 ALTER DATABASE ACTIVATE STANDBY DATABASE 来执行故障转移，因为这条语句可能导致数据丢失。 

 

 

故障转移步骤 

本小节描述了转换挑选的物理备数据库到主角色必须执行的步骤。任何也是配置中的一部分的其它物理或逻辑备数据库将保留在配置中，并将不需要关闭或重启。 

如果目标备数据库操作于使用日志写进程（LGWR）的最大保护模式或最大可用性模式，在归档重做日志文件中不应该存在中断，你能直接进行到步骤 4。否则，从步骤 1 开始以确定是否必须执行一些手工中断解决步骤。 

 

第1 步 确定并解决归档重做日志文件中的任何中断。 

要在目标备数据库上确定是否在归档重做日志文件中存在中断，查询

V$ARCHIVE_GAP 视图。 

V$ARCHIVE_GAP 视图包含对于每个线程已知丢失的归档重做日志文件的序列号。返回的数据只反映最高的中断。 

例如： 

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM

V$ARCHIVE_GAP;

THREAD#    LOW_SEQUENCE# HIGH_SEQUENCE#

---------- ------------- --------------          1            90             92

 

在这个例子中，中断包括线程1 的归档重做日志文件序号 90、91、和 92。如果可能，从主数据库拷贝所有确定的丢失的归档重做日志文件到目标备数据库，并注册它们。这必须对于每个线程执行。 

例如： 

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

 

第2 步 重复步骤 1 直到解决所有中断。 

在步骤1 中执行的查询只显示最高的中断信息。在解决那个中断后，你必须重复步骤 1

直到查询返回零行。 

 

第3 步 拷贝任何其它丢失的归档重做日志文件。 

要确定是否还有其它丢失的归档重做日志文件，在目标备数据库上查询V$ARCHIVED_LOG 视图以获得每个线程的最高序列号。 

例如： 

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#)

  2> OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

 

    THREAD       LAST

---------- ----------          1        100

 

从包含比目标备数据库上可用的最高序列号更高序列号的主数据库，拷贝任何可用的

归档重做日志文件到目标备数据库并注册它们。这必须对每个线程执行。例如： 

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

 

在所有可用的归档重做日志文件已经注册后，如步骤1 中描述地查询 V$ARCHIVE_GAP 视图，检验没有更多的中断在步骤 3 中引入。 

 

注：     如果，当执行步骤 1 到 3 时，你不能解决在归档重做日志文件中的中断（例如，因为你没有访问故障主数据库所在的系统），在故障转移过程中会发生数据丢失。 

 

 

第4 步 在目标物理备数据库上发起故障转移。 

执行下面语句以发起故障转移： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;

 

FORCE 关键词终止目标物理备数据库上活动的 RFS 进程，使得故障转移能不用等待网络连接超时而立即进行： 

 

注： 

    故障转移添加一个重做结束的标识到最后一个归档的日志文件的头部，并发送重做到所有允许的对于主数据库有效的目的地（使用 VALID_FOR=(PRIMARY_ROLE, *_LOGFILES) 或 VALID_FOR=(ALL_ROLE, *_LOGFILES)属性指定）。 

 

 

 

注： 

    在 SQL 语句中 FINISH 关键词必须跟在所有其它关键词后面，除了 FORCE、WAIT、或 NOWAIT。 

 

 

第5 步 转换物理备数据库到主角色。 

一旦SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE …

FINISH FORCE 语句成功完成，通过执行下面 SQL 语句更改物理备数据库到主数据库： 

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

 

在执行这条SQL 语句之后，目标备数据库经历到主角色的转换。作为结果，你不能再使用这个数据库作为备数据库，并且任何后继的从原主数据库接收的重做不能被应用。再故障转移过程中，备重做日志文件在其它所有从原主数据库导出的备数据库上被自动归档并恢复。只有当备目的地在新的主数据库上正确定义时这才会发生。 

没有必要关闭并重启任何其它在配置中没有参与故障转移的备数据库。 

 

第6 步 完成备数据库到主数据库角色的转换。 

你在本步骤执行的任务依赖于物理备数据库是否曾经以只读模式打开过： 

z 如果物理备数据库自从上次启动过后没有以只读模式打开过，执行SQL ALTER

DATABASE OPEN 语句来打开新的主数据库： 

SQL> ALTER DATABASE OPEN;

 

然后，跳到步骤7。 

z 如果物理备数据库自从上次启动过后曾经以只读模式打开，你必须关闭目标备数据库并重启： 

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP;

 

目标物理备数据库现在经历到主数据库角色的转换。 

查看5.4.1 节，“指定有 VALID_FOR 属性的基于角色的目的地”和第 14 章，

“LOG_ARCHIVE_DEST_n 参数属性”以获得使用 LOG_ARCHIVE_DEST_n VALID_FOR 属性的相关信息，使得 Data Guard 配置在角色转换后正确操作。 

 

第7 步 备份新的主数据库。 

在执行STARTUP 语句之前，备份新的主数据库。立即执行备份是必要的安全措施，因为你无法在没有完整的数据库备份拷贝的情况下，恢复故障转移之后的更改。 

作为故障转移的结果，原数据库不能再参与在Data Guard 配置中，并且所有其它备数据库现在接收和应用从新的主数据库的重做数据。 

 

第8 步 可选地，还原故障的主数据库。 

在故障转移之后，原主数据库不再参与在配置中。在执行故障转移后，你可能将故障的主数据库还原作为新的备数据库，使用下述方法之一： 

使用闪回数据库来还原故障的主数据库到故障转移发生前的时间点，然后遵循12.4 节，

“在故障转移后使用 Flashback 数据库”中的过程将其转换到备数据库。 

 

注： 

    在故障转移前，你必须已经在旧的主数据库上允许 Flashback 数据库。查看 Oracle 数据库备份和恢复基础以获得更多信息。 

 

 

重建故障的数据库并作为新的备数据库将其添加到配置中。要在新的配置中重用旧的主数据库，你必须使用新的主数据库的备份拷贝将其重建为备数据库。这个过程在3.2 节，

“创建物理备数据库的逐步指导”或 4.2 节，“创建逻辑备数据库的逐步指导”中描述。 

使用Oracle 企业管理器或 DGMGRL REINSTATE DATABASE 命令，当连接重新建立时重建故障的主数据库为新配置中的备数据库。恢复的逐步指导在 Oracle Data Guard Broker 中描述。这个选项需要在故障转移前允许闪回数据库。 

一旦故障的主数据库被恢复并运行于备角色，你能选择执行切换以执行数据库的角色转换到它们的原（故障前）角色。查看7.2.1 节，“包含物理备数据库的切换”以获得更多信息。 

 

 

7.3 包含逻辑备数据库的角色转换 

本节描述如何执行包含逻辑备数据库的切换和故障转移。 

 

7.3.1 包含逻辑备数据库的切换 

当你执行切换，在主数据库和逻辑备数据库之间更改角色，总是在主数据库上发起切换并在逻辑备数据库上完成。这些步骤必须以所描述的顺序执行，否则切换将不会成功。 

 

注： 

    如果主数据库是 RAC 数据库，确保除了一个以外关闭所有实例，并且在发起切换之前禁止相应的线程。类似地，如果逻辑备数据库是 RAC 数据库，确保除了一个以外的所有实例关闭 SQL 应用，并且在发起切换之前禁止相应的线程。一旦切换操作成功完成，你能重新允许这些线程并启动实例。虽然实例是关闭的，但是当它们重启时，角色更改将不会自动传递到这些实例。 

 

 

第1 步 在主数据库上检验是否有可能执行切换 

在当前的主数据库上，查询在主数据库上的V$DATABASE 固定视图的

SWITCHOVER_STATUS 列，以检验是否可能执行切换。 

－

例如： 

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS

-----------------

TO STANDBY

1 row selected

 

在SWITCHOVER_STATUS 列中的 TO STANDBY 或 SESSIONS ACTIVE 的值指出可能

切换主数据库到逻辑备角色。如果这些值之一没有显示，则检验Data Guard 配置是否正确起作用（例如，检验所有 LOG_ARCHIVE_DEST_n 参数值是否正确指定）。查看 Oracle 数据库参考以获得 V$DATABASE 视图的 SWITCHOVER_STATUS 列的其它有效值的相关信息。 

 

第2 步 为切换准备当前主数据库。 

要为逻辑备数据库角色准备当前主数据库，在主数据库上执行下面的SQL 语句： 

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;

 

这条语句通知当前主数据库，它将马上切换到逻辑备角色并开始从新的主数据库接收重做数据。你在主数据库上执行这个步骤，为接收LogMiner Multiversioned Data Dictionary 记录在当前逻辑备数据库的重做流中做准备，如步骤 3 中描述。 

如果这个操作成功，则V$DATABASE.SWITCHOVER_STATUS 列中显示 PREPARING SWITCHOVER 值。 

 

第3 步 为切换准备目标逻辑备数据库。 

使用下面命令在作为切换目标的逻辑备数据库上建立LogMiner Multiversioned Data

Dictionary： 

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;

 

这条语句也在逻辑备数据库上开始重做传输服务，开始传送其重做数据到当前主数据

库和Data Guard 配置中的其它备数据库。从这个逻辑备数据库接收重做数据的站点接收重做数据但不应用。 

依赖于完成的工作量和数据库的大小，切换需要花费一些时间来完成。 

当LogMiner Multiversioned Data Dictionary 正在重做流中记录时，在逻辑备数据库上的 V$DATABASE.SWITCHOVER_STATUS 最初显示 PREPARING DICTIONARY。一旦这个成功完成，SWITCHOVER_STATUS 列显示 PREPARING SWITCHOVER。 

 

第4 步 确保当前主数据库为将来的主数据库的重做流做好准备。 

在你能完成主数据库到逻辑备角色的转换之前，通过查询主数据库上的V$DATABASE 固定视图的 SWITCHOVER_STATUS 列，检验 LogMiner Multiversioned Data Dictionary 是否被主数据库接收到。没有收到 LogMiner Multiversioned Data Dictionary，切换无法进行，因为当前的主数据库将不能解释从未来的主数据库发送的重做记录。SWITCHOVER_STATUS 列显示了切换的过程。 

当查询返回TO LOGICAL STANDBY 值，你能进行到步骤 5。例如： 

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

 

SWITCHOVER_STATUS

-----------------

TO LOGICAL STANDBY

1 row selected

 

 

注：你能通过以下面的顺序执行下面的语句来取消切换操作：

1．在主数据库上取消切换：

SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;

2．在逻辑备数据库上取消切换：

SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;

 

 

第5 步 切换主数据库到逻辑备数据库角色。 

要完成主数据库到逻辑备数据库的角色转换，执行下面SQL 语句： 

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

 

这条语句等待主数据库上的所有当前事务结束，并阻止任何新的用户开始新事务，并在切换将要提交的地方建立一个时间点。 

执行这条语句也将阻止用户对由逻辑备数据库维护的数据进行更改。要确保更快地执行，确保主数据库在执行切换语句之前处于安静的状态，没有更新活动（例如，要求所有用户暂时从主数据库退出登录）。你能查询V$TRANSACTIONS 视图以获得任何当前正在处理的事务的状态，这些事务可能延迟这条语句的执行。 

主数据库现在可以经历角色转换以运行到备数据库角色。 

当主数据库经历角色转换到逻辑备数据库角色时，你不需要关闭和重启数据库。 

 

第6 步 确保所有可用的重做应用到将要成为新的主数据库的目标逻辑备数据库上。 

在你完成主数据库到逻辑备角色的角色转换，以及配置中的备数据库接收到切换通知之后，你应该检验切换通知是否被目标备数据库处理，通过查询目标备数据库上的

V$DATABASE 固定视图的 SWITCHOVER_STATUS 列。一旦所有可用的重做记录应用到逻辑备数据库，SQL 应用自动关闭以准备预料中的角色转换。 

SWITCHOVER_STATUS 值更新以显示切换中的过程。当状态为 TO PRIMARY，你能进行步骤 7。 

例如： 

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS

-----------------

TO PRIMARY

1 row selected

 

查看Oracle 数据库参考以获得 V$DATABASE 视图的 SWITCHOVER_STATUS 列的其它有效值的相关信息。 

 

第7 步 切换目标逻辑备数据库到主数据库角色。 

在你希望切换到主角色的逻辑备数据库上，使用下面的SQL 语句来切换逻辑备数据库到主角色： 

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

 

没有必要关闭并重启在Data Guard 配置中的任何逻辑备数据库。其它现有的逻辑备数据库将在切换完成后继续正常起作用。然而，所有现有的物理备数据库在切换后无法参与到

Data Guard 配置中了。 

 

第8 步 在新的逻辑备数据库上开始 SQL 应用。 

在新的逻辑备数据库，开始SQL 应用： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

 

7.3.2 包含逻辑备数据库的故障转移 

本小节描述如何执行包含逻辑备数据库的故障转移。包含逻辑备数据库的故障转移角色转换需要在故障的主数据库和所有旁观逻辑备数据库上执行正确的操作。如果在故障的主数据库上没有允许Flashback 数据库，你必须从当前主数据库获得的备份重建数据库。另外，你能遵照 12.4 节中描述的过程转换故障的主数据库为新的主数据库的逻辑备数据库。 

依赖于配置的保护模式以及你选择的重做传输服务，有可能自动恢复所有或部分主数据库更改。 

如果目标备数据库操作于无数据丢失模式，在归档重做日志文件中将不存在中断，你能直接进行步骤2。否则，从步骤 1 开始以确定是否必须执行手工中断解决步骤。 

 

第1步 拷贝和注册任何丢失的重做日志文件到候选成为新主数据库的目标逻辑备数据库。 

依赖于配置中断组件条件，你可能访问主数据库上的归档重做日志文件。如果可用，做如下操作： 

1．确定在逻辑备数据库上是否丢失归档重做日志文件。 

2．从主数据库拷贝丢失的日志文件到逻辑备数据库。 

3．注册拷贝的日志文件。 

你能通过执行下面的语句来注册归档重做日志文件到逻辑备数据库。例如： 

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 

  2> '/disk1/oracle/dbs/log-%r_%s_%t.arc';

Database altered.

 

第2 步 确保所有可用的归档重做日志文件已应用。 

在你要转换到主角色的逻辑备数据库上，通过查询V$LOGSTDBY_PROGRESS 视图检验所有可用的归档重做日志文件已应用。例如： 

SQL> SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS;

APPLIED_SCN LATEST_SCN

----------- ----------

     190725     190725

 

当APPLIED_SCN 和 LASTEST_SCN 值相等时，所有可得到的数据已应用并且逻辑备数据库现在包含与主数据库可能一样多的数据库。 

注： 

如果在目标逻辑备数据上SQL 应用没有活动，在目标备数据库上执行下面语句以开始

SQL 应用： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY FINISH;

Database altered. 

 

 

查看第 9 章，“管理逻辑备数据库”和第 12 章，“Data Guard 场景”以获得

V$LOGSTDBY_PROGRESS 视图相关信息。 

 

第3 步 允许远程目的地。 

如果你前面没有配置基于角色的目的地，如5.4.1 节，“使用 VALID_FOR 属性指定基于角色的目的地”中所描述，对于新的主数据库确定相应于远程逻辑备目的地的初始化参数，并手工允许对于每个这些目的地的重做数据的归档。 

例如，要允许对于由LOG_ARCHIVE_DEST_2 参数定义的远程目的地的归档，执行下面语句： 

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;

 

要确保这个更改在如果新的主数据库后来重启后还能保持，更新适当的文本初始化参数文件或服务器参数文件。总的来说，当数据库操作于主角色，你必须允许归档到远程目的地，并且当数据库操作于备角色，你必须禁止归档到远程目的地。 

查看5.4.1 节，“使用 VALID_FOR 属性指定基于角色的目的地”和第 14 章，

“LOG_ARCHIVE_DEST_n 参数属性”以获得使用 LOG_ARCHIVE_DEST_n VALID_FOR 属性来定义基于角色的目的地，以为将来的角色转换做准备。 

 

第4 步 激活新的主数据库。 

在目标逻辑备数据库（你转换到新的主角色的）上执行下面的语句： 

SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;

 

这条语句停止RFS 进程，在逻辑备数据库成为主数据库之前应用在备重做日志文件中的剩余重做数据，停止 SQL 应用，并激活数据库为主数据库角色。 

如果没有指定FINISH APPLY 子句，则从当前备重做日志文件未应用的重做在备数据库成为主数据库之前将不会应用。 

 

第5 步 准备恢复其它备数据库。 

依赖于你能够应用多少重做数据到新的主数据库，你可能添加其它现有的逻辑备数据库回到Data Guard 配置以作为备数据库为新的主数据库服务。在每个逻辑备数据库上执行下述步骤以准备添加回到 Data Guard 配置： 

1．在每个逻辑备数据库上创建数据库链接。 

使用ALTER SESSION DISABLE GUARD 语句来绕过数据库守卫并允许对逻辑备数据库中的表的更改。例如，下面创建了到主数据库 chicago 的数据库链接： 

SQL> ALTER SESSION DISABLE GUARD;

SQL> CREATE DATABASE LINK chicago 

  2> CONNECT TO username IDENTIFIED BY password USING 'chicago';

SQL> ALTER SESSION ENABLE GUARD;

 

在CREATE DATABASE LINK 语句中指定的数据库用户帐户必须有在主数据库上的 SELECT_CATALOG_ROLE 角色。 

 

注： 

    在主数据库打开过后但在任何DDL 语句执行之前，你必须执行数据库字典建立操作。如果在字典建立操作执行之前有任何DDL 语句执行，作为创建逻辑备数据的源，备份将变得无效。 

 

 

查看Oracle 数据库管理员指南以获得创建数据库链接的更多相关信息。 

 

2．检验数据库链接。 

在逻辑备数据库，通过使用数据库链接执行下述查询来检验数据库链接是否正确配置： 

SQL> SELECT * FROM DBA_LOGSTDBY_PARAMETERS@chicago;

 

如果查询成功，则确认在步骤1 中创建的数据库链接能在角色转换期间使用。 

 

第6 步 开始 SQL 应用。 

在每个逻辑备数据库上开始SQL 应用。 

例如，下面的语句在chicago 数据库上开始 SQL 应用： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY chicago;

 

当这条语句完成，所有剩余的归档重做日志文件将已经被应用。依赖于要完成的工作，这个操作可能需要一定时间来完成。 

如果返回ORA－16109 错误，你必须从新的主数据库的备份拷贝重新创建逻辑备数据库，然后将其添加到 Data Guard 配置。 

下面的例子显示了在新配置中的逻辑备数据库上开始SQL 应用的失败尝试，chicago 是指向新的主数据库的服务名： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY chicago;

ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY chicago

                                                       *

ERROR at line 1:

ORA-16109: failed to apply log data from previous primary

 

第7 步 备份新的主数据库。 

在Data Guard 数据库故障转移之后立即备份新的主数据库。立即执行备份是必要的安

全措施，因为你不能在没有完整数据库备份拷贝的情况下恢复在故障转移后进行的更改。 

 

第8 步 还原故障的主数据库。 

在执行故障转移之后，你可以选择使用下述方法之一还原故障的主数据库作为新的备数据库： 

z 使用闪回数据库转换故障的主数据库到故障转移发生前的时间点，然后遵循 12.4 节，“在故障转换后使用闪回数据库”中的过程将其转换为备数据库。 

注： 

    在故障转移之前你必须已经在旧的主数据库上允许 Flashback 数据库。查看 Oracle 数据库备份和恢复基础以获得更多信息。 

 

 

z 使用DBMS_LOGSTDBY.REBUILD PL/SQL过程来重建主数据库为新的备数据库。

在你运行该过程之前，你必须检验： 

{ 查询V$STANDBY_LOG或V$LOGFILE视图以检验备重做日志文件已被归档 

{ 查询 DBA_LOGSTDBY_EVENTS 视图以检验 LogMiner 字典建立成功完成 

 

同时查看： 

    在 Oracle 数据库 PL/SQL 包和类型参考中的 DBMS_LOGSTDBY 包以获得 REBUILD 子程序的相关信息 

 

 

z 当连接重新建立时，使用 Oracle 企业管理器或 DGMGRL REINSTATE DATABASE 命令来重建故障的主数据库作为配置中的备数据库。复原的逐步指导在 Oracle Data

Guard Broker 中描述。 

遵循3.2 节，“创建物理备数库的逐步指导”或 4.2 节，“创建逻辑备数据库的逐步指导” 中过程，重建故障的数据库并作为新的备数据库将其添加到配置中。 

一旦故障的主数据库被还原并运行于备角色，你能选择执行切换以转换数据库到它们的原（故障前）角色。查看7.3.1 节，“包含逻辑备数据库的切换”以获得更多信息。 

 

 

7.4 在角色转换后使用 Flashback 数据库 

在角色转换后，你能选择使用FLASHBACK DATABASE 命令来回复数据库到角色转换发生前的时间点或系统更改号（SCN）。 

在物理备数据库环境中，你可能需要闪回主数据库和所有备数据库以维护Data Guard 配置。如果你闪回主数据库到一个特定的 SCN 或时间，你必须闪回所有备数据到同样（或更早）的 SCN 或时间。这样，在开始重做应用后，物理备数据库将自动开始应用从主数据库接收到的重做数据。当以这种方式闪回主或备数据库，你不需要考虑过去的切换。如果

SCN/时间是在过去切换之前，Oracle 能自动跨越过去的切换闪回。 

 

注： 

    在角色转换发生之前必须在数据库上允许 Flashback 数据库。查看 Oracle 数据库备和恢复基础以获得更多信息。 

 

 

7.4.1 在切换后使用 Flashback 数据库 

在切换后，你能使用FLASHBACK DATABASE 命令返回数据库到一个切换发生前的时间或系统更改号（SCN）。 

如果切换包含物理备数据库，主和备数据库角色在闪回操作期间保持不变。就是说，当数据库闪回到你闪回数据库的目标SCN 或时间时，数据运行的角色不能更改。在切换后但是在闪回前运行在物理备角色的数据库，在 Flashback 数据库操作后将还是运行在物理备角色。 

如果切换包含逻辑备数据，闪回更改备数据库的角色到你闪回数据库到的目标SCN 或时间时的状态。 

 

7.4.2 在故障转换后使用 Flashback 数据库 

你能使用Flashback 数据库来回复主数据库到故障转换发生前的时间点，然后将其转换

为备数据库。查看12.4 节，“在故障转换后使用 Flashback 数据库”以获得完整的逐步过程。 

 

 

8 管理物理备数据库 

 

本章描述如何管理物理备数据库。本章包含下述主题： z 启动和关闭物理备数据库 

z 打开备数据库以用于只读或读/写访问 z 管理影响备数据库的主数据库事件 z 通过 OPEN RESETLOGS 语句恢复 z 监控主和备数据库 z 为物理备数据库调优日志应用速度 

在本章中的主题描述如何使用SQL 语句、初始化参数、和视图来管理物理备数据库。 

查看Oracle Data Guard Broker 来使用 Data Guard broker 来自动化本章中描述的管理任务。 

 

 

8.1 启动和关闭物理备数据库 

本节描述了用于启动和关闭物理备数据库的SQL*Plus 语句。 

 

8.1.1 启动物理备数据库 

要启动物理备数据库，使用SQL*Plus 以管理员权限连接到数据库，然后使用 SQL*Plus 的 STARTUP 或 STARTUP MOUNT 语句。当在物理备数据库上使用时： 

z STARTUP 语句启动数据库，作为物理备数据库安装数据库，并打开数据库以用于只读访问。 

z STARTUP MOUNT 语句作为物理备数据库启动并安装数据库，但不打开数据库。 

一旦安装，数据库能接受从主数据库的重做数据。然后你有开始重做应用或实时应用的选项，或打开数据库以用于只读访问。 

例如： 

1． 启动并安装物理备数据库： 

SQL> STARTUP MOUNT;

2． 开始重做应用或实时应用： 

要开始重做应用，执行下面语句： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 

  2> DISCONNECT FROM SESSION;

 

要开始实时应用，执行下面语句： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 

  2> USING CURRENT LOGFILE;

 

在主数据库上，查询V$ARCHIVED_DEST_STATUS 视图中的 RECOVERY_MODE 列，它显示备数据库的操作，对于重做应用是 MANAGED_RECOVERY，对于实时应用是

MANAGED REAL TIME APPLY。 

查看6.3 节以获得重做应用相关信息，6.2.1 节以获得实时应用相关信息，以及 8.2 节以获得打开物理备数据库以用于只读或读/写操作。 

 

注： 

    当你首次在新创建的还没从主数据库接受任何重做数据的物理备数据库上开始重做应用，可能会返回 ORA-01112 信息。这指出重做应用不能确定媒质恢复的开始序列号。如果发生这种情况，你必须在备数据库上手工检索并注册归档重做日志文件，或者等待自动归档在重启重做应用前发生。 

 

 

8.1.2 关闭物理备数据库 

要关闭物理备数据库并停止重做应用，使用SQL*Plus SHUTDOMN 语句。控制没有返回到发起数据库关闭的会话，直到关闭完成。 

如果主数据库启动并运行，延迟主数据库上的目的地并在关闭备数据库之前执行日志切换。 

要在关闭数据库之前停止重做应用，使用下述步骤： 

1．执行下面查询以发现备数据库是执行重做应用还是实时应用。如果 MRP0 或 MRP 进程存在，则备数据库应用重做。 

SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;

 

2．如果重做应用在运行，如下述例子中所示将其取消： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

 

3．关闭备数据库： 

SQL> SHUTDOWN IMMEDIATE;

 

 

8.2 打开备数据库以用于只读或读/写访问 

当备数据库打开以用于只读访问时，用户能查询备数据库当时不能更新。因此，你能通过使用备数据库用于报表用途来减少主数据库上的负载。你能定期地打开备数据库以用于只读访问，并执行特别的查询来检验重做应用正确地更新备数据库。（注意对于分布式查询，在你能在只读数据库上执行查询之前，你必须首先执行ALTER DATABASE SET

TRANSACTION READ ONLY 语句。） 

图8－1 显示了备数据库打开以用于只读访问。 

图8－1 备数据库打开以用于只读访问 

z 打开物理备数据库以用于只读访问 

 

 

物理备数据库能以读/写模式临时地打开以用于开发、报表、或测试用途，然后闪回到过去的点以回复到物理备数据库。当数据库闪回时，Data Guard 自动与主数据库同步备数据库，而不需要从主数据库的备份拷贝重建物理备数据库。 

 

同时查看： 

    12.6 节以获得描述激活物理备数据库作为读/写报表数据库的场景，然后重新与主数据库同步数据库 

 

 

8.2.1 评估是否打开备数据库 

当你决定是否打开物理备数据库以用于只读或读/写访问，考虑下面： 

z 只读打开物理备数据库可能延长从故障或断电恢复所需的时间，因为数据库必须

在故障转换后重启。 

只要物理备数据库自从上次启动后没有只读打开过，在故障转换后没有必要重启，因而增加系统可用性。 

z 当备数据库打开以用于只读或读/写访问，它不应用从主数据库接受的重做数据，

因而它没有与主数据库保持事务一致性。 

当物理备数据库打开时，从主数据库的重做数据由备数据库接收，但是日志文件不被应用。在一些点上，你需要在备数据库上继续重做应用，并应用归档重做日志文件以重新与主数据库同步备数据库。因为应用任何累积的归档重做日志文件需要额外的时间，将备数据库打开以用于只读访问能增加完成故障转移或切换所需的时间。 

如果你在备系统上配置超过一个备数据库，你能使用物理备数据库以用于报表用途或作为克隆数据库的同时也维持快速完成故障转移或切换的能力。 

例如，基于你的业务需求，你可能： z 配置两个物理备数据库，一个备数据库总是执行重做应用，与主数据库尽可能保持一致，另一个备数据库在业务时间以只读模式打开以用于报表用途。 

z 配置一个物理备数据库来维护主数据库的拷贝以用于灾难恢复用途，并同时配置一个逻辑备数据库来减负需要从主数据库访问最近的数据的报表任务。 

当在同一系统配置超过一个备数据库，考虑使用LOG_ARCHIVE_DEST_n 初始化参数的 DEPENDENCY 属性来定义一个归档目的地来代表所有目的地接收重做数据，而不是传送重做数据到每个单独目的地。查看 5.7.5 节以获得更多信息。 

 

8.2.2 打开物理备数据库以用于只读访问 

你能使用下述过程在将物理备数据库打开以用于只读访问和执行重做应用之间切换。 

 

要备数据库当前关闭时打开以用于只读访问： 

使用下面语句启动、安装、并打开数据库以用于只读访问： 

SQL> STARTUP;

 

当备数据库当前执行重做应用时打开以用于只读访问： 

1． 取消重做应用： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

 

    2．打开数据库以用于只读访问： 

SQL> ALTER DATABASE OPEN;

 

你不需要关闭实例来打开以用于只读访问。 

 

注： 

    默认地，ALTER DATABASE OPEN 语句以只读模式打开物理备数据库。Oracle 数据库基于控制文件中的信息确定这是否是物理备数据库。 

 

 

要从打开以用于只读访问更改备数据库到执行重做应用： 

1．在备数据库上终止所有活动的用户会话。 

2．重启重做应用。要开始重做应用，执行下面语句： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

  2> DISCONNECT FROM SESSION;

 

要允许实时应用，包括USING CURRENT LOGFILE 子句： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

  2> USING CURRENT LOGFILE;

 

你不需要关闭实例来开始任何这些应用模式之一。 

 

 

8.3 管理影响备数据库的主数据库事件 

要防止可能的问题，你必须注意在主数据库上影响备数据库的事件，并学习如何响应它们。本节描述这些事件和对于这些事件建议的响应。在一些情况中，在主数据库上发生的事件或更改自动通过重做数据传播到备数据库，因而在备数据库上不需要额外的操作。在其它情况中，你可能需要在备数据库上执行维护任务。 

表8－1 指出在主数据库上进行的更改是否需要数据库管理员（DBA）额外的介入来传播到备数据库。也能很简短地描述如何响应这些事件。响应的详细描述在提供的小节参考中描述。 

下面的事件由重做传输服务和重做应用自动管理，因此不需要数据库管理员的介入： z 使用 ENABLE THREAD 或 DISABLE THREAD 子句执行的 SQL ALTER

DATABASE 语句。 

z 表空间的状态更改（更改到读/写或只读，置于联机或脱机）。 

z 当 STANDBY_FILE_MANAGEMENT 初始化参数设为 AUTO 时，添加数据文件或创建表空间。 

表8－1 在更改到主数据库后需要在备数据库上的操作 

参考	在主数据库上进行的更改	在备数据库上需要的操作
8.3.1 节	添加数据文件或创建表空间	如果你没有设置STANDBY_FILE_MANAGEMENT初始化参数为 AUTO，你必须拷贝新数据文件到备数据库。
8.3.2 节	删去或删除表空间或数据文件	在包含 DROP 或 DELETE 命令的归档重做日志文件应用后从主和备数据库删除数据文件。
8.3.3 节	使用可传输表空间	在主和备数据库之间移动表空间。
8.3.4 节	重命名数据文件	在备数据库上重命名数据文件。
8.3.5 节	添加或删除重做日志文件	在备数据库上同步更改。
8.3.6 节	使用 NOLOGGING 或 UNRECOVERABLE 子句执行 DML 或 DDL 操作	发送包含未记录更改的数据文件到备数据库。
第 13 章	更改初始化参数	动态更改备参数或关闭备数据库并更新初始化参数。

 

8.3.1 添加数据文件或创建表空间 

初始化参数，STANDBY_FILE_MANAGEMENT，允许你控制是否向主数据库的添加数据文件自动传播到备数据库，如下： 

z 如果你在备数据库服务器参数文件（SPFILE）中设置

STANDBY_FILE_MANAGEMENT 初始化参数为 AUTO，则任何在主数据库上创建的新数据文件一样自动创建在备数据库上。 

z 如果你没有指定 STANDBY_FILE_MANAGEMENT 初始化参数，或者你设置为

MANUAL，则当你添加数据文件到主数据库时你必须手工拷贝新数据文件到备数据库。 

注意如果你从其它数据库拷贝现有的数据文件到主数据库，则你必须也拷贝新数据文件到备数据库并重建备控制文件，不管STANDBY_FILE_MANAGEMENT 初始化参数的设置。 

下面小节提供了当STANDBY_FILE_MANAGEMENT 初始化参数分别设置为 AUTO 和

MAMUAL 时，添加数据文件到主数据库的例子。 

 

8.3.1.1 当 STANDBY_FILE_MANAGEMENT 设为 AUTO 时 

下面的例子显示了当STANDBY_FILE_MANAGEMENT 初始化参数设置为 AUTO 时添

加新数据文件到主和备数据库所需的步骤。 

1．添加新表空间到主数据库： 

SQL> CREATE TABLESPACE new_ts DATAFILE

'/disk1/oracle/oradata/payroll/t_db2.dbf'

  2> SIZE 1m AUTOEXTEND ON MAXSIZE UNLIMITED;

 

2．归档当前的联机重做日志文件，使得重做数据将被传送到并在备数据库上应用： 

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

 

3．检验新数据文件添加到主数据库： 

SQL> SELECT NAME FROM V$DATAFILE;

NAME

--------------------------------------------------------------

/disk1/oracle/oradata/payroll/t_db1.dbf

/disk1/oracle/oradata/payroll/t_db2.dbf

 

4．检验新数据文件添加到备数据库： 

SQL> SELECT NAME FROM V$DATAFILE;

NAME

--------------------------------------------------------------

/disk1/oracle/oradata/payroll/s2t_db1.dbf

/disk1/oracle/oradata/payroll/s2t_db2.dbf 

8.3.1.2 当 STANDBY_FILE_MANAGEMENT 设为 MANUAL 时本小节显示当STANDBY_FILE_MANAGEMENT 初始化参数设为 MANUAL 时，如何

添加新数据文件到主和备数据库。当备数据文件位于裸设备上时，你必须设置

STANDBY_FILE_MANAGEMENT 初始化参数为 MANUAL。本小节也描述如何在错误发生后从错误中恢复。 

 

注：     不要在使用 Oracle Managed Files 的数据库上使用下面的过程。同样，如果在主和备服务器上的裸设备路径名不是相同，使用 DB_FILE_NAME_CONVERT 初始化参数来转换路径名。 

 

 

8.3.1.2.1 使用带裸设备的 STANDBY_FILE_MANAGEMENT 参数通过设置 STANDBY_FILE_MANAGEMENT 参数为 AUTO，不管新数据文件在主数据库上是添加还是删除，相应的更改在备数据库上就进行，不需要手工介入。只要备数据库使用文件系统这就是正确的。如果备数据库使用裸设备作为数据文件，则

STANDBY_FILE_MANAGEMENT 初始化参数将继续工作，但是需要手工介入。这个手工介入包括确保，裸设备在备数据库上的日志应用服务恢复将要创建新数据文件的重做数据之前存在。在主数据库上，创建新的表空间，其数据文件位于裸设备。在同一时间，在备数据库上创建同样的裸设备。例如： 

SQL> CREATE TABLESPACE MTS2 DATAFILE '/dev/raw/raw100' size 1m;

Tablespace created.

 

SQL> ALTER SYSTEM SWITCH LOGFILE;  System altered.

 

备数据库当作裸设备已经存在，自动添加数据文件。备警告日志显示如下： 

Fri Apr  8 09:49:31 2005

Media Recovery Log

/u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1

_mf_1_7_15ffgt0z_.arc

Recovery created file /dev/raw/raw100 Successfully added datafile 6 to media recovery

Datafile #6: '/dev/raw/raw100'

Media Recovery Waiting for thread 1 sequence 8 (in transit)

 

然而，如果裸设备在主系统上但是没有在备上创建，则MRP 进程将会由于文件创建错

误关闭。例如，在主数据库上执行下面语句： 

SQL> CREATE TABLESPACE MTS3 DATAFILE '/dev/raw/raw101' size 1m;

Tablespace created.

 

SQL> ALTER SYSTEM SWITCH LOGFILE; System altered.

 

备系统还没有创建/Dave/raw/raw101 裸设备。备警告日志在恢复归档时显示下述信息： 

Fri Apr  8 10:00:22 2005

Media Recovery Log

/u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1

_mf_1_8_15ffjrov_.arc

File #7 added to control file as 'UNNAMED00007'.

Originally created as:

'/dev/raw/raw101'

Recovery was unable to create the file as:

'/dev/raw/raw101'

MRP0: Background Media Recovery terminated with error 1274

Fri Apr  8 10:00:22 2005

Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc:

ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created

ORA-01119: error in creating database file '/dev/raw/raw101'

ORA-27041: unable to open file

Linux Error: 13: Permission denied

Additional information: 1

Some recovered datafiles maybe left media fuzzy

Media recovery may continue but open resetlogs may fail

Fri Apr  8 10:00:22 2005

Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc:

ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created

ORA-01119: error in creating database file '/dev/raw/raw101'

ORA-27041: unable to open file

Linux Error: 13: Permission denied

Additional information: 1

Fri Apr  8 10:00:22 2005

MTS; MRP0: Background Media Recovery process shutdown ARCH: Connecting to console port...

 

8.3.1.2.2 从错误中恢复 

要纠正8.3.1.2.1 节中描述的问题，执行下面步骤： 

1．在备数据库上创建裸分区，并赋予权限给 Oracle 用户。 

2．查询 V$DATAFILE 视图。例如： 

SQL> SELECT NAME FROM V$DATAFILE;

 

NAME

--------------------------------------------------------------

/u01/MILLER/MTS/system01.dbf

/u01/MILLER/MTS/undotbs01.dbf

/u01/MILLER/MTS/sysaux01.dbf

/u01/MILLER/MTS/users01.dbf

/u01/MILLER/MTS/mts.dbf

/dev/raw/raw100

/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007

 

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

 

SQL> ALTER DATABASE CREATE DATAFILE

2 '/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007'

3 AS

4 '/dev/raw/raw101';

 

3．在备警告日志中你应该看到类似如下的信息： 

Fri Apr  8 10:09:30 2005 alter database create datafile

'/dev/raw/raw101' as '/dev/raw/raw101'

Fri Apr  8 10:09:30 2005

Completed: alter database create datafile

'/dev/raw/raw101' a 

 

4．在备数据库上，设置 STANDBY_FILE_MANAGEMENT 为 AUTO 并重启重做应用： 

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT;

 在这个点重做应用使用新的裸设备数据库并且恢复继续。 

 

8.3.2 删去表空间和删除数据文件 

当你在主数据库删除一个或更多数据文件或者删去一个或更多表空间时，你也需要删

除备数据库中的相应数据文件。下面小节提供了当STANDBY_FILE_MANAGEMENT 初始化参数设为 AUTO 或 MANUAL 时，删去表空间和删除数据文件的例子。 

 

8.3.2.1 当 STANDBY_FILE_MANAGEMENT 设为 AUTO 或 MANUAL 时不管STANDBY_FILE_MANAGEMENT 初始化参数设为 AUTO 还是 MANUAL 下面过

程都起作用，如下： 

1．从主数据库删除表空间 

SQL> DROP TABLESPACE tbs_4; SQL> ALTER SYSTEM SWITCH LOGFILE;

 

2．确保重做应用正在运行（使得更改应用到备数据库）。如果下面查询返回 MRP 或 MRP0 进程，重做正在运行。 

SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;

 要检验删除的数据文件不再是数据库的一部分，查询 V$DATAFILE 视图。 

 

3．在归档重做日志文件应用到备数据库上后，在备系统上删除相应的数据文件。例如： 

% rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf

 

4．在主数据库上，在确保备数据库应用删除表空间的重做信息的，你能删除表空间的

数据文件。例如： 

% rm /disk1/oracle/oradata/payroll/tbs_4.dbf 

8.3.2.2 使用 DROP TABLESPACE INCLUDING CONTENTS AND

DATAFILES 你能在主数据库上执行SQL DROP TABLESPACE INCLUDING CONTENTS AND

DATAFILES 语句来在主和备数据库上同时删除数据文件。要使用这个语句， STANDBY_FILE_MANAGEMENT 初始化参数必须设为 AUTO。例如，要在主站点删去表空间： 

SQL> DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES tbs_4;

SQL> ALTER SYSTEM SWITCH LOGFILE;

 

8.3.3 使用带物理备数据库的可传输表空间 

你能使用Oracle 可传输表空间特性来移动 Oracle 数据库的一个子集，并插入其它Oracle

数据库，根本地在数据库之间移动表空间。 

当使用物理备时，要移动并拷贝一系列表空间到主数据库，执行下述步骤： 

 

1．生成一个包含要传输表空间集的数据文件的可传输表空间集，和包含该表空间集的结构信息的导出文件。 

2．传输表空间集： a．拷贝数据文件和导出文件到主数据库。 

b．拷贝数据文件到备数据库。 

数据文件必须拷贝到由DB_FILE_NAME_CONVERT 初始化参数定义的目录。如

果没有定义DB_FILE_NAME_CONVERT，则在包含可传输表空间的重做数据应用并失败后，执行 ALTER DATABASE RENAME FILE 语句来更改备控制文件。

STANDBY_FILE_MANAGEMENT 初始化参数必须设为 AUTO。 

    3．插入表空间。 

调用Data Pump 工具来插入表空间集到主数据库。重做数据将生成并应用到备站

点以插入表空间到备数据库。 

对于可传输表空间相关的更多信息，查看Oracle 数据库管理员指南。 

 

8.3.4 在主数据库中重命名数据文件 

当你在主数据库中重命名一个或更多数据文件时，更改没有传播到备数据库。因此，

如果你想在备数据库上重命名同样的数据文件，你必须手工在备数据库上进行等同的更改，因为该更改不会自动执行，即使STANDBY_FILE_MANAGEMENT 初始化参数设为 AUTO。下述步骤描述了如果在主数据库中重命名数据文件和手工传播更改到备数据库。 

1．要在主数据库中重命名数据文件，将表空间脱机： 

SQL> ALTER TABLESPACE tbs_4 OFFLINE;

 

2．从 SQL 提示符退出并执行操作系统命令，如下面的 UNIX mv 命令，来在主数据库上重命名数据文件： 

% mv /disk1/oracle/oradata/payroll/tbs_4.dbf 

/disk1/oracle/oradata/payroll/tbs_x.dbf

 

3．在主数据库中重命名数据文件并将表空间联机： 

SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE      

2> '/disk1/oracle/oradata/payroll/tbs_4.dbf' 

  3>  TO '/disk1/oracle/oradata/payroll/tbs_x.dbf'; SQL> ALTER TABLESPACE tbs_4 ONLINE;

 

4．连接到备数据库，查询 V$ARCHIVED_LOG 视图来检验所有归档重做日志文件都被应用了，然后停止重做应用： 

SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY

SEQUENCE#;

SEQUENCE# APP

--------- ---

8 YES

9 YES

10 YES

11 YES

4 rows selected.

 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

 

5．关闭备数据库： 

SQL> SHUTDOWN;

 

6．在备站点使用操作系统命令重命名数据文件，如 UNIX mv 命令： 

% mv /disk1/oracle/oradata/payroll/tbs_4.dbf

/disk1/oracle/oradata/payroll/tbs_x.dbf

 

7．启动并安装备数据库： 

SQL> STARTUP MOUNT;

 

8．重命名备控制文件中的数据文件。注意 STANDBY_FILE_MANAGEMENT 初始化参数必须设置为 MANUAL。 

SQL> ALTER DATABASE RENAME FILE

'/disk1/oracle/oradata/payroll/tbs_4.dbf' 

  2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';

 

9．在备数据库上，重启重做应用： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

  2> DISCONNECT FROM SESSION;

 

如果你没有在备系统上重命名相应的数据文件，然后试图刷新备数据库控制文件，备

数据库将会企图使用重命名的数据文件，但是它将无法找到。因此，你将在警告日志中看到类似于如下的错误信息： 

ORA-00283: recovery session canceled due to errors

ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file

ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'

 

8.3.5 添加或删除联机重做日志文件 

有时需要更改联机重做日志文件的大小和数目来调优数据库。你能向主数据库添加联

机重做日志文件组或成员而不影响备数据库。类似地，你能从主数据库删去日志文件组或成员而不影响你的备数据库。然而，这些更改在切换后影响备数据库的性能。 

 

注意：     无论何时你添加一个联机重做日志文件到主数据库，你应该添加相应的联机和备重做日志文件到备数据库。 

 

 

例如，如果主数据库有10 个联机重做日志文件，备数据库有 2 个，然后你切换到备数

据库使得其作为新的主数据库起作用，新的主数据库被迫比原主数据库更频繁地归档。因此，当你在主站点添加或删除一个联机重做日志文件，通过下面这些步骤在备数据库中同步更改是很重要的：     1．如果重做应用正在运行，你必须在你能更改日志文件之前取消重做应用。 

2．如果 STANDBY_FILE_MANAGEMENT 初始化参数设为 AUTO，更改该值为

MANUAL。 

3．添加或删去一个联机重做日志文件： z 要添加一个联机重做日志文件，使用如下的 SQL 语句： 

SQL> ALTER DATABASE ADD LOGFILE

'/disk1/oracle/oradata/payroll/prmy3.log' SIZE 100M

 

z 要删去一个联机重做日志文件，使用如下的 SQL 语句： 

SQL> ALTER DATABASE DROP LOGFILE

'/disk1/oracle/oradata/payroll/prmy3.log';

 

4．在每个备数据库上充分你在步骤 3 中使用的语句。 

5．还原 STANDBY_FILE_MANAGEMENT 初始化参数和重做应用选项到它们的原始状态。 

 

8.3.6 NOLOGGING 或不可恢复的操作 

当你使用NOLOGGING 或 UNRECOVERABLE 子句执行 DML 或 DDL 操作，备数据库变得无效并行可能需要很多地 DBA 管理活动来修复。你能指定带 FORCELOGGING 子句的 SQL ALTER DATABASE 或 SQL ALTER TABLESPACE 语句来覆盖 NOLOGGING 设置。

然而，该语句将不会修复已经无效的数据库。 

查看12.10 节以获得在使用 NOLOGGING 子句之后恢复相关的信息。 

 

 

8.4 通过 OPEN RESETLOGS 语句恢复 

Data Guard 允许在物理备数据库上的恢复在主数据库以 RESETLOGS 选项打开后继续。当在主数据库上执行ALTER DATABASE OPEN RESETLOGS语句时，数据库的化身改变了，创建了新的重做数据分支。 

当物理备数据库接受到新的重做数据分支，重做应用自动取得新的重做数据分支。对于物理备数据库，如果备数据库没有应用新的重置日志SCN 以前的重做数据（新的重做数据分支起点以前），则不需要手工介入。下面的表描述如何与主数据库分支重新同步备数据库。 

 

如果备数据库… 则… 执行这些步骤…

 

还没有应用新的重置日志 SCN 重做应用自动取得新的以前的重做数据（新的重做数据 重做分支。  分支起点以前）	没有手工介入的必要。MRP 自动与新 的重做数据分支的备数据库重新同步。
已经应用了新的重置日志 SCN 备数据库恢复到新的重以前的重做数据（新的重做数据 做数据分支的后面。  分支起点以前）并且在备数据库上允许 Flashback 数据	1． 遵循在 12.5 节中的过程来闪回物理备数据库。  2． 重启重做应用来继续重做数据的应用到新的重置日志分支。  MRP 自动与新的分支重新同步备数据库。

已经应用了新的重置日志SCN主数据库在指出的主数遵循在第 3 章中的过程重建物理备数以前的重做数据（新的重做数据 据库分支从备数据库分据库。 

分支起点以前）并且在备数据库 叉。 

上没有允许Flashback 数据 

从新的重做数据分支丢失介于MRP 不能继续直到检索 从每个分支定位并注册丢失的归档期间的归档重做日志文件 到丢失的日志文件。 重做日志文件。 

从前面重做数据分支的结尾丢MRP 不能继续直到检索 从前面的分支定位并注册丢失的归失归档重做日志文件 到丢失的日志文件。 档重做日志文件。 

 

 

查看Oracle 数据库备份和恢复高级用户指导以活动数据库化身的更多相关信息，通过

OPEN RESETLOGS 操作恢复，和 Flashback 数据库。 

 

 

8.5 监控主和备数据库 

本节给你一个概述，从中可以找到用于监控在Data Guard 环境中的主和备数据库的信息。 

本节包含下述主题： z 警告日志 z 动态性能视图（固定视图） z 监控恢复过程 z 监控在物理备数据库上的日志应用服务 

表8－2 总结了通常在主数据库上出现的事件，它们指向文件和视图，从那里你能监控这些在主和备站点上的事件。 

表8－2 定位在主数据库上哪里能监控普通活动 

主数据库事件	主站点信息	备站点信息
指定 ENABLE THREAD 或 DISABLE THREAD 子句的 SQL ALTER DATABASE 语 句执行了	z 警告日志 z V$THREAD 视图	警告日志
当前数据库角色，保护模式和级别，切换状态，和快速启动故障转移信息	V$DATABASE	V$DATABASE
重做日志更改了	z 警告日志 z V$LOG 视图 z V$LOGFILE 视图的 STATUS 列	警告日志
CREATE CONTROLFILE 语句执行了	警告日志	警告日志
管理的恢复执行了	警告日志	警告日志
表空间状态更改了（改为读 /写或只读，置于联机或脱机	z DBA_TABLESPACES 视图 z 警告日志	V$RECOVER_FILE 视图
数据文件添加或表空间创建	z DBA_DATA_FILES 视图 z 警告日志	z V$DATAFILE 视图 z 警告日志
表空间删去	z DBA_DATA_FILES 视图 z 警告日志	z V$DATAFILE 视图 z 警告日志
表空间或数据文件脱机，或数据文件被删除脱机	z V$RECOVER_FILE 视图 z 警告日志  z DBA_TABLESPACES	z V$RECOVER_FILE 视图 z DBA_TABLESPACES
重命名数据文件	z V$DATAFILE  z 警告日志	z V$DATAFILE 视图 z 警告日志
未记录的或不可恢复的操作	z V$DATAFILE 视图 z V$DATABASE 视图	警告日志
恢复过程	z V$ARCHIVE_DEST_STATUS 视图 z 警告日志	z V$ARCHIVED_LOG 视图 z V$LOG_HISTORY 视图 z V$MANAGED_STANDBY 视图 z 警告日志
重做传输状态和过程	z V$ARCHIVE_DEST_STATUS 视图  z V$ARCHIVED_LOG 视图 z V$ARCHIVE_DEST 视图 z 警告日志	z V$ARCHIVED_LOG 视图 z 警告日志
自动扩展数据文件	警告日志	警告日志
执行 OPEN RESETLOGS 或 CLEAR UNARCHIVED LOGFILES 语句	警告日志	警告日志
更改初始化参数	警告日志	警告日志

 

8.5.1 警告日志 

数据库警告日志是信息和错误的按时间排序的记录。除了提供Oracle 数据库相关信息以外，它也包括 Data Guard 特定操作的相关信息，包括如下： 

z 管理操作如下面 SQL 语句：ALTER DATABASE RECOVER MANAGED

STANDBY，STARTUP，SHUTDOWN，ARCHIVE LOG，和 RECOVER 的相关信息 

z 由后台进程如 ARC0，MRP0，RFS，LGWR 报告的管理操作的相关错误 z 管理操作的完整时间戳 

警告日志也提供指向由指定进程生成的跟踪或转储文件。 

 

8.5.2 动态性能视图（固定视图） 

Oracle 数据库包含一系列基础视图。这些视图经常被称为动态性能视图，因为它们是在数据库打开和使用中是连续更新的，并且它们的内容主要与性能相关。这些视图也称为固定视图，因为它们不能被数据库管理员更改或删除。 

这些视图名字以V$或 GV$前缀，例如，V$ARCHIVE_DEST 或 GV$ARCHIVE_DEST。 

标准动态性能视图（V$固定视图）存储本地实例相关信息。相对地，全局动态性能视图（GV$固定视图）存储在 Real Applications Cluster（RAC）中所有打开实例的相关信息。每个 V$固定视图有一个相应的 GV$固定视图。在 GV$固定视图上的选择使用并行查询从进程来获得所有实例上的信息。查看第 16 章，“Oracle Data Guard 相关视图”和“Oracle 数据库参考”以获得额外信息。 

 

8.5.3 监控恢复过程 

本小节显示在8.5.2 节中讨论的视图类型的一些例子，以用来监控 Data Guard 环境中的

恢复过程。它包含下述例子： z 监控进程活动 z 确定重做应用过程 z 确定归档重做日志文件的位置和创建者 

z 查看 OPEN RESETLOGS 前后的数据库化身 z 查看归档重做日志历史 z 确定哪些日志文件被应用到备数据库 

z 确定哪些日志文件还没有被备站点接收到 

 

8.5.3.1 监控进程活动 

在备数据库上你能通过监控由下述进程执行的活动来获得重做应用相关的信息： 

参考名字	系统进程名字
ARCH	ARC0, ARC1, ARC2,…
MRP	MRP, MRP0
RFS	ORACLE{SID}

 

在备数据库站点上的V$MANAGED_STANDBY 视图显示给你在 Data Guard 环境中重

做传输和重做应用进程执行的活动。在下面查询输出中的CLIENT_P 列确定了相应的主数据库进程。 

SQL> SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM

V$MANAGED_STANDBY;

 

PROCESS CLIENT_P  SEQUENCE# STATUS

------- -------- ---------- ------------ ARCH    ARCH              0 CONNECTED

ARCH    ARCH              0 CONNECTED

MRP0    N/A             204 WAIT_FOR_LOG

RFS     LGWR            204 WRITING

RFS     N/A               0 RECEIVING

 

8.5.3.2 确定重做应用的过程在主或备数据库站点上的V$ARCHIVE_DEST_STATUS 视图提供给你信息，如已归档的联机重做日志文件，已应用的归档重做日志文件，和每个日志序列号。下述查询输出显示备数据库应用从主数据库接收的重做数据落后两个归档重做日志文件。 

SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#,

APPLIED_SEQ#

  2> FROM V$ARCHIVE_DEST_STATUS;

 

ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ#

---------------- ------------- --------------- ------------ 1                947           1               945

 

8.5.3.3 确定归档重做日志文件的位置和创建者在备数据库上查询V$ARCHIVED_LOG 视图来找到归档重做日志相关的额外信息。你能获得的一些信息包括归档重做日志的位置，那个进程创建归档重做日志，每个归档重做日志文件的重做日志序列号，每个日志文件何时归档，以及归档重做日志文件是否被应用。例如： 

SQL> SELECT NAME, CREATOR, SEQUENCE#, APPLIED, COMPLETION_TIME 

  2> FROM V$ARCHIVED_LOG;

 

NAME                                                    CREATOR SEQUENCE#

APP COMPLETIO

----------------------------------------------  ------- ---------

--- ---------

H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00198.001  ARCH          198

YES 30-MAY-02

H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00199.001  ARCH          199

YES 30-MAY-02

H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00200.001  ARCH          200

YES 30-MAY-02

H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00201.001  LGWR          201

YES 30-MAY-02

H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00202.001  ARCH          202

YES 30-MAY-02

H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00203.001  LGWR          203

YES 30-MAY-02

 

6 rows selected.

 

8.5.3.4 查看 OPEN RESETLOGS 前后的数据库化身在备数据库上查询V$DATABASE_INCARNATION 视图来监控数据库化身和

RESETLOGS_ID 列。 

在主数据库上执行OPEN RESETLOGS 语句之前在备数据库上执行下述查询： 

SQL> SELECT INCARNATION#, RESETLOGS_ID, STATUS FROM

V$DATABASE_INCARNATION ;

 

INCARNATION# RESETLOGS_ID STATUS

------------ ------------ ------- 

1 509191005 PARENT 

2 509275501 CURRENT

 

SQL> SELECT RESETLOGS_ID,THREAD#,SEQUENCE#,STATUS,ARCHIVED FROM

V$ARCHIVED_LOG

  2  ORDER BY RESETLOGS_ID,SEQUENCE# ;

 

RESETLOGS_ID  THREAD#  SEQUENCE# S ARC

------------  -------  --------- - ---- 

   509275501        1          1 A YES

   509275501        1          2 A YES

   509275501        1          3 A YES

   509275501        1          4 A YES

   509275501        1          5 A YES 

 

5 rows selected.

 

在主数据库上执行OPEN RESETLOGS 语句之后在备数据库上执行下述查询，并且备

数据库开始在新的重做分支接受重做数据： 

SQL> SELECT INCARNATION#, RESETLOGS_ID, STATUS FROM

V$DATABASE_INCARNATION ;

 

INCARNATION# RESETLOGS_ID STATUS

------------ ------------ -------

1 509191005 PARENT

2 509275501 PARENT

3 509278970 CURRENT   

 

SQL> SELECT RESETLOGS_ID,THREAD#,SEQUENCE#,STATUS,ARCHIVED FROM

V$ARCHIVED_LOG

  2  ORDER BY RESETLOGS_ID,SEQUENCE# ;

 

RESETLOGS_ID  THREAD#  SEQUENCE# S ARC

------------  -------  --------- - ---

   509275501        1          1 A YES

   509275501        1          2 A YES

   509275501        1          3 A YES

   509275501        1          4 A YES

   509275501        1          5 A YES

   509278970        1          1 A YES

   509278970        1          2 A YES

   509278970        1          3 A YES 8 rows selected.

 

8.5.3.5 查看归档重做日志历史在备站点上的V$LOG_HISTORY 显示给你一个归档重做日志的完整历史，包括如第一个条目的时间，日志中最低的 SCN，日志中最高的 SCN，和归档重做日志文件的序列号。 

SQL> SELECT FIRST_TIME, FIRST_CHANGE#, NEXT_CHANGE#, SEQUENCE# FROM

V$LOG_HISTORY;

 

FIRST_TIM FIRST_CHANGE# NEXT_CHANGE#  SEQUENCE#

--------- ------------- ------------ ----------

13-MAY-02        190578       214480          1

13-MAY-02        214480       234595          2

13-MAY-02        234595       254713          3 .

.

.

30-MAY-02       3418615      3418874        201

30-MAY-02       3418874      3419280        202

30-MAY-02       3419280      3421165        203 203 rows selected.

 

8.5.3.6 确定哪些日志文件被应用到备数据库在备数据库上查询V$LOG_HISTORY 视图，它记录已应用的最近的日志序列号。例如，

执行下述查询： 

SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG"

  2> FROM V$LOG_HISTORY

  3> GROUP BY THREAD#;

 

THREAD# LAST_APPLIED_LOG

------- ----------------       1              967

 

在这个例子中，日志序列号967 的归档重做日志文件是最近应用的日志文件。你也能在备数据库上使用 V$ARCHIVED_LOG 固定视图的 APPLIED 列来找出哪些日

志文件被应用到备数据库上。例如： 

SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG; 

   THREAD#  SEQUENCE# APP 

---------- ---------- --- 

         1          2 YES 

         1          3 YES 

         1          4 YES 

         1          5 YES 

         1          6 YES 

         1          7 YES 

         1          8 YES 

         1          9 YES 

         1         10 YES           1         11 NO  10 rows selected.

 

8.5.3.7 确定哪些日志文件还没有被备站点接收到每个归档目的地有一个分配给它的目的地ID。你能查询 V$ARCHIVE_DEST 固定视图

的DEST_ID 列来找出你的目的地 ID。然后你能在主数据库上的查询中使用这个目的地 ID 来找到还没有发送到特定备站点的日志文件。例如，假设在你的主数据库上的当前本地归档目的地 ID 是 1，你的远程备数据库之一的目的地 ID 是 2。要找到哪些日志文件还没有被这个备目的地接收到，在主数据库上执行下述查询： 

SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM 

  2> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1)

LOCAL 

  3>  WHERE LOCAL.SEQUENCE# NOT IN 

  5> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND 

  6> THREAD# = LOCAL.THREAD#); 

THREAD#  SEQUENCE# 

---------- ----------    1        12 

  1        13 

  1        14 

 前面所述例子显示了还没有被备目的地 2 接受到的日志文件。 

 

8.5.4 监控在物理备数据库上的日志应用服务 

要监控在物理备数据上的日志应用服务的状态，查询在本小节中描述的固定视图。你

也能使用Oracle 企业管理器 GUI 来监控备数据库。 

本小节包含下述主题： 

z 访问 V$DATABASE 视图 z 访问 V$MANAGED_STANDBY 固定视图 z 访问 V$ARCHIVE_DEST_STATUS 固定视图 z 访问 V$ARCHIVED_LOG 固定视图 z 访问 V$LOG_HISTORY 固定视图 z 访问 V$DATAGUARD_STATUS 固定视图 

同时，查看Oracle 数据库参考以获得视图相关的完整参考信息。 

 

8.5.4.1 访问 V$DATABASE 视图 

执行下述查询来显示保护模式、保护级别、数据库的角色、和切换状态相关的信息： 

SQL> SELECT DATABASE_ROLE, DB_UNIQUE_NAME INSTANCE, OPEN_MODE, 

       PROTECTION_MODE, PROTECTION_LEVEL, SWITCHOVER_STATUS 

       FROM V$DATABASE;

 

执行下述查询来显示快速启动故障转移相关的信息： 

SQL> SELECT FS_FAILOVER_STATUS FSFO_STATUS,

FS_FAILOVER_CURRENT_TARGET TARGET_STANDBY,

FS_FAILOVER_THRESHOLD THRESHOLD, 

       FS_FAILOVER_OBSERVER_PRESENT OBS_PRES 

       FROM V$DATABASE;

 

8.5.4.2 访问 V$MANAGED_STANDBY 固定视图查询物理备数据库来在备站点监控重做应用和重做传输服务活动。 

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS

  2> FROM V$MANAGED_STANDBY;

 

PROCESS STATUS       THREAD#   SEQUENCE#  BLOCK#   BLOCKS

------- ----------- -------- ---------- -------- ---------- RFS     ATTACHED      1          947         72         72

MRP0    APPLYING_LOG 1          946         10         72

 

前面的查询输出显示RFS 进程完成归档序列号 947 的日志文件。输出也显示重做应用

正活动应用一个序列号946 的归档重做日志文件。恢复操作当前正在恢复 72 个块的归档重做日志文件中的第 10 号块。 

 

8.5.4.3 访问 V$ARCHIVE_DEST_STATUS 固定视图 

要快速确定备数据库的同步级别，在物理备数据库上执行下述查询： 

SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#,

APPLIED_SEQ#

  2> FROM V$ARCHIVE_DEST_STATUS;

 

ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ#

---------------- ------------- --------------- ------------ 1                947           1               945

 

前面的查询输出显示备数据库落后于主数据库两个归档重做日志文件。 

要确定是否允许实时应用，查询V$ARCHIVE_DEST_STATUS 视图的 RECOVERY_MODE 列。当允许实时应用时它将包含值为 MANAGED REAL TIME APPLY，如下面例子所示： 

SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE

DEST_ID=2 ;

 

RECOVERY_MODE

-----------------------

MANAGED REAL TIME APPLY

 

8.5.4.4 访问 V$ARCHIVED_LOG 固定视图物理备数据库上的V$ARCHIVED_LOG 固定视图显示所有从主数据库接收到的归档重做日志文件。该视图只有在备站点开始接收重做数据才有用；在那个时间以前，该视图由从主控制文件生成的旧的归档重做日志记录构成。例如，你能执行下述 SQL*Plus 语句： 

SQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#,

  2> NEXT_CHANGE# FROM V$ARCHIVED_LOG;

 

REGISTRAR CREATOR THREAD#    SEQUENCE#  FIRST_CHANGE# NEXT_CHANGE# --------- ------- --------- ---------- ------------- ------------ RFS        ARCH    1            945          74651          74739

RFS        ARCH    1            946          74739          74772 RFS        ARCH    1            947          74772          74774

 前面的查询输出显示从主数据库接收三个归档重做日志文件。 

 

8.5.4.5 访问 V$LOG_HISTORY 固定视图在物理备数据库上查询V$LOG_HISTORY 固定视图来显示所有已应用的归档重做日志

文件。 

SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#

  2> FROM V$LOG_HISTORY;

 

THREAD#    SEQUENCE#  FIRST_CHANGE# NEXT_CHANGE# --------- ---------- ------------- ------------ 1           945          74651          74739

 前面的查询输出显示最近应用的归档重做日志文件是序列号 945。 

 

8.5.4.6 访问 V$DATAGUARD_STATUS 固定视图 

    V$DATAGUARD_STATUS 固定视图显示了典型地可能被任何消息触发到警告日志或服务进程跟踪文件的事件。 

下面的例子显示了在主数据库上从V$DATAGUARD_STATUS 视图的输出： 

SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;

 

MESSAGE

-----------------------------------------------------------------

ARC0: Archival started

ARC1: Archival started

Archivelog destination LOG_ARCHIVE_DEST_2 validated for no-data-loss recovery

Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2'

ARCH: Transmitting activation ID 0

LGWR: Completed archiving log 3 thread 1 sequence 11

Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2'

LGWR: Transmitting activation ID 6877c1fe

LGWR: Beginning to archive log 4 thread 1 sequence 12

ARC0: Evaluating archive   log 3 thread 1 sequence 11

ARC0: Archive destination LOG_ARCHIVE_DEST_2: Previously completed ARC0: Beginning to archive log 3 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_1:

'/oracle/arch/arch_1_11.arc'

ARC0: Completed archiving  log 3 thread 1 sequence 11 ARC1: Transmitting activation ID 6877c1fe 15 rows selected.

 

下面的例子显示了在物理被数据库上从V$DATAGUARD_STATUS 视图的内容： 

SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;

 

MESSAGE

-----------------------------------------------------------------

ARC0: Archival started

ARC1: Archival started

RFS: Successfully opened standby logfile 6: '/oracle/dbs/sorl2.log'

ARC1: Evaluating archive   log 6 thread 1 sequence 11 ARC1: Beginning to archive log 6 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_1:

'/oracle/arch/arch_1_11.arc'

ARC1: Completed archiving  log 6 thread 1 sequence 11

RFS: Successfully opened standby logfile 5: '/oracle/dbs/sorl1.log'

Attempt to start background Managed Standby Recovery process Media Recovery Log /oracle/arch/arch_1_9.arc

 

10 rows selected.

 

 

8.6 为物理备数据库调优日志应用速度 

考虑使用下述方法来优化应用重做到物理备数据库所需的时间。同时，查看Oracle

Media Recovery Best Practices 白皮书以获得更多信息： http://otn.oracle.com/deploy/availability/htdocs/maa.htm.

 

在一个备主机上设置并行恢复为CPU 数目的两倍 

在媒质恢复或重做应用期间，重做日志文件被读取，需要重做应用的数据块被分析出来。使用并行媒质恢复，这些数据块连续平均分布到所有恢复进程来被读取到高速缓存。默认是串行恢复或零并行度，这意味这同一恢复进程读取重做，从磁盘读取数据块，并应用重做更改。要实施并行媒质恢复或重做应用，添加可选的PARALLEL 子句到恢复命令。进一步地，

设置数据库参数PARALLEL_MAX_SERVERS 为最少的并行度。下面例子显示了如何设置恢复并行度： 

RECOVER STANDBY DATABASE PARALLEL #CPUs * 2; 你应该比较多个串行和并行恢复运行以确定最优的恢复性能。 

 

为快速重做应用率设置DB_BLOCK_CHECKING=FALSE

在备或媒质恢复期间设置DB_BLOCK_CHECKING=FALSE 参数能提供几乎两倍的应用速度。在恢复过程中缺少块校验必须是可接收的风险。块校验应该在主数据库上允许。

DB_BLOCK_CHECKSUM=TRUE（默认值）应该在生产和备数据库上都允许。因为

DB_BLOCK_CHECKING 参数是动态的，它能在不关闭备数据库的情况下转换。 

 

设置PARALLEL_EXECUTION_MESSAGE_SIZE=4096

当使用并行媒质恢复或并行备恢复，增加PARALLEL_EXECUTION_MESSAGE_SIZE 数据库参数为 4K（4096）能增加并行恢复大概百分之二十的性能。在主和备数据库上同时设置这个参数是为了切换操作做准备。增加这个参数每个并行执行从进程需要更多共享池中的内存。 

并行查询操作也使用PARALLEL_EXECUTION_MESSAGE_SIZE 参数，应该与一些并行查询操作一起测试以确保在系统上有足够的内存。在 32 位安装上的大量并行查询从进程可能会达到内存限制并禁止 PARALLEL_EXECUTION_MESSAGE_SIZE 从默认的 2K

（2048）增加到 4K。 

 

调优磁盘I/O

在恢复期间遇到的最大瓶颈是读和写I/O。要释放这个瓶颈，使用本地异步 I/O 并设置数据库参数 DISK_ASYNCH_IO 为 TRUE（默认值）。DISK_ASYNCH_IO 参数控制到数据文件的磁盘 I/O 是否是异步的。异步 I/O 应该能显著地降低数据库文件并行读，并且应该改进整个恢复时间。 

 

 

9 管理逻辑备数据库 

 

本章包含下述主题： 

z SQL 应用架构概述 z 管理和监控逻辑备数据库相关的视图 z 监控逻辑备数据库 z 定制逻辑备数据库 z 管理逻辑备数据库环境下的特定工作负载 z 调优逻辑备数据库 

 

 

9.1 SQL 应用架构概述 

SQL 应用使用一些并行执行服务器和后台进程的集合来应用从主数据库的更改到逻辑备数据库。 

图9－1 显示了信息的流和每个进程执行的角色。 

图9－1 SQL 应用过程 

 

 

包括的不同进程和它们在日志提取与应用过程期间的作用如下：在日志提取期间： 

z READER 进程从归档重做日志文件或备重做日志文件读取重做记录。 

z PREPARER 进程转换在重做记录中包含的块更改为逻辑更改记录（LCRs）。对于给定的归档重做日志文件或备重做日志文件能有多个 PREPARER 进程激活。LCRs 驻留在系统全局区（SGA）的共享池中，称为 LCR 缓存。 

z BUILDER 进程组织 LCRs 为事务，并执行其它任务，如 LCR 缓存中的内存管理，

SQL 应用重启相关的检查点和过滤不感兴趣的更改。 

在应用过程期间： 

z ANALYZER 进程检查包含一组 LCRs 的事务块，可能过滤出不感兴趣的事务，并识别不同事务之间的依赖性。 

z COORDINATOR 进程（LSP）： 

{ 分配事务 

{ 监控事务间的依赖性并协调调度 

{ 批准更改向逻辑备数据库的提交 z APPLIER 进程： 

{ 应用 LCRs 到数据库 

{ 要求 COORDINATOR 进程批准有未解决依赖性的事务 

{ 提交事务 

你能查询V$LOGSTDBY_PROCESS 事务来检查 SQL 应用过程的活动。提供当前活动信息的其它视图是 V$LOGSTDBY_STATS 视图，其显示逻辑备数据库在 SQL 应用活动期间的状态信息。这些和其它相关视图在 9.2 节，“管理和监控逻辑备数据库”中更详细地讨论。 

 

9.1.1 对于 SQL 应用的不同考虑 

本小节包含下述主题： z 事务大小考虑 z 页面交换考虑 z 重启考虑 

z DML 应用考虑 z DDL 应用考虑 

 

9.1.1.1 事务大小考虑 

SQL 应用划分事务为两类：小的和大的： 

z 小事务——SQL 应用一旦遇到重做日志文件中事务的提交记录就开始应用属于小事务的 LCRs。 

z 大事务——SQL 应用分开大事务为小的片称为事务块，并在重做日志文件中看到的大事务的提交记录之前开始应用块。这是为了减少LCR 缓存上的内存压力并减少整个故障转移时间。 

例如，不分开到小片的话，SQL*Loader 转载一千万行，每行大小 100 字节，可能会在 LCR 缓存中使用超过 1GB 内存。如果分配给 LCR 缓存的内存小于 1GB，就会导致 LCR 缓存的页面交换。 

除了内存考虑以外，如果SQL 应用不开始应用一千万行 SQL*Loader 装载相关的更改，直到遇到事务的 COMMIT 记录，就可能会停止角色转换。在事务提交之后发起的切换或故障转移无法完成，直到 SQL 应用在逻辑备数据库上应用了事务。 

所有的事务一开始被分类为小事务。依赖与LCR 缓存可用的内存数量和属于一个事务的 LCR 使用的内存数量，SQL 应用确定何时重新分类一个事务为大事务。 

 

9.1.1.2 页面交互考虑 

页面交互出现在SQL 应用的环境中，当 LCR 缓存中的内存用尽了并且需要释放空间给

SQL 应用向前处理。 

例如，假设分配给LCR 缓存的内存是 100MB，并且 SQL 应用遇到一个的 INSERT 事务，有一个 300MB 大小的 LONG 列。在这个情况下，日志提取组件将会页面交换出 LONG 数据的第一部分来读取列更改的后面部分。在一个优化好的逻辑备数据库中，页面交换活动只会偶尔出现并且应该不影响系统的整个吞吐量。 

 

同时查看：     查看 9.4 节，“定制逻辑备数据库”以获得如何确定造成问题的页面交换并执行正确的操作的更多相关信息。 

 

 

9.1.1.3 重启考虑 

向逻辑备数据库的更改不会变得持久，直到事务的提交记录从重做日志文件中提取到并应用到逻辑备数据库。因此，每次SQL 应用停止时，不管是作为用户指令的结果还是因为系统故障，SQL 应用必须返回并再次提取最早的未提交的事务。 

在事务做很少工作但是保持长时间打开的情况下，重启SQL 应用的代价十分惊人。这是因为 SQL 应用可能必须再次提取大量归档重做日志文件，仅仅是为了读取少量未提交事务的重做数据。要减轻这个，SQL 应用定时地检查点旧的未提交的数据。在检查点进行的 SCN 反应在 V$LOGSTDBY_PROGRESS 视图的 RESTART_SCN 列中。随着重启，SQL 应用开始提取比 RESTART_SCN 列中所示的值更高的 SCN 上生成的重做记录。对于重启不需要的归档重做日志文件被 SQL 应用自动删除。 

通常的工作负载，如大的DDL 事务，并行 DML 语句（PDML），以及直接路径装载，将阻止 RESTART_SCN 在工作负载期间前进。 

 

9.1.1.4 DML 应用考虑 

SQL 应用当应用影响逻辑备数据上的吞吐量和延迟的 DML 事务时有如下特性： 

z 在单语句导致多行更改的地方，在主数据库上的批量更新或删除，在逻辑备数据库上作为单独行更改而应用。因此，对于每个维护的表必须有唯一或主键。查看

4.1.2 节，“确保在主数据库上的表行能被唯一标识”以获得更多信息。 z 在主数据库上直接路径插入在逻辑备数据库上使用常规 INSERT 语句。 

z 并行 DML（PDML）事务在逻辑备数据库上不以并行执行。 

 

9.1.1.5 DDL 应用考虑 

SQL 应用当应用影响逻辑备数据上的吞吐量和延迟的 DDL 事务时有如下特性： z 并行 DDL（PDDL）事务在逻辑备数据库上不以并行执行。 

z DDL 事务在逻辑备数据库上串行应用。因此，在主数据库上并行应用的 DDL 事务在逻辑备数据库上一次应用一个。 

z 如执行 CREATE TABLE AS SELECT(CTAS)那样的语句，DML 活动（CTAS 语句的一部分）在逻辑备数据库上被抑制。插入到新建立的表中的行作为 CTAS 语句的一部分被从重做日志文件中提取并使用 INSERT 语句应用到逻辑备数据库中。 

 

 

9.2 管理和监控逻辑备数据库相关的视图 

下面性能视图监控维护逻辑备数据库的SQL 应用的行为。下述小节描述了能用于监控逻辑备数据库的关键视图： 

z DBA_LOGSTDBY_EVENTS 视图 z DBA_LOGSTDBY_LOG 视图 z V$LOGSTDBY_STATS 视图 

z V$LOGSTDBY_PROCESS 视图 z V$LOGSTDBY_PROGRESS 视图 z V$LOGSTDBY_STATE 视图 

z V$LOGSTDBY_STATS 视图 

 

9.2.1 DBA_LOGSTDBY_EVENTS 视图 

DBA_LOGSTDBY_EVENTS 视图记录在 SQL 应用操作期间发生的感兴趣的事件。默认地，该视图记录最近的 100 个事件。然而，你能通过调用 DBMS_LOGSTDBY.APPLY_SET() PL/SQL 过程来更改记录事件的数目。如果 SQL 应用应该未预料地停止，问题的原因也记录在该视图中。 

 

注： 

    造成 SQL 应用停止的错误记录在这个事件表中。这些事件也记录到 ALERT.LOG 中，以 LOGSTDBY 关键词包含在文本中。当查询视图时，以 EVENT_TIME_STAMP、

COMMIT_SCN、CURRENT_SCN 排序选择列。该顺序确保关闭故障出现在视图的最后面。

 

 

该视图也包含其它信息，如哪些DDL 事务被应用以及哪些被跳过了。例如： 

SQL> ALTER SESSION SET NLS_DATE_FORMAT  = 'DD-MON-YY HH24:MI:SS'; Session altered.

SQL> COLUMN STATUS FORMAT A60

SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS

  2  ORDER BY EVENT_TIMESTAMP, COMMIT_SCN;

 

EVENT_TIME         STATUS

----------------------------------------------------------------- EVENT

-----------------------------------------------------------------

23-JUL-02 18:20:12 ORA-16111: log mining and apply setting up 23-JUL-02 18:25:12 ORA-16128: User initiated shut down successfully completed

23-JUL-02 18:27:12 ORA-16112: log mining and apply stopping 23-JUL-02 18:55:12 ORA-16128: User initiated shut down successfully completed

23-JUL-02 18:57:09 ORA-16111: log mining and apply setting up

23-JUL-02 20:21:47 ORA-16204: DDL successfully applied create table hr.test_emp (empno number, ename varchar2(64)) 23-JUL-02 20:22:55 ORA-16205: DDL skipped due to skip setting  create database link link_to_boston connect to system identified by change_on_inst 7 rows selected.

 

上面查询显示SQL 应用多次开始和停止。它也显示哪些 DDL 被应用和跳过了。如果 SQL 应用停止了，查询中的最后记录将显示问题的原因。 

 

同时查看： 

    Oracle 数据库参考中的 DBA_LOGSTDBY_EVENTS 视图。 

 

 

9.2.2 DBA_LOGSTDBY_LOG 视图 

DBA_LOGSTDBY_LOG 视图提供了被 SQL 应用处理的归档日志的动态相关信息。 

例如： 

SQL> COLUMN DICT_BEGIN FORMAT A10;

SQL> SET NUMF 9999999

SQL> SELECT FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS FCHANGE#, 

     NEXT_CHANGE# AS NCHANGE#, TIMESTAMP, -

     DICT_BEGIN AS BEG, DICT_END AS END, -

     THREAD# AS THR# FROM DBA_LOGSTDBY_LOG -

     ORDER BY SEQUENCE#;

FILE_NAME                    SEQ# F_SCN    N_SCN TIMESTAM BEG END THR# APPLIED

------------------------- ---- ------- ------- -------- --- --- --- ---------

/oracle/dbs/hq_nyc_2.log  2     101579  101588 11:02:58 NO  NO  1    

YES

/oracle/dbs/hq_nyc_3.log  3     101588  142065 11:02:02 NO  NO  1    

YES

/oracle/dbs/hq_nyc_4.log  4     142065  142307 11:02:10 NO  NO  1     YES

/oracle/dbs/hq_nyc_5.log  5     142307  142739 11:02:48 YES YES 1     YES

/oracle/dbs/hq_nyc_6.log  6     142739  143973 12:02:10 NO  NO  1    

YES

/oracle/dbs/hq_nyc_7.log  7     143973  144042 01:02:11 NO  NO  1    

YES

/oracle/dbs/hq_nyc_8.log  8     144042  144051 01:02:01 NO  NO  1    

YES

/oracle/dbs/hq_nyc_9.log  9     144051  144054 01:02:16 NO  NO  1     YES

/oracle/dbs/hq_nyc_10.log 10    144054  144057 01:02:21 NO  NO  1     YES

/oracle/dbs/hq_nyc_11.log 11    144057  144060 01:02:26 NO  NO  1 

CURRENT

/oracle/dbs/hq_nyc_12.log 12    144060  144089 01:02:30 NO  NO  1  CURRENT

/oracle/dbs/hq_nyc_13.log 13    144089  144147 01:02:41 NO  NO  1       NO

 

在BEG 和 END 列中的 YES 条目指出 LogMiner dictionary build 在日志文件序列号 5 开始。最近的归档重做日志文件是序列号 13，并且它是在 01：02：41 在逻辑备数据库上接收到的。APPLIED 列指出 SQL 应用已经应用了在 SCN144057 以前的所有重做。因为事务能跨多个归档日志文件，所以可以有多个归档日志文件在 APPLIED 列中显示 CURRENT 值。同时查看： 

    Oracle 数据库参考中的 DBA_LOGSTDBY_LOG 视图 

 

 

9.2.3 V$LOGSTDBY_STATUS 视图 

该视图提供了逻辑备数据库的故障转移特性的相关信息，包括： 

到故障转移的时间（apply finish time） 

在逻辑备数据库中已提交的数据有多新（lag time）在灾难发生的情况下可能会丢失什么数据（potential data loss） 

例如： 

SQL> SELECT NAME, VALUE, TIME_COMPUTED FROM V$LOGSTDBY_STATS;

        

NAME                VALUE            TIME_COMPUTED

------------------  --------------   --------------------- apply finish time   +00 00:00:00.1   07-APR-2005 08:29:23 lag time            +00 00:00:00.1   07-APR-2005 08:29:23 potential data loss +00 00:00:00     07-APR-2005 08:29:23

 

每个显示的列的单位（量度）以天（2）到秒（1）为间隔。输出确认一个逻辑备数据库紧跟于主数据库后在 0.1 秒之内，并且在主数据库故障的情况下没有数据丢失会发生。 

 

同时查看： 

    Oracle 数据库参考中的 V$LOGSTDBY_STATS 视图 

 

 

9.2.4 V$LOGSTDBY_PROCESS 视图 

该视图提供涉及SQL 应用的不同进程的当前状态的相关信息，包括： z 确认信息（sid | serial# | spid） 

z SQL 应用进程：COORDINATOR、READER、BUILDER、PREPARER、ANALYZER、或 APPLIER（type） 

z 进程当前活动的状态（status_code | status） z 这个进程处理的最高重做记录（high_scn）例如： 

SQL> COLUMN LID FORMAT 9999

SQL> COLUMN SERIAL# FORMAT 9999

SQL> COLUMN SID FORMAT 9999

SQL> SELECT SID, SERIAL#, LOGSTDBY_ID AS LID, SPID, TYPE, HIGH_SCN

FROM V$LOGSTDBY_PROCESS;

 

  SID   SERIAL#   LID   SPID         TYPE             HIGH_SCN

  ----- -------  ----- -------- --------------- ----------

   48        6     -1    11074      COORDINATOR     7178242899    56       56      0    10858      READER           7178243497

   46        1      1    10860      BUILDER          7178242901

   45        1      2    10862      PREPARER         7178243295

   37        1      3    10864      ANALYZER         7178241034

   36        1      4    10866      APPLIER          7178239467

   35        3      5    10868      APPLIER          7178239463

   34        7      6    10870      APPLIER          7178239461

   33        1      7    10872      APPLIER          7178239472

 

9 rows selected.

 

HIGH_SCN 列显示读进程在所有其它进程之前，并且 PREPARER 和 BUILDER 进程在剩余的前面。 

SQL> COLUMN STATUS FORMAT A40

SQL> SELECT TYPE, STATUS_CODE, STATUS FROM V$LOGSTDBY_PROCESS;

 

TYPE             STATUS_CODE STATUS

------------- ----------- ----------------------------------------- COORDINATOR          16117 ORA-16117: processing

READER                16127 ORA-16127: stalled waiting for additional                              transactions to be applied

BUILDER               16116 ORA-16116: no work available

PREPARER              16116 ORA-16117: processing

ANALYZER              16120 ORA-16120: dependencies being computed for                              transaction at SCN 0x0001.abdb440a APPLIER               16124 ORA-16124: transaction 1 13 1427 is waiting                              on another transaction

APPLIER               16121 ORA-16121: applying transaction with commit                              SCN 0x0001.abdb4390

APPLIER               16123 ORA-16123: transaction 1 23  1231 is waiting

                             for commit approval

APPLIER               16116 ORA-16116: no work available

 

输出显示SQL 应用运行的快照。在提取一边，READER 进程在它能读取更多内存之前

等待额外的可用内存，PREPARER 进程处理重做记录，并且 BUILDER 进程没有可用的工作。在应用一边，COORDINATOR 分配更多的事务给 APPLIER 进程，ANALYZER 计算 SCN 7178241034 处的依存关系，一个 APPLIER 没有可用的工作，而其它两个有还未解决的还没有满足的依存关系。 

 

同时查看： 

    Oracle 数据库参考中的 V$LOGSTDBY_PROCESS 以获得参考信息和 9.3.1 节，“监控

SQL 应用过程”以获得例子输出 

 

 

9.2.5 V$LOGSTDBY_PROGRESS 视图 

该视图提供了SQL 应用进展的过程的相关详细信息，包括： z SCN 或时间，在那个点所有在主数据库上已经提交的事务已经应用到逻辑备数据库上（applied_scn | applied_time） 

z SCN 或时间，在那个点 SQL 应用将开始在重启动上读取重做记录（restart_scn | restart_time） 

z 最近的重做记录在逻辑备数据库上接收到的 SCN 或时间（latest_scn | latest_time） z 由 BUILDER 进程处理的最近的记录的 SCN 或时间（mining_scn | mining_time）例如： 

SQL> SELECT APPLIED_SCN, LATEST_SCN, MINING_SCN, RESTART_SCN FROM

V$LOGSTDBY_PROGRESS;

 

APPLIED_SCN  LATEST_SCN MINING_SCN RESTART_SCN

----------- ----------- ---------- -----------

7178240496  7178240507 7178240507  7178219805

 

依照输出： 

z SQL 应用已经应用了所有在 SCN 7178240496 上或之前已提交的事务 z 在逻辑备数据库接收到的最近的重做记录是在 SCN 7178240507 生成的 z 提取组件已经处理了所有在 SCN 7178240507 上或之前生成的重做记录 z 如果 SQL 应用由于任何原因停止并重启，它将开始提取在 SCN 7178219805 上或之后生成的重做记录 

SQL> ALTER SESSION SET NLS_DATE_FORMAT='yy-mm-dd hh24:mi:ss';

Session altered

 

SQL> SELECT APPLIED_TIME, LATEST_TIME, MINING_TIME, RESTART_TIME FROM

V$LOGSTDBY_PROGRESS;

 

APPLIED_TIME      LATEST_TIME       MINING_TIME       RESTART_TIME     

----------------- ----------------- -----------------

-----------------

05-05-12 10:38:21 05-05-12 10:41:21 05-05-12 10:41:53 05-05-12 10:09:30

 

依照输出： 

z SQL 应用已经应用了所有在时间 05-05-12 10:38:21（APPLIED_TIME）上或之前已提交的事务 

z 主数据库上最近的重做是在时间 05-05-12 10:41:53（LASTED_TIME）生成的 z 提取引擎已经处理了所有在 05-05-12 10:41:21 上或之前生成的重做记录

（MINING_TIME） z 在重启的情况下，SQL 应用将开始提取在时间 05-05-12 10:09:30 以后生成的重做记录 

 

同时查看： 

    Oracle 数据库参考中的 V$DATAGUARD_PROGRESS 视图以获得参考信息和 9.3.1 节，

“监控 SQL 应用过程”以获得例子输出 

 

 

9.2.6 V$LOGSTDBY_STATE 视图 

该视图提供了SQL 应用的当前状态的概要，包括： z 主数据库的 DBID（primary_dbid） z 分配给 SQL 应用的 LogMiner 会话 ID（session_id） z SQL 应用是否以实时应用（realtime_apply） 

z 关于装载 LogMiner Multiversioned Data Dictionary（在 4.2.3.2 节，“在重做数据中

建立字典”），从主数据库接收重做，以及应用重做数据（STATE），SQL 应用当前在哪里 

例如： 

SQL> COLUMN REALTIME_APPLY FORMAT a15

SQL> COLUMN STATE FORMAT a16 SQL> SELECT * FROM V$LOGSTDBY_STATE;

 

PRIMARY_DBID SESSION_ID REALTIME_APPLY  STATE

------------ ---------- --------------- ----------------   1562626987          1 Y               APPLYING

 

输出显示SQL 应用运行在实时应用模式并且当前应用从主数据库接收到的重做数据，主数据库的 DBID 是 1562626987 并且 SQL 应用会话相关的 LogMiner 会话标识符是 1。 

 

同时查看： 

    Oracle 数据库参考中的 V$LOGSTDBY_STATE 视图以获得参考信息和 9.3.1 节，“监控

SQL 应用过程”以获得例子输出 

 

 

9.2.7 V$LOGSTDBY_STATS 视图 

该视图提供SQL 应用统计信息：例如： 

SQL> COLUMN NAME FORMAT a32

SQL> COLUMN VALUE FORMAT a32 SQL> SELECT * FROM V$LOGSTDBY_STATS;

 

NAME                                   VALUE

-------------------------------- -------------------------------- number of preparers                 1 number of appliers                  4 maximum SGA for LCR cache          30 parallel servers in use            8 maximum events recorded            1000 preserve commit order              TRUE record skip errors                  Y record skip DDL                      Y record applied DDL                  N record unsupported operations     N coordinator state                    APPLYING transactions ready                  132412

 

transactions applied                132118 coordinator uptime                  132102 realtime logmining                  Y apply delay                          0 Log Miner session ID                1 bytes of redo processed            130142100140 txns delivered to client           131515 DML txns delivered                  128

DDL txns delivered                  23

CTAS txns delivered                 0

Recursive txns delivered           874

Rolled back txns seen              40 LCRs delivered to client           2246414 bytes paged out                      0 secs spent in pageout               0 bytes checkpointed                   0 secs spent in checkpoint            0 bytes rolled back                    0 secs spent in rollback              0 secs system is idle                  2119

 

32 rows selected.

 

 

同时查看： 

    Oracle 数据库参考中的 V$LOGSTDBY_STATS 视图 

 

 

 

9.3 监控逻辑备数据库 

本节包含下述主题： z 监控 SQL 应用过程 

z 日志文件的自动删除 

 

9.3.1 监控 SQL 应用过程 

SQL 应用可以是六个进展状态中的任何一个：初始化 SQL 应用，等待字典日志，装载

LogMiner Multiversioned Data Dictionary，应用（重做数据），等待归档中断被解决，和空闲。图 9－2 显示了这些状态的流程。图9－2 在SQL 应用处理期间的进展状态 

  下面子小节更详细地描述了每个状态。 

 

初始化状态 

当你通过执行ALTER DATABASE START LOGICAL STANDBY APPLY 语句开始 SQL 应用时，它处于初始化状态。 

要确定SQL 应用的当前状态，查询 V$LOGSTDBY_STATE 视图。例如： 

SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;

 

SESSION_ID    STATE

----------    ------------- 1             INITIALIZING

 

SESSION_ID 列标识了由 SQL 应用创建的持久 LogMiner 会话，用来提取由主数据库生成的归档重做日志文件。 

 

等待字典日志 

SQL 应用第一次开始时，它需要装载在重做日志文件中捕获的 LogMiner Multiversioned Data Dictionary。SQL 应用将逗留在 WAITING FOR DICTIONARY LOGS 状态，直到它接收到所有装载 LogMiner Multiversioned Data Dictionary 所需的重做数据。 

 

装载字典状态 

这个装载字典状态能保持一段时间。在大型数据上的装载LogMiner Multiversioned Data

Dictionary 可能花很长时间。当装载字典时查询 V$LOGSTDBY_STATE 视图返回下面输出： 

SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;

 

SESSION_ID    STATE

----------    ------------------ 1             LOADING DICTIONARY

 

只有COORDINATOR 进程和提取进程被产生，直到 LogMiner 字典被完全装载。因此，如果你在这个点查询 V$LOGSTDBY_PROCESS，你将不会看到任何 APPLIER 进程。例如： 

SQL> SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS;

 

SID     SERIAL#     SPID       TYPE

------  ---------   ---------  --------------------- 47      3           11438      COORDINATOR

50      7           11334      READER

45      1           11336      BUILDER

44      2           11338      PREPARER

43      2           11340      PREPARER

 

你能通过查询V$LOGMNR_DICTIONARY_LOAD 视图来获得装载字典过程相关的更

详细的信息。字典装载分三个阶段： 

1．相关的归档重做日志文件或备重做日志文件被提取以收集装载 LogMiner

Multiversioned Data Dictionary 相关的重做更改。 

2．更改被处理并装载到数据库内部的分段运输表。 

3．通过执行一系列 DDL 语句装载 LogMiner Multiversioned Data Dictionary 表。例如： 

SQL> SELECT PERCENT_DONE, COMMAND

     FROM   V$LOGMNR_DICTIONARY_LOAD

     WHERE  SESSION_ID = (SELECT SESSION_ID FROM V$LOGSTDBY_STATE);

 

PERCENT_DONE     COMMAND

-------------    -------------------------------

40               alter table SYSTEM.LOGMNR_CCOL$ exchange partition                   P101 with table SYS.LOGMNRLT_101_CCOL$ excluding                  indexes without validation

 如果PERCENT_DONE 或 COMMAND 列长时间没有发生更改，查询 V$SESSION_LONGOPS 视图来监控问题 DDL 事务的进展。 

 

应用状态 

在这个状态，SQL 应用已经成功装载了 LogMiner Multiversioned Data Dictionary 的初始快照，并当前正应用重做数据到逻辑备数据库。 

要获得SQL 应用进展的详细信息，查询 V$LOGSTDBY_PROGRESS 视图： 

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';

SQL> SELECT APPLIED_TIME, APPLIED_SCN, MINING_TIME, MINING_SCN,

     FROM V$LOGSTDBY_PROGRESS;

 

APPLIED_TIME            APPLIED_SCN   MINING_TIME           MINING_SCN

--------------------    -----------   -------------------- 

-----------

10-JAN-2005 12:00:05    346791023     10-JAN-2005 12:10:05  3468810134

 

所有主数据库上的在APPLIED_SCN（或 APPLIED_TIME）或之前的已提交事务已经

应用到逻辑备数据库。提取引擎已经处理了在MINING_SCN（和 MINING_TIME）或之前生成的所有重做记录。在平稳状态，值 MINING_SCN（和 MINING_TIME）将总是在 APPLIED_SCN（和 APPLIED_TIME）之前。 

 

等待中断状态 

这个状态当SQL 应用已经提取并应用所有可用的重做记录时发生，并且是等待新的日

志文件（或丢失的日志文件）被RFS 进程归档。 

SQL> SELECT STATUS FROM V$LOGSTBDY_PROCESS WHERE TYPE = 'READER';

 

STATUS

-----------------------------------------------------------------

ORA:01291 Waiting for logfile

 

空闲状态一旦 SQL 应用已经应用了由主数据库生成的所有重做就进入这个状态。 

 

9.3.2 日志文件的自动删除 

当不再需要时，SQL 应用自动删除归档日志文件。这种行为能通过执行下述 PL/SQL 过程来覆盖： 

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', FALSE);

 

 

注： 

默认地，SQL 应用将删除不再需要的归档重做日志文件。如果你闪回逻辑备数据库，

可能会将逻辑备数据库带会到一个状态，归档重做日志文件在SQL 应用元数据中存在（在

DBA_LOGSTDBY_LOGS 视图中反映）但是不存在于文件系统。尝试在 Flashback 数据库后

重启SQL 应用可能会失败，在警告日志中会有如下错误： 

Errors in file

/home/oracle/DGR2/logical/stdl/bdump/stdl_lsp0_11310.trc:

ORA-00308: cannot open archived log '/home/oracle/DGR2/logical/stdl/stlog/1_15_559399019.dbf' ORA-27037: unable to obtain file status

 

    你需要拷贝已经被自动删除策略删除的归档重做日志文件到适当的目录并重启 SQL 应用。 

 

 

虽然SQL 应用在逻辑备数据库上自动删除不再需要的归档重做日志文件，但是可能会

有你想手工删除它们的时候（例如，要清理磁盘空间）。 

如果你覆盖默认的自动日志删除能力，执行下述步骤以确定并删除SQL 应用不再需要

的归档重做日志文件： 

1． 要清除不再需要的元数据的逻辑备会话，输入下述 PL/SQL 语句： 

SQL> EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;

 

该语句也更新DBA_LOGMNR_PURGED_LOG 视图，是显示不再需要的归档重做

日志文件。 

    2．查询 DBA_LOGMNR_PURGED_LOG 视图来列出能被删除的归档重做日志文件：     SQL> SELECT * FROM DBA_LOGMNR_PURGED_LOG;

 

   FILE_NAME

   ------------------------------------

   /boston/arc_dest/arc_1_40_509538672.log

   /boston/arc_dest/arc_1_41_509538672.log

   /boston/arc_dest/arc_1_42_509538672.log

   /boston/arc_dest/arc_1_43_509538672.log

   /boston/arc_dest/arc_1_44_509538672.log

   /boston/arc_dest/arc_1_45_509538672.log

   /boston/arc_dest/arc_1_46_509538672.log

   /boston/arc_dest/arc_1_47_509538672.log

 

     3．使用操作系统相关的命令来删除查询列出的归档重做日志文件。 

 

 

9.4 定制逻辑备数据库 

本节包含下述主题： 

z 在逻辑备数据库上使用实时应用 

z 定制记录在 DBA_LOGSTDBY_EVENTS 视图中的事件 z 使用 DBMS_LOGSTDBY.SKIP 来阻止对特定方案对象的更改 z 对于 DDL 语句设置跳过处理 z 更改逻辑备数据库 z 在逻辑备数据库上添加或重建表 

 

同时查看： 

    Oracle 数据库 PL/SQL 包和类型参考中的 DBMS_LOGSTDBY 包 

 

 

9.4.1 在逻辑备数据库上使用实时应用 

默认地，Data Guard 等待全部归档重做日志文件在应用到备数据库之前到达备数据库。然而，如果你在备数据库上已经配置了一个备重做日志，你能选择允许实时应用。当允许实时应用，SQL 应用在日志文件被写入的同时从备重做日志文件应用重做数据，相对于在日志切换发生后从归档重做日志文件应用。以这种方式立即应用备重做日志文件保持逻辑备数据库紧密跟随主数据库，而不需要备重做日志文件在备站点归档。这能导致快速切换和故障转移。 

要在逻辑备数据库上启动实时应用，执行下述语句： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

 

Oracle 推荐你以实时应用模式运行 SQL 应用。同时查看 3.1.3 节，“配置备重做日志” 以获得配置备重做日志相关的更多信息。 

 

9.4.2 定制记录 DBA_LOGSTDBY_EVENTS 视图中的事件 

DBA_LOGSTDBY_EVENTS 视图可用被视为包含发生在 SQL 应用环境中的最近感兴趣的事件的循环日志。默认地最近的 100 个事件被记录在事件视图。你能通过调用

DBMS_LOGSTDBY.APPLI_SET 过程来更改记录事件的数量。例如，要确保记录最近的

10000 个事件，你能执行下述语句： 

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('MAX_EVENTS_RECORDED', '10000');

 

 

注： 

    在 Oracle 数据库 10g 版本 1（10.1）中，DBMS_LOGSTDBY.MAX_EVENTS 常量被称为 DBMS_LOGSTDBY_PUBLIC.MAX_EVENTS。这两个常量的效果是一样的，但是在版本 2（10.2）中 DBMS_LOGSTDBY_PUBLIC 包已经被除去了，而该常量的定义就移到 DBMS_LOGSTDBY 包中。 

 

 

另外，你能指定在视图中记录哪种类型的事件。例如，要记录应用的DDL 事务到

DBA_LOGSTDBY_EVENTS 视图中，执行下述语句： 

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('RECORD_APPLIED_DDL', 'TRUE');

 

造成SQL 应用停止的错误总是记录在事件视图中（除非在系统表空间中没有足够的空

间）。这些事件总是也记入ALERT.LOG 文件中，在文本中包括 LOGSTDBY 关键词。当查询该视图时，以 EVENT_TIME、COMMIT_SCN、和 CURRENT_SCN 排序选择列。这个顺序确保关闭故障出现在视图的最后面。 

 

9.4.3 使用 DBMS_LOGSTDBY.SKIP 来阻止对特定方案对象的更改 

默认地，在主数据库中所有支持的表被复制到逻辑备数据库中。你能通过指定规则来

跳过对特定表的应用更改，从而更改默认行为。例如，要忽略对HR.EMPLOYEES 表的更改，

你能指定规则来阻止对特定表的DML 和 DDL 更改的应用。例如： 

1．停止 SQL 应用： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

 

    2．注册 SKIP 规则： 

SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'DML', schema_name => 'HR',           

object_name => 'EMPLOYEES', proc_name => null);

SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'SCHEMA_DDL', schema_name => 'HR', object_name => 'EMPLOYEES', proc_name => null);

 

    3．开始 SQL 应用： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

 

9.4.4 对 DDL 语句设置跳过处理你能创建一个过程来截取某个DDL 语句并使用其它语句替代原始 DDL 语句。例如，如果在逻辑备数据库中的文件系统组织不同于主数据库中的，你能写一个

DBMS_LOGSTDBY.SKIP 过程来透明地处理与文件相关的 DDL 事务。 

下面过程能处理主数据库和备数据库之间不同的文件系统组织，只要你对于你的文件

相关串使用特定的名字转换。 

1．创建跳过过程来处理表空间 DDL 事务： 

CREATE OR REPLACE PROCEDURE SYS.HANDLE_TBS_DDL ( 

  OLD_STMT  IN  VARCHAR2, 

  STMT_TYP  IN  VARCHAR2, 

  SCHEMA    IN  VARCHAR2, 

  NAME      IN  VARCHAR2, 

  XIDUSN    IN  NUMBER, 

  XIDSLT    IN  NUMBER, 

  XIDSQN    IN  NUMBER, 

  ACTION    OUT NUMBER, 

  NEW_STMT  OUT VARCHAR2 

) AS 

BEGIN 

  

-- All primary file specification that contains a directory 

-- /usr/orcl/primary/dbs 

-- should go to /usr/orcl/stdby directory specification

 

 

  NEW_STMT = REPLACE(OLD_STMT, 

                     '/usr/orcl/primary/dbs', 

                     '/usr/orcl/stdby');

 

  ACTION := DBMS_LOGSTDBY.SKIP_ACTION_REPLACE;

 

EXCEPTION

  WHEN OTHERS THEN

    ACTION := DBMS_LOGSTDBY.SKIP_ACTION_ERROR;

    NEW_STMT := NULL; END HANDLE_TBS_DDL; 

 

2．停止 SQL 应用： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

 

3．向 SQL 应用注册跳过过程： 

SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'TABLESPACE', -              proc_name => 'sys.handle_tbs_ddl');

 

4．开始 SQL 应用： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

 

9.4.5 更改逻辑备数据库 

逻辑备数据库能用于报表活动，即使当SQL 语句在被应用时。数据库guard 控制用户到逻辑备数据库中表的访问，使用 ALTER SESSION DATABASE DISABLE GUARD 语句可以绕过数据库 guard 并允许更改逻辑备数据库中表。默认地，逻辑备数据库是操作在数据库 guard 设置为 ALL，这是最严格的设置，不允许

在数据库上执行任何用户操作。你能通过执行ALTER SESSION DISABLE GUARD 语句来覆盖数据库 guard 以允许对逻辑备数据库进行更改。特权用户能执行这句语句来将数据库 guard 对当前会话关闭。 

下面小节提供了一些例子。在这些小节中的讨论假设数据库guard 是设为 ALL 或

STANDBY。 

 

9.4.5.1 在逻辑备数据库上执行 DDL 本小节描述如何添加一个约束到通过SQL 应用维护的表。 

默认地，当数据库guard 设置为 ALL 或 STANDBY 时，只有拥有 SYS 权限的帐户才能

更改数据库。如果你以SYSTEM 或其它特权帐户登录，要没有首先对会话绕过数据库 guard，你将不能在逻辑备数据库上执行 DDL 语句。 

下面例子显示了如何停止SQL 应用，绕过数据库 guard，在逻辑备数据库上执行 SQL

语句，然后重新允许guard： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

Database altered.

 

SQL> ALTER SESSION DISABLE GUARD; PL/SQL procedure successfully completed.

 

SQL> ALTER TABLE SCOTT.EMP ADD CONSTRAINT EMPID UNIQUE (EMPNO);

Table altered.

 

SQL> ALTER SESSION ENABLE GUARD; PL/SQL procedure successfully completed.

 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; Database altered.

 

Oracle 建议在允许绕过数据库 guard 时，你不要在由 SQL 应用维护的表上执行 DML 操作。这将在主和备数据库之间引入背离，那将使得维护逻辑备数据库变得不可能。 

 

9.4.5.2 更改不是由 SQL 应用维护的表 

    有些时候，报表应用必须收集总结结果并临时存储它们或跟踪报表运行的次数。虽然应用的主要目的是执行报表活动，但是应用可能需要在逻辑备数据库上执行 DML（插入，更新，和删除）操作。甚至可能需要创建或删去表。 

你能设置数据库guard 以允许报表操作更改数据，只要数据不是通过 SQL 应用维护的。要这么做，你必须： 

z 在逻辑备数据库上指定表集合，应用能通过执行 DBMS_LOGSTDBY.SKIP 过程向其上面写数据。跳过的表是不通过 SQL 应用维护的。 

z 设置数据库 guard 只保护备表。 

在下面例子中，假设报表要写的表也在主数据库上。例子停止SQL 应用，跳过表，然后重启 SQL 应用，使得更改能被应用到逻辑备数据库

上。报表应用将能够写到MYSCHEMA 中的 MYTABLES%。它们将不再通过 SQL 应用维护。 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

Database altered.

 

SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL',-      schema_name => 'HR', -      object_name => 'TESTEMP%');

PL/SQL procedure successfully completed.

 

SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','HR','TESTEMP%'); PL/SQL procedure successfully completed.

 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered.

 

一旦SQL 应用开始，它需要为新指定添加到跳过规则的表更新备数据库上的元数据。直到 SQL 应用已经有机会更新元数据，试图更改新跳过的表将会失败。你能通过执行下面

查询来找出SQL 应用是否已经成功考虑你刚添加的 SKIP 规则： 

SQL> SELECT VALUE FROM DBA_LOGSDTBY_PARAMETERS 

     WHERE NAME = 'GUARD_STANDBY';

 

VALUE

--------------- Ready  

 

一旦VALUE 列显示“Ready”，SQL 应用已经成功更新了对于跳过表的所有相关元数据，

并且此时更改表是安全的。 

 

同时查看： 

    C.6 节，“逻辑备数据库支持的 DDL 语句”和 Oracle 数据库 PL/SQL 包和类型参考中的

DBMS_LOGSTDBY 包 

 

 

9.4.6 在逻辑备数据库上添加或重建表 

典型地，在无法恢复的操作之后你使用表实例化来重建表。你也能使用这个过程来在

以前跳过的表上允许SQL 应用。 

在你能创建表之前，它必须满足在4.1.2 节，“确保主数据库中的表行能被唯一标识”

中描述的需求。然后，你能使用下述步骤来重建名为HR.EMPLOYEES 的表并重新开始 SQL 应用。说明假设已经定义了数据库连接 BOSTON 来访问主数据库。下面列表显示了如果重建表并重启那个表上的 SQL 应用： 

1．停止 SQL 应用： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 

2．通过查询 DBA_LOGSTDBY_SKIP 视图来确保怀疑的表上没有操作被跳过： 

SQL> SELECT * FROM DBA_LOGSTDBY_SKIP;

ERROR  STATEMENT_OPT        OWNER          NAME                PROC

-----  ---------------  -------------  ----------------    ----- N      SCHEMA_DDL           HR             EMPLOYEES

N      DML                   HR             EMPLOYEES

N      SCHEMA_DDL           OE             TEST_ORDER

N      DML                   OE             TEST_ORDER

 

因为你已经有相关的跳过规则与你想在逻辑备数据库上重建的表相关联，你必须首先删除那些规则。你能通过调用DBMS_LOGSTDBY.UNSKIP 过程来完成。例如： 

SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', -

     schema_name => 'HR', -     object_name => 'EMPLOYEES');SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'SCHEMA_DDL', -      schema_name => 'HR', -     object_name => 'EMPLOYEES');

 

3．通过使用 DBMS_LOGSTDBY.INSTANTIATE_TABLE 过程在逻辑备数据库中重建表

HR.EMPLOYEES 与其所有数据。例如： 

SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE(shema_name => 'HR',       object-+_name => 'EMPLOYEES', -      dblink => 'BOSTON');

    

4．开始 SQL 应用： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

 

 

同时查看： 

    Oracle 数据库 PL/SQL 包和类型参考以获得 DBMS_LOGSTDBY.UNSKIP 和 DBMS_LOGSTDBY.INSTANTIATE_TABLE 过程的相关信息 

 

 

要确保一个跨新实例化的表和数据库的剩余部分的一致性视图，在查询这个表之前等

待SQL 应用追赶上主数据库。你能通过执行下述步骤来做到这点： 

1．在主数据库上，通过查询 V$DATABASE 视图确定当前 SCN： 

SQL> SELECT CURRENT_SCN FROM V$DATABASE@BOSTON;

CURRENT_SCN

---------------------

345162788

 

2．确保 SQL 应用已经应用了所有在前面查询中返回的 CURRENT_SCN 之前提交的事务： 

SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS;

 

APPLIED_SCN

--------------------------

345161345

 

当在这个查询中返回的APPLIED_SCN 比第一个查询返回的 CURRENT_SCN 大

时，查询新重建的表是安全的。 

 

 

9.5 管理逻辑备数据库环境下的特定工作负载 

本节包含下述主题： z 导入一个可传输表空间到主数据库 z 使用物化视图 z 触发器和约束是如何在逻辑备数据库上处理的 

z 通过 OPEN RESETLOG 语句恢复 

 

9.5.1 导入一个可传输表空间到主数据库 

执行下述步骤来导入一个表空间到主数据库。 1．禁止 guard 设置使得你能更改逻辑备数据库： 

SQL> ALTER SESSION DISABLE GUARD;

 

2．在逻辑备数据导入表空间。 

3．允许数据库 guard 设置（或从会话断开）： 

SQL> ALTER SESSION ENABLE GUARD;

 

4．在主数据库导入表空间。 

 

9.5.2 使用物化视图 

SQL 应用不支持这些物化视图相关的 DDL 语句： 

z CREATE、ALTER、或 DROP MATERIALIZED VIEW z CREATE、ALTER、或 DROP MATERIALIZED VIEW LOG 

因此，在逻辑备数据库已经创建后，在主数据库上创建的、更改的、或删去的新物化

视图不会在逻辑备数据库上反映。然而，在逻辑备数据库已经创建之前，在主数据库上创建的物化视图也表现在逻辑备数据库上。 

z 对于同时存在于主和逻辑备数据库上的物化视图，当事务提交发生时 ON-COMMIT 物化视图在逻辑备数据库上刷新。 

ON-COMMIT 物化视图不是由 SQL 应用自动刷新的。你必须执行 DBMS_MVIEW.REFRESH 过程来刷新它。例如，要在逻辑备数据库上使用快速刷新方

式刷新名为HR.DEPARTMENTS_MV 的 ON-DEMAND 物化视图，执行下面命令： 

SQL> EXECUTE DBMS_MVIEW.REFRESH (-          LIST => 'HR.DEPARTMENTS_MV', -         METHOD => 'F');

 

z 在逻辑备数据库上创建的额外 ON-COMMIT 物化视图是自动维护的。 

z 在逻辑备数据库上创建的额外 ON-DEMAND 物化视图不是由 SQL 应用维护，你必须使用 DBMS_MVIEW.REFRESH 过程刷新它们。 

 

9.5.3 触发器和约束是如何在逻辑备数据库上处理的 

默认地，触发器和约束在逻辑备数据库上是自动允许和处理的。 

对于由SQL 应用维护的表上的触发器和约束： z 约束——检查约束在主数据库上被评估并不需要在逻辑备数据库上重新评估 z 触发器——在主数据库上执行的触发器的效果记录并应用到备数据库上对于不是由SQL 应用维护的表上的触发器和约束： z 约束被评估 

z 触发器被触发 

 

9.5.4 通过 OPEN RESETLOGS 语句恢复 

当逻辑备数据库接收到新的重做数据分支，SQL 应用自动获得新的重做数据分支。对于逻辑备数据库，如果备数据库没有应用新重置日志 SCN 以前的（在新的重做数据分支开始以前的）重做数据，则不需要手工介入。下面的表描述了如果与主数据库分支重新同步备数据库。 

如果备数据库…	则…	执行这些步骤…
还没有应用新重置日志SCN以前的（在新的重做数据分支开始以前的）重做数据	SQL 应用自动获取新的重做数据分支。	没有必要手工介入。SQL 应用自动与新的重做数据分支重新同步。
已经应用新重置日志 SCN 以前的 （在新的重做数据分支开始以前 的）重做数据，并且在备数据库上允许 Flashback 数据库	备数据库恢复到新的重做数据分支之后。	1．遵循 12.5.2 节，“在闪回主之后闪回逻辑备数据库”中的步骤来闪回逻辑备数据库。  2．重启 SQL 应用以继续应用重做到新的重置日志分支。  SQL 应用自动与新的分支重新同步备数据库。
已经应用新重置日志 SCN 以前的 （在新的重做数据分支开始以前 的）重做数据，并且在备数据库上没有允许 Flashback 数据库	主数据库在指定的主数据库分支从备分叉。	遵循第 4 章，“创建逻辑备数据库” 中的步骤重建逻辑备数据库。
丢失介于新的重做数据分支其间的归档重做日志文件	SQL 应用无法继续直到 从每个分支定位并注册丢失的归档检索到丢失的日志文件。 重做日志文件。
丢失从前面重做数据分支结尾的归档重做日志文件	SQL 应用无法继续直到 从前面分支定位并注册丢失的归档检索到丢失的日志文件。 重做日志文件。

 

查看Oracle 数据库备份和恢复高级用户指南以获得数据库化身，通过 OPEN

RESETLOGS 操作恢复，和 Flashback 数据库的更多相关信息。 

 

 

9.6 调优逻辑备数据库 

本节包含下述主题： z 创建主键 RELY 约束 z 为基于代价的优化器收集统计信息 z 调整进程的数量 z 调整 LCR 缓存使用的内存 

z 调整如何在逻辑备数据库上应用事务 

 

9.6.1 创建主键 RELY 约束 

在主数据库上，如果表没有主键或唯一索引，并且你确认行是唯一的，则创建一个主

键RELY 约束。在逻辑备数据库上，在组成主键的列上创建一个索引。下面查询生成一个表的列表，这些表没有索引信息能被逻辑备数据库使用来应用唯一地标识行。通过在下述表上创建索引，性能能显著提高。 

SQL> SELECT OWNER, TABLE_NAME FROM DBA_TABLES

  2> WHERE OWNER NOT IN('SYS','SYSTEM','OUTLN','DBSNMP')   3> MINUS

  3> SELECT DISTINCT TABLE_OWNER, TABLE_NAME FROM DBA_INDEXES

  4> WHERE INDEX_TYPE NOT LIKE ('FUNCTION-BASED%')

  5> MINUS

  6> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED;

 

你能向主数据库上的表添加一个rely 主键约束，如下： 

1．在主数据库上添加主键 rely 约束 

SQL> ALTER TABLE HR.TEST_EMPLOYEES ADD PRIMARY KEY (EMPNO) RELY

DISABLE;

SQL> ALTER SESSION DISABLE GUARD;

 

这将确保EMPNO 列，能被用于唯一标识 HR.TEST_EMPLOYEES 表中的行，将

作为表上任何更新的一部分被补充记录。注意到HR.TEST_EMPLOYEES 表还没有任何唯一索引在逻辑备数据库上指定。这可能造成 UPDATE 语句在逻辑备数据库上做全表扫描。你能通过在逻辑备数据库上在 EMPNO 列添加一个唯一索引来改正这个问题。查看 4.1.2 节，“确保在主数据库中的行能被唯一标识”和 Oracle 数据库 SQL 参考以获得 RELY 约束相关的更多信息。 

2．停止 SQL 应用： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

 

3．禁止 guard 使得你在逻辑备数据上更改逻辑备数据上的被维护的表： 

SQL> ALTER SESSION DISABLE GUARD;

 

4．在 EMPNO 列上添加一个唯一索引： 

SQL> CREATE UNIQUE INDEX UI_TEST_EMP ON HR.TEST_EMPLOYEES (EMPNO);

 

5．允许 guard： 

SQL> ALTER SESSION ENABLE GUARD;

 

6．开始 SQL 应用： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

 

9.6.2 为基于代价的优化器收集统计信息 

在逻辑备数据库上应该收集统计信息，因为基于代价的优化器（CBO）使用它们来确

定最优的查询执行路径。在方案对象的数据或结构发生改变使得以前的统计信息不准确时，应该收集新的统计信息。例如，在对表插入或删除大量行后，收集相应数量行的新统计信息。 

应该在备数据库上收集统计信息，因为在主数据上的DML 和 DDL 操作是作为工作复

杂的功能执行的。当备数据库逻辑等同于主数据库时，SQL 应用可能以不同的方式执行工作负载。这就是为什么使用逻辑备数据库上的 STATS 包和 V$SYSTAT 视图能用于确定哪些表消耗了最多的资源和表扫描。 

 

同时查看： 

    4.1.2节，“确保主数据库中的表行能被唯一标识”和Oracle数据库SQL参考以获得RELY 约束相关的更多信息 

 

 

9.6.3 调整进程的数量 

下面小节描述了：调整 APPLIER 进程的数量 

调整PREPARER 进程的数量 

 

9.6.3.1 调整 APPLIER 进程的数量执行下述步骤来找出调整APPLIER 进程的数量是否能帮助你获得更高的吞吐量： 

1．通过执行下面查询确定 APPLIER 进程是否繁忙： 

SQL> SELECT COUNT(*) AS IDLE_APPLIER

     FROM V$LOGSTDBY_PROCESS 

     WHERE TYPE = 'APPLIER' and status_code = 16166;

 

IDLE_APPLIER

-------------------------

0

 

2．一旦你确定有非空闲的 APPLIER 进程，如果你选择调整 APPLIER 的数量，执行下

面查询来确保对于额外的APPLIER 进程有足够的工作可做： 

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS

     WHERE NAME LIKE 'TRANSACTIONS%';

 

NAME                          VALUE

---------------------         ------- transactions ready             27896 transactions applied           25671

 

有两种统计信息保留事务的累计总数，一种是APPLIER 进程准备应用的事务数，

另一种是已经被应用的事务数量。 

如果数量（transactions ready – transactions applied）比两倍可用的 APPLIER 进程数量还要高，则如果你增加 APPLIER 进程的数量对吞吐量的提高是可能的。 

 

注： 

    数量是准备好的工作的大概测量。工作负载可能由于准备好的事务之间的相关性阻止额外可用的 APPLIER 进程应用它们。例如，如果大多数准备好应用的事务是 DDL 事务，则添加更多的 APPLIER 进程将不会导致更高的吞吐量。 

 

 

要从默认值5 调整 APPLIER 进程的数量到 20，执行下述步骤： 

a．停止 SQL 应用： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered

 

b．设置 APPLY_SERVERS 的数量为 20： 

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', 20);

PL/SQL procedure successfully completed

 

c．开始 SQL 应用 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered

 

9.6.3.2 调整 PREPARER 进程的数量只有在很罕见的情况下你需要调整PREPARER 进程的数量。在你决定增加 PREPARER

进程的数量之前，确保下面条件为真： z 所有 PREPARER 进程是繁忙的 z 准备好要应用的事务数量少于可用的 APPLIER 进程数量 z 有空闲的 APPLIER 进程下面步骤显示如何确定这些条件为真： 

1．确保所有 PREPARER 进程是繁忙的： 

SQL> SELECT COUNT(*) AS IDLE_PREPARER

     FROM V$LOGSTDBY_PROCESS

     WHERE TYPE = 'PREPARER' and status_code = 16166;

IDLE_PREPARER

-------------

0

 

2．确保准备好要应用的事务数量少于可用的 APPLIER 进程数量： 

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS

     WHERE NAME LIKE 'transactions%';

NAME                              VALUE ---------------------         ------- transactions ready             27896 transactions applied           27892

 

SQL> SELECT COUNT(*) AS APPLIER_COUNT 

     FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER';

APPLIER_COUNT

-------------

20

 

注：多次执行这个查询以确保这不是一个短暂的事件。 

3．确保有空闲的 APPLIER 进程： 

SQL> SELECT COUNT(*) AS IDLE_APPLIER

     FROM V$LOGSTDBY_PROCESS 

     WHERE TYPE = 'APPLIER' and status_code = 16166;

IDLE_APPLIER

-------------------------

19

 

在这个例子中，所有条件已经被满足。因此，你现在可以增加PREPARER 进程到 4（从

默认值1），通过执行下述步骤： 

1．停止 SQL 应用： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered

 

2．设置 PREPARE_SERVERS 的数量为 4： 

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS', 4);

PL/SQL procedure successfully completed

 

3．开始 SQL 应用： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered

 

9.6.4 调整 LCR 缓存使用的内存 

对于一些工作负载，SQL 应用可能使用大量的换页操作，从而减轻系统的整个吞吐量。要找到增加分配给 LCR 缓存的内存是否有益，执行下述步骤： 

1．执行下面查询以获得换页活动的快照： 

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS

        WHERE NAME LIKE '%PAGE%' OR 

        NAME LIKE '%UPTIME%' OR NAME LIKE '%idle%';

NAME                           VALUE

--------------------------     ---------------

coordinator uptime in secs              894856 bytes paged out                          20000 seconds spent in pageout                     2 system idle time in secs                  1000

 

2．在 5 分钟内再次执行查询： 

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS

        WHERE NAME LIKE '%PAGE%' OR

        NAME LIKE '%UPTIME%' OR NAME LIKE '%idle%';

NAME                           VALUE

--------------------------     --------------- coordinator uptime in secs              895156 bytes paged out                        1020000 seconds spent in pageout                   100 system idle time in secs                  1000

 

3．计算规格化的换页活动。例如： 

Change in coordinator uptime (C)= (895156 – 894856) = 300 secs

Amount of additional idle time (I)= (1000 – 1000) = 0

Change in time spent in pageout (P) = (100 – 2) = 98 secs

Pageout time in comparison to uptime = P/(C-I) = 98/300 ~ 32.67%

 

理想地，换页活动不应该消耗超过百分之5 的整个运行时间。如果你继续在延长的间

隔获取快照，你会发现换页活动继续消耗了应用时间的显著部分，增加内存大小能提供一些益处。你能通过执行下述步骤增加分配给SQL 应用的内存： 

1．停止 SQL 应用： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered

 

2．设置分配给 LCR 缓存的内存（对于这个例子，SGA 设为 1GB）： 

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 1024);

PL/SQL procedure successfully completed

 

因为MAX_SGA 是以兆字节（MB）指定的，增加内存到 1GB 在例子中以 1024MB

指定。 

3．开始 SQL 应用： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered

 

9.6.5 调整如何在逻辑备数据库上应用事务 

默认地，在逻辑备数据库上应用的事务与它们在主数据库上提交的次序完全相同。提

交事务的默认顺序允许任何报表应用在逻辑备数据库上透明地运行。然而，当你想逻辑备数据库追赶上主数据库时是要时间的（如在由于硬件故障或升级逻辑备数据库长时间地中断之后），并且能容忍不运行报表应用一段时间。在这种情况下，你能通过执行下述步骤更改默认应用模式： 

1．停止 SQL 应用： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered

 

2．执行下面以允许事务不按它们在主数据库上提交的顺序应用： 

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER',

'FALSE');

PL/SQL procedure successfully completed

 

3．开始 SQL 应用： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered

 

一旦你已经追赶上主数据库（通过查询V$LOGSTDBY_STATS 视图来检验），并且你准

备打开逻辑备数据库以用于报表应用，你能如下更改应用模式： 

1．停止 SQL 应用： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered

 

2．还原 PRESERVE_COMMIT_ORDER 参数的默认值： 

SQL> EXECUTE

DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER');

PL/SQL procedure successfully completed

 

3．开始 SQL 应用： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Database altered

 

对于典型的联机事务处理（OLTP）工作负载，非默认模式能比默认的应用模式提

供百分之50 或更好的吞吐量提高。 

 

 

10 使用 RMAN 来备份和恢复文件 

 

本章描述与Data Guard 和备数据库使用 Oracle 恢复管理器工具（RMAN）的备份策略。

RMAN 能以对主数据库最小影响来执行备份并且从丢失单个数据文件或整个数据库中快速恢复。RMAN 和 Data Guard 能一起使用来简化 Data Guard 配置的关联。 

本章包含下述主题： 

z 备份过程 z 切换、故障转移、和控制文件重建在备份上的影响 z 额外的备份情况 

 

 

注： 

    因为逻辑备数据库不是主数据库的块对块拷贝，你不能使用逻辑备数据库来备份主数据库。 

 

 

 

10.1 备份过程 

在备环境中，在主或备系统上进行的备份数据文件和归档重做日志文件在其它系统是可以用于恢复的。虽然一些文件如控制文件和SPFILE 必须在主数据库上备份，但是备份数据文件和归档重做日志文件的步骤能卸载到备系统，以最小化生产系统上的备份影响。 

只有那些由备实例创建的归档重做日志文件才能在备站点上备份。如果有在备数据库启动之前生成的归档重做日志文件，它们必须在主数据库上备份。例如，如果从主数据库发送到备的第一个日志是日志序列100 线程 1，则日志序列小于 100 的归档重做日志文件的备份必须在主数据库上完成。 

如果配置了闪回恢复区，Oracle 软件基于需求从闪回恢复区删除文件。闪回恢复区对于磁带备份作为磁盘缓存。 

 

10.1.1 对磁带备份使用磁盘作为缓存 

下面指导假设已配置了闪回恢复区（如5.2.3 节中描述）和设置了其它 RMAN 持久平配置。执行下述步骤： 

1．在主数据库上，执行下面 RMAN 命令来进行控制文件和 SPFILE 的当前备份，并备份由主实例创建的闪回恢复区中的文件到磁带： 

BACKUP DEVICE TYPE DISK CURRENT CONTROLFILE;

BACKUP RECOVERY AREA;

 

每天或一周一次执行这些命令（或在脚本中使用它们），取决于在丢失所有当前控制文件的情况下能容忍丢失多少重做数据的应用（查看10.2.4 节）。 

2．在备数据库上，每天执行下面 RMAN 命令来前滚 0 级别数据库拷贝： 

RECOVER COPY OF DATABASE WITH TAG 'OSS';

BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY

WITH TAG 'OSS' DATABASE;

BACKUP DEVICE TYPE DISK ARCHIVELOG ALL NOT BACKED UP 2 TIMES; BACKUP RECOVERY AREA;

 

这些命令应用一天以前进行的级别1 增量备份，创建一个新的级别 1 增量备份，备份归档重做日志文件到闪回恢复区，并从闪回恢复区备份由备实例创建的文件到磁带。 

 

10.1.2 直接执行备份到磁带 

如果所有备份直接写到磁带，使用RMAN CONFIGURE DEFAULT DEVICE TYPE TO

SBT 命令来配置默认的设备类型为 SBT。 

在主数据库上，使用下面RMAN 命令来备份当前控制文件并拷贝由主实例创建的自动备份到磁带上： 

BACKUP AS BACKUPSET CURRENT CONTROLFILE;

BACKUP RECOVERY AREA;

 

每天或一周一次执行这些命令，取决于在丢失所有当前控制文件的情况下能容忍丢失多少重做数据的应用（查看10.2.4 节）。 

假设每周日进行全数据库备份，能在备数据库上执行下面命令来进行级别0 数据库备份： 

BACKUP AS BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG NOT

BACKED UP 2 TIMES;

 

在备份周期的其它日期，运行下面命令来创建数据库的级别1 增量备份和所有还没有备份两次的归档重做日志文件： 

BACKUP AS BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG NOT

BACKED UP 2 TIMES;

 

 

10.2 切换、故障转移、和控制文件重建在备份上的影响 

所有在备份完成所在系统上的上次备份以后生成的归档重做日志文件，在下述事件之

后，必须使用RMAN CATALOG ARCHIVELOG ‘archivelog_name_complete_path’命令手工编录： 

z 主或备控制文件重建。 

z 在切换后主数据库角色转换到备。 

z 在切换或故障转移后备数据库角色转换到主。 

如果新的归档重做日志文件没有编录，RMAN 将不会备份它们。 

在下面小节中的例子假设你从磁带还原文件到备份创建的同一系统上。如果你需要还原文件到不同系统，你可能需要更改媒质配置或在还原期间在RMAN 通道上指定不同的参数，或两者都。查看媒质管理文档以获得如何从不同系统访问 RMAN 备份的更多相关信息。 

 

10.2.1 从主数据库上数据文件的丢失恢复 

指定下面RMAN 命令来还原并恢复数据文件。你必须同时连接到主和恢复目录数据库。 

RESTORE DATAFILE n,m...;

RECOVER DATAFILE n,m...;

 

执行下面RMAN 命令来还原并恢复表空间。你必须同时连接到主和恢复目录数据库。 

RESTORE TABLESPACE tbs_name1, tbs_name2, ... 

RECOVER TABLESPACE tbs_name1, tbs_name2, ... 

 

10.2.2 从备数据库上数据文件的丢失恢复 

要在丢失一个或更多数据文件恢复备数据库，你必须使用RMAN RESTORE DATAFILE 命令从备份中还原丢失的文件到备数据库。如果恢复损坏文件所需的所有归档重做日志文件在磁盘上可以由备数据库访问，则重启重做应用。如果恢复所需的归档重做日志文件在磁盘上不可访问，使用 RMAN 还原恢复的数据文

件到SCN/日志序号高于最近应用到备数据库的，然后重启重做应用继续应用重做数据，如下： 

1．停止重做应用。 

2．确定 UNTIL_SCN 列的值，通过执行下面查询： 

SQL> SELECT MAX(NEXT_CHANGE#)+1 UNTIL_SCN FROM V$LOG_HISTORY LH, V$DATABASE DB WHERE LH.RESETLOGS_CHANGE#=DB.RESETLOGS_CHANGE#

AND LH.RESETLOGS_TIME = DB.RESETLOGS_TIME;

UNTIL_SCN

------- ----------------

967786

 

3．执行下面 RMAN 命令来还原并恢复备数据库上的数据文件。你必须同时连接到备

和恢复目录数据库（使用TARGET 关键词来连接到备实例）： 

RESTORE DATAFILE <n,m,...>;

RECOVER DATABASE UNTIL SCN 967786;

 

要还原一个表空间，使用RMAN ‘RESTORE TABLESPACE tbs_name1,

tbs_name2, …’命令。 

4．重启重做应用。 

 

10.2.3 从备控制文件的丢失恢复 

Oracle 软件允许多重备控制文件。要确保备控制文件被多重，检查 CONTROL_FILES 初始化参数，如下： 

SQL> SHOW PARAMETER CONTROL_FILES

NAME                                         TYPE        VALUE

------------------------------------ -----------

------------------------------

control_files                        string     

<cfilepath1>,<cfilepath2>

 

如果其中一个多重备控制文件丢失或不可访问，Oracle 软件停止实例并写下面信息到警告日志： 

ORA-00210: cannot open the specified controlfile

ORA-00202: controlfile: '/ade/banand_hosted6/oracle/dbs/scf3_2.f'

ORA-27041: unable to open file

 

你能拷贝一个控制文件的完整拷贝覆盖到丢失的拷贝，然后使用下面SQL 语句重启备实例： 

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM

SESSION;

 

如果所有备控制文件丢失了，则你必须从主数据库创建一个新的控制文件，拷贝它到备数据库上所有多重位置，并重启备实例和重做应用。创建的控制文件丢失所有在其创建之前生成的归档重做日志文件的相关信息。因为RMAN 到控制文件中查找要备份的归档重做日志文件的列表，所有在最近备份以后生成的归档重做日志文件必须手工编录。 

 

10.2.4 从主控制文件的丢失恢复 

Oracle 软件允许在主数据库上多重控制文件。如果其中一个控制文件无法在主数据库上更新，则主数据库实例自动关闭。如 10.2.3 节中描述，你能拷贝一个控制文件的完整拷贝并重启实例而不用执行还原或恢复操作。 

如果你丢失你的所有控制文件，你能选择下述步骤之一，取决于可接受的宕机事件。 

创建一个新的控制文件 如果所有控制文件的拷贝丢失了，你能使用 NORESETLOGS 选项来创建一个新的控制文件并在完成媒质恢复之后打开数据库。现有的备数据库实例能通过使用下面语句生成脚本来创建一个新的控制文件： 

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS;

 

注意到数据库文件名在主和备数据库中是不同的，然后你必须编辑生成的脚本来更改文件名。 

这个语句能定期地使用以生成控制文件创建脚本。如果你要将控制文件创建作为你的恢复计划的一部分，则你应该在任何物理架构更改后使用这个语句，如添加或删去数据文件、表空间、或重做日志成员。 

创建的控制文件丢失所有在控制文件创建时间之前生成的归档重做日志文件的相关信息。如果归档重做日志文件备份正在主数据库上执行，自从最近归档重做日志文件备份以后生成的所有归档重做日志文件必须手工编录。 

使用备份控制文件恢复 如果你不能使用前面的步骤创建控制文件，则你能使用一个备份控制文件，执行完全恢复，并以 RESETLOGS 选项打开数据库。 

要还原控制文件并恢复数据库，在连接到主实例（在NOMOUNT 状态）之后执行下面

RMAN 命令并编录数据库： RESTORE CONTROLFILE;

ALTER DATABASE MOUNT;

RECOVER DATABASE;

ALTER DATABASE OPEN RESETLOGS;

从Oracle 版本 10.1.0 开始，所有在 RESETLOGS 选项之前进行的备份能用于恢复。因此，没有必要在可用于生产之前备份数据库。 

 

10.2.5 从联机重做日志文件的丢失恢复 

Oracle 建议多重联机重做日志文件。丢失一个联机重做日志组的所有成员导致 Oracle 软件终止实例。如果只有一个日志文件组的一些成员无法写入，则它们将不被使用直到它们变得可访问。视图 V$LOGFILE 和 V$LOG 包含主数据库实例中日志文件成员的当前状态的更多相关信息。 

当Oracle 软件不能写联机重做日志文件成员之一时，会返回下面警告信息： 

ORA-00313: open failed for members of log group 1 of thread 1

ORA-00312: online log 1 thread 1:

'/ade/banand_hosted6/oracle/dbs/t1_log1.f'

ORA-27037: unable to obtain file status

SVR4 Error: 2: No such file or directory

Additional information: 3

 

如果访问问题是暂时由于硬件问题，更正问题处理将自动继续。如果丢失是永久的，可以添加一个新的成员并从组中删去旧的组。 

要添加一个新的成员到重做日志组，执行下面语句： 

SQL> ALTER DATABASE ADD LOGFILE MEMBER 'log_file_name' REUSE TO GROUP n

 

即使数据库打开时你也能执行这个语句，而不影响数据库可用性。 

如果一个已经归档的非活动组的所有成员丢失了，该组能删除并重建。 

在所有其它情况（丢失当前ACTIVE 组，或还没有备归档的非活动组的所有联机日志成员），你必须故障转移到备数据库。参考第 7 章以获得故障转移步骤。 

 

10.2.6 数据库的不完全恢复 

主数据库的不完全恢复通常在如下情况下完成，如当数据库逻辑损坏（被一些用户或应用）或当表空间或数据文件意外从数据库删去。 

取决于备数据库实例上的当前数据库检查点SCN，你能使用下面步骤之一来执行数据库的不完全恢复。所有过程按优先排序，以花费最少时间的开始。 

使用Flashback 数据库 当在主数据库上允许 Flashback 数据库特性时，使用 Flashback 数据库是推荐的步骤，不丢失一个数据库文件，并且基于时间点的恢复比最旧的闪回 SCN 或最旧的闪回时间还大。查看 12.5 节以获得使用 Flashback 数据库来做基于时间点的恢复的步骤。 

使用备数据库实例 当备数据库处于期望的不完全恢复时间之后时，并且在主或备数据库上没有允许 Flashback 数据库，推荐使用这个步骤， 

1．恢复备数据库到期望的时间点： 

RECOVER DATABASE UNTIL TIME 'time';

 

可选的，不完全恢复时间能使用SCN 或日志序列号指定： 

RECOVER DATABASE UNTIL SCN incomplete recovery SCN'

RECOVER DATABASE UNTIL LOGSEQ incomplete recovery log sequence number THREAD thread number 

 

2．以只读模式打开备数据库以检验数据库的状态。 

如果状态不是期望的，使用LogMiner 工具来查找归档重做日志文件以找到不完全恢复正确的目标时间或 SCN。可选地，你能开始恢复备数据库到你已知的在目标时间前的点，然后以只读模式打开数据库来检查数据的状态。重复这个过程直到数据库的状态检查为正确。注意如果你恢复数据库太远，（就是说，经过错误发生的 SCN）你不能返回到更早的 SCN。 

3．使用 SQL ALTER DATABASE ACTIVATE STANDBY DATABASE 语句激活备数据库。这转换备数据库到主数据库，创建一个新的重置日志分支，并打开数据库。查看

8.4 节以认识到备数据库如何反应到新的重置日志分支。 

使用主数据库实例 如果所有的备数据库实例已经恢复到期望的时间点以后，并且在主或备数据库上允许 Flashback 数据库，则这是你的唯一选择。 

使用下面步骤在主数据库上执行不完全恢复： 

1．使用 LogMiner 或其它方法来确定在那个时间或 SCN，数据库中的所有数据是好的。 

2．使用时间或 SCN，执行下面 RMAN 命令来做不完全数据库恢复并使用 RESETLOGS

选项打开数据库（在连接到目录数据库和处于MOUNT 状态的主实例之后）： 

RUN 

{

SET UNTIL TIME 'time';

RESTORE DATABASE; RECOVER DATABASE;

}

ALTER DATABASE OPEN RESETLOGS;

 

在这个过程之后，所有备数据库实例必须在Data Guard 配置中重新建立。 

 

 

10.3 额外的备份情况 

下面小节描述了如何对于其它配置更改备份步骤，如当备和主数据库无法共享备份文件时；备实例只用于远程归档重做日志文件时；或备数据库文件名不同于主数据库时。 

 

10.3.1 备数据库地理距离太远无法共享备份 

在这种情况中，在备系统上进行的备份不容易被主系统或其它备系统访问到。在所有系统上执行数据库的完全备份以执行恢复操作。闪回恢复区能位于主和备系统的本地（例如，闪回恢复区对于主和备数据库不是同一个）。 

在这个场景中，你还是能使用10.2 节中描述的普通策略，但有如下例外： 

z 由 RMAN 创建的备份文件必须标记本地系统名字，在 RESTORE 操作时必须使用标记以限制 RMAN 选择在同一主机上进行的备份。换句话说，BACKUP 命令在创建备份时必须使用 TAG node name 选项；RESTORE 命令必须使用 FROM TAG node name 选项；并且 RECOVER 命令必须使用 FROM TAG node name ARCHIVELOG TAG node name 选项。 

z 备站点的灾难恢复： 

1．使用备实例以前操作使用的同样参数文件以 NOMOUNT 状态启动备实例。 

2．使用 SQL ALTER DATABASE CREATE STANDBY CONTROLFILE AS filename 语句在主实例上创建一个备控制文件，并使用创建的控制文件来安装备实例。 

3．执行下面 RMAN 命令来还原和恢复数据库文件： 

RESTORE DATABASE FROM TAG 'node name'

RECOVER DATABASE FROM TAG 'node name' ARCHIVELOG TAG 'node name'

 

4．重启重做应用。 

备实例将取得5.8 节中描述的剩余归档重做日志文件。 

 

10.3.2 备数据库不包含数据文件，用于 FAL 服务器 

使用在10.1 节中描述的同样步骤，除了备份数据文件的 RMAN 命令不能对 FAL 服务

器运行。对于所有归档重做日志文件FAL 服务器能用于备份源，从而减负向 FAL 服务器的归档重做日志文件的备份。 

 

10.3.3 备数据库文件名不同于主数据库 

如果数据库文件名在主和备数据库上是不同的，你使用的RESTORE 和 RECOVER 命

令将会稍微不同。要获得备数据库上实际的数据文件名字，查询V$DATAFILE 视图并对于

数据库中的所有数据文件指定SET NEWNAME 选项： 

RUN 

{

SET NEWNAME FOR DATAFILE 1 TO 'existing file location for file#1 from

V$DATAFILE';

SET NEWNAME FOR DATAFILE 2 TO 'existing file location for file#2 from

V$DATAFILE';

…

…

SET NEWNAME FOR DATAFILE n TO 'existing file location for file#n from V$DATAFILE';

RESTORE {DATAFILE <n,m,…> | TABLESPACE tbs_name_1, 2, …| DATABASE;

SWITCH DATAFILE ALL; 

RECOVER DATABASE {NOREDO};

}

 

类似地，在备数据库恢复期间，RMAN DUPLICATE 命令也应该使用 SET NEWNAME

选项来指定新的文件名。 

 

10.3.4 对于闪回恢复区中的归档重做日志文件的删除策略 

默认地，在闪回恢复区中已备份到第三方设备或变得废弃（如RMAN 保留策略定义）的归档重做日志文件是适宜删除的。如果闪回恢复区中的磁盘空间变满了，已备份或废弃的归档重做日志文件最终能被自动删除以腾出空间。然而，你能使用下面 RMAN 命令来更改这种默认删除策略： 

CONFIGURE ARCHIVELOG DELETION POLICY TO [CLEAR | NONE | APPLIED ON

STANDBY];

 

本小节描述命令限定词并提供设置删除策略的例子。查看Oracle 数据库备份和恢复高级用户指南以获得 Oracle 软件如何管理闪回恢复区中的磁盘空间的更多相关信息。 

 

使用APPLIED ON STANDBY 子句 

使用APPLIED ON STANDBY 子句使得已经被应用到所有强制备目的地的归档重做日志文件将被删除。当你指定这个子句时进行的处理在下面表中描述： 

当 APPLIED ON STANDBY 子句配置在…	然后，这些文件适宜于删除…
主数据库	在闪回恢复区中已经应用在所有强制备数据库上的归档重做日志文件
有一个或更多强制级联备数据库的备数据库	在闪回恢复区中已经应用在所有强制级联备数据库上的归档重做日志文件
没有级联备数控的备数据库	在闪回恢复区中已经应用在备数据库上的归档重做日志文件

 

查看附录 E 以获得级联目的地的更多相关信息。 

 

使用CLEAR 子句 

使用CLEAR 子句来禁止以前使用 RMAN CONFIGURE ARCHIVELOG DELETION

POLICY 命令设置的删除策略。Oracle 数据库将继续默认的删除策略行为，就是如果闪回恢复区中的磁盘空间变满就删除已备份或废弃的归档重做日志。 

 

使用NONE 子句 

使用NONE 子句使得在闪回恢复区中已备份或作为 RMAN 保留策略废弃的归档重做日志适宜于删除。这是默认的配置。如果闪回恢复区中的磁盘空间变满了，已备份或废弃的归档重做日志文件被删除以腾出空间。 

 

CONFIGURE ARCHIVELOG DELETION POLICY 命令的例子当在备数据库上进行归档重做日志文件的备份时： 

1．在主数据库上执行下面命令： 

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

 

2．在备数据库上执行下面命令： 

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

 

当在主数据库上进行归档重做日志文件的备份时： 

1．在备数据库上执行下面命令： 

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY; 2．在主数据库上执行下面命令： 

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

 

10.3.4.1 在角色转换之后重新配置删除策略在切换或故障转移之后，你可能需要在每个数据库上重新执行RMAN CONFIGURE

ARCHIVELOG DELETION POLICY 命令。如果对于归档重做日志文件的备份站点保持相同，则不需要操作。否则，你必须通过在不进行备份的数据库上执行CONFIGURE

ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY 语句来切换归档日志删除策略，并在进行备份的数据库上执行 CONFIGURE ARCHIVELOG DELETION POLICY TO NONE 语句。 

 

10.3.4.2 查看当前删除策略要查看数据库的当前设置（APPLIED ON STANDBY、CLEAR、NONE），执行下面查

询： 

SELECT NAME, VALUE FROM V$RMAN_CONFIGURATION WHERE

NAME LIKE '%ARCHIVELOG DELETION POLICY%';

 

NAME                                  VALUE

-----------------------------     -------------- ARCHIVELOG DELETION POLICY        TO APPLIED ON STANDBY

 

你也能使用RMAN SHOW ARCHIVELOG DELETION POLICY 命令来找出现有的配

置： 

RMAN> SHOW ARCHIVELOG DELETION POLICY RMAN configuration parameters are:

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

 

 

11 使用SQL 应用来升级Oracle 数据库 

 

从Oracle 数据库 10g 版本 1（10.1.0.3）开始，你能使用逻辑备数据库来执行 Oracle 数据库 10g 软件的滚动升级。在滚动升级期间，你能在升级的时候在主和数据库上运行不同版本的Oracle 数据库，每次一个，从而最小化主数据库的宕机时间。 

 

注： 

    本章描述如何以滚动方式在逻辑备备数据库到位时升级以最小化宕机时间。第二种方法，在 B.3 节，“在逻辑备数据库到位时升级 Oracle 数据库”中描述的是一种传统的升级步骤，它会导致在升级过程中宕机。只能使用一种方法的步骤来执行完整升级。不要尝试使用两种方法或组合两种方法中的步骤。 

 

 

在本章中的指导描述当升级Oracle 数据库时如何最小化宕机时间。本章包含下述主题： z 使用 SQL 应用滚动升级的益处 z 使用 SQL 应用执行滚动升级的必要条件 z 在升级指导中使用的图示和规范 z 准备升级 

z 升级数据库 

 

 

11.1 使用 SQL 应用滚动升级的益处 

使用SQL 应用执行滚动升级提供了一些优点： z 你的数据库将会发生非常小的宕机时间。整个宕机时间就是执行切换所需的时间。 

z 由于 PL/SQL 重新编译你消除了应用宕机时间。 z 你能验证升级的数据库版本而不影响主数据库。 

 

 

11.2 使用 SQL 应用执行滚动升级的必要条件 

滚动升级过程需要下述： 

z 运行于 Oracle 数据库版本 x 中的主数据库和运行于 Oracle 数据库版本 y 的逻辑备数据库。 

z 数据库必须不是 Data Guard Broker 配置中的一部分。查看 Oracle Data Guard Broker 以获得从 broker 配置中移除数据库的相关信息。 

z Data Guard 保护模式必须设为最大可用性或最大性能。查询 V$DATABASE 视图中的 PROTECTION_LEVEL 列来找出当前的保护模式设置。 

z 对于逻辑备数据库目的地的 LOG_ARCHIVE_DEST_n 初始化参数必须设为

OPTIONAL 以确保主数据库在逻辑备数据库升级时能处理。 

 

同时查看： 

    Oracle Data Guard 概念和管理以获得在 LOG_ARCHIVE_DEST_n 初始化参数中使用

MANDATORY 和 OPTIONAL 属性的完整相关信息 

 

 

z COMPATIBLE 初始化参数必须符合升级前的软件版本。就是说，从版本 x 滚动升级到版本 y 需要 COMPATIBLE 初始化参数在主和被数据库上都设为版本 x。 

 

 

11.3 在升级指导中使用的图示和规范 

图11－1 显示了在升级开始之前的 Data Guard 配置，主和逻辑备数据库都运行在同一

Oracle 数据库软件版本。 

图11－1 在升级之前的Data Guard 配置 

 

 

在升级过程中，Data Guard 配置在这个过程中的一些点上运行于混合数据库版本。数据保护在跨版本时不可用。在这些步骤期间，考虑在 Data Guard 配置中设置第二个备数据库以提供数据保护。 

描述升级过程的步骤和图示称数据库为“数据库 A”和“数据库 B”，而不是“主数据库”和“备数据库”。这是因为在升级过程中数据库切换角色。数据库 A 是主数据库，数据库 B 是备数据库，如图 11－1 中所示。 

 

 

11.4 准备升级 

执行下述步骤来为升级准备主和备数据库。 

 

第1 步 设置 COMPATIBLE 初始化参数 

确保COMPATIBLE初始化参数在升级之前确定运行在主数据库上的Oracle数据库软件版本号。 

例如，如果主数据库运行在版本10.1，则在两个数据库上都设置 COMPATIBLE 初始化参数为 10.1。确保在设置主数据库之前先在备数据库上设置 COMPATIBLE 初始化参数。 

 

第2 步 获得不支持表的相关信息 

在数据库A 上，使用 DBMS_LOGSTDBY PL/SQL 过程来捕获运行在主数据库上的将不被逻辑备数据库支持的事务相关信息。运行下面过程来捕获并以

DBA_LOGSTDBY_EVENTS 表中的时间记录信息： 

EXEC

DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',DBMS_LOGSTDBY.MAX_E

VENTS);

EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS',

'TRUE');

 

 

注： 

    在 Oracle 数据库 10g 版本 1（10.1）中，DBMS_LOGSTDBY.MAX_EVENTS 常量被称为 DBMS_LOGSTDBY_PUBLIC.MAX_EVENTS。两个常量的效果是一样的，但是在版本 2 （10.2）中 DBMS_LOGSTDBY_PUBLIC 包被废弃了，常量的定义就转移到 DBMS_LOGSTDBY 包中。 

 

 

即使你在数据库A 上运行这些 PL/SQL 过程，它们也不会影响主数据库。然而，通过

在创建逻辑备数据库（和逻辑备数据库控制文件）之前在主数据库上运行这些过程，当你在步骤4 中创建逻辑备数据库时这些设置自动转移。如果逻辑备数据库以及存在（数据库 B）并且能用于升级过程，在两边数据库上都执行

DBMS_LOGSTDBY PL/SQL 命令，然后跳到步骤 3。 

 

同时查看： 

    Oracle 数据库 PL/SQL 包和类型参考以获得 DBMS_LOGSTDBY 过程的完整相关信息 

 

 

第3 步 确认不支持的数据类型和存储属性要在主数据库上确认不支持的数据库对象并决定如何处理它们，遵循这些步骤： 

1．确认对表不支持的数据类型和存储属性： z 回顾在附录 C，“逻辑备数据库上支持的数据类型和 DDL 支持”中提供的支持的数据类型和存储属性的列表。 

z 在主数据库上查询 DBA_LOGSTDBY_UNSUPPORTED 和 DBA_LOGSTDBY_SKIP 视图。在主数据库上向列出表和方案进行的更改将不会应

用到逻辑备数据库上。下面查询显示了不支持表的列表的例子： 

SQL> SELECT DISTINCT OWNER, TABLE_NAME FROM

DBA_LOGSTDBY_UNSUPPORTED;

OWNER      TABLE_NAME

---------- ----------------- OE         CATEGORIES_TAB

OE         CUSTOMERS

OE         WAREHOUSES

PM         ONLINE_MEDIA

PM         PRINT_MEDIA

SCOTT      MYCOMPRESS SH         MVIEW$_EXCEPTIONS 7 rows selected.

 

SQL> 

SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP

  2   WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';

 

OWNER

------------------------------

CTXSYS

DBSNMP

DIP

ORDPLUGINS

ORDSYS

OUTLN

SI_INFORMTN_SCHEMA

SYS

SYSTEM

WMSYS

10 rows selected.

 

2．决定如何处理不支持的表。 

如果在你的主数据库上更改不支持的对象，可能使用下面方法之一来执行升级： z 在执行升级过程的时间期间临时挂起对不支持的表的更改。 

如果你能阻止对不支持更改的更改，则使用SQL 应用还是一个可行的执行升级过程的方法。这种方法需要你从创建逻辑备控制文件到你完成升级期间阻止用户更改任何不支持的表。你能监控在 DBA_LOGSTDBY_EVENTS 视图中的事务活动并终止升级（如果必要）直到你执行第一次切换。 

z 当用户将不能对不支持的表进行更改时执行升级。 

对于支持多个不同需求的部门的逻辑备数据库，如果你知道用户如何访问数据库中的表，使用SQL 应用来执行升级还是可能的。例如，假设薪酬部门更新一个对象表，但是那个部门只是从周一到周五更新数据库。然而，客户服务部门需要每天 24 小时、每周 7 天地访问数据库，但是只使用支持的数据类型和表。在这种场景，你能在周末执行升级。 

如果在升级期间你不能阻止对不支持的表的更改，任何发生的不支持的事务被记录在逻辑备数据库上的DBA_LOGSTDBY_EVENTS 表中。在更新完成后，你可能能使用 Oracle Data Pump 或 Export/Import 工具来导入更改的表到升级的数据库中。 

更改的表的大小将会确定数据库操作有多长时间不可用，所以你必须决定表是否太大而无法到处并导入其数据到备数据库。例如，一个4TB 的表不适于导出/导入处理。 

 

注：     如果因为在你的应用中的数据类型不被支持，你不能使用逻辑备数据库，则根据 Oracle 数据库升级指南中的文档执行升级。 

 

 

第4 步 创建逻辑备数据库 

要创建逻辑备数据库，遵循第 4 章中的指导。 

Oracle 建议在逻辑备数据库上配置一个备重做日志以最小化宕机时间。 

 

注： 

    如果已经存在逻辑备数据库，跳到 11.5 节，“升级数据库”来开始升级过程。 

 

 

 

11.5 升级数据库 

本节提供了升级逻辑备数据库和主数据库的逐步过程。表 11－1 列出了步骤。 

表11－1 升级Oracle 数据库软件的逐步过程 

1 停止 SQL 应用并升级逻辑备数据库 

2 重启 SQL 应用 

3 监控已升级备数据库上的事件 

4 开始切换 

5 确定在升级期间是否有更改不支持的对象 

6 完成切换并激活用户应用 

7 升级前主数据库 

8 开始 SQL 应用 

9 可选地，在两边数据库上都提升兼容级别 

10 监控在新的逻辑备数据库上的事件 

11 可选地，执行另一次切换 

注： 

    如果你的业务不需要逻辑备数据库来支持主数据库，你能跳过步骤 7 到 11。 

 

 

第1 步 停止 SQL 应用并升级逻辑备数据库 

要开始升级，停止SQL 应用并在逻辑备数据库（数据库 B）上升级 Oracle 数据库软件到版本 y。要停止 SQL 应用，在数据库 B 上执行下面语句： 

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

 

要升级Oracle 数据库软件，参考 Oracle 数据库升级指南以获得合适的 Oracle 数据库版本。 

图11－2 显示了数据库 A 运行在版本 x，数据库 B 运行在版本 y。在升级期间，重做数据库在主系统上累积。 

图11－2 升级逻辑备数据库版本 

 

 

第2 步 重启 SQL 应用 

重启SQL 应用并操作于数据库 A 上的版本 x 和数据库 B 上的版本 y。要开始 SQL 应用，在数据库 B 上执行下面语句： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

 

在主系统上累积的重做数据库自动传输并应用到新升级的逻辑备数据库上。当你检验升级的Oracle 数据库软件版本在生产环境正确运行的任意时期，Data Guard 配置都能运行图

11－3 所示的混合版本。图11－3 运行混合模式 

  

要监控数据库B 多快赶上数据库 A，在数据库 B 上查询 V$LOGSTDBY_PROGRESS

视图。例如： 

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS';

Session altered.

 

SQL> SELECT SYSDATE, APPLIED_TIME FROM V$LOGSTDBY_PROGRESS;

 

SYSDATE            APPLIED_TIME

------------------ ------------------

27-JUN-05 17:07:06 27-JUN-05 17:06:50

 

第3 步 监控已升级备数据库上的事件 

你应该频繁地查询DBA_LOGSTDBY_EVENTS 视图来获知是否有 DDL 和 DML 语句还没有在数据库 B 上被应用。例子 11－1 示范了监控事件如何能警告你在两个数据库中可能的区别。 

例子11－1 通过DBA_LOGSTDBY_EVENTS 监控事件 

SQL> SET LONG 1000

SQL> SET PAGESIZE 180

SQL> SET LINESIZE 79

SQL> SELECT EVENT_TIMESTAMP, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS

ORDER BY EVENT_TIMESTAMP;

 

EVENT_TIMESTAMP

----------------------------------------------------------------- EVENT

----------------------------------------------------------------- STATUS

-----------------------------------------------------------------

…

24-MAY-05 05.18.29.318912 PM

CREATE TABLE SYSTEM.TST (one number) ORA-16226: DDL skipped due to lack of support

 

24-MAY-05 05.18.29.379990 PM

"SYSTEM"."TST"

ORA-16129: unsupported dml encountered

 

在前面的例子中： 

z ORA-16226 错误显示了一句 DDL 语句可能不被支持。在这种情况下，因为它属于内部方案而可能不被支持。 

z ORA-16129 错误显示了一句 DML 语句没有被应用。 

这些错误类型指出所有在数据库A 上发生的更改还没有被应用到数据库 B。在这个点上，你必须决定是否继续升级过程。如果你确定这种逻辑备数据库和主数据库之间的不同是能够接收的，则继续升级过程。如果不是，中断并丢弃数据库 B 并在其它时间执行升级过程。 

 

第4 步 开始切换 

当你对升级的数据库软件正确操作感到满意时，通过在数据库A 上执行下面语句来执行切换以反转数据库角色： 

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

 

这可能只需要几秒钟，取决于语句是否必须等待现有的事务完成。还是连接到数据库A 的用户应该立即注销并重新连接到数据库 B。 

 

注： 

    如果当数据库 A 是主数据库时，你对其上面的不支持的表或包挂起活动，如果你最终

计划切换回数据库A，你必须当数据库 B 是主数据库时继续在其上面挂起同样的活动。 

 

 

第5 步 确定在升级期间是否有更改不支持的对象 

步骤3，“监控已升级备数据库上的事件”描述了如何列出被更改的不支持的表。如果在主数据库上执行了不支持的 DML 语句（如例子 11－1 中描述），使用导入工具如 Oracle

Data Pump 导入那些表的最近的版本。 

 

注： 

    你导入的表必须满足在 11.4 节，“准备升级”，步骤 3 中声明的数据类型需求。 

 

 

例如，下面导入命令截断scott.emp 表并导入符合前主数据库（A）的数据： 

IMPDP SYSTEM/MANAGER NETWORK_LINK=DATABASEA TABLES=SCOTT.EMP

TABLE_EXIST_ACTION=TRUNCATE

 

第6 步 完成切换并激活用户应用当你对升级的数据库软件正确操作感到满意时，完成切换以反转数据库角色： 

1．在数据库 B 上，查询 V$DATABASE 视图的 SWITCHOVER_STATUS 列，如下： 

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

 

SWITCHOVER_STATUS

--------------------

TO PRIMARY

 

2．当 SWITCHOVER_STATUS 列显示 TO PRIMARY 时，通过在数据库 B 上执行下面语句完成切换： 

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL PRIMARY;

 

3．在数据库 B 上激活用户应用和服务，它现在运行在主数据库角色了。 

在切换过后，你不能从运行在新数据库软件版本的新的主数据库（B）发送重做数据到运行在旧的软件版本的新的备数据库（A）。这意味着： z 重做数据在新的主数据库上累积。 

z 新的主数据库在这个时候是不受保护的。 

图11－4 显示数据库 B，前备数据库（运行版本 y），现在是主数据库，数据库 A，前主数据库（运行版本 x），现在是备数据库。用户连接到数据库 B。 

如果数据库B 能足够地作为主数据库服务并且你的业务不需要逻辑备数据库来支持主数据库，则你已经完成了滚动升级步骤。允许用户登陆到数据库 B 并在那里开始工作，并在方便的时候丢弃数据库 A。否则，继续步骤 7。 

图11－4 在切换过后 

 

 

第7 步 升级前主数据库 

数据库A 还是运行在版本 x 并且不能从数据库 B 应用重做数据，直到你升级它并开始

SQL 应用。 

要获得升级Oracle 数据库软件的更多信息，查看 Oracle 数据库升级指南以获得合适的

Oracle 数据库版本。 

图11－5 显示了在两边数据库都升级过后的系统。 

图11－5 两边数据库都升级了 

 

 

第8 步 开始 SQL 应用 

在数据库A 上执行下面语句以开始 SQL 应用，如果必要，创建一个数据库链接到数据库 B： 

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY db_link_to_b;

 

注： 

    只有在数据库链接还没有设置时，在执行这条语句之前创建数据库链接。 

 

 

当你在数据库A 上开始 SQL 应用时，在主数据库（B）上累积的重做数据被发送到逻

辑备数据库（A）。一旦所有重做数据库在备数据库上变得可用，主数据库再次受到保护。 

 

第9 步 可选地，在两边数据库上都提升兼容级别 

通过设置COMPATIBLE 初始化参数提升两个数据库的兼容性级别。在设置主数据库之前先在备数据库上设置 COMPATIBLE 参数。查看 Oracle 数据库参考以获得 COMPATIBLE 初始化参数的更多相关信息。 

 

第10 步 监控在新的逻辑备数据库上的事件 

要确保在数据库B 上执行的所哟更改正确应用到逻辑备数据库（A），你应该频繁地查询 DBA_LOGSTDBY_EVENTS 视图，如在步骤 3 中对数据库 A 所做。（查看例子 11－1）如果进行的更改使得数据库 A 无效作为你的现有主数据库的拷贝，你能丢弃数据库 A 并在其位置创建一个新的逻辑备数据库，查看第 4 章，“创建逻辑备数据库”以获得完整信息。 

 

第11 步 可选地，执行另一次切换 

可选地，执行数据库的另一次切换使得数据库A 再次运行于主数据库角色（如图 11－1 中所示）。 

 

同时查看： 

   7.3.1 节，“包含逻辑备数据库的切换”