【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