Re: problems with dbshut/dbstart

In the Client's tnsnames.ora file, you can add ( SERVER=Dedicated ) or
(SERVER=SHAREd)

to request either a Dedicated or shared Connection...By default, it requests a dedicated Connection..

You can have multiple Connect Stings like

Prod_Shared =
or
Prod_Dedicated =

in the Same client machine which runs multiple applications (say a Content Load job and a OLTP application) to facilitate specific connections..But the Server's Tnsnames.ora file should have (SERVER=SHARED) to server Shared Requests..

-Thiru

Kenneth C Stahl wrote:

> 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.
> > >
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> ------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -----------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -----------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -----------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -----------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -----------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -----------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -----------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -----------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
Received on Thu Sep 23 1999 - 11:54:28 CDT