| RAC to RAC physical standby, why only one node to be applied? [message #677715] |
Tue, 08 October 2019 21:38  |
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  |
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
So, I changed the CHGRPRIM to CHGRA, then the node 1 is doing receive job, node 2 is applying job.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
