DG确保企业数据高可用，数据保护，和灾难恢复。提供了一套创建，控制，管理和监控一个或多个备库去确保主生产库数据的安全可用的服务。DG控制这些备库像事务的一致性一样，是生产库的一个副本。如果生产库由于意外中断，DG可以切换任何一个备库来作为主库使用。而减少因为主库down机而带来的影响。


Primary Database

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


Standby Databases

备库就是主库的一个完全副本。通过对主库进行备份，可以创建9个备库关联到主库上。一旦备库创建了，DG会自动保持每个备库都能从主库传输redo日志到备库，并且DG会在备库上应用redo来保证db的一致性。

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

1.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.

物理备库时提供了一个主库的物理特性备份。从磁盘结构上去备份主库。它要求与主库在块与块上要一致。数据库的方案对象，包括索引等都要相同。它就是主库的一个同步备份。它是通过Redo Apply来实现与主库的同步的。


2.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.

逻辑备库时包含了相同的逻辑数据，但是物理结构上有所不同。逻辑备库是通过SQL Apply来实现与主库的同步。



Redo Apply 与 SQL Apply

Redo Apply用于物理备库与主库的同步。是通过从主库应用传输过来的日志在物理备库上进行重新执行来使得备库保持和主库有同样地结构与数据。

SQL Apply用于逻辑备库与主库的同步。是通过将在主库的操作变成相应的SQL语句。然后在逻辑备库重新执行这些SQL语句来实现主备的同步


Redo Transport Services

控制从主库到备库redo data的自动传输。主要完成以下几个任务：

按配置，从主库传输redo data到备库

管理由于网络失败的原因导致的归档日志文件的缺失，造成的gap。

执行数据库保护模式

自动检索备库中缺失的或者错误的归档日志，然后自动的从主库或者其他备库处检索回相应的替代物。


Log Apply Services

从主库传输过来的redo data会被写到备库的redo日志文件中。如果有配置的话，还会自动归档到归档文件中。Log Apply services会在standby database上自动应用redo data来使备库与主库保持一致性。同时可以允许对数据的只读访问。

Log Apply Services有两种不同的方式：Redo Apply（physical standby） 、 SQL Apply（Logical standby）


Role Transitions（角色切换）

一个Oracle数据库操作可以有两个角色，一个是主库，一个时备库。用DG时，你可以通过switchover和failover操作来切换数据库的角色。

switchover：就是将主库与备库的角色调换过来。主库变备库，备库变主库。做switchover时，可以确保数据的不丢失。切换的顺序是，先将主库切换成备库，后将备库切换成主库。


failover：当主库不可用时。只有在主库发生了灾难性故障时才会用到failover。

Data Guard Protection Modes

在一些情况下，一个企业不允许数据丢失。另一些企业则对数据库的可用性比丢数据还要看重。同样一些企业看重的时数据库的最大性能并且可以容忍少量数据丢失


Maximum protection（最大保护模式）--保护数据不丢失，即使主库fail了，也不丢数据。为了实现这个级别的保护，恢复事务需要的redo data都必须被写到当地的online redo日志文件中，也必须写到备库的日志文件中，而且是要在事务提交之前就写进去了。为了保证数据不丢失，如果当一个错误阻止主库写redo stream（重做记录流）到备库的日志文件中时，主库会shutdown


Maximunm availability（最大可用模式）--这种模式是在尽可能提高数据保护的基础上，确保主库的可用性。像最大保护模式一样，在redo（用来恢复事务的）还没有被写到本地在线日志文件和至少一个事务一致性备库的备库的日志文件中前，事务不能被提交。不像最大保护模式，主库是不能shut down的。如果一个错误阻止了redo流写到一个远程的备库redo日志中。相应的主库就变成最大性能模式直到错误被纠正，还有所有的redo graps都被运用。当所有的redo graps都恢复后，redo有了连续性了。主库会自动重新运行为最大可用模式



Maximum performance（最大性能模式）

这个模式在提供数据库一个最高水平的数据保护的基础上不影响主库的性能。这是通过允许事务在redo data写到本地的在线日志文件时就可以提交了。主库的redo data流同样要写到至少一个备库上去，但是redo data（来自于事务所产生的重做记录）会被异步地写到standby上去。

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_n initialization parameter to send redo data to at least one standby database. 


A Physical standby

DG通过执行Redo Apply来保持物理standby。当不用执行恢复时，物理standby可以在open成read-only和read/write模式

 Redo Apply

 物理standby通过用oracle恢复机制来执行冲归档日志文件来的或直接从standby日志文件来的重做记录redo data来保持物理standby与主库的一致性。当正在应用redo时，db不能被打开。

 

 Open read-only

 物理standby运行成read-only时，可以执行查询数据库的操作。当read-only时，备库可以继续接收redo data。但是要等到standby切换到Redo Apply时才可以应用这写redo data。

 read-only与Redo Apply之间可以互相切换。


 Open read/write

 为了创建一个克隆的数据库或者一个read/write报告时，物理standby可以被open成read/write。当read/write时，standby不能接收从主库来的redo data，也不能提供远程保护。物理standby可以被临时换成read/write，但是一定要闪回到之前那个恢复点。当闪回到之前那个恢复点，DG会自动使standby database与主库同步。


Logical Standby Databases

logical standby database是通过执行SQL语句来更新的。这允许用户去对备库进行查询访问和生成报告在任何时候。

DG自动应用从归档日志文件和备库日志文件中到logicalstandby的信息。通过转换日志文件中的数据成为SQL语句，然后执行在logical standby上执行这些SQL语句。因为logical standby是通过SQL语句来更新的，所以它必须保持开着的状态。尽管logical standby是open read/write模式的，为了再生成SQL而用到的目的表是可用的，这只是在read-only操作时。


实现DG必须注意以下两个点：

Hardware and Operating System Requirements

1、所有的DG配置成员的Oracle都必须运行在同一个平台

2、主库与备库之间的硬件性能可以不一样。

3、主库与备库必须用同样地操作系统。但是版本号可以不一样。

Oracle Software Requirements

1、DG只能在Oracle Database企业版用。



Standby Database Directory Structure Considerations

standby的文件路径与文件名最好应设置成与主库一样。

但是如果要设成不一样的话，就要在参数配置时，加多一个路径转换的参数配置了。


以下情况，你可能要standby与主库的路径不一样。

1、当你的standby和你的主库时在同一个系统中的时候，那就不得不把standby的文件路径与主库设置成不一样了。


Online Redo Logs and Archived Redo Logs and Standby Redo Logs

对于DG恢复操作来说最重要的结构就是online redo logs，archived redo logs还有standby redo logs。从主库传输过来的redo data（重做记录）被运行在standby上的进程remote file server（RFS）接收。在standby上RFS进程写redo data到归档日志文件和standby日志文件中。redo data可以在redo写进到归档日志文件或standby日志文件中被应用，也可以在实时应用开启时，直接从standby日志文件中应用。当这个standby日志文件被写满了。


Online Redo Logs and Archived Redo Logs

redo的传输完整地保持了主库与备库的事务一致性。online redo logs和archived redo logs同样是DG中所必须的。

什么是online redo logs？

每一个Oracle主库和逻辑备库的实例都有一个online redo log来保护数据库不受实例损坏的影响。物理备库没有用online redo log，因为物理备库不能被打开成read/write I/O模式。所以物理备库没有改变，所以就没有新的redo生成了，也就不用online redo logs。

什么是archived redo logs

一个archived redo log是被要求的，因为归档是一种能够用来保持备库与主库一致性的方法。主库，还有无论是物理备库还是逻辑备库都用到archived redo log。一旦Oracle数据库建立，默认的，就会运行在archivelog模式下。所以归档日志写进程（ARCn）会自动copy那些写满了的online redo file到一个或多个archived log files（归档日志文件）中。


不像物理备库，逻辑备库可以打开数据库，就会生成redo data和产生多个log files包括online redo log files，archived log files，和standby redo log files（当然前提是由配置standby redo log file）。


Oracle数据库会在每次的日志切换时都会去进行一次检查点。因此，如果online redo log files太小的话，就会由频繁地日志切换，这也将导致频繁地检查点刷新。就会对备库的性能有很大的影响。


Standby Redo Logs

standby redo logs与online redo logs很像，但是standby redo logs是用来存储那些从其他数据库来的redo data。而online redo log是存储本数据库的redo data。

以下情况必须还有standby redo log

1、在最大保护模式和最大性能模式下

2、有实时应用的情况下

3、级联目的地时。



Standby Database Location and DirectoryOptions

1、Standby System is the same as primary system

   不同于主库的目录结构。于是你必须给我们standby database取一个DB_UNIQUE_NAME而且是唯一的来区分这个备库。并且你要设置多两个路径转换参数：DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT。standby db不能提供对灾难的预防。所谓的灾难是指那些可以破坏主库与备库系统的（因为在同一个系统中，如果系统奔溃，那些主库，备库也全奔溃了），但是standby db却可以为planned maintenace提供一个切换功能。


2、Standby System 和主库不在同一个系统中，就是separate system

   于主库有相同的目录结构。所以你无需去重命名这些在备库控制文件中的数据库文件，归档日志文件盒standby的日志文件。由于在不同的location中，所以就不怕主库受到损坏时，系统就奔溃，因为有备库可以使用。


3、Standby System 和主库不在同一个系统中，而且没有相同的目录结构。

   应该有两个转换参数DB_FILE_NAME_CONVERT AND LOB_FILE_NAME_CONVERT.来自动进行路径转换。由于是在不同的系统中，所以备库可以防止主库在受到破坏时，起到一定的作用。