RE: Applying patches - minimizing database down time

Look again at step 5. The sequence is:

alter system checkpoint;
shutdown abort;
startup;
shutdown immediate;

The theory is that the checkpoint may take awhile but the database is still available. Then the shutdown abort - startup - shutdown immediate sequence get's us to a consistent state as required by the Oracle patch instructions.

Comments?

-----Original Message-----
Sent: Friday, February 09, 2001 2:11 PM
To: Multiple recipients of list ORACLE-L

• Original Message ----- To: <ORACLE-L_at_fatcity.com> Sent: Thursday, February 08, 2001 8:52 PM

> Steve,
>
> Seems like a fast, secure procedure. One question though,
>
> Why would you issue the 'shutdown abort' in step 5 ? You never quite know
> how long instance recovery will take.
>
> Someone mentioned replication. It seems that a standby db might be worth
> taking a look at. A lot of work building, cutting over, and rebuilding,
but
> may result in minimum downtime.
>
> dgm
>
> ----- Original Message -----
> > > > Attention all installation gurus/hacks...
> > > >
> > > > I'm looking for suggestions, experiences, and best practices on
safely
> > > > applying Oracle patches and minimizing database down time. By way of
> > > > example let's say we're going from server version 8.1.6.0.0 to
8.1.6.3.0.
> Let's
> > > > also
> > > > say we're going to apply the 8.1.6.3.0 interMedia patchset. Here are
> > > some
> > > > generalized steps:
> > > >
> > > > 1) Uncompress/untar the patchsets to a staging area.
> > > > 2) Whilst the database is up, run the installer to install all the
> > > > requisite
> > > > software to a new $ORACLE_HOME.
> > > > old $ORACLE_HOME = /u01/app/oracle/product/8.1.6
> > > > new $ORACLE_HOME = /u01/app/oracle/product/8.1.6.3.0
> > > > export ORACLE_HOME=/u01/app/oracle/product/8.1.6.3.0
> > > > /u01/app/oracle/product/8.1.6/bin/runInstaller
> > > > 3) Whilst the database is up, copy interMedia executables and
> libraries
> > > to
> > > > the appropriate sub-directores of the new $ORACLE_HOME.
> > > > 4) Whilst the database is up, run the installer to install the new
> > > patches
> > > > pointing it to the staging area in step 1.
> > > > 5) Shut everything down. Shutdown Oracle dependent processes like
> > > ctxsrv.
> > > > Shutdown the listener. Shutdown the database:
> > > > alter system checkpoint;
> > > > shutdown abort;
> > > > startup;
> > > > shutdown immediate;
> > > > Do not make any cold backups. Depend on RMAN backups for recovery
> > > > should
> > > > anything go awry.
> > > > 6) Relink oracle.
> > > > make -f ins_rdbms.mk ioracle
> > > > 7) Change the PATH and oratab to reflect the new $ORACLE_HOME.
> > > > 8) Startup the database, listener, and ctxsrv to make the
application
> > > > available.
> > > > 9) With everything up, run the SQL scripts to complete the patch:
> > > > @catalog.sql
> > > > @catproc.sql
> > > > @catrep.sql
> > > > create or replace java system;
> > > > -- interMedia stuff
> > > > @dr0pkh.sql
> > > > @dr0plb.sql
> > > > @dr0type.plb
> > > > 10) scan/recompile invalid objects.
> > > >
> > > > HERE'S THE PIVOTAL ISSUE...
> > > > Depending on resources step 9 could take about two hours. What are
the
> > > > effects of executing this while the application is running? Comments
> and
> > > > suggestions?
> > > >
> > > > TIA,
> > > > Steve Orr

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Steve Orr
  INET: sorr_at_arzoo.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (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).