2 Getting Started with Data Guard

A Data Guard configuration contains a primary database and up to thirty associated standby databases. This chapter describes the following considerations for getting started with Data Guard:

Standby Database Types

User Interfaces for Administering Data Guard Configurations

Data Guard Operational Prerequisites

Standby Database Directory Structure Considerations

2.1 Standby Database Types

A standby database is a transactionally consistent copy of an Oracle production database that is initially created from a backup copy of the primary database. Once the standby database is created and configured, Data Guard automatically maintains the standby database by transmitting primary database redo data to the standby system, where the redo data is applied to the standby database.

A standby database can be one of these types: a physical standby database, a logical standby database, or a snapshot standby database. If needed, either a physical or a logical standby database can assume the role of the primary database and take over production processing. A Data Guard configuration can include any combination of these types of standby databases.

（一个standby数据库是Oracle生产数据库的事务一致副本，最初是从主数据库的备份副本创建的。一旦创建并配置了备用数据库，Data Guard就会通过将主数据库重做数据传输到备用系统来自动维护备用数据库，备用系统将重做数据应用于备用数据库。

备用数据库可以是以下类型之一：物理备用数据库，逻辑备用数据库或快照备用数据库。如果需要，物理备用数据库或逻辑备用数据库可承担主数据库的角色并接管生产处理。Data Guard配置可以包括这些类型的备用数据库的任意组合。）

2.1.1 Physical Standby Databases

A physical standby database is an exact, block-for-block copy of a primary database. A physical standby is maintained as an exact copy through a process called Redo Apply, in which redo data received from a primary database is continuously applied to a physical standby database using the database recovery mechanisms.

A physical standby database can be opened for read-only access and used to offload queries from a primary database. If a license for the Oracle Active Data Guard option has been purchased, Redo Apply can be active while the physical standby database is open, thus allowing queries to return results that are identical to what would be returned from the primary database. This capability is known as the real-time query feature.

（物理备用数据库是主数据库的确切块对块拷贝。通过名为“重做应用”的进程将物理备用数据库作为精确副本进行维护，其中使用数据库恢复机制将从主数据库接收到的重做数据连续应用于物理备用数据库。

可以打开物理备用数据库以进行只读访问，并用于卸载主数据库中的查询。如果购买了Oracle Active Data Guard选件的许可证，则在物理备用数据库处于打开状态时，重做应用可以处于活动状态，从而允许查询返回与主数据库返回的结果相同的结果。这种能力被称为实时查询功能。）

Benefits of a Physical Standby Database

A physical standby database provides the following benefits:

Disaster recovery and high availability

A physical standby database is a robust and efficient disaster recovery and high availability solution. Easy-to-manage switchover and failover capabilities allow easy role reversals between primary and physical standby databases, minimizing the downtime of the primary database for planned and unplanned outages.

（物理备用数据库是强大而高效的灾难恢复和高可用性解决方案。易于管理的切换和故障转移功能使主数据库和物理备用数据库之间的角色转换轻松实现，从而将计划内和计划外停机的主数据库停机时间降至最低。）

Data protection

A physical standby database can prevent data loss, even in the face of unforeseen disasters. A physical standby database supports all datatypes, and all DDL and DML operations that the primary database can support. It also provides a safeguard against data corruptions and user errors. Storage level physical corruptions on the primary database will not be propagated to a standby database. Similarly, logical corruptions or user errors that would otherwise cause data loss can be easily resolved.

（物理备用数据库可以防止数据丢失，即使面对不可预见的灾难。物理备用数据库支持所有数据类型，以及主数据库可以支持的所有DDL和DML操作。它还提供了防止数据损坏和用户错误的安全措施。主数据库上的存储级物理损坏将不会传播到备用数据库。同样，可以很容易地解决否则会导致数据丢失的逻辑损坏或用户错误。）

Reduction in primary database workload

Oracle Recovery Manager (RMAN) can use a physical standby database to off-load backups from a primary database, saving valuable CPU and I/O cycles.

A physical standby database can also be queried while Redo Apply is active, which allows queries to be offloaded from the primary to a physical standby, further reducing the primary workload.

（Oracle Recovery Manager（RMAN）可以使用物理备用数据库来卸载主数据库的备份，从而节省宝贵的CPU和I / O周期。

当“重做申请”处于活动状态时，也可以查询物理备用数据库，这样可以将查询从主数据库卸载到物理备用数据库，从而进一步减少主要工作负载。）

Performance

The Redo Apply technology used by a physical standby database is the most efficient mechanism for keeping a standby database updated with changes being made at a primary database because it applies changes using low-level recovery mechanisms which bypass all SQL level code layers.

（物理备用数据库使用的重做应用技术是保持备用数据库更新的最有效机制，在主数据库中进行了更改，因为它使用绕过所有SQL级代码层的低级恢复机制来应用更改。）

2.1.2 Logical Standby Databases

A logical standby database is initially created as an identical copy of the primary database, but it later can be altered to have a different structure. The logical standby database is updated by executing SQL statements. This allows users to access the standby database for queries and reporting at any time. Thus, the logical standby database can be used concurrently for data protection and reporting operations.

（逻辑备用数据库最初是作为主数据库的相同副本创建的，但以后可以更改为具有不同的结构。逻辑备用数据库通过执行SQL语句进行更新。这使用户可以随时访问备用数据库进行查询和报告。因此，逻辑备用数据库可以同时用于数据保护和报告操作。）

Data Guard automatically applies information from the archived redo log file or standby redo log file to the logical standby database by transforming the data in the log files into SQL statements and then executing the SQL statements on the logical standby database. Because the logical standby database is updated using SQL statements, it must remain open. Although the logical standby database is opened in read/write mode, its target tables for the regenerated SQL are available only for read-only operations. While those tables are being updated, they can be used simultaneously for other tasks such as reporting, summations, and queries. Moreover, these tasks can be optimized by creating additional indexes and materialized views on the maintained tables.

（Data Guard通过将日志文件中的数据转换为SQL语句，然后在逻辑备用数据库上执行SQL语句，自动将归档重做日志文件或备用重做日志文件中的信息应用于逻辑备用数据库。由于逻辑备用数据库使用SQL语句进行更新，因此必须保持打开状态。虽然逻辑备用数据库以读/写模式打开，但是其重新生成的SQL的目标表只能用于只读操作。当这些表正在更新时，它们可以同时用于其他任务，如报告，求和和查询。而且，这些任务可以通过创建附加索引来进行优化在维护的表上实现物化视图。）

A logical standby database has some restrictions on datatypes, types of tables, and types of DDL and DML operations. See Appendix C for information on data type and DDL support on logical standby databases.

（逻辑备用数据库对数据类型，表类型以及DDL和DML操作的类型有一些限制。有关逻辑备数据库上数据类型和DDL支持的信息。）

B enefits of a Logical Standby Database

A logical standby database is ideal for high availability (HA) while still offering data recovery (DR) benefits. Compared to a physical standby database, a logical standby database provides significant additional HA benefits:

（逻辑备用数据库是高可用性（HA）的理想选择，同时还提供数据恢复（DR）的好处。与物理备用数据库相比，逻辑备用数据库提供了显着的额外HA优势：）

Protection against additional kinds of failure

Because logical standby analyzes the redo and reconstructs logical changes to the database, it can detect and protect against certain kinds of hardware failure on the primary that could potentially be replicated through block level changes. Oracle supports having both physical and logical standbys for the same primary server.

（由于逻辑备用数据库分析重做数据并重建数据库的逻辑更改，因此它可以检测并防止主数据库上可能通过数据块级别更改复制的某些类型的硬件故障。Oracle支持为同一主服务器提供物理和逻辑备用数据库。）

Efficient use of resources

A logical standby database is open read/write while changes on the primary are being replicated. Consequently, a logical standby database can simultaneously be used to meet many other business requirements, for example it can run reporting workloads that would problematical for the primary's throughput. It can be used to test new software releases and some kinds of applications on a complete and accurate copy of the primary's data. It can host other applications and additional schemas while protecting data replicated from the primary against local changes. It can be used to assess the impact of certain kinds of physical restructuring (for example, changes to partitioning schemes). Because a logical standby identifies user transactions and replicates only those changes while filtering out background system changes, it can efficiently replicate only transactions of interest.

（逻辑备用数据库是开放的读/写，而主要的变化正在被复制。因此，可以同时使用逻辑备用数据库来满足许多其他业务需求，例如，它可以运行报告工作负载，这对主数据的吞吐量会产生问题。它可以用来测试新的软件版本和一些完整而准确的主数据副本的应用程序。它可以托管其他应用程序和附加模式，同时保护从主数据复制的数据免受本地更改。它可以用来评估某些类型的物理重组的影响（例如，对分区方案的改变）。由于逻辑备用数据库标识用户事务并仅复制这些更改，同时过滤掉后台系统更改，）

Workload distribution

Logical standby provides a simple turnkey solution for creating up-to-the-minute, consistent replicas of a primary database that can be used for workload distribution. As the reporting workload increases, additional logical standbys can be created with transparent load distribution without affecting the transactional throughput of the primary server.

（逻辑备用提供了一个简单的统包解决方案，用于创建可用于工作负载分配的主数据库的最新，一致的副本。随着报告工作负载的增加，可以使用透明的负载分配创建额外的逻辑备用数据库，而不会影响主服务器的事务吞吐量。）

Optimized for reporting and decision support requirements

A key benefit of logical standby is that significant auxiliary structures can be created to optimize the reporting workload; structures that could have a prohibitive impact on the primary's transactional response time. A logical standby can have its data physically reorganized into a different storage type with different partitioning, have many different indexes, have on-demand refresh materialized views created and maintained, and it can be used to drive the creation of data cubes and other OLAP data views.

（逻辑待机的关键好处是可以创建重要的辅助结构来优化报告工作负载; 这种结构可能会对主库的交易响应时间产生极大的影响。逻辑备用可以将其数据物理重组为具有不同分区的不同存储类型，具有许多不同的索引，具有创建和维护的按需刷新物化视图，并且可以用于驱动数据立方体和其他OLAP数据的创建观点。）

Minimizing downtime on software upgrades

Logical standby can be used to greatly reduce downtime associated with applying patchsets and new software releases. A logical standby can be upgraded to the new release and then switched over to become the active primary. This allows full availability while the old primary is converted to a logical standby and the patchset is applied.

（逻辑备用可以用来大大减少与应用补丁集和新软件版本相关的停机时间。逻辑待机可以升级到新版本，然后切换到活动的主要。这允许完全可用性，而旧的主要转换为逻辑备用，并应用补丁集。）

2.1.3 Snapshot Standby Databases

A snapshot standby database is a type of updatable standby database that provides full data protection for a primary database. A snapshot standby database receives and archives, but does not apply, redo data from its primary database. Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.

（快照备用数据库是一种可更新的备用数据库，为主数据库提供完整的数据保护。快照备用数据库接收并归档（但不适用）重做其主数据库中的数据。在将快照备用数据库的所有本地更新都废弃后，将快照备用数据库转换回物理备用数据库时，将应用从主数据库接收到的重做数据。）

A snapshot standby database typically diverges from its primary database over time because redo data from the primary database is not applied as it is received. Local updates to the snapshot standby database will cause additional divergence. The data in the primary database is fully protected however, because a snapshot standby can be converted back into a physical standby database at any time, and the redo data received from the primary will then be applied.

（快照备用数据库通常会随时间而偏离其主数据库，因为主数据库中的重做数据在收到时不会应用。快照备用数据库的本地更新将导致额外的分歧。然而，主数据库中的数据是完全受保护的，因为可以随时将快照备用数据库转换回物理备用数据库，然后应用从主数据库接收到的重做数据。）

Benefits of a Snapshot Standby Database

A snapshot standby database is a fully updatable standby database that provides disaster recovery and data protection benefits that are similar to those of a physical standby database. Snapshot standby databases are best used in scenarios where the benefit of having a temporary, updatable snapshot of the primary database justifies the increased time to recover from primary database failures.

（快照备用数据库是完全可更新的备用数据库，提供类似于物理备用数据库的灾难恢复和数据保护优势。快照备用数据库最适用于具有主数据库的临时可更新快照的好处，从而增加了从主数据库故障中恢复的时间。）

The benefits of using a snapshot standby database include the following:

It provides an exact replica of a production database for development and testing purposes, while maintaining data protection at all times.

It can be easily refreshed to contain current production data by converting to a physical standby and resynchronizing.

（它提供了用于开发和测试目的的生产数据库的精确副本，同时始终保持数据保护。

通过转换为物理备用数据库并重新同步，可以轻松刷新以包含当前生产数据。）

The ability to create a snapshot standby, test, resynchronize with production, and then again create a snapshot standby and test, is a cycle that can be repeated as often as desired. The same process can be used to easily create and regularly update a snapshot standby for reporting purposes where read/write access to data is required.

（创建快照备用，测试，重新同步生产，然后再次创建快照备用和测试的能力，是一个可以按需要重复的循环。可以使用相同的过程轻松地创建和定期更新快照备用数据库，以用于需要读/写数据访问权限的报告目的。）

2.2 User Interfaces for Administering Data Guard Configurations

You can use the following interfaces to configure, implement, and manage a Data Guard configuration:

Oracle Enterprise Manager

Enterprise Manager provides a GUI interface for the Data Guard broker that automates many of the tasks involved in creating, configuring, and monitoring a Data Guard environment. See Oracle Data Guard Broker and the Oracle Enterprise Manager online Help for information about the GUI and its wizards.

（企业管理器为Data Guard代理提供了一个GUI界面，可自动执行创建，配置和监视Data Guard环境所涉及的许多任务。有关GUI及其向导的信息，请参阅Oracle Data Guard Broker和Oracle Enterprise Manager联机帮助。）

SQL*Plus Command-line interface

Several SQL*Plus statements use the STANDBY keyword to specify operations on a standby database. Other SQL statements do not include standby-specific syntax, but they are useful for performing operations on a standby database. See Chapter 16 for a list of the relevant statements.

（多个SQL * Plus语句使用STANDBY关键字来指定备用数据库上的操作。其他SQL语句不包括特定于待机的语法，但是它们对于在备用数据库上执行操作很有用。有关报表的清单见第16章。）

Initialization parameters

Several initialization parameters are used to define the Data Guard environment. See Chapter 14 for a list of the relevant initialization parameters.

（几个初始化参数用于定义Data Guard环境。有关初始化参数的列表，请参阅第14章。）

Data Guard broker command-line interface (DGMGRL)

The DGMGRL command-line interface is an alternative to using Oracle Enterprise Manager. The DGMGRL command-line interface is useful if you want to use the broker to manage a Data Guard configuration from batch programs or scripts. See Oracle Data Guard Broker for complete information.

（DGMGRL命令行界面是使用Oracle企业管理器的替代方法。如果要使用代理从批处理程序或脚本管理Data Guard配置，则DGMGRL命令行界面很有用。有关完整信息，请参阅Oracle Data Guard Broker。）

2.3 Data Guard Operational Prerequisites

The following sections describe operational requirements for using Data Guard:

Hardware and Operating System Requirements

Oracle Software Requirements

2.3.1 Hardware and Operating System Requirements

As of Oracle Database 11g, Data Guard provides increased flexibility for Data Guard configurations in which the primary and standby systems may have different CPU architectures, operating systems (for example, Windows & Linux), operating system binaries (32-bit/64-bit), or Oracle database binaries (32-bit/64-bit).

This increased mixed-platform flexibility is subject to the current restrictions documented in the My Oracle Support notes 413484.1 and 1085687.1 at http://support.oracle.com.

Note 413484.1 discusses mixed-platform support and restrictions for physical standbys.

Note 1085687.1 discusses mixed-platform support and restrictions for logical standbys.

The same release of Oracle Database Enterprise Edition must be installed on the primary database and all standby databases, except during rolling database upgrades using logical standby databases.

（从Oracle Database 11g起，Data Guard为Data Guard配置提供了更高的灵活性，其中主系统和备用系统可能具有不同的CPU体系结构，操作系统（例如Windows和Linux），操作系统二进制文件（32位/位）或Oracle数据库二进制文件（32位/ 64位）。

这种增加的混合平台灵活性受“My Oracle Support说明”413484.1和1085687.1中记录的当前限制的限制http://support.oracle.com。

注释413484.1讨论了物理备用的混合平台支持和限制。

注1085687.1讨论了逻辑备用的混合平台支持和限制。

除了在使用逻辑备用数据库的滚动数据库升级期间，主数据库和所有备用数据库上必须安装相同版本的Oracle数据库企业版）

2.3.2 Oracle Software Requirements

The following list describes Oracle software requirements for using Data Guard:

Oracle Data Guard is available only as a feature of Oracle Database Enterprise Edition. It is not available with Oracle Database Standard Edition.

Using Data Guard SQL Apply, you will be able to perform a rolling upgrade of the Oracle database software from patch set release n (minimally, this must be release 10.1.0.3) to any higher versioned patch set or major version release. During a rolling upgrade, you can run different releases of the Oracle database on the primary and l ogical standby databases while you upgrade them, one at a time. For complete information, see Chapter 12, "Using SQL Apply to Upgrade the Oracle Database" and the ReadMe file for the applicable Oracle Database 10g patch set release.

The COMPATIBLE database initialization parameter must be set to the same value on all databases in a Data Guard configuration, except when using a logical standby database, which can have a higher COMPATIBLE setting than the primary database.

If you are currently running Oracle Data Guard on Oracle8i database software, see Oracle Database Upgrade Guide for complete information about upgrading to Oracle Data Guard 11g.

The primary database must run in ARCHIVELOG mode. See Oracle Database Administrator's Guide for more information.

主数据库必须运行 ARCHIVELOG模式。有关更多信息，请参阅Oracle数据库管理员指南。

The primary database can be a single instance database or an Oracle Real Application Clusters (Oracle RAC) database. The standby databases can be single instance databases or Oracle RAC databases, and these standby databases can be a mix of physical, logical, and snapshot types. See Oracle Database High Availability Overview for more information about configuring and using Oracle Data Guard with Oracle RAC.

主数据库可以是单个实例数据库，也可以是Oracle Real Application Clusters（Oracle RAC）数据库。备用数据库可以是单实例数据库或Oracle RAC数据库，这些备用数据库可以是物理，逻辑和快照类型的混合。有关配置和使用Oracle Data Guard与Oracle RAC的更多信息，请参见Oracle数据库高可用性概述。

Each primary database and standby database must have its own control file.

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

If a standby database is located on the same system as the primary database, the archival directories for the standby database must use a different directory structure than the primary database. Otherwise, the standby database may overwrite the primary database files.

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

To protect against unlogged direct writes in the primary database that cannot be propagated to the standby database, turn on FORCE LOGGING at the primary database before performing datafile backups for standby creation. Keep the database in FORCE LOGGING mode as long as the standby database is required.

为防止主数据库中未记录的直接写入无法传播到备用数据库，请在执行数据文件备份以创建备用数据库之前，在主数据库上打开。只要需要备用数据库，就保持数据库处于FORCE LOGGING模式。

The user accounts you use to manage the primary and standby database instances must have SYSDBA system privileges.

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

For operational simplicity, Oracle recommends that when you set up Oracle Automatic Storage Management (Oracle ASM) and Oracle Managed Files (OMF) in a Data Guard configuration that you set it up symmetrically on the primary and standby database(s). That is, if any database in the Data Guard configuration uses Oracle ASM, OMF, or both, then every database in the configuration should use Oracle ASM, OMF, or both, respectively, unless you are purposely implementing a mixed configuration for migration or maintenance purposes. See the scenario in Section 13.5 for more information.

（为简化操作，Oracle建议您在Data Guard配置中设置Oracle自动存储管理（Oracle ASM）和Oracle管理文件（OMF），并在主数据库和备用数据库上进行对称设置。也就是说，如果Data Guard配置中的任何数据库使用Oracle ASM，OMF或两者，那么配置中的每个数据库应该分别使用Oracle ASM，OMF或两者，除非您有意实施混合配置进行迁移或维护目的。有关更多信息，请参阅第13.5节中的场景。）

2.4 Standby Database Directory S tructure Considerations

The directory structure of the various standby databases is important because it determines the path names for the standby datafiles, archived redo log files, and standby redo log files. If possible, the datafiles, log files, and control files on the primary and standby systems should have the same names and path names and use Optimal Flexible Architecture (OFA) naming conventions. The archival directories on the standby database should also be identical between sites, including size and structure. This strategy allows other operations such as backups, switchovers, and failovers to execute the same set of steps, reducing the maintenance complexity.

（各种备用数据库的目录结构非常重要，因为它确定备用数据文件，归档重做日志文件和备用重做日志文件的路径名。如有可能，主系统和备用系统上的数据文件，日志文件和控制文件应具有相同的名称和路径名称，并使用最佳灵活架构（OFA）命名约定。备用数据库上的档案目录在站点之间也应该是相同的，包括大小和结构。此策略允许其他操作（如备份，切换和故障转移）执行相同的一组步骤，从而降低维护的复杂性。）

Otherwise, you must set the filename conversion parameters (as shown in Table 2-1) or rename the datafile. Nevertheless, if you need to use a system with a different directory structure or place the standby and primary databases on the same system, you can do so with a minimum of extra administration.

（否则，您必须设置文件名转换参数（如表2-1所示）或重命名数据文件。不过，如果您需要使用具有不同目录结构的系统，或者将备用数据库和主数据库放在同一个系统上，则可以使用最少的额外管理。）

The three basic configuration options are illustrated in Figure 2-1. These include:

A standby database on the same system as the primary database that uses a different directory structure than the primary system. This is illustrated in Figure 2-1 as Standby1.

与主数据库位于同一系统上的备用数据库，与主系统使用不同的目录结构。这在示出图2-1的Standby1。

If you have a standby database on the same system as the primary database, you must use a different directory structure. Otherwise, the standby database attempts to overwrite the primary database files.

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

A standby database on a separate system that uses the same directory structure as the primary system. This is illustrated in Figure 2-1 as Standby2. This is the recommended method.

独立系统上的备用数据库，与主系统使用相同的目录结构。这在示出图2-1的Standby2。这是推荐的方法

A standby database on a separate system that uses a different directory structure than the primary system. This is illustrated in Figure 2-1 as Standby3.

独立系统上的备用数据库，使用与主系统不同的目录结构。这在示出图2-1的Standby3。

Figure 2-1 Possible Standby Configurations