dataguard之概念

备库是主库的事务一致的拷贝，使用主库的备份，你可以创建9个备库。一旦创建，dg自动维护备库，从主库传输redo数据，在备库上应用他们。
一个备库可以使物理备库或是逻辑备库

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.                                                      

dg的服务

redo transport services 控制redo数据在主库到多个归档地点的自动传输，主要有下面几个任务

1传输redo数据

2管理和解决由网络导致的归档redo log中的gap。

3强制数据库保护模式

4自动检测备库上丢失或是损坏的归档redo日志文件盒自动从主数据库中或是别的备库中获取替换的归档日志。

log apply services 在备库上应用redo数据来维护与主库上的事务一致性，redo数据可以再归档redo log文件中被应用或是如果实时应用启用了，那么当备redo log文件被填满后直接应用，不在需要redo数据在备库上归档了。物理备库与逻辑备库的主要不同就是应用日志数据方式的不同，物理备库是redo apply方式，逻辑备库是使用sql apply.

role transitions :使用转换或故障转移来转换主备库的角色的。

转换时角色的互换，没有数据的丢失，主要是在维护主库时候使用。

故障转移时当主库不可用时候，将备库转换成主库的。

dg的保护模式

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.

就是最高保护模式redo一定要写到一个备库上，要是没有写过去，就关闭了。最高可用模式是不关闭，转换到最高性能上。最高性能是不管redo有没有传递过去都马上commit。