Re: problems with dbshut/dbstart

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.

HTH. Pete

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.
>
> Alex Hudghton wrote:
> >
> > Greg Silverman <gms_at_gms.email.umn.edu> wrote in message
> > news:37E95615.9D032230_at_gms.email.umn.edu...
> > > Help,
> > > We are trying to get a script working to do shutdown/startup for backups
> > > of an 8i db.
> > >
> > > Have tried something like this for the shutdown (similar for startup):
> > >
> > > su - oracle -c "lsnrctl stop" >> /var/log/oracle
> > > rm -f /var/lock/subsys/oracle
> > > su - oracle -c dbshut >> /var/log/oracle
> > >
> > > The listener does stop (start), as seen from /var/log/oracle, but I
> > > cannot get the
> > > dbshut (dbstart) to actually stop the database.
> > >
> > > We do have all instances defined in the oratab file, but I assume that
> > > this file is only looked at if/when the server is rebooted. What is the
> > > proper syntax to get the instance names in the dbshut (dbstart) command
> > > line, or is there some other problem?
> >
> > You may wish to edit your dbshut to do a 'shutdown immediate' instead of
> > shutdown.
> > If there are any processes connected to the database at the time you run the
> > script, the database will not shutdown until they are terminated. 'Shutdown
> > immediate' does this cleanly (with rollback) although it may take a while.
> >
> > dbshut / dbstart uses oratab at all times.
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------
> -------------------------------------------------------------

Received on Thu Sep 23 1999 - 08:29:50 CDT