RE: Switchover of Logical Standby database

  • From: Mathias Zarick <Mathias.Zarick@xxxxxxxxxxxx>
  • To: "gerry@xxxxxxxxxxxxxxxxxxx" <gerry@xxxxxxxxxxxxxxxxxxx>
  • Date: Sun, 18 Dec 2011 09:28:37 +0000

Hi Gerry,

try this in your after role change trigger:

HTH Mathias

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Gerry Miller
Sent: Saturday, December 17, 2011 12:08 AM
Cc: oracle-l@xxxxxxxxxxxxx
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 

In the physical configuration I had TAF configured via tnsnames:
    (ADDRESS =  (PROTOCOL = TCP)  (HOST = server1)  (PORT = 1521) )
    (ADDRESS =  (PROTOCOL = TCP)  (HOST = server2)  (PORT = 1521) )
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.



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: oracle-l-bounce@xxxxxxxxxxxxx[1] 
[mailto:oracle-l-bounce@xxxxxxxxxxxxx[2]] On Behalf Of Gerry Miller Sent:
Friday, December 16, 2011 12:24 AM To: oracle-l@xxxxxxxxxxxxx[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 mailto:oracle-l-bounce@xxxxxxxxxxxxx
   2 mailto:oracle-l-bounce@xxxxxxxxxxxxx
   3 mailto:oracle-l@xxxxxxxxxxxxx


Other related posts: