本节中的信息介绍了如何开始使用Oracle Data Guard。
请参阅以下主题：
目录
[二、用于管理Oracle Data Guard配置的用户界面](#二、用于管理Oracle Data Guard配置的用户界面)
[2.1.Oracle Enterprise Manager Cloud Control](#2.1.Oracle Enterprise Manager Cloud Control)
[2.2.SQL*Plus 命令行界面](#2.2.SQL*Plus 命令行界面)
[2.4.Oracle Data Guard代理命令行界面（DGMGRL）](#2.4.Oracle Data Guard代理命令行界面（DGMGRL）)
[三、Oracle Data Guard 操作先决条件](#三、Oracle Data Guard 操作先决条件)
一、备用数据库类型
备用数据库是Oracle生产数据库的事务一致性副本，最初是从主数据库的备份副本创建的。
一旦创建并配置了备用数据库，Oracle Data Guard就会自动通过将主数据库的重做数据传输到备用系统来维护备用数据库，在备用系统中，这些重做数据会被应用到备用数据库。
备用数据库可以是以下类型之一：**物理备用数据库、逻辑备用数据库或快照备用数据库。**如果需要，物理或逻辑备用数据库可以承担主数据库的角色，并接管生产处理。Oracle Data Guard配置可以包含下列类型备用数据库的任意组合
2.1.物理备用数据库
物理备用数据库是主数据库的精确、逐块复制的副本。
通过一个称为"重做应用"的过程，将物理备用数据库维护为精确副本，在该过程中，使用数据库恢复机制将从主数据库接收到的重做数据连续应用于物理备用数据库。
可以打开一个物理备用数据库进行只读访问，并用于从主数据库卸载查询。如果已购买Oracle Active Data Guard选项的许可证，则当物理备用数据库处于打开状态时，Redo Apply可以处于活动状态，从而使查询返回的结果与主数据库返回的结果相同。 此功能称为实时查询功能**（ADG）。**
2.1.1.物理备用数据库的优点
物理备用数据库具有以下优势：
1）灾难恢复与高可用性
物理备用数据库是一种稳健且高效的灾难恢复和高可用性解决方案。其易于管理的切换和故障转移功能，使得主数据库和物理备用数据库之间的角色能够轻松互换，从而最大限度地减少了主数据库因计划内和计划外停机而导致的停机时间。
2）数据保护
物理备用数据库能够防止数据丢失，即使在遭遇不可预知的灾难时也是如此。物理备用数据库支持主数据库所能支持的所有数据类型以及所有DDL和DML操作。此外，它还能提供保护，防止数据损坏和用户错误。**主数据库上的存储级物理损坏不会传播到备用数据库。**同样，原本可能导致数据丢失的逻辑损坏或用户错误也能轻松解决。
3）主数据库工作负载减少
Oracle Recovery Manager (RMAN) 可以利用物理备用数据库来卸载主数据库的备份，从而节省宝贵的 CPU 和 I/O 周期。
在重做应用（Redo Apply）处于活动状态时，也可以查询物理备用数据库，这样可以将查询从主数据库卸载到物理备用数据库，从而进一步减轻主数据库的工作负载。
4）性能
物理备用数据库所使用的Redo Apply技术 是使备用数据库保持与主数据库所做更改同步的最有效机制 ，因为它使用低级恢复机制来应用更改，从而绕过所有SQL级别的代码层。
2.2.逻辑备用数据库
逻辑备用数据库最初是作为主数据库的完全相同副本创建的，但之后可以修改为具有不同的结构。
逻辑备用数据库通过执行SQL语句进行更新。 逻辑备用数据库的灵活性使您能够以滚动方式升级Oracle数据库软件（补丁集和新的Oracle数据库版本）并执行其他数据库维护，几乎无需停机。从Oracle数据库11g开始，瞬态逻辑数据库滚动升级过程也可用于现有的物理备用数据库。
**原理：**Oracle Data Guard通过将日志文件中的数据转换为SQL语句，然后在逻辑备用数据库上执行这些SQL语句，从而自动将已存档的重做日志文件或备用重做日志文件中的信息应用到逻辑备用数据库。由于逻辑备用数据库是使用SQL语句进行更新的，因此它必须保持打开状态。尽管逻辑备用数据库是以读/写模式打开的，但其用于重新生成SQL的目标表仅可用于只读操作。在这些表被更新的同时，它们可以同时用于其他任务，如报告、汇总和查询。
逻辑备用数据库对数据类型、表类型以及DDL和DML操作类型有一些限制。有关逻辑备用数据库对数据类型和DDL支持的信息，请参阅"逻辑备用数据库上的数据类型和DDL支持"。
2.2.1.逻辑备用数据库的优点
逻辑备用数据库是实现高可用性（HA）的理想选择，同时还能提供数据恢复（DR）的益处。与物理备用数据库相比，逻辑备用数据库在提供高可用性方面具有显著优势：
1）尽量减少软件升级带来的停机时间
逻辑备用数据库是滚动升级Oracle Data Guard配置的理想选择。 逻辑备用数据库可大幅减少因应用补丁集和新软件版本而导致的停机时间。**逻辑备用数据库可以升级到新版本，然后切换成为活动主数据库。**这样，在旧主数据库转换为逻辑备用数据库并应用补丁集时，系统仍可保持完全可用。逻辑备用数据库为DBMS_ROLLING PL/SQL包提供了底层平台，该包提供的功能使您的Oracle Data Guard配置在滚动升级和其他存储重组环境中保持高可用性。
2）对报告和决策支持需求的支持
逻辑备份的一个关键优势在于，可以创建重要的辅助结构来优化报告工作负载；这些结构可能会对主数据库的事务响应时间产生严重影响。
逻辑备份的数据可以物理重组为具有不同分区和许多不同索引的不同存储类型，可以创建和维护按需刷新的物化视图，并且可以用于驱动数据立方体和其他OLAP数据视图的创建。然而，逻辑备份数据库不允许对数据进行任何转换（例如仅复制用户表中的部分列或允许用户表上有额外的列）。对于这些类型的报告活动，Oracle GoldenGate是Oracle的首选解决方案。
2.3.快照备用数据库
快照备用数据库是一种可更新的备用数据库，为主数据库提供完整的数据保护。
**快照备用数据库接收并存档来自主数据库的重做数据，但不会应用这些数据。**当快照备用数据库在丢弃所有本地更新后转换回物理备用数据库时，会应用从主数据库接收到的重做数据。
随着时间的推移，快照备用数据库会与其主数据库产生差异，因为主数据库的重做数据在接收时并未被应用。对快照备用数据库的本地更新会导致额外的差异。然而，主数据库中的数据得到了充分保护，因为快照备用数据库可以随时转换回物理备用数据库，然后应用从主数据库接收到的重做数据。
2.3.1.快照备用数据库的优点
快照备用数据库是一个完全可更新的备用数据库，它提供的灾难恢复和数据保护功能与物理备用数据库相似。在主数据库出现故障时，如果临时、可更新的主数据库快照所带来的好处足以弥补恢复时间增加的损失，那么最好使用快照备用数据库。
使用快照备用数据库的好处包括以下几点：
1.它为开发和测试目的**提供了一个生产数据库的精确副本，同时始终保持数据保护。**您可以使用Oracle Real Application Testing选项来捕获主数据库的工作负载，然后在快照备用数据库上重放以进行测试。
2.通过转换为物理备用状态并重新同步，可以轻松刷新以包含当前的生产数据。
创建快照备用副本、进行测试、与生产环境重新同步，然后再次创建快照备用副本并进行测试，这一循环可以根据需要重复任意多次。在需要读写数据的情况下，可以使用相同的过程轻松创建并定期更新快照备用副本，以用于报告目的。
二、用于管理Oracle Data Guard配置的用户界面
Oracle Data Guard提供了多个接口，可用于配置、实施和管理Oracle Data Guard配置。
2.1.Oracle Enterprise Manager Cloud Control
Oracle Enterprise Manager Cloud Control 为 Oracle Data Guard 代理提供了一个图形用户界面（GUI），该界面可自动化创建、配置和监控 Oracle Data Guard 环境中的许多任务。
有关 GUI 及其向导的信息，请参阅 Oracle Enterprise Manager Cloud Control 在线帮助。
2.2.SQL*Plus 命令行界面
多条SQL*Plus语句使用STANDBY关键字来指定对备用数据库的操作。其他SQL语句虽然不包含特定于备用的语法，但它们对于在备用数据库上执行操作非常有用。
有关相关语句的列表，请参阅与Oracle Data Guard相关的SQL语句。
2.3.初始化参数
Oracle Data Guard环境需要使用多个初始化参数来定义。
有关相关初始化参数的列表，请参阅初始化参数。
2.4.Oracle Data Guard代理命令行界面（DGMGRL）
DGMGRL命令行界面是使用Oracle Enterprise Manager Cloud Control的替代方案。如果您想使用代理从批处理程序或脚本中管理Oracle Data Guard配置，DGMGRL命令行界面将非常有用。有关完整信息，请参阅Oracle Data Guard Broker。
三、Oracle Data Guard 操作先决条件
使用Oracle Data Guard需要满足特定的硬件和软件先决条件。硬件和操作系统要求、Oracle软件要求。
3.1.硬件要求
主数据库和所有备用数据库必须安装同一版本的Oracle数据库企业版，但在使用逻辑或临时逻辑备用数据库进行滚动数据库升级时除外。
从Oracle数据库11g开始，Oracle Data Guard为主系统和备用系统可能具有不同的CPU架构、操作系统（例如Windows和Linux）、操作系统二进制文件（32位/64位）或Oracle数据库二进制文件（32位/64位）的Oracle Data Guard配置提供了更大的灵活性。
这种增强的混合平台灵活性受限于当前在"我的Oracle支持"说明413484.1和1085687.1（网址为http://support.oracle.com）中记录的限制。
注释413484.1讨论了物理备用机的混合平台支持和限制。
注释1085687.1讨论了逻辑备用的混合平台支持和限制。
3.2.软件要求
要使用Oracle Data Guard，您必须满足特定的Oracle软件要求。Oracle Data Guard仅作为Oracle数据库企业版的一项功能提供。Oracle数据库标准版不提供此功能。
注意： 可以使用运行Oracle数据库标准版的数据库来模拟备用数据库环境。**具体做法是，使用操作系统复制工具手动传输已存档的重做日志文件，或使用自定义脚本定期将已存档的重做日志文件从一个数据库发送到另一个数据库，对它们进行注册，并在灾难恢复站点使用媒体恢复来前滚数据库副本。**但这种配置无法提供Oracle Data Guard所具备的易用性、可管理性、性能和灾难恢复能力。
使用Oracle Data Guard SQL Apply，您可以将Oracle数据库软件从补丁集版本n（最低要求是10.1.0.3版本）滚动升级到任何更高版本的补丁集或主要版本。在滚动升级过程中，您可以在主数据库和逻辑备用数据库上运行不同版本的Oracle数据库，同时逐一进行升级。
如需完整信息，请参阅《使用SQL Apply升级Oracle数据库》以及适用Oracle Database 10g补丁集版本的ReadMe文件。
在Oracle Data Guard配置中，所有数据库上的COMPATIBLE数据库初始化参数必须设置为相同的值，但使用逻辑备用数据库时除外，逻辑备用数据库的COMPATIBLE设置可以高于主数据库。
主数据库必须在归档（ARCHIVELOG）模式下运行。更多信息请参阅《Oracle数据库管理员指南》。
主数据库可以是单实例数据库，也可以是Oracle Real Application Clusters（Oracle RAC）数据库。备用数据库可以是单实例数据库，也可以是Oracle RAC数据库，并且这些备用数据库可以是物理、逻辑和快照类型的混合。生产中最为常见的就是RAC+DG，单实例+ADG。
每个主数据库和备用数据库都必须有自己的控制文件。
如果备用数据库与主数据库位于同一系统上，则备用数据库的归档目录必须使用与主数据库不同的目录结构。 否则，备用数据库可能会覆盖主数据库的文件。但是这个不满足于一般规范。生产中不常见，一般都是异机部署。
为了防止主数据库中未记录的直接写入操作无法传播到备用数据库，请在执行数据文件备份以创建备用数据库之前，在主数据库中启用FORCE LOGGING模式。只要需要备用数据库，就应将数据库保持在FORCE LOGGING模式。这里非常重要，实际的部署安装中也确实是这样。
您用于管理主数据库实例和备用数据库实例的用户账户必须具有SYSDG或SYSDBA管理权限。
为了简化操作，Oracle 建议在 Oracle Data Guard 配置中设置 Oracle 自动存储管理 (Oracle ASM) 和 Oracle 受管理文件 (OMF) 时，应在主数据库和备用数据库上对称设置。如果 Oracle Data Guard 配置中的任何数据库使用 Oracle ASM、OMF 或两者，则该配置中的每个数据库都应分别使用 Oracle ASM、OMF 或两者，除非您有意为实现迁移或维护目的而采用混合配置。有关更多信息，请参阅"创建使用 OMF 或 Oracle ASM 的备用数据库"中的场景。
**注意：**由于某些执行涉及基于时间的数据更新的应用程序无法处理来自多个时区的数据，因此建议将主系统和远程备用系统的时区设置为相同，以确保在角色转换后记录的时序顺序得以保持。
四、备用数据库目录结构注意事项
**各种备用数据库的目录结构非常重要，因为它决定了备用数据文件、已存档的重做日志文件以及备用重做日志文件的路径名。**在实际的部署过程中需要尤为关注这一点。
如果可能的话，主系统和备用系统上的数据文件、日志文件和控制文件应具有相同的名称和路径名，并遵循最优灵活架构（OFA）的命名约定。备用数据库上的归档目录在各个站点之间也应保持一致，包括大小和结构。这一策略使得备份、切换和故障转移等其他操作能够执行相同的步骤集，从而降低维护的复杂性。总的来说就是最佳实践推荐目录结构最好保持一致、
有关最优灵活架构（OFA）的更多信息，请参阅特定于您的操作系统的Oracle文档
**否则，您必须设置文件名转换参数（如表4-1所示）或重命名数据文件。**然而，如果您需要使用具有不同目录结构的系统，或者将备用数据库和主数据库置于同一系统上，您只需进行少量的额外管理即可实现。
Table 4-1 Standby Database Location and Directory Options
| Standby System | Directory Structure | Consequences |
|---|---|---|
| Same as primary system | Different than primary system (required) | * You can either manually rename files or set up the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT initialization parameters on the standby database to automatically update the path names for primary database data files and archived redo log files and standby redo log files in the standby database control file. (See Set Primary Database Initialization Parameters.) * The standby database does not protect against disasters that destroy the system on which the primary and standby databases reside, but it does provide switchover capabilities for planned maintenance. |
| Separate system | Same as primary system | * You do not need to rename primary database files, archived redo log files, and standby redo log files in the standby database control file, although you can still do so if you want a new naming scheme (for example, to spread the files among different disks). * By locating the standby database on separate physical media, you safeguard the data on the primary database against disasters that destroy the primary system. |
| Separate system | Different than primary system | * You can either manually rename files or set up the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT initialization parameters on the standby database to automatically rename the data files (see Set Primary Database Initialization Parameters). * By locating the standby database on separate physical media, you safeguard the data on the primary database against disasters that destroy the primary system. |
下图4-1展示了三种基本配置选项。
这些选项包括：
1.与主数据库位于同一系统上的备用数据库，其目录结构与主系统不同。这在上图中以"Standby1"表示。
2.如果备用数据库与主数据库位于同一系统上，则必须使用不同的目录结构。否则，备用数据库会尝试覆盖主数据库文件。
3.一个位于独立系统上的备用数据库，其目录结构与主系统相同。这在图4-1中以"Standby2"表示。这是推荐的方法。
4.一个位于独立系统上的备用数据库，其目录结构与主系统不同。这在图4-1中以"Standby3"表示。
**注意：**为简化操作，Oracle 建议在 Oracle Data Guard 配置中设置 Oracle 自动存储管理 (Oracle ASM) 和 Oracle 受管理文件 (OMF) 时，应在主数据库和备用数据库上对称设置。如果 Oracle Data Guard 配置中的任何数据库使用 Oracle ASM、OMF 或两者，则该配置中的每个数据库都应分别使用 Oracle ASM、OMF 或两者，除非您有意为实现迁移或维护目的而采用混合配置。有关更多信息，请参阅"创建使用 OMF 或 Oracle ASM 的备用数据库"中的场景。
五、移动在线数据文件的位置
在数据库正在访问文件时，您可以将在线数据文件的位置从一个物理文件移动到另一个物理文件。
要移动文件的位置，您可以使用SQL语句ALTER DATABASE MOVE DATAFILE。
使用ALTER DATABASE MOVE DATAFILE语句执行的操作可提高数据库的可用性，因为该操作不需要关闭数据库即可移动在线数据文件的位置。
您可以在主服务器和备用服务器（无论是物理服务器还是逻辑服务器）上独立执行在线移动数据文件的操作。在主服务器上移动数据文件时，备用服务器不会受到影响，反之亦然。
在物理待机状态下，如果打开数据库的实例处于只读模式，则可以在待机恢复运行时执行在线移动数据文件操作。此功能需要Oracle Active Data Guard许可证。
5.1.移动在线数据文件位置时的限制
在移动在线数据文件位置时，存在一些限制。
1.如果物理备用数据库已装载但未打开，则不能使用SQL的ALTER DATABASE MOVE DATAFILE命令来重命名或重新定位作为快速启动故障转移目标的该备用数据库上的在线数据文件。
2.在已装载但未打开的实例中运行待机恢复时，无法在物理待机状态下执行在线移动数据文件操作。
3.如果备用恢复过程使数据文件离线、缩小文件大小或删除表空间，则在线移动数据文件操作可能会中止。
4.在主数据库上，无法对属于已在该主数据库所有实例上关闭的可插拔数据库（PDB）的文件执行在线移动数据文件操作。