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 数据库的更多相关信息。