dg重做 oracle_Oracle11gDG概念与进程详解

最新推荐文章于 2022-11-10 22:51:26 发布

weixin_39767124

最新推荐文章于 2022-11-10 22:51:26 发布

阅读量131

点赞数

文章标签： dg重做 oracle

本文链接：https://blog.csdn.net/weixin_39767124/article/details/111733687

版权

Oracle Data Guard提供数据保护，通过日志同步确保主库与备库间的数据一致性。日志发送涉及ARCH和LGWR进程，日志接收由RFS进程处理，日志应用分为物理和逻辑Standby。物理Standby使用Media Recovery，逻辑Standby通过Logminer技术实现数据同步。Data Guard支持实时应用和归档时应用两种恢复方式。

摘要由CSDN通过智能技术生成

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更适用在应用层面的数据共享。

一． Data Guard

DG架构可以按照功能分成3个部分：

1) 日志发送(Redo Send)

2) 日志接收(Redo Receive)

3) 日志应用(Redo Apply)

1. 日志发送(Redo Send)

Primary Database运行过程中，会源源不断地产生Redo日志，这些日志需要发送到Standy Database。这个发送动作可以由Primary Database的LGWR或者ARCH进程完成，不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。选择哪个进程对数据保护能力和系统可用性有很大区别。

1.1 使用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;

1.2 使用LGWR 进程的SYNC 方式

1)Primary Database 产生的Redo 日志要同时写道日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程(LGWR 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 RedoLog的归档，然后触发Standby Database的MRP或者LSP进程恢复归档日志。

因为Primary Database 的Redo是实时传递的，于是Standby Database端可以使用两种恢复方法：

实时恢复(Real-Time Apply)：只要RFS把日志写入Standby Redo Log就会立即进行恢复；

归档恢复：在完成对Standby RedoLog归档才触发恢复。

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;

1.3 使用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;

2.日志接收(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.

3.日志应用(Redo Apply)

日志应用服务，就是在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数据库可以在恢复的同时进行读写操作。

Standby数据库的相关进程读取接收到的REDO数据(可能来自于Standby端的归档文件，也可能来自于Standby Redologs)，再将其写入Standby数据库。保存之后数据又是怎么生成的呢？两种方式：物理Standby通过REDO应用，逻辑Standby通过SQL应用

根据Redo 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;

SQL> set wrap off

SQL> select