> Names can't handle multiple interface and or
Explain please? Not sure what you mean.
> distinct allocation of certain clients to certain
> listeners/interfaces.
Are you referring to protocol.ora, or something else?
I've never had to setup a very complex sqlnet environment,
so I'm not following what you're referring to.
Jared
Jeremiah Wilton <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/30/2003 08:10 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: RE: Making dispatchers re-read tnsnames.ora?
On Thu, 30 Jan 2003, Gogala, Mladen wrote:
> Yeah! Put it in Oracle*Names.
Will it make a difference? Does a dispatcher really re-query Names
every time it tries to make a connection? No caching of service
addresses? You promise?
Off I go to convert my 300-instance organization to rely on a single
point of failure and make a bunch more calls for every connect...
YEEHAW! Oh wait. Names can't handle multiple interface and or
distinct allocation of certain clients to certain
listeners/interfaces. Oh well, and I thought I was going to have an
exciting weekend. Guess its back to that Rubik's cube.
--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton
> > -----Original Message-----
> > From: Jeremiah Wilton [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, January 30, 2003 7:49 AM
> > To: Multiple recipients of list ORACLE-L
> > Subject: Making dispatchers re-read tnsnames.ora?
> >
> >
> > Dispatchers and job queue processes read tnsnames.ora on process
> > startup in case they need to make an outound database link on behalf
> > of one of he sessions using that dispatcher.
> >
> > If you make a change to the tnsnames.ora, dispatchers and job queue
> > processes won't register it unless you restart them. For job queue
> > processes this is simple (alter syste set job_queue_processes = 0;
> > wait for jobs to complete, then set them back to the orig. value).
> >
> > For dispatchers, you have to "shutdown dispatcher" (alter system
> > shutdown 'Dnnn'). Then, to get it to restart, you have to run "alter
> > system set dispatchers = '<foobar>';" with the COMPLETE dispatcher
> > specification for the parameter index you eliminated the dispatcher
> > from.
> >
> > This is annoyingly complex. When using multiple interfaces, multiple
> > dispatcher parameter indexes and a variety of listener attributes
> > within the dispatcher parameters, it can be difficult to get it right.
> >
> > Also, you have to do the dispatchers ONE AT A TIME so you don't block
> > everyone out while you are waiting for the dispatchers to exit. TIME
> > CONSUMING!
> >
> > Is there a way to make the dispatcher just reread the tnsnames.ora
> > file without all this rigamaroll?
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jeremiah Wilton
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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.net
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
