RE: Requesting a RFS walkthrough
- From: "Goulet, Richard" <Richard.Goulet@xxxxxxxxxxx>
- To: <sacrophyte@xxxxxxxxx>, "ORACLE-L" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 5 Jun 2009 13:20:36 -0400
Check out Metalink Doc ID: 386417.1
Dick Goulet
Senior Oracle DBA
PAREXEL International
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Charles Schultz
Sent: Friday, June 05, 2009 12:57 PM
To: ORACLE-L
Subject: Requesting a RFS walkthrough
Good day, list,
I am curious if someone would be able to divulge some of the under
pinnings of RFS. The snippet below is from our alert.log on the standby;
this is one of two 10.2.0.2 physical standby databases with no DB Broker
using real-time apply, and we have been seeing this situation happen
more and more often. Our networking group tells us there are no issues
with the infrastructure, so I am struggling to understand why this
happening.
My basic understanding of RFS explains the situation like so:
* At 10:45:02, the heartbeat process attempts to talk to Primary
but is unable to. I assume there are two similar messages because we
have two FAL_SERVERS, but I could be way off in that.
* The next few verbose messages show a connection being
reestablished with the primary.
* At 10:45:20, FAL attempts to get logseq 6045. Why does it fail?
The log was archived on the Primary at 10:45:15
(v$archived_log.completion_time).
* It fails again at 10:45:55, but succeeds at 10:45:56. Why?
Fri Jun 5 10:45:02 2009
RFS[143]: Possible network disconnect with primary database
Fri Jun 5 10:45:05 2009
RFS[144]: Possible network disconnect with primary database
Fri Jun 5 10:45:15 2009
RFS[142]: Successfully opened standby log 22:
'+DATA/gcprod/onlinelog/group_22.352.633713051'
Fri Jun 5 10:45:15 2009
RFS[139]: Successfully opened standby log 25:
'+DATA/gcprod/onlinelog/group_25.262.633713253'
Fri Jun 5 10:45:16 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[147]: Assigned to RFS process 18916
RFS[147]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
Fri Jun 5 10:45:16 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[148]: Assigned to RFS process 18918
RFS[148]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Fri Jun 5 10:45:16 2009
RFS[147]: Successfully opened standby log 21:
'+DATA/gcprod/onlinelog/group_21.351.633713041'
Fri Jun 5 10:45:16 2009
Primary database is in MAXIMUM PERFORMANCE mode
RFS[148]: Successfully opened standby log 24:
'+DATA/gcprod/onlinelog/group_24.282.633713233'
Fri Jun 5 10:45:20 2009
Fetching gap sequence in thread 1, gap sequence 6045-6045
FAL[client]: Error fetching gap sequence, no FAL server specified
Fri Jun 5 10:45:55 2009
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 6045-6045
DBID 1222165961 branch 631792716
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.
-------------------------------------------------------------
Fri Jun 5 10:45:56 2009
RFS[145]: Archived Log: '+FRA/gcprod/archivelog/1_6045_631792716.dbf'
Fri Jun 5 10:46:30 2009
Media Recovery Log +FRA/gcprod/archivelog/1_6045_631792716.dbf
--
Charles Schultz
Other related posts:
