Re: sqlplus shutdown "time-out"

  • From: Vitalis <vitalisman@xxxxxxxxx>
  • To: jungwolf <spatenau@xxxxxxxxx>
  • Date: Wed, 20 Apr 2005 18:18:40 +0200

Hi Steven!

Comments in-lined:

On 4/20/05, jungwolf <spatenau@xxxxxxxxx> wrote:
> On 4/20/05, Vitalis <vitalisman@xxxxxxxxx> wrote:
> > Regarding my original script (used with 9i instances on Unix):
> > shutdown immediate
> > startup
> > shutdown immediate
> > startup mount
> ...
> > instance has crashed. I wrote this first shutdown so that it would
> > completely close a "half-crashed" instance. Then hopefully the startup
> > would proceed without any problem.
> > Of course this approach is not suitable for production databases
> > (offline backups should be avoided on production databases in the
> > first place!)
> >
> > Question: Is this "half-crashed" instance scenario plausible (with
> > regard of PMON, SMON...)?
>=20
> Sure, I've seen database processes hanging around after a crash.  You
> might even be able to "connect", but as soon as you try anything it
> shuts the connection.  Unfortunately, I've also noticed that a
> "shutdown immediate" usually hangs when the database is in this state.

Thanks for this piece of information.

>=20
> Since this is not production, how about the venerable "shutdown abort;
> startup; shutdown immediate" process?

Maybe that's a sequence that would work in all situations (crash/no
crash). But like Jay I don't feel comfortable doing this (why use
"abort" and force a recovery everytime while we could use "immediate"
in most cases?)
The best (but longer) solution might be to code a script capable of
testing the instance status and launch the proper command
accordingly...

>=20
> Steven
>=20
> p.s.
> As a side note, why do you say offline backups should be avoided on
> PROD DBs?  If the downtime window is available, I don't see the
> problem (although just because one can doesn't mean one should).
> Certain business requirements might even mandate a cold backup
> (archival reasons, copies of DB to satellite offices for research,
> etc).

I agree. My sentence should have read: *regular automated scheduled*
offline backups should be avoided on production databases (the
day-to-day backup policy should not be made of cold backups.) The main
reason (apart from the obvious instance unavailability) is that the
backup might fail due to something going awry during the shutdown (for
example, a shutdown time-out =3D)
Of course I don't have anything against exceptional manual offline
backups of production databases.

Regards,
Jerome
--
//www.freelists.org/webpage/oracle-l

Other related posts: