Had same problem on 9.0.1.3.
Ended up being that you had to specify a
LOCAL_LISTENER parameter even though it defaults to a
reasonable value. The value must be one that is
resolvable by all parties (clients and servers)via
/etc/hosts or DNS. This is due to the manner in which
redirects are done.
Bill
- Jack van Zanen <nlzanen1_at_EY.NL> wrote:
> Hi All,
>
>
>
> I have a question regarding setup of above.
>
> We have the above database setup working except for
> connecting from the
> clientfails every now and then.
>
> We have load balancing turned on on the client so
> that it alternates
> connection between the two servers.
> We think we have load balancing turned on on the
> servers (but documentation
> is somewhat confusing on the proper setup)
>
> If we connect from the client it sometimes succeeds
> and sometimes fails
> with different messages on diefferent clients(but
> always the same message
> on the same client)
>
> - No listener
> or
> - No connect_data received
>
> the succesfull connections are not just to one
> instance but both instances
> have succesfull logons.
>
> If we specify one server in the tnsnames.ora (no
> load balancing) and use
> the service_name i.s.o sid it show the same
> succesfull/unsuccesfull logon
> behaviour.
> if we then shut down the remote listener and
> instance all connections go
> fine
>
> This all looks like the load balancing on the server
> seems to be not
> working correctly
>
> Does anybody have experience with setting this up
> correctly, have good
> clear documents about it or know any gotcha's that
> might help solve
> this......
>
>
> Any help appreciated
>
>
> This is for testing purpose only and we do not pay
> support for RAC (yet,
> you never know if we can turn the sql*server march
> around) so Creating a
> TAR may be difficult
>
>
> TIA
>
>
> Jack
>
>
> De informatie verzonden in dit e-mailbericht is
> vertrouwelijk en is
> uitsluitend bestemd voor de geadresseerde.
> Openbaarmaking,
> vermenigvuldiging, verspreiding en/of verstrekking
> van deze informatie aan
> derden is, behoudens voorafgaande schriftelijke
> toestemming van Ernst &
> Young, niet toegestaan. Ernst & Young staat niet in
> voor de juiste en
> volledige overbrenging van de inhoud van een
> verzonden e-mailbericht, noch
> voor tijdige ontvangst daarvan. Ernst & Young kan
> niet garanderen dat een
> verzonden e-mailbericht vrij is van virussen, noch
> dat e-mailberichten
> worden overgebracht zonder inbreuk of tussenkomst
> van onbevoegde derden.
>
> Indien bovenstaand e-mailbericht niet aan u is
> gericht, verzoeken wij u
> vriendelijk doch dringend het e-mailbericht te
> retourneren aan de verzender
> en het origineel en eventuele kopieën te verwijderen
> en te vernietigen.
>
> Ernst & Young hanteert bij de uitoefening van haar
> werkzaamheden algemene
> voorwaarden, waarin een beperking van
> aansprakelijkheid is opgenomen. De
> algemene voorwaarden worden u op verzoek kosteloos
> toegezonden.
>
> The information contained in this communication is
> confidential and is
> intended solely for the use of the individual or
> entity to whom it is
> addressed. You should not copy, disclose or
> distribute this communication
> without the authority of Ernst & Young. Ernst &
> Young is neither liable for
> the proper and complete transmission of the
> information contained in this
> communication nor for any delay in its receipt.
> Ernst & Young does not
> guarantee that the integrity of this communication
> has been maintained nor
> that the communication is free of viruses,
> interceptions or interference.
>
> If you are not the intended recipient of this
> communication please return
> the communication to the sender and delete and
> destroy all copies.
>
> In carrying out its engagements, Ernst & Young
> applies general terms and
> conditions, which contain a clause that limits its
> liability. A copy of
> these terms and conditions is available on request
> free of charge.
>
>
>
>
>
>
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> --
> Author: Jack van Zanen
> INET: nlzanen1_at_EY.NL
>
> 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).
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Bill Pass
INET: wbpass_at_yahoo.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).
Received on Tue Jul 09 2002 - 10:28:27 CDT
