Oracle-DataGuard中日志服务

日志传输服务（Redo Transport Service）

日志传输服务的职责是控制redo数据从生产端数据库到一个或多个归档目的地的自动传输服务。

当主库LGWR写ORL日志时，LNS进程从SGA（实际是Log buffer cache）中读取redo数据，然后通过Oracle Net Services将数据传输到备库上。如果主库是RAC，每个DB实例都有自己的LNS进程。在备用数据库上的Remote File Server (RFS)接收传过来的Redo数据，并将其写入到standby redo logfile (SRL)或是archive logfile中。如果是多备库环境，主库为每个备库都启用一个独立的LNS进程与对应的RFS进程通信，进行传输日志数据。

负责日志传输的进程

  • ARCH进程：它传输的是归档日志，自带异步属性
  • LGWR进程：LGWR传输机制与ARCH不一样，它不需要等待Primary端online redo log切换及归档后才开始传输redo数据。它有两种属性：同步(sync)和异步(async)
LNS进程支持的传输方式类型
  • 同步(sync)：在主库上的LGWR进程将log buffer数据写入到ORL的同时，必须等待本地的LNS确认redo数据已写入配置的所有备库的Standby redo logfile才允许提交事务
  • 异步(async)：在主库上的LGWR不需要等待本地的LNS进程确认回应信息，此种方式对主库性能几乎无影响。
    • 如果LNS进程无法跟上进度，并且在redo数据传输到备端之前，日志缓冲区被回收，LNS将自动转换为从ORL（11g之后版本）读取和发送。一旦LNS进程追上进度，它会自动转换回直接从日志缓冲区读取或发送。
    • 日志缓冲区命中率在视图X$LOGBUF_READHIST中跟踪
      • 命中率低表示LNS经常从ORL而不是日志缓冲区读取。如果redo传输与生成速率不同步，则考虑增加日志缓冲区大小以获得更有利的命中率。这将减少或消除LNS进程从ORL读取数据的I/O开销。
同步传输流程
  1. LGWR进程会将记录从log buffer写入到online redo日志文件中，最后等待LNS确认的消息
  2. LNS在log buffer读取重做记录并通过网络传输到备用数据库，然后RFS接收并写入到standby redo logfile中
  3. RFS将接收的数据写入standby redo logfile完成时，它将确认消息发送给主端LNS,再通知LGWR，最后LGWR向用户提交确认消息
异步传输流程
  1. LGWR进程会将记录从log buffer写入到online redo日志文件中就可以向用户提交的确认消息
  2. LNS读取log buffer或ORL中的redo数据并通过网络传输到备用数据库，然后备端的RFS进程接收并写入到standby redo logfile中

日志传输服务具体实现

默认情况下，redo传输服务使用ARCn进程归档redo日志。不过ARCn归档进程只支持最高性能的保护模式。如果standby数据库处于其它类型的保护模式，那你必须使用LGWR进程传输redo数据。对于最大保护和最高可用性两种模式，redo数据必须实时传输到standby数据库。

使用ARCH进程归档redo数据

默认使用ARCH进程负责redo传输。当主库发生日志切换时，触发归档联机在线日志后发送归档日志到备库。

主备之间通过ARCn进程传输redo data的过程（最大性能模式）

  • Primary端持续产生redo数据的过程中，LGWR进程将它写入到online redo log，当一组日志组写满后，就触发日志切换，并触发ARCn进程归档online redo log至本地的LOG_ARCHIVE_DEST_1位置。如：LOG_ARCHIVE_DEST_1='LOCATION=/path'

  • ARCn归档完成后，ARCn进程通过Oracle Net Service传输该归档日志文件至本地LOG_ARCHIVE_DEST_2定义的Standby端的位置。如：LOG_ARCHIVE_DEST_2='SERVICE=tns_dg_std'

  • Standby端的RFS（remote file server）进程将接收到Primary端的redo数据写入到归档日志文件。用ARCH模式传输不写Standby Redo Logs，直接保存成归档文件存放于Standby端

  • Standby端的MRP（Managed Recovery Process）进程[Redo Apply]或者LSP（logical standby process）进程[SQL Apply]使用接收到归档日志进行redo应用，从而实现主备端数据同步

    • 逻辑Standby接收后将其转换成SQL语句，在Standby数据库上执行SQL语句实现同步，这种方式叫SQL Apply
    • 物理Standby接收完Primary数据库生成的REDO(Standby Redologs)数据后，以介质恢复的方式实现同步，这种方式也叫Redo Apply
相关参数配置
alter system set log_archive_dest_2='SERVICE=biudbst' scope=both sid='*';
alter system set LOG_ARCHIVE_DEST_STATE_2='enable' scope=both sid='*';

LOG_ARCHIVE_MAX_PROCESSES：可以用来指定最大可被调用的ARCn进程的数量

注意：

使用ARCH进程传递最大问题在于：Primary Database只有在发生归档时才会发送日志到Standby Database。如果Primary Database异常宕机，联机日志中的Redo内容就会丢失，因此使用ARCH进程无法避免数据丢失的问题

使用LGWR归档redo数据

Standby端apply节点的LGWR进程会选择一个standby redo logfile对应着primary端redo log的sequence号及大小。这样，当primary端有redo数据产生的时候，以同步或异步的方式将redo data传送至standby端。

如果选择LGWR归档redo数据，那么在LOG_ARCHIVE_DEST_n中必须指定SERVICE和LGWR属性以允许日志传输服务使用LGWR 进程来传送redo数据到远程目的地。同时，还需要指定SYNC(同步)还是ASYNC(异步)的传输方式。如果指定SYNC属性(如果不明确指定的话，默认是SYNC)，则primary数据库上任何会产生redo操作都会同步触发网络I/O，并且等到网络I/O全部完成才会提交，而如果指定了ASYNC属性，则会primary数据库的操作会先记录online redo logfile，然后再传输到standby端

注意：

  • 同步方式只能在DataGuard的最大保护(maximum protection)或是最高可用(maximum availability)的模式下实现，因为最高性能模式(max perfermance)的机制就是异步的。
  • redo传输服务必须在primary库的LOG_ARCHIVE_DEST_n参数定义LGWR以及SERVICE属性，才能使用LGWR进程传输redo data至standby端
LGWR SYNC传输redo data的过程
  1. 在Primary Database产生的Redo数据后，LGWR进程将其写入online redo logfile，同时提交redo数据给一个或多个LGWR Network Server Process(LNSn)进程
    • LNSn（LGWR Network Server process）进程将redo数据通过ORACLE Net服务传送到standby端。每个远程目录对应一个LNS进程，多个LNS进程能够并行工作
  2. Standby端的RFS进程接收传输过来的redo data后，负责写入standby database上的standby redo logfile里
  3. 直到standby端所有定义了LGWR SYNC的LOG_ARCHIVE_DEST_n地址都成功完成接收传送过来的redo data后，primary端的事务才会commit
  4. Primary Database的日志切换也会触发Standby Database上的日志切换，级联触发Standby端上的ARCn进程将Standby Redo Logfile写入归档日志文件，然后触发Standby Database的MRP或者LSP进程应用redo数据到standby database。
  5. Primary Database的Redo数据是实时传递的，Standby Database端可以使用两种恢复方法
    • 实时恢复（Real-Time Apply）：只要RFS进程将redo数据写入Standby Redo Logfile里，就会直接从current standby redo logfiles恢复redo数据到standby端。
    • 归档恢复：在完成对Standby Redo Logfile归档才触发恢复
  • 同步传输日志模型

img

主库写REDO的时候，LGWR进程通过LNS进程把日志写到STANDBY，LGWR必须等待写入本地日志文件和STANDBY都写入成功了，主库上的事务才算提交，STANDBY的RFS进程把接收到的日志写入到STANDBY REDO LOG中，如果备库开启了实时恢复则当日志传过来时就会进行REDO APPLY。如果备库未开启实时应用，则需主库发生归档时，备库才会进行应用。

  • 配置方式

    如果设置LOG_ARCHIVE_DEST_n初始化参数SYNC属性，建议同时设置NET_TIMEOUT属性，该属性控制网络连接的超时时间，如果超时仍无响应，则会返回错误信息

    -- NET_TIMEOUT: 如果多长时间内网络发送没有响应，LGWR进程会抛出错误, 单位:秒
alter system set log_archive_dest_2 = 'SERVICE=biudbst LGWR SYNC NET_TIMEOUT=30' scope=both;
alter system set  LOG_ARCHIVE_DEST_STATE_2=ENABLE;
-- SERVICE=biudbst，指定本地tnsnames.ora定义的Oracle Net名称

  • SYNC 可能问题：在于日志发送给Standby Database过程失败，LGWR进程就会报错。Primary Database的LGWR进程非常依赖于网络带宽

LGWR ASYNC传输redo data的过程
  1. Primary端产生redo data后，LGWR进程将redo data写入online redo logfile
  2. Primary端的LNSn进程读取online redo log，透过ORACLE Net服务以ASYNC的方式的将redo data传送至standby端的RFS进程
  3. Standby端的RFS进程接收传输过来的redo data后，并负责写入standby database上的standby redo logfile里
  4. primary端LGWR不用确认LNSn进程的传输状态，直接将新的redo data写入本地的online redo logfile
  5. Primary端的Online Redo Log写满后发生Log Switch，触发本地归档日志操作，也会级联触发Standby端ARCn进程对Standby Redo Logfile的归档，然后Standby Database的MRP或者LSP进程应用redo数据到standby database。
  • 异步传输日志模式

img

主库写REDO的时候，LGWR进程通过LNS进程把日志写到STANDBY，LGWR不必等待日志传输成功，主库上的事务一旦发生提交，则事务完成，STANDBY的RFS进程把接收到的日志写入到STANDBY REDO LOG中，如果备库开启了实时恢复则当日志传过来时就会进行REDO APPLY。如果备库未开启实时应用，则需主库发生归档时，备库才会进行应用。

  • 配置

    alter system set log_archive_dest_2 = 'SERVICE=biudbst LGWR ASYNC ' scope=both;

注意：异步机制下，primary端不需要确认standby端的网络传输，故不用设置NET_TIMEOUT参数。也不会影响primary端提交事务。

其它支持的特性

数据压缩

Oracle 11g之后提供了日志传输压缩技术，减少带宽对传输的影响，提高了cpu使用率。在一些带宽限制较多，cpu资源空间较大情况下可以考虑使用。

日志应用服务（Apply Services）

Data Guard通过应用REDO维持Primary数据库与各Standby数据库之间的一致性。

分类

  • Redo Apply：物理Standby数据库专用，通过介质恢复的方式保持与Primary数据库的同步。

    Description of Figure 1-2 follows

  • SQL Apply：逻辑Standby数据库专用，核心是通过LogMiner分析出SQL语句，然后在Standby端执行。他需要更多的cpu，内存和IO等资源。注意：不支持的数据类型

    Description of Figure 1-3 follows

配置选项

默认情况下，Log应用服务会等待单个归档文件全部接收之后再启动redo应用，如果Standby数据库配置了Standby Redologs，就可以打开实时应用（Real-Time Apply），这样Data Guard就不需要再等待接收完归档文件，只要RFS进程将REDO数据写入Standby Redologs，即可通过MRP/LSP进程实时写向Standby数据库

REDO数据实时应用

实时应用redo数据的前提是Standby数据库端配置了Standby Redologs，在启动REDO应用的语句时添加对应子句即可。

Description of Figure 7-1 follows

REDO数据延时应用

在某些场景时（如：基于数据容错方面因素，即误操作时可以通过standby快速恢复），需要使用到延迟属性。就可以在Primary端设置LOG_ARCHIVE_DEST_n参数时指定DELAY属性，单位是分钟。用于指定primary端发送REDO数据到Standby后，在指定的DELAY时间值后开始应用redo数据。

-- 设置LOG_ARCHIVE_DEST_3的DELAY属性为15分钟
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=bpri ARCH VALID_FOR= 
(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=biudb DELAY=15';

注意：

  • 如果在启动REDO应用时指定了实时应用，即使在LOG_ ARCHIVE_DEST_n参数中指定了DELAY属性，Standby数据库也会忽略DELAY属性

  • Standby端也可以在启动REDO应用时，通过附加NODELAY子句的方式，取消延迟应用

    -- 物理Standby
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
-- 逻辑Standby
ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

应用REDO数据到Standby数据库

物理standby

  • 前台应用数据

    -- 语句执行完成后，不会将控制权返回到命令行窗口
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

  • 后台应用数据

    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

    语句执行完后，控制权自动返回到当前的命令行模式，REDO应用以后台进程运行。

  • 实时应用数据

    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

    附加USING CURRENT LOGFILE子句

  • 停止REDO应用

    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

逻辑standby

SQL应用的原理是将接收到的REDO数据转换成SQL语句在逻辑Standby数据库端执行，因此逻辑Standby需要启动至OPEN状态。

  • 启动SQL应用

    ALTER DATABASE START LOGICAL STANDBY APPLY;
-- 实时应用
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

  • 停止SQL应用

    ALTER DATABASE STOP LOGICAL STANDBY APPLY;

    执行语句需要等待当前执行的SQL触发的事务结束，才能真正停止REDO应用的状态

    -- 不考虑事务执行情况，马上停止REDO应用
ALTER DATABASE ABORT LOGICAL STANDBY APPLY;

角色转换(Role Transitions)

负责将主库转换为备库或者从备库到主库。

switchover和failover 方法
  • switchover为主动的做角色转换，首先将主库切换到备库，然后将原来的备库切换至主库角色
  • failover为当主库出现故障时将备库切换至主库，故障转移仅在主数据库发生故障时执行
【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/binliubiao/p/15139232.html