prod = (description=
(address_list=
(failover=ON)
(load_balance=OFF)
(address=...) <========= points to primary db
(address=...) <========= points to standby db
)
(connect_data=(service_name=prod)
)
)
The "ADDRESS_LIST=" stuff has worked since the 7.2 time-frame, though I
think the "FAILOVER=" and "LOAD_BALANCE=" syntax was added with 8.0; it was
just for failover functionality originally. Of course, the "SERVICE_NAME="
stuff didn't happen until Oracle8i; before that it was "SID=" only...
The key to the FAILOVER=ON functionality working correctly is the death of
the SQL*Net listener at the specified port, not the death of the database.
Make sure that when the database dies, the SQL*Net listener dies too.
Create a "sniper" process that monitors the database instance and
automatically stops the listener if necessary. Or, calls the UNIX "halt"
command... :-) Whatever works...
Otherwise, if the database instance is dead but the SQL*Net listener is
still running, then this TNS syntax will timeout waiting for a connection
rather than just failing over to the next "ADDRESS=" entry...
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, May 17, 2002 10:33 AM
> When we switch between production and standby databases our procedure is
to
> change the DNS Name to point to the new ip address.
> This works perfectly for all our old Powerbuilder client/server apps.
>
> However, our connections that go through Microsoft Transaction Server as a
> middle tier apparently continue to try and connect to the old database
until
> all the services are recycled or the NT boxes are rebooted. This
> unfortunately adds about a half hour to our downtime as well as requiring
> several more people to be present when we're doing the switch.
>
> Microsoft and Oracle are unanimous in saying it's the other one's fault.
> Our developers say there's no way of monitoring what's going on in MTS.
>
> To make matters more difficult we've been unable to replicate the problem
in
> our test environment. We have someone developing a loadrunner script now
in
> the hopes that a much higher load will cause the problem to show up.
There
> are several things (such as TAF) that we'd like to test to see if it helps
> but we can't do that until we can replicate the problem.
>
> So has anyone else seen this behaviour or (even better!) have a proven
> solution for it?
>
> Thanks,
> Jay Miller
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Miller, Jay
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tim Gorman
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
