RFS porcess is stopped
Dear All,
Till yesterday my physical dr was in sync and all of sudden this morning i have found 1000 archive gap between my primary and standby.
I have applied incremental backup ,i have also replaced old standby controlfile with latest one and tried to put the standby database in recovery mode , but the RFS process is not starting.
Following are the required details for the same ..
SQL> select banner from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for 32-bit Windows: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL> select process,status from v$managed_standby;
PROCESS STATUS
--------- ------------
ARCH CONNECTED
ARCH CONNECTED
MRP0 WAIT_FOR_GAP
SQL> select message from v$dataguard_Status;
MESSAGE
--------------------------------------------------------------------------------
ARC0: Archival started
ARC1: Archival started
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
ARC1: Becoming the heartbeat ARCH
Managed Standby Recovery not using Real Time Apply
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 Waiting for thread 1 sequence 461642
Fetching gap sequence in thread 1, gap sequence 461642-461679
MESSAGE
--------------------------------------------------------------------------------
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 461642-461679
DBID 2578507424 branch 709654561
FAL[client]: All defined FAL servers have been attempted.
Alter log :-
Completed: alter database recover managed standby database disconnect from session
Wed May 04 13:18:18 2011
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 461642-461679
DBID 2578507424 branch 709654561
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------
Wed May 04 13:28:52 2011
db_recovery_file_dest_size of 2048 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
mrpo Process:-
Redo shipping client performing standby login
*** 2011-05-04 13:16:44.162 66535 kcrr.c
Logged on to standby successfully
Client logon and security negotiation successful!
*** 2011-05-04 13:17:15.486
Redo shipping client performing standby login
*** 2011-05-04 13:17:15.549 66535 kcrr.c
Logged on to standby successfully
Client logon and security negotiation successful!
*** 2011-05-04 13:17:46.905
Redo shipping client performing standby login
*** 2011-05-04 13:17:46.967 66535 kcrr.c
Logged on to standby successfully
Client logon and security negotiation successful!
*** 2011-05-04 13:18:18.245
-----------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-----------------------------------------------------------
udump trace output:
*** 2011-05-04 13:14:11.672
*** ACTION NAME:() 2011-05-04 13:14:11.500
*** MODULE NAME:(sqlplus.exe) 2011-05-04 13:14:11.500
*** SERVICE NAME:() 2011-05-04 13:14:11.500
*** SESSION ID:(873.1) 2011-05-04 13:14:11.500
tkcrrsarc: (WARN) Failed to find ARCH for message (message:0x4)
tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message:0x4)
*** 2011-05-04 13:14:23.574
*** 2011-05-04 13:14:23.574 62692 kcrr.c
Managed Standby Recovery not using Real Time Apply
Recovery target incarnation = 2, activation ID = 0
Influx buffer limit = 80419 (50% x 160839)
Successfully allocated 3 recovery slaves
Using 364 overflow buffers per recovery slave
Start recovery at thread 1 ckpt scn 4075771372 logseq 461642 block 35812
*** 2011-05-04 13:14:29.939
Media Recovery add redo thread 1
*** 2011-05-04 13:14:35.618
Media Recovery drop redo thread 1
*** 2011-05-04 13:15:04.212
*** 2011-05-04 13:15:04.212 2289 krsm.c
Managed Recovery: THROUGH NEXT SWITCHOVER posted.
*** 2011-05-04 13:15:04.228 1118 krsm.c
Managed Recovery: DISCONNECT posted.
*** 2011-05-04 13:15:04.228 1118 krsm.c
Managed Recovery: Startup posted.