Oracle Dataguard原理，Oracle 数据实时性

Oracle Dataguard原理

 

Oracle DataGuard是Oracle自带的数据同步功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用这些日志文件，从而使目标数据库与源数据库保持同步，是一种数据库级别的高可用性方案。 

 

DataGuard可以提供Oracle数据库的冗灾、数据保护、故障恢复等，实现数据库快速切换与灾难性恢复。在生产数据库的保证"事务一致性"时，使用生产库的物理全备份创建备库，备库会通过生产库传输过来的归档日志或重做条目自动维护备用数据库。 

 

DataGuard数据同步技术有以下优势：  

1） Oracle数据库自身内置的功能，与每个Oracle新版本的新特性都完全兼容，且不需要另外付费。 

2） 配置管理较简单，不需要熟悉其他第三方的软件产品。

3） 物理Standby数据库支持任何类型的数据对象和数据类型；  

4） 逻辑Standby数据库处于打开状态，可以在保持数据同步的同时执行查询等操作。

5） 在最大保护模式下，可确保数据的零丢失。 

 

一、架构 

Oracle DataGuard由一个primary数据库(生产数据库)及一个或多个standby数据库(最多9个)组成。组成Data Guard的数据库通过Oracle Net连接，并且有可以分布于不同地域。只要各库之间可以相互通信，它们的物理位置并没有什么限制，不受操作系统的限制。

 

1.Primary 数据库  

DataGuard包含一个primary数据库即被大部分应用访问的生产数据库，该库既可以是 单实例数据库，也可以是RAC。

 

2.Standby 数据库  

Standby数据库是primary数据库的复制(事务上一致)。在同一个Data Guard中可以最多创建9个standby数据库。一旦创建完成，Data Guard通过应用primary数据库的redo自动维护每一个standby数据库。Standby数据库同样即可以是单实例数据库，也可以是RAC结构。 

 

二、Standby数据库类型

Standby数据库通常分两类：逻辑standby和物理standby。  逻辑standby  

逻辑standby是通过接收primary数据库的redo log并转换成sql语句，然后在standby数据库上执行SQL语句实现同步。 物理standby  

物理standby是通过接收并应用primary数据库的redo log以介质恢复的方式实现同步，不仅文件的物理结构相同，连块在磁盘上的存储位置都是一模一样的。 

 

三、服务 

重做传输服务(Redo Transport Services)  

控制redo数据的传输到一个或多个归档目的地。  日志应用服务(Log Apply Services)  

应用redo数据到standby数据库，以保持与primary数据库的事务一致。redo数据即可以从standby数据库的归档文件读取，也可直接应用备用日志文件读取。  角色转换服务(Role Transitions)  

DataGuard中有两种角色：primary和standby。角色转换就是让数据库在这两个角色中切换， 切换分两种：switchover和failover  

  1）switchover：转换primary数据库与standby数据库。switchover可以确保不会丢失数据。  

  2）failover：当primary数据库出现故障并且不能被及时恢复时，会调用failover将一个standby数据库转换为新的primary数据库。在最大保护模式或最高可用性模式下，failover可以保证不会丢失数据。 

 

四、保护模式 

 1.最大保护  

  这种模式是默认的数据保护模式，在不影响源数据库性能的条件下提供尽可能高的数

据保护等级。在该种模式下，一旦日志数据写到源数据库的联机日志文件，事务即可提交，不必等待日志写到目标数据库，如果网络带宽充足，该种模式可提供类似于最大可用模式的数据保护等级。

2.最大可用性  

  这种模式和"最大保护"基本上差不多。正常情况下，主备库之间是同步的。

当网络或者备库出现问题时，不会影响到主库的当机，主库会自动转换库"最大性能"模式，等待备库可用时，将归档传输到备库做恢复。

3.最大性能  

  这种模式保证主库性能最大化，主备库之间数据是异步传输的。即，主备日志归档以

后才会传输到备用库

 

[以上 来源]

 

 

1、DATAGUARD原理

DATAGUARD是通过建立一个PRIMARY和STANDBY组来确立其参照关系。

 

STANDBY一旦创建，DATAGUARD就会通过将主数据库(PRIMARY)的REDO传递给STANDBY数据库，然后在STANDBY中应用REDO实现数据库的同步。

 

有两种类型的STANDBY：物理STANDBY和逻辑STANDBY

物理STANDBY提供与主数据库完全一样的拷贝（块到块），数据库SCHEMA，包括索引都是一样的。它是直接应用REDO实现同步的。

逻辑STANDBY则不是这样，在逻辑STANDBY中，逻辑信息是相同的，但物理组织和数据结构可以不同，它和主库保持同步的方法是将接收的REDO转换成SQL语句，然后在STANDBY上执行SQL语句。逻辑STANDBY除灾难恢复外还有其它用途，比如用于用户进行查询和报表。

 

DATAGUARD包含三个服务（日志传输、日志应用、角色转换）

日志传输服务控制REDO数据的传输（传输日志，实施数据库保护模式）--------------STANDBY上通过起用RFS进程接收REDO数据。

日志应用服务则一方面自动应用日志，另一方面自动检测STANDBY缺少的REDO，并从主数据库或其它STANDBY中自动查询出丢失的REDO。

 

DATAGUARD的几种保护模式：最大保护，最大可用，最大性能

最大保护是指除非REDO在至少一个STANDBY中可用，否则事务不能提交。如果在某个STANDBY中不可用，则主数据库的操作被停止。通常受制约比较多，在生产环境中不是很常用（性价比不好）。

最大可用是指如果STANDBY不可用，主数据库仍然可以处理事务，只是在问题被纠正后，STANDBY和主数据库进行再同步。这样的一个问题是：当再同步之前有FAILOVER时，有些数据可能会丢失。

最大性能是指主数据库的提交操作不等待STANDBY。PRIMARY和STANDBY松耦合，数据保护级别较低。

 

物理STANDBY可能的模式：只读模式（OPEN READONLY）和恢复模式（MANANGED RECOVERY）

 

2、物理DATAGUARD实施简要过程

主数据库的准备工作：FORCE LOGGING，ENABLE ARCHIVING，一个本地归档目的地。

创建STANDBY数据库：

a.关闭主库，冷备份主库数据文件、日志文件和密码文件，然后启动主库，在主库上创建STANDBY的控制文件:alter database create standby controlfile as '文件名'

b.准备参数文件，将参数文件、备份的主库文件和STANDBY控制文件拷贝到STANDBY系统。

需要更改的参数有：standby_archive_dest-----接收的归档日志存放处

db_file_name_convert和log_file_name_convert-----仅当主库和STANDBY库在同一系统下时用

log_archive_dest_1-----本地归档目的地

log_archive_dest_2='service=standby'-----归档到STANDBY的目的地

standby_file_management=auto

remote_archive_enable=true

fal_server

fal_client

instance_name-----当主库和STANDBY库在同一系统下时该参数用于区分主库

lock_name_space-----当主库和STANDBY库在同一系统下时指定STANDBY的实例名和INSTANCE_NAME相同

c.如果是WINDOWS系统，需要创建WINDOWS服务。

d.配置两台机器的tnsnames.ora,双方都能tnsping通

e.在主库和STANDBY库上配置监听

f.起用STANDBY系统上的死连接检测：sqlnet.ora中设置sqlnet.expire_time=2

g.在STANDBY上创建SPFILE

h.启动STANDBY：

startup nomount

alter database mount standby database

i.初始化日志应用服务

alter database recover managed standby database disconnect from session;

 

3、DATAGUARD维护

 

a.日志传送服务

有些情况下，你可能需要在归档日志和应用日志之间有个时间间隔，此时可以通过在STANDBY上指定参数log_archive_dest_n中指定delay=minutes属性。

STANDBY上的日志应该与主库上的日志大小相同，另外STANDBY上的日志组应该比主库多，因为这样归档操作才有时间完成。也就是RFS（日志接收）进程在使用STANDBY的日志前，不用等待该日志被归档。最简单判断日志组是否够的方法是查看警告日志和RFS的TRACE文件。

增加STANDBY日志文件的方法：

alter database 语句中使用add standby logfile子句。相关视图v$standby_log,v$logfile

增加STANDBY日志组的方法：

alter database add standby logfile group 10 ('文件名1'，'文件名2') size 100M对于多个 STANDBY共享归档日志文件目的地，有些情况下需要指定log_archive_dest_n参数的dependency属性，该属性的作用是说明该目的地依赖于父目的地的成功归档。

参数log_archive_dest_n还可以指定reopen、max_failures、sync、async属性。通过给该参数指定LGWR或者ARCH属性以选择是用LGWR还是ARCH进程传送日志。

用于日志接收的几个进程是：LGWR，ARCH，RFS，FAL。FAL进程用于解决日志缝。

设置数据保护模式的语句为：alter database set standby database to maximun(protection|availability|performance)

 

b.日志应用服务

对于物理STANDBY，日志应用服务涉及到下面几个进程：RFS，ARC，MRP。MRP是管理恢复进程。

启动STANDBY的恢复操作的几个命令：alter database recover managed standby database(启动前台会话);alter database recover managed standby database disconnect from session(启动后台会话，也就是说会话可以继续干别的事情);alter database recover managed standby database cancel(停止日志应用).

可以通过查询视图v$managed_standby查看日志应用情况。

 

c.数据文件管理

当主库新创建数据文件，可定义参数standby_file_management为auto，让standby也自动创建数据文件。如果主库和standby的数据文件的目录结构不一样，可以设定db_file_name_convert将主库上的文件名转换成standby上的文件名。如果standby_file_management设为auto，则不能在standby上重命名或创建数据文件、日志文件。

每分钟主库会询问standby是否有gap，该行为被称为heartbeat.

可以查询视图v$archived_gap，如果发现有GAP，则可以从主库上将日志文件拷贝到standby，然后将相关文件注册到standby，具体方法是：alter database register logfile '文件名'。当然也可以通过设置参数fal_server,fal_client，让日志应用服务自动处理gap问题。

对于STANDBY日志应用服务，下面几个视图有助于监控：v$managed_standby,v$archived_dest_status,v$archived_log,v$log_status,v$dataguard_status.

可以设置参数log_archive_trace对归档进行不同级别的跟踪。

 

d.角色转换

ORACLE支持两种形式的角色转换----switchover和failover

switchover包含两个步骤，首先主库被转换成STANDBY，然后STANDBY被转换成主库

switchover的准备工作：完成角色转换需要改变的参数(必须改变所有STANDBY上的 log_archive_dest_n和log_archive_dest_state_n);确保主库和所有STANDBY都有连接;确认没有用户连接到数据库;对于RAC环境确保只有一个实例是活动状态;角色转换之前，主库实例应该是OPEN状态，而STANDBY实例是MOUNT状态，因为这样的话，转换过程中STANDBY数据库也可以应用归档日志，如果STANDBY为READONLY，切换操作仍然可以进行，只是要花一点额外的时间;如果切换操作包含逻辑STANDBY，那么，主库实例和STANDBY实例都必须为OPEN状态;将要转换成主库的STANDBY变成归档模式;取消在该STANDBY库上的日志延迟。

switchover的步骤：在当前主库上，首先确认可以执行switchover操作(select switchover_status from v$database,如果值为TO STANDBY则可以切换，否则需要检查当前DATAGUARD配置是否运行正常)，然后将主库切换为STANDBY(执行ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;这样原控制文件被备份并生成新的STANDBY控制文件，然后只要重新启动该库为STANDBY模式就可以了);以上操作完成后，在原STANDBY数据库上，需要查询原主库的切换信息是否被目标STANDBY接收到(SELECT SWITCHOVER_STATUS FROM V$DATABASE;如果结果为SWITCHOVER PENDING说明STANDBY切换为PRIMARY是可行的，否则需要检查DATAGUARD的配置是否运行正常)，然后执行ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;将STANDBY转换成PRIMARY，并重新启动该库。这里需要说明的是如果该库在线重做日志不存在，该切换语句会自动创建它们，然而这样一来，会花费很长的时间。因此ORACLE建议手工增加在线重做日志。手工增加在线重做日志的方法有两种：第一种是将原主库的日志拷贝到原STANDBY，并且定义参数log_file_name_convert，让它将standby和新的日志联系起来。第二种方法是DROP所有目标STANDBY上存在的日志，并且用命令ALTER DATABASE ADD STANDBY LOGFILE创建新的日志。switchover的最后一步是将新生成的STANDBY转换成恢复模式，并将新PRIMARY进行一次归档操作。

 

failover的准备工作：完成角色转换需要改变的参数(必须改变所有STANDBY上的log_archive_dest_n和log_archive_dest_state_n);确保主库和所有STANDBY都有连接;对于RAC环境确保只有一个实例是活动状态;如果要进行failover操作的STANDBY当前运行于最大保护模式，则应该将它转换成最大性能模式(通过命令ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;)

 

failover的步骤：首先发现并解决日志GAP的问题，然后从其它库中将日志号高于本库的日志拷贝过来并应用这些日志，如果你没有手工注册新的日志，那么可以执行下面的语句ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;否则需要执行的语句为ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH SKIP STANDBY LOGFILE;接下来执行ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;完成切换并重新启动新的主库，可能的话对主库进行一次备份。

 

e.启动STANDBY

STARTUP NOMOUNT;

ALTER DATABASE MOUNT STANDBY DATABASE;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

 

f.关闭STANDBY

首先确认是否处于恢复状态：SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;

取消恢复操作：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SHUTDOWN IMMEDIATE;

 

g.让standby运行于只读访问模式

启动STANDBY为只读模式：

STARTUP NOMOUNT;

ALTER DATABASE MOUNT STANDBY DATABASE;

ALTER DATABASE OPEN READ ONLY;

将恢复模式的STANDBY转换成read only模式：

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

ALTER DATABASE OPEN READ ONLY;

 

h.让STANDBY从READ ONLY转变成恢复模式

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

 

i.让为只读模式的STANDBY执行排序操作应该注意的问题：

排序操作不能使用非临时表空间，临时表空间必须是本地管理的，并且只包含临时文件

如果在创建STANDBY时主库没有临时表空间，则需要在主库上创建临时表空间，并执行ALTER SYSTEM SWITCH LOGFILE;将redo传给STANDBY。如果要给STANDBY的临时表空间增加临时文件，需要先将STANDBY转换成READ ONLY模式，并执行命令ALTER TABLESPACE temp1 ADD TEMPFILE '/disk1/oracle/dbs/s_temp1.dbf' SIZE 10M REUSE;增加临时文件。

 

j.可以通过对STANDBY的备份实现对数据库的备份。

 

k.主库上的操作和STANDBY的应对：

如果你执行ALTER DATABASE CLEAR UNARCHIVED LOGFILE或者打开数据库时使用RESETLOGS，那么必须重新创建STANDBY。

如果你在主库上执行ALTER DATABASE ENABLE|DISABLE,如果你改变表空间的状态，如果你设置了参数STANDBY_FILE_MANAGEMENT为AUTO并创建表空间或者增加数据文件，则不需要对STANDBY进行操作。

如果你在主库上删除了表空间或者数据文件，你需要在STANDBY上等日志应用后在操作系统上删除相关数据文件。

如果你在主库上重命名了数据文件，你也要在STANDBY上重命名(因为是对控制文件的改变，所以没有日志传过去，因此两边都要进行相同的操作)

如果你在主库上改变了控制文件，你就要重新创建STANDBY控制文件或者重建STANDBY数据库。

如果你在主库上增加或删除日志文件，你也需要在STANDBY上进行同步变化。

具体方法为：先取消恢复，如果STANDBY_FILE_MANAGEMENT为AUTO，则改为MANUAL，然后使用命令ALTER DATABASE ADD STANDBY LOGFILE 'prmy3.log' SIZE 100K;增加日志文件或者用命令ALTER DATABASE DROP STANDBY LOGFILE 'prmy3.log'DROP掉日志文件，最后恢复参数STANDBY_FILE_MANAGEMENT的值。

如果你在主库上进行了nologging|unrecoverable等操作，则应该将包含这些变化的表空间拷贝到STANDBY。

如果你改变了主库的参数文件，那么你也应该改变STANDBY的参数文件。

 

l.监控进程

SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;

 

m.监控恢复操作的进程

SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# FROM V$ARCHIVE_DEST_STATUS;

 

[以上 来源]

 

======================================================

https://docs.oracle.com/cd/B19306_01/server.102/b14239/concepts.htm#g1049956

1 Introduction to Oracle Data Guard

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as transactionally consistent copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability.

With Data Guard, administrators can optionally improve production database performance by offloading resource-intensive backup and reporting operations to standby systems.

This chapter includes the following topics that describe the highlights of Oracle Data Guard:

• Data Guard Configurations

• Data Guard Services

• Data Guard Broker

• Data Guard Protection Modes

• Data Guard and Complementary Technologies

• Summary of Data Guard Benefits

1.1 Data Guard Configurations

A Data Guard configuration consists of one production database and one or more standby databases. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically. There are no restrictions on where the databases are located, provided they can communicate with each other. For example, you can have a standby database on the same system as the production database, along with two standby databases on other systems at remote locations.

You can manage primary and standby databases using the SQL command-line interfaces or the Data Guard broker interfaces, including a command-line interface (DGMGRL) and a graphical user interface that is integrated in Oracle Enterprise Manager.

1.1.1 Primary Database

A Data Guard configuration contains one production database, also referred to as the primary database, that functions in the primary role. This is the database that is accessed by most of your applications.

The primary database can be either a single-instance Oracle database or an Oracle Real Application Clusters database.

1.1.2 Standby Databases

A standby database is a transactionally consistent copy of the primary database. Using a backup copy of the primary database, you can create up to nine standby databases and incorporate them in a Data Guard configuration. Once created, Data Guard automatically maintains each standby database by transmitting redo data from the primary database and then applying the redo to the standby database.

Similar to a primary database, a standby database can be either a single-instance Oracle database or an Oracle Real Application Clusters database.

A standby database can be either a physical standby database or a logical standby database:

• Physical standby database

  Provides a physically identical copy of the primary database, with on disk database structures that are identical to the primary database on a block-for-block basis. The database schema, including indexes, are the same. A physical standby database is kept synchronized with the primary database, though Redo Apply, which recovers the redo data received from the primary database and applies the redo to the physical standby database.

  A physical standby database can be used for business purposes other than disaster recovery on a limited basis.

• Logical standby database

  Contains the same logical information as the production database, although the physical organization and structure of the data can be different. The logical standby database is kept synchronized with the primary database though SQL Apply, which transforms the data in the redo received from the primary database into SQL statements and then executing the SQL statements on the standby database.

  A logical standby database can be used for other business purposes in addition to disaster recovery requirements. This allows users to access a logical standby database for queries and reporting purposes at any time. Also, using a logical standby database, you can upgrade Oracle Database software and patch sets with almost no downtime. Thus, a logical standby database can be used concurrently for data protection, reporting, and database upgrades.

1.1.3 Configuration Example

Figure 1-1 shows a typical Data Guard configuration that contains a primary database that transmits redo data to a standby database. The standby database is remotely located from the primary database for disaster recovery and backup operations. You can configure the standby database at the same location as the primary database. However, for disaster recovery purposes, Oracle recommends you configure standby databases at remote locations.

Figure 1-1 shows a typical Data Guard configuration in which redo is being applied out of standby redo log files to a standby database.

Figure 1-1 Typical Data Guard Configuration

Description of "Figure 1-1 Typical Data Guard Configuration"
 

1.2 Data Guard Services

The following sections explain how Data Guard manages the transmission of redo data, the application of redo data, and changes to the database roles:

• Redo Transport Services

  Control the automated transfer of redo data from the production database to one or more archival destinations.

• Log Apply Services

  Apply redo data on the standby database to maintain transactional synchronization with the primary database. Redo data can be applied either from archived redo log files, or, if real-time apply is enabled, directly from the standby redo log files as they are being filled, without requiring the redo data to be archived first at the standby database.

• Role Transitions

  Change the role of a database from a standby database to a primary database, or from a primary database to a standby database using either a switchover or a failover operation.

1.2.1 Redo Transport Services

Redo transport services control the automated transfer of redo data from the production database to one or more archival destinations.

Redo transport services perform the following tasks:

• Transmit redo data from the primary system to the standby systems in the configuration

• Manage the process of resolving any gaps in the archived redo log files due to a network failure

• Enforce the database protection modes (described in Section 1.4)

• Automatically detect missing or corrupted archived redo log files on a standby system and automatically retrieve replacement archived redo log files from the primary database or another standby database

1.2.2 Log Apply Services

The redo data transmitted from the primary database is written on the standby system into standby redo log files, if configured, and then archived into archived redo log files. Log apply services automatically apply the redo data on the standby database to maintain consistency with the primary database. It also allows read-only access to the data.

The main difference between physical and logical standby databases is the manner in which log apply services apply the archived redo data:

• For physical standby databases, Data Guard uses Redo Apply technology, which applies redo data on the standby database using standard recovery techniques of an Oracle database, as shown in Figure 1-2.

Figure 1-2 Automatic Updating of a Physical Standby Database

Description of "Figure 1-2 Automatic Updating of a Physical Standby Database "
 

• For logical standby databases, Data Guard uses SQL Apply technology, which first transforms the received redo data into SQL statements and then executes the generated SQL statements on the logical standby database, as shown in Figure 1-3.

Figure 1-3 Automatic Updating of a Logical Standby Database

Description of "Figure 1-3 Automatic Updating of a Logical Standby Database"

1.2.3 Role Transitions

An Oracle database operates in one of two roles: primary or standby. Using Data Guard, you can change the role of a database using either a switchover or a failover operation.

A switchover is a role reversal between the primary database and one of its standby databases. A switchover ensures no data loss. This is typically done for planned maintenance of the primary system. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role. The transition occurs without having to re-create either database.

A failover is when the primary database is unavailable. Failover is performed only in the event of a catastrophic failure of the primary database, and the failover results in a transition of a standby database to the primary role. The database administrator can configure Data Guard to ensure no data loss.

The role transitions described in this documentation are invoked manually using SQL statements. You can also use the Oracle Data Guard broker to simplify role transitions and automate failovers using Oracle Enterprise Manager or the DGMGRL command-line interface, as described in Section 1.3.

1.3 Data Guard Broker

The Data Guard broker is a distributed management framework that automates the creation, maintenance, and monitoring of Data Guard configurations. You can use either the Oracle Enterprise Manager graphical user interface (GUI) or the Data Guard command-line interface (DGMGRL) to:

• Create and enable Data Guard configurations, including setting up redo transport services and log apply services

• Manage an entire Data Guard configuration from any system in the configuration

• Manage and monitor Data Guard configurations that contain Real Application Clusters primary or standby databases

• Simplify switchovers and failovers by allowing you to invoke them using either a single key click in Oracle Enterprise Manager or a single command in the DGMGRL command-line interface.

• Enable fast-start failover to fail over automatically when the primary database becomes unavailable. When fast-start failover is enabled, the Data Guard broker determines if a failover is necessary and initiates the failover to the specified target standby database automatically, with no need for DBA intervention and with no loss of data.

In addition, Oracle Enterprise Manager automates and simplifies:

• Creating a physical or logical standby database from a backup copy of the primary database

• Adding new or existing standby databases to an existing Data Guard configuration

• Monitoring log apply rates, capturing diagnostic information, and detecting problems quickly with centralized monitoring, testing, and performance tools

See Also:

Oracle Data Guard Broker for more information

1.3.1 Using Oracle Enterprise Manager

Oracle Enterprise Manager, also referred to as Enterprise Manager, provides a web-based interface for viewing, monitoring, and administering primary and standby databases in a Data Guard configuration. Enterprise Manager's easy-to-use interfaces combined with the broker's centralized management and monitoring of the Data Guard configuration enhance the Data Guard solution for high availability, site protection, and data protection of an enterprise.

From the Enterprise Manager Central Console, all management operations can be performed locally or remotely. You can view home pages for Oracle databases, including primary and standby databases and instances, create or add existing standby databases, start and stop instances, monitor instance performance, view events, schedule jobs, and perform backup and recovery operations. See Oracle Data Guard Broker and the Oracle Enterprise Manager online help system.

Figure 1-4 shows the Data Guard management overview page in Enterprise Manager.

Figure 1-4 Data Guard Overview Page in Oracle Enterprise Manager

Description of "Figure 1-4 Data Guard Overview Page in Oracle Enterprise Manager"

1.3.2 Using the Data Guard Command-Line Interface

The Data Guard command-line interface (DGMGRL) enables you to control and monitor a Data Guard configuration from the DGMGRL prompt or within scripts. You can perform most of the activities required to manage and monitor the databases in the configuration using DGMGRL. See Oracle Data Guard Broker for complete DGMGRL reference information and examples.

1.4 Data Guard Protection Modes

In some situations, a business cannot afford to lose data. In other situations, the availability of the database may be more important than the loss of data. Some applications require maximum database performance and can tolerate some small amount of data loss. The following descriptions summarize the three distinct modes of data protection.

Maximum protection This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover each transaction must be written to both the local online redo log and to the standby redo log on at least one standby database before the transaction commits. To ensure data loss cannot occur, the primary database shuts down if a fault prevents it from writing its redo stream to the standby redo log of at least one transactionally consistent standby database.

Maximum availability This protection mode provides the highest level of data protection that is possible without compromising the availability of the primary database. Like maximum protection mode, a transaction will not commit until the redo needed to recover that transaction is written to the local online redo log and to the standby redo log of at least one transactionally consistent standby database. Unlike maximum protection mode, the primary database does not shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Instead, the primary database operates in maximum performance mode until the fault is corrected, and all gaps in redo log files are resolved. When all gaps are resolved, the primary database automatically resumes operating in maximum availability mode.

This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.

Maximum performance This protection mode (the default) provides the highest level of data protection that is possible without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. The primary database's redo data stream is also written to at least one standby database, but that redo stream is written asynchronously with respect to the transactions that create the redo data.

When network links with sufficient bandwidth are used, this mode provides a level of data protection that approaches that of maximum availability mode with minimal impact on primary database performance.

The maximum protection and maximum availability modes require that standby redo log files are configured on at least one standby database in the configuration. All three protection modes require that specific log transport attributes be specified on the LOG_ARCHIVE_DEST_ninitialization parameter to send redo data to at least one standby database. See Section 5.6 for complete information about the data protection modes.

1.5 Data Guard and Complementary Technologies

Oracle Database provides several unique technologies that complement Data Guard to help keep business critical systems running with greater levels of availability and data protection than when using any one solution by itself. The following list summarizes some Oracle high-availability technologies:

• Oracle Real Application Clusters (RAC)

  RAC enables multiple independent servers that are linked by an interconnect to share access to an Oracle database, providing high availability, scalability, and redundancy during failures. RAC and Data Guard together provide the benefits of both system-level, site-level, and data-level protection, resulting in high levels of availability and disaster recovery without loss of data:

  • RAC addresses system failures by providing rapid and automatic recovery from failures, such as node failures and instance crashes. It also provides increased scalability for applications.

  • Data Guard addresses site failures and data protection through transactionally consistent primary and standby databases that do not share disks, enabling recovery from site disasters and data corruption.

  Many different architectures using RAC and Data Guard are possible depending on the use of local and remote sites and the use of nodes and a combination of logical and physical standby databases. See Appendix D, "Data Guard and Real Application Clusters" and Oracle Database High Availability Overview for RAC and Data Guard integration.

• Flashback Database

  The Flashback Database feature provides fast recovery from logical data corruption and user errors. By allowing you to flash back in time, previous versions of business information that might have been erroneously changed or deleted can be accessed once again. This feature:

  • Eliminates the need to restore a backup and roll forward changes up to the time of the error or corruption. Instead, Flashback Database can roll back an Oracle database to a previous point-in-time, without restoring datafiles.

  • Provides an alternative to delaying the application of redo to protect against user errors or logical corruptions. Therefore, standby databases can be more closely synchronized with the primary database, thus reducing failover and switchover times.

  • Avoids the need to completely re-create the original primary database after a failover. The failed primary database can be flashed back to a point in time before the failover and converted to be a standby database for the new primary database.

  See Oracle Database Backup and Recovery Advanced User's Guide for information about Flashback Database, and Section 6.2.2 for information delaying the application of redo data.

• Recovery Manager (RMAN)

  RMAN is an Oracle utility that simplifies backing up, restoring, and recovering database files. Like Data Guard, RMAN is a feature of the Oracle database and does not require separate installation. Data Guard is well integrated with RMAN, allowing you to:

  • Use the Recovery Manager DUPLICATE command to create a standby database from backups of your primary database.

  • Take backups on a physical standby database instead of the production database, relieving the load on the production database and enabling efficient use of system resources on the standby site. Moreover, backups can be taken while the physical standby database is applying redo.

  • Help manage archived redo log files by automatically deleting the archived redo log files used for input after performing a backup.

  See Appendix F, "Creating a Standby Database with Recovery Manager" and Oracle Database Backup and Recovery Basics.

1.6 Summary of Data Guard Benefits

Data Guard offers these benefits:

• Disaster recovery, data protection, and high availability

  Data Guard provides an efficient and comprehensive disaster recovery and high availability solution. Easy-to-manage switchover and failover capabilities allow role reversals between primary and standby databases, minimizing the downtime of the primary database for planned and unplanned outages.

• Complete data protection

  Data Guard can ensure no data loss, even in the face of unforeseen disasters. A standby database provides a safeguard against data corruption and user errors. Storage level physical corruptions on the primary database do not propagate to the standby database. Similarly, logical corruptions or user errors that cause the primary database to be permanently damaged can be resolved. Finally, the redo data is validated when it is applied to the standby database.

• Efficient use of system resources

  The standby database tables that are updated with redo data received from the primary database can be used for other tasks such as backups, reporting, summations, and queries, thereby reducing the primary database workload necessary to perform these tasks, saving valuable CPU and I/O cycles. With a logical standby database, users can perform normal data manipulation on tables in schemas that are not updated from the primary database. A logical standby database can remain open while the tables are updated from the primary database, and the tables are simultaneously available for read-only access. Finally, additional indexes and materialized views can be created on the maintained tables for better query performance and to suit specific business requirements.

• Flexibility in data protection to balance availability against performance requirements

  Oracle Data Guard offers maximum protection, maximum availability, and maximum performance modes to help enterprises balance data availability against system performance requirements.

• Automatic gap detection and resolution

  If connectivity is lost between the primary and one or more standby databases (for example, due to network problems), redo data being generated on the primary database cannot be sent to those standby databases. Once a connection is reestablished, the missing archived redo log files (referred to as a gap) are automatically detected by Data Guard, which then automatically transmits the missing archived redo log files to the standby databases. The standby databases are synchronized with the primary database, without manual intervention by the DBA.

• Centralized and simple management

  The Data Guard broker provides a graphical user interface and a command-line interface to automate management and operational tasks across multiple databases in a Data Guard configuration. The broker also monitors all of the systems within a single Data Guard configuration.

• Integration with Oracle Database

  Data Guard is a feature of Oracle Database Enterprise Edition and does not require separate installation.

• Automatic role transitions

  When fast-start failover is enabled, the Data Guard broker automatically fails over to a synchronized standby site in the event of a disaster at the primary site, requiring no intervention by the DBA. In addition, applications are automatically notified of the role transition.