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@xxxxxxxxx> 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@xxxxxxxxx>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