Re: Primary gets ora-16009 when attempting a heartbeat with standby

Romas, great question.

Looking back at the sequence of events, it does appear that the DNS configuration was such that the primary was trying to ship logs to itself for about 5 minutes after the last switchover. However, after that was corrected, the configuration ran without a hitch until the standby was restarted a few weeks later.

On Mon, Sep 8, 2008 at 8:36 AM, Roman Podshivalov < roman.podshivalov_at_gmail.com> wrote:

> Charles,
>
> Did you do any DNS changes during switchovers ? I suspect some DNS aliases
> got cached and you are trying to ship logs from primary to itself, but as
> usual I could be wrong. NSCD refresh on both servers would be a first thing
> to do....
>
> --romas
>
> On Mon, Sep 8, 2008 at 9:29 AM, Charles Schultz <sacrophyte_at_gmail.com>wrote:
>
>> Good day, list,
>>
>> Curious if anyone had seen anything like this. Working with OSEE 10.2.0.2,
>> Primary and physical Standby are both on Solaris 10. Several months ago we
>> did a switchover twice (switchover to standby site, then switch back to
>> original configuration). A couple weeks ago was the first time we bounced
>> the standby since the switchover event; directly after that, the primary
>> spawned ora-16009 errors:
>> Errors in file /u01/app/oracle/admin/PRODDB/udump/proddb_rfs_19865.trc:
>> ORA-16009: remote archive log destination must be a STANDBY database
>> Mon Sep 8 08:04:35 2008
>> Errors in file /u01/app/oracle/admin/PRODDB/bdump/proddb_arc1_7783.trc:
>> ORA-16009: remote archive log destination must be a STANDBY database
>> Mon Sep 8 08:04:35 2008
>> PING[ARC1]: Heartbeat failed to connect to standby 'PRODSTBY'. Error is
>> 16009.
>>
>>
>> Text from the RFS trace:
>> RFS[1335]: Not using real application clusters
>> ORA-16009: remote archive log destination must be a STANDBY database
>>
>>
>> Interestingly, the ARC trace does not exist.
>>
>> The strange part is that I can change the tns aliast for the standby
>> service and work around the problem; even though both tns aliases point to
>> the same service name, one works and one does not. It seems like the primary
>> has cached one alias and associated an error with it for some reason.
>>
>> I have searched Google and have not found much that is helpful. I have had
>> an SR open with Oracle for over a week, but they have been stumped. Anyone
>> else? At this point, I am extremely curious why that alias causes a problem,
>> and how to prevent this in the future.
>>
>>
>> --
>> Charles Schultz
>>
>
>

-- 
Charles Schultz

--
http://www.freelists.org/webpage/oracle-l