| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: problems with dbshut/dbstart
That is the first I've ever heard that there is a special setting in
tnsnames.ora which determines whether a dedicated or shared server. What is
the setting?
Pete Sharman wrote:
>
> Kenneth
>
> If you look at when the listener is actually used, you'll have a better
> understanding of what is important in the ordering. When a user connects, they
> contact the listener and are passed to a server process in some way (there are a
> couple of ways this is done, but I won't go into those now). As soon as the
> connection between the client and server process is made, the listener is no
> longer involved. This means that the listener can be shut down with no effect on
> active users, just new users who are trying to connect.
>
> In some ways, you can put together an argument that you should stop the listener
> before the database so the database has less work to do when shutting down (less
> connections to roll back).
>
> On startup, the dispatchers are started as background processes when the database
> starts, so starting the listener first should have no effect on the timing of
> connections being dedicated or not. Also, it's the tnsnames alias that determines
> whether shared servers are used or not, so it's really up to the users to connect
> using MTS rather than dedicated servers. Of course, if they don't know the way we
> use the tnsnames file, then they'll simply connect as you tell them to anyway, so
> that won't be so much of a problem.
>
> Kenneth C Stahl wrote:
>
> > This brings up another question. In my /etc/rc2.d/K99oracle script I always
> > do the dbshut first (the dbshut has been edited to do SHUTDOWN IMMEDIATE)
> > and then take the listener down. Is there any good reason for having any
> > specific order to which is shut down first. I guess I always figured that
> > if there were active connections then I couldn't shut the listener down, so
> > by shutting down the instance first (with SHUTDOWN IMMEDIATE), I am sure
> > that there are no connections and then the listener will come down without
> > complaints. On the way up, then, I start the listener first and then the
> > database - I primarly do this because I have client apps which are always
> > trying to acquire a connection and since I use MTS I want to make sure that
> > the dispatchers are ready and waiting when the database comes up because
> > otherwise the clients will acquire a direct connection and that is
> > undesireable.
> >
 |
 |