前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >【DG】物理DG中主库的LNSn、NSS、NSA进程的比较

【DG】物理DG中主库的LNSn、NSS、NSA进程的比较

作者头像
小麦苗DBA宝典
发布2023-04-27 13:28:39
1.5K0
发布2023-04-27 13:28:39
举报

同事说dg不能同步,让我帮忙看看,我用自己写的2个视图查看了下,首先发现主库没有常见的LNSn进程,下意识的认为主库这个进程没有启动,需要切换日志唤醒LNSn进程,事实上也这样做了,(alter system set log_archive_dest_state_2='defer'; alter system switch logfile; alter system set log_archive_dest_state_2='enable'; alter system switch logfile;),切换后发现日志可以正常传输了,但是主库还是看不到LNSn这个进程,于是找找资料,深入的研究了一下这个问题。

在读完整个文章后,大家就会了解我这里碰到的问题,说明配置的时候不是采用的异步方式,而小麦苗后来也的确去查看了下,采用的是LGWR SYNC的方式,在读完这篇文章后大家对这个问题就非常明朗了。

本文涉及到以下的内容:

① 检查物理DG是否正常的常用SQL

② 日志传输进程LNSn、NSS、NSA的区别

③ 日志传输的2种方式:lgwr和arch,10g和11g有了变化

④ dg的架构图

1.1 DG架构图

下图是小麦苗绘制的dg结构图,对于里边的redo buffer到底如何传递到LNSn,众说纷纭,10g和11g也有不同,但这个不是我们今天讨论的内容,详细点的资料可以参考:http://www.itpub.net/thread-1841337-1-1.html,我们讨论并实验LNSn、NSS、NSA进程在10g和11g的中表现形式。

1.2 DG日志传输

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

1) 日志发送(Redo Send)

2) 日志接收(Redo Receive)

3) 日志应用(Redo Apply)

我们今天着重来讲讲这里的日志发送的部分。

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

如果你配置一个目的地来使用 LGWR 进程, 但是由于某些原因 LGWR 进程变得无法归到目的地了,则重做传输将会回复到使用 ARCn 进程来完成归档操作。

alter system set log_archive_dest_2='SERVICE=tns_mydgwl LGWR ASYNC db_unique_name=mydgwl valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)' sid='*';

alter system set log_archive_dest_2='SERVICE=tns_mydgwl db_unique_name=mydgwl valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)' sid='*';

若不写传输进程和模式的话,11g下默认为LGWR ASYNC方式,10g为ARCH SYNC模式。

1.2.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上应用这些日志,进而同步数据。

说明:

逻辑Standby接收后将其转换成SQL语句,在Standby数据库上LSP进程执行SQL语句实现同步,这种方式叫SQL Apply。

物理Standby接收完Primary数据库生成的REDO数据后,MRP进程以介质恢复的方式实现同步,这种方式也叫Redo Apply。

1.2.2 使用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进程恢复归档日志。

1.2.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 进程恢复归档日志。

1.3 进程LNSn:LGWR Network Server process

On the primary database, the LGWR process submits the redo data to one or more network server (LNSn) processes, which then initiate the network I/O in parallel to multiple remote destinations.

[root@rhel6_lhr lhr]# ps -ef|grep ora_ln

oracle 8090 1 0 03:57 ? 00:01:40 ora_lns1_oradg10g

oracle 11862 1 0 05:06 ? 00:01:18 ora_lns2_oradg10g

root 26450 25545 0 09:35 pts/4 00:00:00 grep ora_ln

[root@rhel6_lhr lhr]#

DG可以使用ARCH,LGWR来传送日志,但他们都是把日志发送给本地的LNS(如果有多个目标备库,那会启动相应数量的LNS进程,同时发送数据)进程,然后备库那边的RFS进程接收数据,接收到的数据可以存储在备库的备用重做日志文件中或备库的归档日志中,然后再应用到备库中。

主库切换(alter system switch logfile;)可以启动LNS进程, V$MANAGED_STANDBY视图可以查看LNS进程的具体情况:

col group# format a5

set line 9999 pagesize 9999

SELECT a.PROCESS,a.PID,a.STATUS,a.GROUP#,a.SEQUENCE#, a.DELAY_MINS, a.RESETLOG_ID FROM V$MANAGED_STANDBY a;

1.3.1 如何启动LNS进程?

有3种方法:

① alter system switch logfile;

② 推荐: 备库启动实时应用后,主库alter system set log_archive_dest_state_2='defer'; alter system switch logfile; alter system set log_archive_dest_state_2='enable'; alter system switch logfile;

③ 重启备库、主库

1.3.2 LNS进程的后台表现形式

经过小麦苗的研究,日志传输若采用LGWR进程来传输,则在10g dg中是lns的形式,到了11g变为了nsa和nss的形式了,具体可以参考本文实验部分的总结,不管10还是11g我们都可以用命令ps -ef|grep -v grep|grep -E "ora_lns|ora_nsa|ora_nss"来查询后台进程。

[oracle@rhel6_lhr oradgphy]$ ps -ef|grep ora_nsa

oracle 60229 1 0 16:23 ? 00:00:01 ora_nsa2_oradg11g

oracle 60231 1 0 16:23 ? 00:00:01 ora_nsa3_oradg11g

oracle 62421 1 0 16:47 ? 00:00:00 ora_nsa2_oradglg

oracle 62423 1 0 16:47 ? 00:00:00 ora_nsa3_oradglg

oracle 64923 59476 0 17:32 pts/3 00:00:00 grep ora_nsa

oracle@ZT4FLMSDB1:/oracle$ ps -ef|grep -v grep|grep -E "ora_lns|ora_nsa|ora_nss"

oracle 35258592 1 0 08:07:58 - 0:00 ora_nss2_oraFLMS1

NSAn

Redo Transport NSA1 Process

Ships redo from current online redo logs to remote standby destinations configured for ASYNC transport

NSAn can run as multiple processes, where n is 1-9 or A-V.

See Also: Oracle Data Guard Concepts and Administration

NSSn

Redo Transport NSS1 Process

Acts as a slave for LGWR when SYNC transport is configured for a remote standby destination

NSSn can run as multiple processes, where n is 1-9 or A-V.

See Also: Oracle Data Guard Concepts and Administration

NSVn

Data Guard Broker NetSlave Process

Performs broker network communications between databases in a Data Guard environment

NSVn is created when a Data Guard broker configuration is enabled. There can be as many NSVn processes (where n is 0- 9 and A-U) created as there are databases in the Data Guard broker configuration.

由于微信篇幅限制,具体的实验过程可以参考我的itpub(http://blog.itpub.net/26736162/viewspace-2121688/)或博客园(http://www.cnblogs.com/lhrbest/articles/5651970.html)内容。

一.1 实验总结

版本

10g

11g

LGWR ASYNC(异步)

LGWR SYNC(同步)

ARCH

LGWR ASYNC(异步)

LGWR SYNC(同步)

ARCH

后台进程表现(ps -ef|grep -v grep|grep -E "ora_lns|ora_nsa|ora_nss" )

ora_lns1_mydg

ora_lnsb_mydg

ora_arc3_mydg

ora_nsa2_mydg

ora_nss2_mydg

ora_arc3_mydg

视图GV$MANAGED_STANDBY

LNS

LGWR

ARCH

LNS

LGWR

ARCH

切换日志的时候告警日志

出现过一次,LNS: Standby redo logfile selected for thread 1 sequence 13 for destination LOG_ARCHIVE_DEST_2,但再切换的时候就不出现了

LNS: Standby redo logfile selected for thread 1 sequence 98 for destination LOG_ARCHIVE_DEST_2

LNS: Standby redo logfile selected for thread 1 sequence 98 for destination LOG_ARCHIVE_DEST_2

ARC0: Standby redo logfile selected for thread 1 sequence 102 for destination LOG_ARCHIVE_DEST_2

是否默认

是,默认归档同步

是,默认归档异步

第二章 实验中用到的SQL总结

二.1 10g

col group_# format a5

col PROCESS format a8

col CLIENT_PID format a8

set line 9999 pagesize 9999

SELECT a.INST_ID,

a.PROCESS,

a.client_process,

a.client_pid,

a.STATUS,

a.GROUP# group_#,

a.thread#,

a.SEQUENCE#,

a.DELAY_MINS,

a.RESETLOG_ID,

c.SID,

c.SERIAL#,

a.PID spid

FROM gVMANAGED_STANDBY a, gvprocess b, gv

WHERE a.PID = b.SPID

and b.ADDR = c.PADDR

and a.INST_ID = b.INST_ID

and b.INST_ID = c.INST_ID

order by a.INST_ID;

set line 9999

col DEST_NAME format a20

col DESTINATION format a15

col GAP_STATUS format a10

col DB_UNIQUE_NAME format a15

col error format a10

col APPLIED_SCN for 999999999999999

SELECT al.thread#,

ads.dest_id,

ads.DEST_NAME,

(SELECT ads.TYPE || ' ' || ad.TARGET

FROM v$archive_dest AD

WHERE AD.DEST_ID = ADS.DEST_ID) TARGET,

ADS.DATABASE_MODE,

ads.STATUS,

ads.error,

ads.RECOVERY_MODE,

ads.DB_UNIQUE_NAME,

ads.DESTINATION,

(SELECT MAX(sequence#) FROM v$log na WHERE na.thread# = al.thread#) Current_Seq#,

MAX(sequence#) Last_Archived,

max(CASE

WHEN al.APPLIED = 'YES' AND ads.TYPE <> 'LOCAL' THEN

al.sequence#

end) APPLIED_SEQ#

FROM (SELECT *

FROM v$archived_log V

WHERE V.resetlogs_change# =

(SELECT d.RESETLOGS_CHANGE# FROM v$database d)) al,

v$archive_dest_status ads

WHERE al.dest_id(+) = ads.dest_id

AND ads.STATUS != 'INACTIVE'

GROUP BY al.thread#,

ads.dest_id,

ads.DEST_NAME,

ads.STATUS,

ads.error,

ads.TYPE,

ADS.DATABASE_MODE,

ads.RECOVERY_MODE,

ads.DB_UNIQUE_NAME,

ads.DESTINATION

ORDER BY al.thread#, ads.dest_id;

col name for a100

set linesize 9999 pagesize 9999

col NEXT_CHANGE# for 999999999999999

SELECT THREAD#,

NAME,

sequence#,

archived,

applied,

a.NEXT_CHANGE#

FROM v$archived_log a

WHERE a.sequence# >= (select max(b.sequence#)-5 from v$log b where b.THREAD#=a.THREAD# )

AND resetlogs_change# = (SELECT d.RESETLOGS_CHANGE# FROM v$database d)

ORDER BY a.THREAD#,

a.sequence#;

SELECT a.VALUE FROM v$parameter a WHERE a.NAME='log_archive_dest_2';

SELECT a.PROCESS,a.TRANSMIT_MODE FROM V$ARCHIVE_DEST a WHERE a.DEST_NAME='LOG_ARCHIVE_DEST_2';

alter system set log_archive_dest_2='SERVICE=tns_mydgwl db_unique_name=mydgwl valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)' sid='*';

SELECT a.VALUE FROM v$parameter a WHERE a.NAME='log_archive_dest_2';

SELECT a.PROCESS,a.TRANSMIT_MODE FROM V$ARCHIVE_DEST a WHERE a.DEST_NAME='LOG_ARCHIVE_DEST_2';

二.2 11g

col group_# format a5

col PROCESS format a8

col CLIENT_PID format a8

set line 9999 pagesize 9999

SELECT a.INST_ID,

a.PROCESS,

a.client_process,

a.client_pid,

a.STATUS,

a.GROUP# group_#,

a.thread#,

a.SEQUENCE#,

a.DELAY_MINS,

a.RESETLOG_ID,

c.SID,

c.SERIAL#,

a.PID spid,

b.PNAME

FROM gVMANAGED_STANDBY a, gvprocess b, gv

WHERE a.PID = b.SPID

and b.ADDR = c.PADDR

and a.INST_ID = b.INST_ID

and b.INST_ID = c.INST_ID

order by a.INST_ID,b.PNAME;

set line 9999

col DEST_NAME format a20

col DESTINATION format a15

col GAP_STATUS format a10

col DB_UNIQUE_NAME format a15

col error format a10

col APPLIED_SCN for 999999999999999

SELECT al.thread#,

ads.dest_id,

ads.DEST_NAME,

(SELECT ads.TYPE || ' ' || ad.TARGET

FROM v$archive_dest AD

WHERE AD.DEST_ID = ADS.DEST_ID) TARGET,

ADS.DATABASE_MODE,

ads.STATUS,

ads.error,

ads.RECOVERY_MODE,

ads.DB_UNIQUE_NAME,

ads.DESTINATION,

ads.GAP_STATUS,

(SELECT MAX(sequence#) FROM v$log na WHERE na.thread# = al.thread#) Current_Seq#,

MAX(sequence#) Last_Archived,

max(CASE

WHEN al.APPLIED = 'YES' AND ads.TYPE <> 'LOCAL' THEN

al.sequence#

end) APPLIED_SEQ#,

(SELECT ad.applied_scn

FROM v$archive_dest AD

WHERE AD.DEST_ID = ADS.DEST_ID) applied_scn

FROM (SELECT *

FROM v$archived_log V

WHERE V.resetlogs_change# =

(SELECT d.RESETLOGS_CHANGE# FROM v$database d)) al,

v$archive_dest_status ads

WHERE al.dest_id(+) = ads.dest_id

AND ads.STATUS != 'INACTIVE'

GROUP BY al.thread#,

ads.dest_id,

ads.DEST_NAME,

ads.STATUS,

ads.error,

ads.TYPE,

ADS.DATABASE_MODE,

ads.RECOVERY_MODE,

ads.DB_UNIQUE_NAME,

ads.DESTINATION,

ads.GAP_STATUS

ORDER BY al.thread#, ads.dest_id;

------------物理dg日志应用情况(备库查询为准)

col name for a100

set linesize 9999 pagesize 9999

col NEXT_CHANGE# for 999999999999999

SELECT THREAD#,

NAME,

sequence#,

archived,

applied,

a.NEXT_CHANGE#

FROM v$archived_log a

WHERE a.sequence# >= (select max(b.sequence#)-3 from v$log b where b.THREAD#=a.THREAD# )

AND resetlogs_change# = (SELECT d.RESETLOGS_CHANGE# FROM v$database d)

ORDER BY a.THREAD#,

a.sequence#;

----物理备库应用进程日志

--select * from gv$dataguard_status d order by d.inst_id,d.timestamp,d.message_num;

set line 9999 pagesize 9999

col message format a85

SELECT inst_id, severity, FACILITY, TIMESTAMP, MESSAGE

FROM (select d.inst_id,

FACILITY,

SEVERITY,

TIMESTAMP,

MESSAGE,

rank() over(partition by d.inst_id ORDER BY d.message_num desc) rank_order

from gv$dataguard_status d)

where rank_order <= 5

order by inst_id, rank_order desc;

---是否启用实时应用

ps -ef|grep ora_mrp

--通用:select RECOVERY_MODE from v$archive_dest_status;

alter database recover managed standby database using current logfile disconnect from session;

alter database recover managed standby database cancel;

select thread#,low_sequence#,high_sequence# from v$archive_gap;

SELECT a.VALUE FROM v$parameter a WHERE a.NAME='log_archive_dest_2';

SELECT a.PROCESS,a.TRANSMIT_MODE FROM V$ARCHIVE_DEST a WHERE a.DEST_NAME='LOG_ARCHIVE_DEST_2';

alter system set log_archive_dest_2='SERVICE=tns_mydgwl db_unique_name=mydgwl valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)' sid='*';

SELECT a.VALUE FROM v$parameter a WHERE a.NAME='log_archive_dest_2';

SELECT a.PROCESS,a.TRANSMIT_MODE FROM V$ARCHIVE_DEST a WHERE a.DEST_NAME='LOG_ARCHIVE_DEST_2';

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2023-02-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 DB宝 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1.1 DG架构图
  • 1.2 DG日志传输
  • 1.3 进程LNSn:LGWR Network Server process
  • 一.1 实验总结
  • 第二章 实验中用到的SQL总结
    • 二.1 10g
      • 二.2 11g
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档