Re: Primary gets ora-16009 when attempting a heartbeat with standby
- From: "David Barbour" <david.barbour1@xxxxxxxxx>
- To: sacrophyte@xxxxxxxxx
- Date: Mon, 8 Sep 2008 11:57:24 -0400
Any errors in your standby alert log? With your tnsnames.ora file in it's
original configuration, what does tnsping show you from both the primary
server and the standby server? I don't think your problem is with the
shared files. You might want to check your listener.
On Mon, Sep 8, 2008 at 10:38 AM, Charles Schultz <sacrophyte@xxxxxxxxx>wrote:
> *grin* I have provided all that to Oracle Support already. It is a rather
> bizarre situation. To answer your question about TNS_ADMIN, I have to say
> "sorta"; we have a central directory in which all Oracle Homes on a host
> link to. For example, /u01/app/oracle/product/10.2.0.2/network/admin would
> have file pointers to individual files (tnsnames.ora, ldap.ora, sqlnet.ora,
> etc) in /u01/app/oracle/tnsAdmin. Think that makes a difference in this
> situation?
>
>
> On Mon, Sep 8, 2008 at 9:30 AM, Roman Podshivalov <
> roman.podshivalov@xxxxxxxxx> wrote:
>
>> Hmmm,
>>
>> In this case to research such situation more information is required about
>> configuration like: init.ora files, tnsnames.ora/sqlnet.ora files and
>> current dns resolutions from both sides, outputs from v$dataguard_* views
>> would be handy as well.
>>
>> PS: are you using custom TNS_ADMIN location ?
>>
>> --romas
>>
>> On Mon, Sep 8, 2008 at 9:39 AM, Charles Schultz <sacrophyte@xxxxxxxxx>wrote:
>>
>>> 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.
>>>
>>>
>>>
>>>
>>
>
>
> --
> Charles Schultz
>
Other related posts:
