Re: Microsoft Transaction Server & Standby database problem

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" <ORACLE-L_at_fatcity.com> 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: JayMiller_at_TDWaterhouse.com
>
> 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: ListGuru_at_fatcity.com (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: Tim_at_SageLogix.com

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: ListGuru_at_fatcity.com (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).