Home » Server Options » Data Guard » RAC to RAC physical standby, why only one node to be applied? (Oracle 11gr2 (11.2.0.4), Oracle Linux 6)
RAC to RAC physical standby, why only one node to be applied? [message #677715] Tue, 08 October 2019 21:38 Go to next message
trantuananh24hg
Messages: 744
Registered: January 2007
Location: Ha Noi, Viet Nam
Senior Member
Dear,

I have just configured RAC physical standby to RAC primary. So, when finished to open read only and DISCONNECT FROM SESSION clause to be used, then I found:

- Only node 1 (RAC DG) do applying and receiving
- Node 2 (RAC DG) do nothing.
- Test to switch log file or archive log current in both of 2 primary nodes, but only one node 1 (DG) applied and received.

Take a review
1. In RAC Primary's parameters

-- Log_archive_dest
log_archive_dest_1		     string	  location=+ARC
						  valid_for=(all_logfiles,all_ro
						  les)
						  db_unique_name=chgra

log_archive_dest_2		     string	  service=chargstd lgwr async
						  valid_for=(online_logfiles,pri
						  mary_role)
						  db_unique_name=chgrstd

log_archive_dest_3		     string	  SERVICE=dbchargxml lgwr async
						  noaffirm VALID_FOR=(ONLINE_LOG
						  FILES,PRIMARY_ROLE) DB_UNIQUE_
						  NAME=chgrxml


We have 2 DGs, one is single (dest_2 = chgrstd), and the last is RAC (dest_3 = chgrxml).

2. In RAC physical
-- Log_archive_dest

log_archive_dest_1		     string	location=+ARC valid_for=(all_l
						ogfiles,all_roles) db_unique_n
						ame=chgrxml

log_archive_dest_3		     string	SERVICE=DBCHARGESTD lgwr async
						 noaffirm VALID_FOR=(ONLINE_LO
						GFILES,PRIMARY_ROLE) DB_UNIQUE
						_NAME=chgra

-- MRP in node 1 (which is the node doing both of applying and receiving progression)
ARC0: Beginning to archive thread 1 sequence 201894 (236470516053-236470955751)
ARC0: Completed archiving thread 1 sequence 201894 (0-0)
Media Recovery Log +ARC/chagrxml/archivelog/2019_10_09/thread_1_seq_201894.604.1021195251
Media Recovery Waiting for thread 2 sequence 188957 (in transit)
ARC3: Beginning to archive thread 2 sequence 188957 (236470631714-236470992768)
ARC3: Completed archiving thread 2 sequence 188957 (0-0)
Media Recovery Log +ARC/chgrxml/archivelog/2019_10_09/thread_2_seq_188957.617.1021195269
Media Recovery Waiting for thread 1 sequence 201895 (in transit)

105 rows selected.

-- Press any key to continue

-- Verify background process

PROCESS   STATUS	  THREAD#  SEQUENCE#	 BLOCK#     BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH	  CLOSING		1     201894	 419840       1899
ARCH	  CLOSING		2     188956	 411648       1391
ARCH	  CONNECTED		0	   0	      0 	 0
ARCH	  CLOSING		2     188957	 415744        636
MRP0	  WAIT_FOR_LOG		1     201895	      0 	 0
RFS	  IDLE			0	   0	      0 	 0
RFS	  IDLE			0	   0	      0 	 0
RFS	  IDLE			0	   0	      0 	 0
RFS	  IDLE			1     201895	 248370 	 4
RFS	  IDLE			0	   0	      0 	 0
RFS	  IDLE			0	   0	      0 	 0
RFS	  IDLE			2     188958	 100738 	 3
ARCH	  CONNECTED		0	   0	      0 	 0
ARCH	  CONNECTED		0	   0	      0 	 0
ARCH	  CONNECTED		0	   0	      0 	 0
ARCH	  CONNECTED		0	   0	      0 	 0
RFS	  IDLE			0	   0	      0 	 0

17 rows selected.

-- Press any key to continue

-- Verify the applied log

   THREAD#   LAST_SEQ APPLIED_SEQ LAST_APP_   ARC_DIFF
---------- ---------- ----------- --------- ----------
	 1     201894	   201894 09-OCT-19	     0
	 2     188957	   188956 09-OCT-19	     1


-- MRP in node 2 (which is the node doing nothing)
Primary database is in MAXIMUM PERFORMANCE mode
RFS[1]: Assigned to RFS process 40205
RFS[2]: Assigned to RFS process 40207
ARC3: Beginning to archive thread 2 sequence 188959 (236471400194-236471681321)
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Assigned to RFS process 40209
ARC3: Completed archiving thread 2 sequence 188959 (0-0)
Managed Standby Recovery not using Real Time Apply
ARC0: Archival started
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
ARC3: Archival started
RFS[1]: Assigned to RFS process 57451
ARC3: Beginning to archive thread 1 sequence 201897 (236471390655-236471682436)
ARC3: Completed archiving thread 1 sequence 201897 (0-0)
Attempt to start background Managed Standby Recovery process
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery not using Real Time Apply
Media Recovery Log +ARC/dbchargxml/archivelog/2019_10_09/thread_1_seq_201897.604.1021195579
Media Recovery Log +ARC/dbchargxml/archivelog/2019_10_09/thread_2_seq_188958.598.1021195453
Media Recovery Log +ARC/dbchargxml/archivelog/2019_10_09/thread_2_seq_188959.617.1021195579
Media Recovery Waiting for thread 2 sequence 188960 (in transit)

34 rows selected.

-- Press any key to continue

-- Verify background process

PROCESS   STATUS	  THREAD#  SEQUENCE#	 BLOCK#     BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH	  CONNECTED		0	   0	      0 	 0
ARCH	  CONNECTED		0	   0	      0 	 0
ARCH	  CONNECTED		0	   0	      0 	 0
ARCH	  CLOSING		2     188959	 212992       1086
RFS	  IDLE			0	   0	      0 	 0
RFS	  IDLE			0	   0	      0 	 0
RFS	  IDLE			2     188960	 153316 	 2
RFS	  IDLE			0	   0	      0 	 0
RFS	  IDLE			1     201898	 155347 	 6
ARCH	  CONNECTED		0	   0	      0 	 0
ARCH	  CONNECTED		0	   0	      0 	 0
ARCH	  CONNECTED		0	   0	      0 	 0
ARCH	  CLOSING		1     201897	 385024        173
RFS	  IDLE			0	   0	      0 	 0
MRP0	  WAIT_FOR_LOG		2     188960	      0 	 0

15 rows selected.

-- Press any key to continue

-- Verify the applied log

   THREAD#   LAST_SEQ APPLIED_SEQ LAST_APP_   ARC_DIFF
---------- ---------- ----------- --------- ----------
	 1     201897	   201896 09-OCT-19	     1
	 2     188959	   188959 09-OCT-19	     0

-- tnsname, password files, .. that's right.

All of them do their jobs very well, but I wonder about the Apply/Receive progression in only one node.

[Updated on: Tue, 08 October 2019 21:49]

Report message to a moderator

Re: RAC to RAC physical standby, why only one node to be applied? [message #677716 is a reply to message #677715] Tue, 08 October 2019 21:54 Go to previous message
trantuananh24hg
Messages: 744
Registered: January 2007
Location: Ha Noi, Viet Nam
Senior Member
Update:

I just find the reason.

FAL_ parameters in RAC Primary
fal_server			     string			      CHGRXML,CHGRSTD
fal_client			     string			      CHGRA

FAL_ parameters in RAC DG
fal_client			     string			      CHGRXML
fal_server			     string			      CHRGA

In TNSNAME entries in RAC DG

[CHGRPRIM]
... 

So, I changed the CHGRPRIM to CHGRA, then the node 1 is doing receive job, node 2 is applying job.
Previous Topic: How long can a snapshot standby run
Next Topic: not updating APPLIED column in v$archived_log.
Goto Forum:
  


Current Time: Thu Mar 28 10:50:42 CDT 2024