OracleDataGuard详解
0- 背景介绍
RAC， Data Gurad， Stream 是Oracle ⾼可⽤性体系中的三种⼯具，每个⼯具即可以独⽴应⽤，也可以相互配合。 他们各⾃的侧重点不同，适⽤场景也不同。
❑ RAC 的强项在于解决单点故障和负载均衡，因此RAC ⽅案常⽤于7*24 的核⼼系统，但RAC ⽅案中的数据只有⼀份，尽管可以通过RAID 等机制避免存储故障，但是数据本⾝是没有冗余的，容易形成单点故障。
❑ Data Gurad 通过冗余数据来提供数据保护，Data Gurad 通过⽇志同步机制保证冗余数据和主数据之前的同步，这种同步可以是实时、延时、同步、异步多种形式。Data Gurad 常⽤于异地容灾和⼩企业的
⾼可⽤性⽅案，虽然可以在Standby 机器上执⾏只读查询，从⽽分散Primary 的性能压⼒，但是Data Gurad 决不是性能解决⽅案。
❑ Stream 是以Oracle Advanced Queue为基础实现的数据同步，提供了多种级别的灵活配置，并且Oracle 提供了丰富的API等开发⽀持，Stream 更适⽤在应⽤层⾯的数据共享。
1- Oracle Data Gurad
Data Guard可以以只读的⽅式打开数据库，但此时Media Recovery利⽤⽇志进⾏数据同步的过程就停⽌了，如果物理备⽤数据库处于恢复的过程中数据库就不能打开查询，也就是说⽇志应⽤和只读打开两个状态是互斥的（10g之前）。
Oracle 11g 中推出的Active Data Guard功能解决了（10g物理DG）这个⽭盾，在利⽤⽇志恢复数据的同时可以⽤只读的⽅式打开数据库，⽤户可以在备⽤数据库上进⾏查询、报表等操作，这类似逻辑Data Guard备⽤数据库的功能（查询功能⽅⾯），但是，数据同步的效率更⾼、对硬件的资源要求更低。这样可以更⼤程度地发挥物理备⽤数据库的硬件资源的效能。
图 1 ADG架构
ADG架构可以按照功能分成3个部分：
⽇志发送（Redo Send）
⽇志接收（Redo Receive）
⽇志应⽤（Redo Apply）
❑⽇志发送（Redo Send）
Primary Database 运⾏过程中，会源源不断地产⽣Redo ⽇志，这些⽇志需要发送到Standy Database。 这个发送动作可以由Primary Database 的LGWR 或者ARCH进程完成， 不同的归档⽬的地可以使⽤不同的⽅法，但是对于⼀个⽬的地，只能选⽤⼀种⽅法。 选择哪个进程对数据保护能⼒和系统可⽤性有很⼤区别。
使⽤ARCH 进程
1）Primary Database 不断产⽣Redo Log，这些⽇志被LGWR 进程写到联机⽇志。
2）当⼀组联机⽇志被写满后，会发⽣⽇志切换（Log Switch），并且会触发本地归档，本地归档位置是采⽤
LOG_ARCHIVE_DEST_1='LOCATION=/path' 这种格式定义的。
如：alter system set log_archive_dest_1 ='LOCATION=/u01/arch' scope=both;
3）完成本地归档后，联机⽇志就可以被覆盖重⽤。
4）ARCH 进程通过Net 把归档⽇志发送给Standby Database的RFS（Remote File Server） 进程。
5）Standby Database 端的RFS 进程把接收的⽇志写⼊到归档⽇志。
6）Standby Database 端的MRP(Managed Recovery Process)进程（Redo Apply）或者LSP 进程（SQL Apply）在Standby Database上应⽤这些⽇志，进⽽同步数据。
⽤ARCH模式传输不写Standby Redologs，直接保存成归档⽂件存放于Standby端。
说明：
逻辑Standby接收后将其转换成SQL语句，在Standby数据库上执⾏SQL语句实现同步，这种⽅式叫SQL Apply。
物理Standby接收完Primary数据库⽣成的REDO数据后，以介质恢复的⽅式实现同步，这种⽅式也叫
Redo Apply。
注意：创建逻辑Standby数据库要先创建⼀个物理Standby数据库，然后再将其转换成逻辑Standby数据库。
使⽤ARCH进程传递最⼤问题在于： Primary Database 只有在发⽣归档时才会发送⽇志到Standby Database。 如果Primary Database 异常宕机，联机⽇志中的Redo 内容就会丢失，因此使⽤ARCH 进程⽆法避免数据丢失的问题，要想避免数据丢失，就必须使⽤LGWR，⽽使⽤LGWR ⼜分SYNC（同步）和ASYNC（异步）两种⽅式。
在缺省⽅式下，Primary Database使⽤的是ARCH进程，参数设置如下：
alter system set log_archive_dest_2 ='SERVICE=ST' scope=both;
使⽤LGWR 进程的SYNC ⽅式
1）Primary Database 产⽣的Redo ⽇志要同时写到⽇志⽂件和⽹络。也就是说LGWR进程把⽇志写到本地⽇志⽂件的同时还要发送给本地的LNSn进程（Network Server Process），再由LNSn（LGWR Network Server process）进程把⽇志通过⽹络发送给远程的⽬的地，每个远程⽬的地对应⼀个LNS进程，多个LNS进程能够并⾏⼯作。
2）LGWR 必须等待写⼊本地⽇志⽂件操作和通过LNSn进程的⽹络传送都成功，Primary Database 上的事务才能提交，这也是SYNC的含义所在。
3）Standby Database的RFS进程把接收到的⽇志写⼊到Standby Redo Log⽇志中。
4）Primary Database的⽇志切换也会触发Standby Database 上的⽇志切换，即Standby Database 对Standby Redo Log的归档，然后触发Standby Database 的MRP或者LSP 进程恢复归档⽇志。
因为Primary Database 的Redo 是实时传递的，于是Standby Database 端可以使⽤两种恢复⽅法：
实时恢复（Real-Time Apply）： 只要RFS把⽇志写⼊Standby Redo Log 就会⽴即进⾏恢复；
归档恢复： 在完成对Standby Redo Log 归档才触发恢复。
Primary Database默认使⽤ARCH进程，如果使⽤LGWR进程必须明确指定。使⽤LGWR SYNC⽅式时，可以同时使⽤NET_TIMEOUT 参数，这个参数单位是秒，代表如果多长时间内⽹络发送没有响应，LGWR 进程会抛出错误。 ⽰例如下：
alter system set log_archive_dest_2 ='SERVICE=ST  LGWR  SYNC  NET_TIMEOUT=30' scope=both;
使⽤LGWR进程的ASYNC ⽅式
使⽤LGWR SYNC⽅法的可能问题在于，如果⽇志发送给Standby Database过程失败，LGWR进程就会报错。也就是说Primary Database的LGWR 进程依赖于⽹络状况，有时这种要求可能过于苛刻，这时就可以使⽤LGWR ASYNC⽅式。 它的⼯作机制如下：
1） Primary Database 产⽣Redo ⽇志后，LGWR 把⽇志同时提交给⽇志⽂件和本地LNS 进程，但是LGWR进程只需成功写⼊⽇志⽂件就可以，不必等待LNSn进程的⽹络传送成功。
2） LNSn进程异步地把⽇志内容发送到Standby Database，多个LNSn进程可以并发发送。
3） Primary Database的Online Redo Log 写满后发⽣Log Switch，触发归档操作，也触发Standby Database对Standby Redo Log 的归档，然后触发MRP或者LSP 进程恢复归档⽇志。
因为LGWR进程不会等待LNSn进程的响应结果，所以配置LGWR ASYNC⽅式时不需要NET_TIMEOUT参数。⽰例如下：
alter system set log_archive_dest_2 ='SERVICE=ST  LGWR  ASYNC ' scope=both;
❑⽇志接收（Redo Receive）
Standby Database 的RFS（Remote File Server）进程接收到⽇志后，就把⽇志写到Standby Redo Log或者Archived Log⽂件中，具体写⼊哪个⽂件，取决于Primary 的⽇志传送⽅式和Standby database的位置。如果写到Standby Redo Log⽂件中，则当Primary Database发⽣⽇志切换时，也会触发Standby Database上的Standby Redo Log 的⽇志切换，并把这个Standby Redo Log 归档。 如果是写到Archived Log，那么这个动作本⾝也可以看作是个归档操作。
在⽇志接收中，需要注意的是归档⽇志会被放在什么位置：
1） 如果配置了STANDBY_ARCHIVE_DEST 参数，则使⽤该参数指定的⽬录。
2） 如果某个LOG_ARCHIVE_DEST_n 参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)选项，则使⽤这个参数指定的⽬录。
3） 如果数据库的COMPATIBLE参数⼤于等于10.0，则选取任意⼀个LOG_ARCHIVE_DEST_n的值。
4） 如果STANDBY_ARCHIVE_DEST 和 LOG_ARCHIVE_DEST_n 参数都没有配置，使⽤缺省的STANDBY_ARCHIVE_DEST参数值，这个缺省值是$ORACLE_HOME/dbs/arc 。
❑⽇志应⽤（Redo Apply）
Standby数据库的相关进程读取接收到的REDO数据（可能来⾃于Standby端的归档⽂件，也可能来⾃于Standby Redologs），再将其写⼊Standby数据库。
⽇志应⽤服务，就是在Standby Database上重演Primary Database⽇志，从⽽实现两个数据库的数据同步。
根据Standby Database重演⽇志⽅式的不同，可分为物理Standby（Physical Standby） 和 逻辑Standby（Logical Standby）。
Physical Standby 使⽤的是Media Recovery 技术，在数据块级别进⾏恢复，这种⽅式没有数据类型的限制，可以保证两个数据库完全⼀致。 Physical Standby数据库只能在Mount 状态下进⾏恢复，也可以是打开，但只能已只读⽅式打开，并且打开时不能执⾏恢复操作。
Logical Standby 使⽤的是Logminer 技术，通过把⽇志内容还原成SQL 语句，然后SQL引擎执⾏这些语句，Logminer Standby不⽀持所有数据类型，可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不⽀持的数据类型，如果使⽤了这种数据类型，则不能保证数据库完全⼀致。 Logical Standby数据库可以在恢复的同时进⾏读写操作。
根据Redo Apply发⽣的时间可以分成两种： 实时应⽤（Real-Time Apply）和归档时应⽤。
实时应⽤（Real-Time Apply）， 这种⽅式必须Standby Redo Log，每当⽇志被写⼊Standby Redo Log时，就会触发恢复，使⽤这种⽅式的好处在于可以减少数据库切换（Switchover 或者Failover）的时间，因为切换时间主要⽤在剩余⽇志的恢复上。
归档时应⽤，这种⽅式在Primary Database发⽣⽇志切换，触发Standby Database 归档操作，归档完成后触发恢复。 这也是默认的恢复⽅式。
如果是Physical Standby，可以使⽤下⾯命令启⽤Real-Time：
Alter database recover managed standby database using current logfile;
如果是Logical Standby，可以使⽤下⾯命令启⽤Real-Time：
Alter database start logical standby apply immediate;
查看是否使⽤Real-Time apply：
Select recovery_mode from v$archive_dest_status;
2- 数据保护模式
Data Guard 允许定义三种数据保护模式，分别是最⼤性能（Maximum Performance）、最⼤可⽤（Maximum Availability）和最⼤保护（Maximum Protection） 。
❑最⼤性能模式（Maximum Performance）
该模式是默认模式，可以保证主数据库的最⾼可⽤性；
这种模式在不影响Primary数据库性能前提下，提供最⾼级别的数据保护策略。事务可以随时提交，当前Primary数据库的Redo数据⾄少需要写⼊⼀个Standby数据库，不过这种写⼊可以是不同步的。如果⽹络条件理想的话，这种模式能够提供类似最⾼可⽤性的数据保护，⽽仅对Primary数据库的性能有轻微影响。
这种⽅式可以使⽤LGWR ASYNC 或者 ARCH 进程实现，Standby Database也不要求使⽤Standby Redo Log。
❑最⼤可⽤模式（Maximum Availability）
该模式提供了仅次于“最⼤保护模式”的数据保护能⼒（介于最⼤保护与最⼤性能之间）。
该模式在不影响Primary数据库可⽤前提下，提供最⾼级别的数据保护策略。其实现⽅式与最⼤保护模
式类似，也是要求本地事务在提交前必须⾄少写⼊⼀台Standby数据库的Standby Redologs中，不过与最⼤保护模式不同的是，如果出现故障导致Standby数据库⽆法访问，Primary数据库并不会被Shutdown，⽽是⾃动转为最⾼性能模式，等Standby数据库恢复正常之后，Primary数据库⼜会⾃动转换成最⾼可⽤性模式。
这种⽅式虽然会尽量避免数据丢失，但不能绝对保证数据完全⼀致。这种⽅式要求Standby Database 必须配置Standby Redo Log，⽽Primary Database必须使⽤LGWR，SYNC，AFFIRM ⽅式归档到Standby Database。
❑最⼤保护模式（Maximum Protection）
这种模式能够确保绝⽆数据丢失。要实现这⼀步当然是有代价的，它要求所有的事务在提交前其Redo不仅被写⼊到本地的Online Redologs，还要同时写⼊到Standby数据库的Standby Redologs，并确认Redo数据⾄少在⼀个Standby数据库中可⽤（如果有多个的话），然后才会在Primary数据库上提交。如果出现了什么故障导致Standby数据库不可⽤的话（⽐如⽹络中断），Primary数据库会被Shutdown，以防⽌数据丢失。oracle 时间转换
使⽤这种⽅式要求Standby Database 必须配置Standby Redo Log，⽽Primary Database必须使⽤LGWR，SYNC，AFFIRM ⽅式归档到Standby Database。
三种模式⽐较
⽐较项Redo写或传输进程⽹络传输模式是否落盘确认standby redologs
最⼤保护lgwr sync affirm需要
最⾼可⽤lgwr sync affirm需要
最⼤性能lgwr或者arch sync或者async affirm或者noaffirm可有可⽆
AFFIRM：在⽇志写进程进⾏之前，所以的归档⽇志和备库⽇志必须同步写完。
NOFFIRM：在主库的⽇志写进程不等所有磁盘IO完成。
（缺省值为NOFFIRM）
修改数据保护模式相关内容可参考⽂章：
3- ⾃动裂缝检测和解决
当Primary Database的某些⽇志没有成功发送到Standby Database， 这时候发⽣了归档裂缝（Archive Gap）。
缺失的这些⽇志就是裂缝（Gap）。 Data Guard能够⾃动检测，解决归档裂缝，不需要DBA的介⼊。这需要配置FAL_CLIENT，
FAL_SERVER 这两个参数（FAL: Fetch Archive Log）。
从FAL 这个名字可以看出，这个过程是Standby Database主动发起的“取”⽇志的过程，Standby Database 就是FAL_CLIENT. 它是从FAL_SERVER中取这些Gap， 10g中，这个FAL_SERVER可以是Primary Database， 也可以是其他的Standby Database。
如：FAL_SERVER='PR1,ST1,ST2';
FAL_CLIENT和FAL_SERVER两个参数都是Oracle Net Name。 FAL_CLIENT 通过⽹络向FAL_SERVER发送请求，FAL_SERVER通过⽹络向FAL_CLIENT发送缺失的⽇志。 但是这两个连接不⼀定是⼀个连接。 因此FAL_CLIENT向FAL_SERVER发送请求时，会携带
FAL_CLIENT参数值，⽤来告诉FAL_SERVER应该向哪⾥发送缺少的⽇志。 这个参数值也是⼀个Oracle Net Name，这个Name是在FAL_SERVER上定义的，⽤来指向FAL_CLIENT.
当然，除了⾃动地⽇志缺失解决，DBA 也可以⼿⼯解决。 具体操作步骤如下：
1） 查看是否有⽇志GAP：
SQL>SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG;
SQL>SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
2） 如果有，则拷贝过来
3） ⼿⼯的注册这些⽇志：
SQL>ALTER DATABASE REGISTER LOGFILE '路径';
4- 指定⽇志发送对象
❑ VALID_FOR属性指定传输及接收对象
LOG_ARCHIVE_DEST_n参数中的VALID_FOR属性，⽤来指定传输的内容。从字⾯理解VALID_FOR就是基于谁有效，该属性有两个参数值需要指定：REDO_LOG_TYPE和DATABASE_ROLE，我们基本上可以将其理解为：发送指定⾓⾊⽣成的指定类型的⽇志⽂件，该参数的主要⽬的是为了确保⼀旦发⽣⾓⾊切换操作后数据库的正常运转。
其中，REDO_LOG_TYPE和DATABASE_ROLE两个参数可供选择的参数值如下：
REDO_LOG_TYPE：可设置为ONLINE_LOGFILE、STANDBY_LOGFILE、ALL_LOGFILES。
DATABASE_ROLE：可设置为PRIMARY_ROLE、STANDBY_ROLE、ALL_ROLES。
注意：VALID_FOR参数默认值是：VALID_FOR=（ALL_LOGFILES,ALL_ROLES）。
推荐⼿动设置该参数⽽不要使⽤默认值，在某些情况下默认的参数值不⼀定合适，如逻辑Standby在默认情况下就处于OPEN READ WRITE模式，不仅有REDO数据⽽且还包含多种⽇志⽂件（Online Redologs、Archived Redologs及Standby Redologs）。
默认情况下，逻辑Standby数据库⽣成的归档⽂件和接收到的归档⽂件在相同的路径下，这既不便于管理，也极有可能带来⼀些隐患。建议对每个LOG_ARCHIVE_DEST_n参数设置合适的VALID_FOR属性。本地⽣成的归档⽂件和接收到的归档⽂件最好分别保存于不同路径下。
❑ DB_UNIQUE_NAME属性指定数据库
DB_UNIQUE_NAME属性是10g版本新增加的⼀个关键字，在之前版本并没有这⼀说法。该属性的作⽤是指定唯⼀的Oracle数据库名称，也正因有了DB_UNIQUE_NAME，REDO数据在传输过程中才能确认传输到DBA希望被传输到的数据库上。
当然要确保REDO数据被传输到指定服务器，除了在LOG_ARCHIVE_DEST_n参数中指定正确DB_UNIQUE_NAME属性之外，还有⼀个初始化参数LOG_ARCHIVE_CONFIG也需要进⾏正确的配置。该参数除了指定Data Guard环境中的唯⼀数据库名外，还包括⼏个属性，⽤来控制REDO数据的传输和接收：
SEND：允许数据库发送数据到远端。
RECEIVE：允许Standby接收来⾃其他数据库的数据。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。