dataguard 日志传输服务

1、日志传输可以分为 lgwr和ARCH,默认是arch,其中lgwr传输可以分为async和sync
sync:同步服务,只有在事物参数的日志成功的传输到备库的目的地,事物才能提交。虽然同步服务没有限制主库和同步目的地的距离,但是主库同步数据到目的地的延时,增加了事物提交的时间
         这种同步模式一般用在最大保护,最高可用
async:异步服务,这种模式在事物提交时不会等待此事物产生的日志成功同步到备库,这种模式一般用在最大性能

2、redo传输的安全
 redo传输使用的 oracle net 服务,通过ssl保护验证或者远端的password 文件

3、参数文件
LOG_ARCHIVE_DEST_n :初始化参数,用来指定备库的传输目的地
 LOG_ARCHIVE_DEST_STATE_n:用来打开关闭目的地,他有三个值
                        enable:默认值,控制日志可以传输到LOG_ARCHIVE_DEST_n 指定的地址
                       defer:控制日志不能传输到 LOG_ARCHIVE_DEST_n指定的地址
                       alternate:在指定的地址传输失败后,可以传输到到这个地址

1.REOPEN 指定时间后再次尝试归档
使用REOPEN=seconds(默认为300秒)属性,在指定时间重复尝试向归档目的地进行归档操作,如果该参数值设置为0,则一旦失败就不会再尝试重新连接并发送,直到下次REDO数据再被归档时会重新尝试。
例如,设置REOPEN为100秒:
LOG_ARCHIVE_DEST_2=‘SERVICE=DavePrimary LGWR ASYNC REOPEN=100‘ 
2.ALTERNATE 指定替补的归档目的地
ALTERNATE属性定义一个替补的归档目的地,所谓替补就是一旦主归档目的地因各种原因无法使用,则临时向ALTERNATE属性中指定的路径写。
例如:
LOG_ARCHIVE_DEST_1=‘LOCATION=/disk1 ALTERNATE=LOG_ARCHIVE_DEST_2‘ 
LOG_ARCHIVE_DEST_STATE_1=ENABLE  
LOG_ARCHIVE_DEST_2=‘LOCATION=/disk2‘ 
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE 
上述参数设置归档路径为/disk1,当/disk1路径下无法成功归档时,自动尝试向/disk2路径下归档文件。
从功能上来看,REOPEN与ALTERNATE是有一定重复的,不过需要注意一点,REOPEN属性比ALTERNATE属性的优先级要高,如果你指定REOPEN属性的值>0,则LGWR(或ARCn)进程会首先尝试向主归档目的地写入,直到达到最大重试次数,如果仍然写入失败,才会向ALTERNATE属性指定的路径写。
 
3.MAX_FAILURE 控制失败尝试次数
用REOPEN指定失败后重新尝试的时间周期,MAX_FAILURE则控制失败尝试的次数。
例如,设置LOG_ARCHIVE_DEST_1在本地归档文件时,如果遇到错误,则每隔100秒尝试一次,共尝试不超过3次,设置如下:
LOG_ARCHIVE_DEST_1=‘LOCATION=E:/ora10g/oradata/jsspdg/ REOPEN=100 MAX_FAILURE=3‘

SYNC: 同步传输日志
ASYNC:异步传输日志
NET_TIMEOUT:指定lgwr进程在规定时间内把日志传输到备库
NOAFFIRM: 主库产生的日志不用等到写入备库后,才算成功
AFFIRM: 主库产生的日志只有写入到备库后,才算成功
DB_UNIQUE_NAME: 数据库的唯一名称,用来指定传输日志的地址
VALID_FOR: 用来指定redo传输服务的目的地
COMPRESSION :日志以压缩的形式传输的目的地
REOPEN : 用来指定由于之前的错误重新连接传输日志到目的地,每次连接的最小时间
LOG_ARCHIVE_DEST_n:用来指定日志传输的目的地

*.standby_file_management=‘AUTO‘:主库增加或减少数据文件的动作是否自动应用到从库

4、standby redo log
1)   同步和异步的传输模式在传输目的地必须有standbylog 才行,standby 用于接收从其他数据传输的日志,其结构和redo一样,管理也和reodo一样管理。
日志是由其他数据库传输过来,通过后台进程RFS进程写入到standby reod log

2)standby redo log大于或者等于主库的redo log,最好备库的standby redo 等于备库的redo
                                  3)备库的standby redo要比主库多一个或者多个日志
              主:
               SQL> SELECT GROUP#, BYTES FROM V$LOG;
                                        备:
                                         SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;
                                    4) 创建standby redo log
                                            如果是single database ,备库创建redo比主库的redo多一个或者多个standby redo,并且和主库的日志大小相同
                                                 SQL> ALTER DATABASE ADD STANDBY LOGFILE (‘/oracle/dbs/slog1.rdo‘) SIZE 500M;
                                               如果是集群
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M;

5)配置standby redo log 归档
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;

配置归档到快速恢复区域:
        LOG_ARCHIVE_DEST_2 = ‘LOCATION=USE_DB_RECOVERY_FILE_DEST  VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)‘
LOG_ARCHIVE_DEST_STATE_2=ENABLE

或者配置归档到本地区域:
LOG_ARCHIVE_DEST_2 = ‘LOCATION = /disk2/archive VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)‘ LOG_ARCHIVE_DEST_STATE_2=ENABLE

5、Configuring a Cascaded Destination
                           1)选择配置级联的备库
                            2) 在级联的备库上配置到主库和备库库的网络服务tnsname.ora 然后配置  FAL_SERVER
                            3)配置 LOG_ARCHIVE_DEST_n  ,SERVICE为到达备库的网络名

Primary Database

DB_UNIQUE_NAME=boston
FAL_SERVER=boston2
LOG_ARCHIVE_CONFIG=‘DG_CONFIG=(boston,boston2,denver)‘
LOG_ARCHIVE_DEST_1=‘LOCATION=USE_DB_RECOVERY_FILE_DEST   VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston‘
LOG_ARCHIVE_DEST_2=‘SERVICE=boston2 SYNC  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston2‘

Cascading Physical Standby Database

DB_UNIQUE_NAME=boston2
FAL_SERVER=boston
LOG_ARCHIVE_CONFIG= ‘DG_CONFIG=(boston,boston2,denver)‘
LOG_ARCHIVE_DEST_1=‘LOCATION= USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston2‘
LOG_ARCHIVE_DEST_2= ‘SERVICE=denver  VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver‘
 
Cascaded Physical Standby Database
                                       DB_UNIQUE_NAME=denver
FAL_SERVER=boston2
LOG_ARCHIVE_CONFIG=‘DG_CONFIG=(boston,boston2,denver)‘
LOG_ARCHIVE_DEST_1=‘LOCATION= USE_DB_RECOVERY_FILE_DEST  VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver‘

6、监控日志的传输:
                              1、查看最近归档的日志文件
                                            SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#;
                                  2、主库查看最近归档的日志,已经归档目的地
                               SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ#  FROM V$ARCHIVE_DEST_STATUS  WHERE STATUS <> ‘DEFERRED‘ AND STATUS <> ‘INACTIVE‘;
                            3、查看主库没有归档日志到备库的日志有哪些
                                SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM  (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1)  LOCAL WHERE 
                                       LOCAL.SEQUENCE# NOT IN  (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND THREAD# = LOCAL.THREAD#);
 
4、主库监控同步日志的响应时间
SQL> SELECT FREQUENCY, DURATION FROM  V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2 AND FREQUENCY>1;
  frequency  指出监控响应时间几次,duration 响应时间

查找最大响应时间是多长时间
SQL> SELECT max(DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2 AND FREQUENCY>1;

主库查找最小响应时间
SQL> SELECT min( DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM  WHERE DEST_ID=2 AND FREQUENCY>1;

The highest observed response time for a destination cannot exceed the highest specified NET_TIMEOUT value specified for that destination, because synchronous redo transport mode sessions are terminated 
if a redo transport destination does not respond to a redo transport message within NET_TIMEOUT seconds.
在最大响应时间不能超过net_timeout指定的时间,否则日志同步就会中断

7、gap的解决:

备库查看是否存在gap
SQL> SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
-----------  -------------  --------------
 1              7              10

如果是物理备库:  
在主库上执行,确定gap,备库缺失的日志名称
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN 7 AND 10;
NAME
--------------------------------------------------------------------------------
/primary/thread1_dest/arcr_1_7.arc 
/primary/thread1_dest/arcr_1_8.arc 
/primary/thread1_dest/arcr_1_9.arc

从主库复制日志到备库,然后注册
SQL> ALTER DATABASE REGISTER LOGFILE  ‘/physical_standby1/thread1_dest/arcr_1_7.arc‘;

SQL> ALTER DATABASE REGISTER LOGFILE  ‘/physical_standby1/thread1_dest/arcr_1_8.arc‘;

SQL> ALTER DATABASE REGISTER LOGFILE  ‘/physical_standby1/thread1_dest/arcr_1_9.arc‘;

如果是逻辑备库查询DBA_LOGSTDBY_LOG:
                           在主库上执行
SQL> COLUMN FILE_NAME FORMAT a55
SQL> SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L  WHERE NEXT_CHANGE# NOT IN 
(SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) 
ORDER BY THREAD#, SEQUENCE#;
 
  THREAD#  SEQUENCE# FILE_NAME
---------- ---------- -----------------------------------------------
1          6 /disk1/oracle/dbs/log-1292880008_6.arc
1         10 /disk1/oracle/dbs/log-1292880008_10.arc
从主库复制日志到备库,然后注册

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE ‘/disk1/oracle/dbs/log-1292880008_7.arc‘;

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE  ‘/disk1/oracle/dbs/log-1292880008_8.arc‘;

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE  ‘/disk1/oracle/dbs/log-1292880008_9.arc‘;

8、日志传输造成的等待事件
在 V$SYSTEM_EVENT 发现等待事件

Wait Event Description
LNS wait on ATTACH   :Total time spent waiting for redo transport sessions to be established to all ASYNC and SYNC redo transport destinations
LNS wait on SENDREQ:Total time spent waiting for redo data to be written to all ASYNC and SYNC redo transport destinations
LNS wait on DETACH    :Total time spent waiting for redo transport connections to be terminated to all ASYNC and SYNC redo transport destinations

查看日志的状态:
SQL> select name,dest_id, SEQUENCE#,RESETLOGS_ID,REGISTRAR,APPLIED,DELETED,STATUS,fal,STANDBY_DEST,ARCHIVED from v$archived_log;
NAME    DEST_ID  SEQUENCE# RESETLOGS_ID REGISTR APPLIED   DEL S FAL STA ARC
---------------------------------------- ---------- ---------- ------------ ------- --------- --- - --- --- ---
 1   403
 815224926 SRMN    YES       YES D NO  NO  YES
 1   404
 815224926 SRMN    YES       YES D NO  NO  YES
/archive/1_405_815224926.arc  2
  405  815224926 RFS     YES       NO  A YES NO  YES
/archive/1_406_815224926.arc  2
  406  815224926 RFS     YES       NO  A NO
NO  YES
/archive/1_407_815224926.arc  2
  407  815224926 RFS     YES       NO  A NO
NO  YES
/archive/1_408_815224926.arc  1
  408  815224926 RFS     YES       NO  A NO
NO  YES
/archive/1_409_815224926.arc  1
  409  815224926 RFS     YES       NO  A NO
NO  YES
/archive/1_410_815224926.arc  1
  410  815224926 RFS     YES       NO  A NO
NO  YES
/archive/1_411_815224926.arc  1
  411  815224926 RFS     YES       NO  A NO
NO  YES
/archive/1_412_815224926.arc  1
  412  815224926 RFS     YES       NO  A NO
NO  YES
/archive/1_413_815224926.arc  1
  413  815224926 RFS     YES       NO  A NO
NO  YES
/archive/1_414_815224926.arc  1
  414  815224926 RFS     YES       NO  A NO
NO  YES
/archive/1_415_815224926.arc  1
  415  815224926 RFS     YES       NO  A NO
NO  YES
/archive/1_416_815224926.arc  0
  416  815224926 RFS     YES       NO  A YES NO  YES
/archive/1_417_815224926.arc  0
  417  815224926 RFS     YES       NO  A YES NO  YES
/archive/1_418_815224926.arc  1
  418  815224926 RFS     YES       NO  A NO
NO  YES
/archive/1_419_815224926.arc  1
  419  815224926 RFS     YES       NO  A NO
NO  YES

时间: 2024-10-05 05:58:28

dataguard 日志传输服务的相关文章

详解dataguard 日志传输服务(参数解析)

dataguard 日志传输服务(参数解析) 1> dg的三种模式1. 最大保护模式1)这种模式提供了最高级别的数据保护能力:2)要求至少一个物理备库收到重做日志后,主库的事务才能够提交:3)主库找不到合适的备库写入时,主库会自动关闭,防止未受保护的数据出现:4)优点:该模式可以保证备库没有数据丢失:5)缺点:主库的自动关闭会影响到主库的可用性,同时需要备库恢复后才能提交,对网络等客观条件要求非常的高,主库的性能会因此受到非常大的冲击. 2. 最大可用性模式1)该模式提供了仅次于“最大保护模式”

Oracle DataGuard日志传输

1. 日志传输方式 有两种日志传输方式(ARC和LGWR),第一种是采用ARC进程传输日志,其示意图如下: 注:上图来自<大话Oracle RAC> 其大致过程如下: 1)主库:日志先写入在线重做日志,当在线重做日志满后(或人为切换), ARC0进程归档该日志至主库本地归档目录,归档完成后,ARC1马上将该归档日志传输到备库: 2)备库:RFS进程接收日志,如果备库有Standby重做日志,则把日志复制到Standby重做日志,接着把Standby重做日志归档至备库本地归档目录,最后应用归档日

azure 云上 oracle11.2.0.4里dataguard归档日志传输 1034 问题详细解决过程

1,dataguard搭建好后,归档日志传输不过去 去查看master库上面的日志 tail –f /data/oracle/diag/rdbms/test_m1/powerdes/trace/alert_powerdes.log,显示信息如下: Sun May 08 00:34:17 2016 Error 1034 received logging on to the standby PING[ARC2]: Heartbeat failed to connect to standby 'tes

Oracle 11g Dataguard 暂停物理备库的日志传输

Oracle 11g Dataguard 暂停物理备库的日志传输分类: Oracle2017-07-18 10:03:17这两天生产端的日志产生过多导致灾备端的归档日志目录满的现象,在清除灾备端的日志后发现log_archive_dest_2处于error状态,需要将其enable.在实际生产系统中,通常有这样的场景,例如在系统维护日,对主库进行大量的业务更新,会有大量的DML操作:为了避免主库中的业务更新对备库造成影响,可以暂停主库对备库的日志传输,这样的话,如果主库的更新出现问题,备库还保留

详解“FTP文件传输服务”安装配置实例

"FTP文件传输服务"安装配置实例 家住海边喜欢浪:zhang789.blog.51cto.com 目录 简介 ftp工作原理 常见的FTP服务 Vsftpd服务器的安装 Vsftpd.conf配置文件详解 配置FTP服务器实例 实例:配置匿名用户 实例:配置本地用户登录 实例:配置虚拟用户登录(MySQL认证) 实例:控制用户登录 实例:设置欢迎信息 分析vsftpd日志管理 FTP服务器配置与管理 简介 FTP 是File Transfer Protocol(文件传输协议)的英文简

Linux网络服务04——FTP文件传输服务

Linux网络服务04--FTP文件传输服务 一.FTP连接及传输模式 1.控制连接:TCP 21,用于发送FTP命令信息 2.数据连接:TCP 20,用于上传.下载数据 3.数据连接的建立类型: (1)主动模式:服务器主动发起数据连接 首先由客户端向服务端的21端口建立FTP控制连接.当需要传输数据时,客户端以PORT命令告知服务器"我打开了某端口,你过来连接我",预算服务器从20端口向客户端的该端口发送请求并建立数据连接. (2)被动模式:服务器被动等待数据连接 如果客户端所在网络

Exchange 邮件服务器传输服务启动失败

Exchange 邮件服务器传输服务启动失败 事件属性-事件ID 16023 日志名称:          Application 来源:            MSExchangeTransport 日期:            2014/10/1 14:51:50 事件 ID:         16023 任务类别:          配置 级别:            错误 关键字:           经典 用户:            暂缺 计算机:           TCS-MAI

Exchange 2007 传输服务自动关闭故障解决方案

故障描述:新建邮件无法发出(outlook客户端现象),新建邮件发送,自动退回草稿箱(WebMail故障现象). 故障原因:在系统服务中(Services),发现Exchange 传输服务自动关闭.(根据程序日志核查是由于:传输邮件数据库,验证失败,因时间戳不匹配.) 解决方案: 首先进入Exchange服务器操作系统,打开"事件查看器",点击应用日志记录,确定故障的原因: 在运行中键入"services.msc",进入系统服务,找到"MS Exchang

「深入 Exchange 2013」10 传输服务简述

前面的内容里面,已经为大家比较深入的介绍了Exchange2013的客户端访问角色涉及到的诸多细节.在接下来的章节里就跟大家聊一聊Exchange 2013里的传输服务,这一节总共的内容都比较多,而且更偏向理论,所以咱先来一篇简述,然后再分拆开一个一个讲. 在之前的版本中,由Exchange2007引入了Hub Transport(集线器传输)角色作为所有邮件信息的传递中枢,任何发送或者接收到的邮件都必然会经过至少一个Ex2010与Ex2007的集线器传输角色:那么在Exchange2013当中