Re: Switchover of Logical Standby database

From: Gerry Miller <>
Date: Mon, 19 Dec 2011 06:05:25 +1000
Message-ID: <>

Thanks Mathias. I had just stumbled upon this myself and it is the way to go.

I have never found TAF very well documented and remember having to discover for myself the use of startup triggers in a physical standby configuration.

Thanks again


Mathias Zarick wrote:
> Hi Gerry,
> try this in your after role change trigger:
> HTH Mathias
> -----Original Message-----
> From: [] On Behalf Of Gerry Miller
> Sent: Saturday, December 17, 2011 12:08 AM
> Cc:
> Subject: Re: Switchover of Logical Standby database
> Hi Jon
> Thanks for your response.
> The clients connect via tnsnames, which is set up for CTF and TAF. I originally created a physical configuration, which I tested for TAF and when a switchover was performed it worked as I expected: a session that was running a query on the original primary ran to completion on the new primary. I then converted the physical standby to a logical standby, dropping and recreating the data guard broker configuration accordingly and switchover and failover worked.
> In the physical configuration I had TAF configured via tnsnames:
> ORCL =
> (ADDRESS = (PROTOCOL = TCP) (HOST = server1) (PORT = 1521) )
> (ADDRESS = (PROTOCOL = TCP) (HOST = server2) (PORT = 1521) )
> (METHOD=BASIC) ) ) )
> and started the ORCL_PRIMARY service via a database startup trigger. In the logical configuration I added a trigger to stop and start the service on db_role_change. Both of these triggers function as expected.
> The fact that the databases are not restarted on a logical standby switchovermakes me wonder when TAF is supposed to occur. At no time does the client session lose connection, which is the point at which it would be redirected to the primary database service via tnsnames. Even in the case ofa logical standby failover the original primary database is still up and running (albeit as a disabled standby) and connections persist. It seems to me that a restart of at least the logical standby is required to cause TAF.
> This behaviour occurs not only via the application but also from a sqlplus session on the database server, so it is not a client configuration issue.
> Active Dataguard is not an option as we are on 10g.
> Regards
> Gerry
> CRISLER, JON A wrote: Are your clients configured with connect strings (jdbc or tnsnames) where both primary and standby sides are defied? Also is your app TAF compliant? And are you using Active Dataguard ? I suspect more a client configuration issue. I have seen funny behavior like this when older clients are connecting to new databases, or bugs in the client side. This is why one should make sure that the client is upgraded to the same level as thedb. We have numerous configurations on 10g Dataguard, 1 primary and 2 standby, and the sessions re-establish to the correct primary database- however they are not TAF compliant so it requires a restart of the app.
> -----Original Message----- From:[1] [[2]] On Behalf Of Gerry Miller Sent:
> Friday, December 16, 2011 12:24 AM To:[3] Subject:
> Switchover of Logical Standby database Hi I have had some experience with physical standby databases and the Data Guard broker but have recently been asked to implement a logical standby on on Windows 2008 Server. I was quite surprised to find that when a switchover or failover is performed that the databases are not shutdown, which results in a faster operation.
> However, I was perturbed to find that any sessions that were originally on the primary remained on the same database, that is, ended up on the standby database, when I would have expected them to be on the new primary. Queries can still be executed but any attempts at DML result in : "ORA-16224 DatabaseGuard is enabled". This seems an unlikely situation and I can't help but feel that I must have something wrong with the configuration, although I can't imagine that it would work at all if that were the case. Is this the expected behaviour or should the sessions have transferred during the switchover? Regards Gerry --[4]
> --- Links ---
> 1
> 2
> 3
> 4
> --

Received on Sun Dec 18 2011 - 14:05:25 CST

Original text of this message