Re: Switchover of Logical Standby database
- From: Gerry Miller <gerry@xxxxxxxxxxxxxxxxxxx>
- To: "CRISLER, JON A" <JC1706@xxxxxxx>
- Date: Sat, 17 Dec 2011 09:07:33 +1000
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 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (HOST = server1) (PORT = 1521) )
(ADDRESS = (PROTOCOL = TCP) (HOST = server2) (PORT = 1521) )
(CONNECT_DATA = (SERVICE_NAME=ORCL_PRIMARY)
(FAILOVER_MODE= (TYPE=SELECT) (RETRIES=1000) (DELAY=60)
(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: 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 10.2.0.4 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 -- //www.freelists.org/webpage/oracle-l[4]
--- Links ---
1 mailto:oracle-l-bounce@xxxxxxxxxxxxx
2 mailto:oracle-l-bounce@xxxxxxxxxxxxx
3 mailto:oracle-l@xxxxxxxxxxxxx
4 //www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
