本篇梳理DG的架构和一些概念知识，欧博abg重新梳理的目的是加强理解，也方便复习，基于11gR2版本写的，不包含12c新特性。如果能帮助到新接触DG的朋友，那就再好不过。
一、DataGuard概述这是一种保障数据安全的高可用架构，搭建与主数据库同步的备用数据库，提供Oracle数据库的容灾、数据保护、故障恢复等，实现数据库快速切换与灾难性恢复。
原理是日志文件从主库传输到备库，然后在备库上应用这些日志，从而使备库与主库保持同步
DG由一个primary数据库及一个或多个standby数据库组成，备库最多9个
主库：即被大部分应用访问的生产数据库，该库即可以使单实例数据库，也可以使RAC
备库：备库也支持单机或RAC，备库正常为只读状态
二、DataGuard分类DG分为物理DG、逻辑DG
物理DG（生产环境使用多）：
物理DG应用的是主库的归档日志，物理DG无论从逻辑结构和物理结构都是和主库保持一致；
通过块拷贝方式同步，使用数据库recovery恢复功能来应用主库的更改；
通过接收并应用主库的 redo log 以介质恢复的方式(Redo Apply)实现同步
逻辑DG：
逻辑DG应用的是主库归档日志中提取的SQL语句，逻辑DG则只需保证逻辑结构一致；
通过接收 primary数据库的 redo log并转换成 sql语句，欧博官网然后在 standby 数据库上执行 SQL 语句(SQL Apply)实现同步
三、日志传输DataGuard数据同步过程分为三个阶段：日志传输、日志接收、日志应用。
本节讲解日志传输概念，这部分参数与上一篇搭建时设置主备库：log_archive_dest1,log_archive_dest2参数相关
主库在运行过程中会不断地产生redo日志，这些日志需要发送到备库，这个发送动作有两种传输方式：ARCH进程（传归档日志）、LGWR进程（传重做日志）
1.ARCH进程-传归档日志
主库：产生日志后通过LGWR进程写入在线重做日志，当满足相关条件后在线重做日志会进行切换，ARC0进程归档该日志至主库本地的归档目录（log_archive_dest_1配置），归档完成后，ARC1进程就会将归档日志传输到备库(log_archive_dest_2配置)
备库：备库RFS进程负责接收日志。 1）如果备库有standby重做日志，则把日志复制到standby重做日志，接着把standby重做日志归档至备库本地归档目录，最后应用归档日志； 2）如果没有配置standby重做日志，rfs进程接收日志后，直接把它放到备库的归档目录下，再应用该日志
Arch方式是Oracle默认的传输方式，这种方式只有在主库日志归档的时候才会发送日志到备库。如果发生主库宕机的情况，则online redo log中的数据就会丢失，要想避免数据丢失，欧博就需要使用LGWR
2.LGWR进程-传重做日志LGWR分为SYNC(同步)和ASYNC（异步）两种模式，12c 增加fast sync模式
ASYNC模式主库： 只要有新的重做日志产生，LGWR进程将触发LNSn（Log Network Server）进程把新生成的重做日志传输到备库（如果配置了3个备库，则有3个LNS进程）。 ASYNC是redo buffer保存到 online redo log后，LNSn才开始传输
备库： RFS进程负责接收日志。接收到日志后将其写入standby重做日志，如果备库开启了实时应用，就立即做日志应用，如果没有开启，则等standby重做日志归档后再应用
主库：redo log buferr中只要有新的变更产生，LGWR进程将触发LNSn进程把新生成的重做日志传输到备库。SYNC是在redo buffer时，LNSn进程就开始传输，也就是说是从内存中就开始传输，并不写入redo log。
备库：rfs进程负责接收日志。接收到日志后将其写入standby重做日志，如果备库开启了实时应用，就立即做日志应用，如果没有开启，欧博娱乐则等standby重做日志归档后再应用。这种方式备库需要给主库一个回复，证明传输成功，如果有问题一直不回复就会导致主库的lgwr进程一直挂起，影响主库
使用LGWR进程存在的问题 使用LGWR SYNC方法的可能问题在于，如果日志发送给备库过程失败，LGWR进程就会报错。也就是说主库的LGWR进程依赖于网络状况，有时这种要求可能过于苛刻，推荐使用LGWR ASYNC方式
3.FAL（Fetch archive log）进程搭建DG的时候配置了fal_client和fal_server参数，它是取回归档日志进程，只有物理备库才有该进程。
FAL进程提供了一个client/server的机制，用来解决检测在主库产生的连续归档日志，而在备库接受的归档日志不连续的问题。该进程只有在需要的时候才会启动，而当工作完成后就关闭了，因此在正常情况下，该进程是无法看见的。
该进程是通过fal_client,fal_server参数进行交互的。
当主库的某些日志没有成功发送到备库，这时候发生了Archive Gap，缺失的这些日志就是Gap。
DG能够自动检测，解决归档裂缝，不需要dba的介入，但是这需要配置fal_client,fal_server这两个参数
fal_client通过网络向fal_server发送请求 fal_server通过网络向fal_client发送缺失的日志
除了自动解决，dba也可以手工解决，把日志拷贝到备库再注册：
代码语言：javascript
复制
--注册单个 alter database register logfile '日志文件名'; --注册多个 rman>catalog start with '/u01/arch/'; --正常注册完，就应该开始自动应用日志，如果没有的话先关闭实时应用再打开
四、日志接收及应用日志接收： 备库使用RFS（remote file server）进程接收日志，该进程接收到日志后，就把日志写到standby redo log（有这个就先写这个，没有这个就直接写archived log文件中）或者archived log文件中。
如果写到standby redo log文件中，则当主库发生日志切换时，也会触发备库上的standby redo log的日志切换，并把这个standby redo log 归档
日志应用： 应用接收到的主库日志，实现主备库的数据同步。
物理备库使用MRP（managed recovery process）进程应用日志
逻辑备库使用LSP（logical standby process）进程应用日志
日志应用服务分为两种方式：
redo应用 物理备库数据库专用，通过介质恢复的方式保持与primary数据库的同步。
sql应用 逻辑备库数据库专用，核心是通过logminer分析出sql语句在standby端执行。
日志应用模式：
实时应用（real-time apply）：这种方式必须使用standby redo log，每当日志被写入standby redo log时，就会触发恢复，使用这种方式的好处在于可以减少数据库切换（switchover或者failover）的时间，因为切换时间主要用在剩余日志的恢复上。
代码语言：javascript
复制
--开启实时应用 alter database recover managed standby database using current logfile disconnect;
非实时应用：这种方式在主库发生日志切换，触发备库归档操作，归档完成后触发恢复
代码语言：javascript
复制
--开启非实时应用，切换归档才应用日志 alter database recover managed standby database disconnect;
五、DataGuard三种保护模式及转换1.最大保护（maximum protection）可以保证主库和备库的同步，任何情况下主库的损毁都不会导致已提交数据的丢失。如果主库和备库之间的网络出现问题，或者备库本身出现问题，都会导致主库宕机。
这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其redo不仅被写入到本地的online redo log，还要同时提交到standby数据库的standby redo log，并确认redo数据至少在一个standby数据库可用(如果有多个的话)，然后才会在primary数据库上提交。如果出现了什么故障导致standby数据库不可用的话， primary数据库会被shutdown。
使用这种方式要求主库必须配置 Standby RedoLog，而备库必须使用LGWR，SYNC，AFFIRM 方式归档到 Standby Database。
2.最大可用（Maximum availability）保证主库和备库的同步，与上面的区别是当网络或备库不可用时，主库仍可以继续使用。
这种模式和"最大保护"基本上差不多。正常情况下，主备库之间是同步的。 当网络或者备库出现问题时，不会影响到主库的宕机，主库会自动转换库"最大性能"模式，等待备库可用时，将归档传输到备库做恢复。
可以把这种模式理解为"最大保护"和"最大性能"两种模式的中间体。 这种模式提供在不影响primary数据库可用前提下最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求所有事务在提交前必须保障redo数据至少在一个standby数据库可用，不过与之不同的是，如果出现故障导致无法同时写入standby数据库redo log， primary数据库并不会shutdown，而是自动转为最高性能模式，等standby数据库恢复正常之后，它又会再自动转换成最高可用性模式。
这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求备库必须配置 Standby RedoLog，而主库必须使用 LGWR，SYNC，AFFIRM 方式归档到备库.
3.最大性能（maximum performan）缺省模式，主库和备库是异步的。这种模式可能在主库出现损坏时，丢失一部分数据。当时这种模式对主库负荷最小，因此具有最好的性能。
这种模式保证主库性能最大化，主备库之间数据是异步传输的。即主库日志归档以后才会传输到备用库，在备库上使用归档日志文件做恢复操作。 这种模式提供在不影响主库性能前提下最高级别的数据保护策略。事务可以随时提交，当前主库的redo数据也需要至少写入一个standby数据库，不过这种写入可以是不同步的。 这种方式可以使用 LGWR ASYNC 或者 ARCH 进程实现，备库也不要求使用 Standby RedoLog。
4.模式转换代码语言：javascript
复制
--主备库都要执行 --转换为最高可用，log_archive_dest_2需要配置LGWR SYNC AFFIRM alter database set standby database to maximize availability; --转换为最大性能，log_archive_dest_2需要配置LGWR ASYNC alter database set standby database to maximize performance; --转换为最大保护，log_archive_dest_2需要配置LGWR SYNC AFFIRM alter database set standby database to maximize protection;
注意：备库shutdown再启动的话，open_mode又变回read only 需要再次执行开启同步
六、总结关于DG的架构和概念主要是需要搞懂日志的传输、接收及应用。 建议阅读官方文档及《Oracle Data Guard 11g完全参考手册》
