Re: Applying patches - minimizing database down time

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 ----- To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Sent: Thursday, February 08, 2001 4:15 PM

> Do you have a test instance to apply the patches to? Check the release
> notes, and see if any DDL is included in the patch. If none of the
database
> objects change, then you do not need to run the rdbms scripts. Also, I
have
> heard that you cannot copy oracle homes any more with the new "Universal"
> installer. You have to reinstall the base software to the new directory.
> It keeps track of the directory it is installed in and will not run out of
a
> new directory.
>
> > -----Original Message-----
> > From: Steve Orr [SMTP:sorr_at_arzoo.com]
> > Sent: Thursday, February 08, 2001 2:45 PM
> > To: Multiple recipients of list ORACLE-L
> > Subject: RE: Applying patches - minimizing database down time
> >
> > Yeah, I like the theory but putting the theory into practice is another
> > story. Maybe I'll try it another day. I thought Oracle supported 24X7
> > Internet ecommerce. Well I guess it does if you never need to upgrade,
as
> > if
> > that were a realistic option. Or if you want to work 80+ hours to reduce
> > database down time from 1 hour to 5 minutes.
> >
> > "Patches? We don't need no stinkin' patches!" L.E.
> >
> > Returning to Dog Patch,
> > Lil' Abner
> >
> >
> > -----Original Message-----
> > Patrick
> > Sent: Thursday, February 08, 2001 12:21 PM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> >
> > You might consider cloning your database, and then using logminer to
> > extract
> > the changes to the production database that occur during the upgrade to
> > the
> > cloned database. The sql extracted from the logs using logminer can
then
> > be
> > run against the upgraded clone after shutting down production and before
> > letting the users loose on the database. Of course you will want to do
> > this
> > at a time of low update/delete activity to minimize the time that it
will
> > take to execute the sql on the upgraded clone.
> >
> > I have not actually done this, but in theory it should work. Look into
> > the
> > documentation for logminer.
> >
> > > -----Original Message-----
> > > From: Molina, Gerardo [SMTP:Gerardo.Molina_at_schwab.com]
> > > Sent: Thursday, February 08, 2001 12:56 PM
> > > To: Multiple recipients of list ORACLE-L
> > > Subject: RE: Applying patches - minimizing database down time
> > >
> > > (Not a sales pitch)
> > >
> > > Talk to your Quest rep about a product they are working on or is
already
> > > available which will allow you to do upgrades/patches with no or
minimal
> > > downtime. It involves a kind of replication. The way I see it is you
> > > must
> > > have some kind of replication if you want to make upgrades or patches
> > > truly
> > > transparent (ie. no or minimal downtime). I would not make a database
> > to
> > > the users will running catalog, catproc, etc.
> > >
> > > HTH
> > > Gerardo
> > >
> > > -----Original Message-----
> > > Sent: Thursday, February 08, 2001 10:23 AM
> > > To: Multiple recipients of list ORACLE-L
> > >
> > >
> > > 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).
> > > --
> > > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > > --
> > > Author: Molina, Gerardo
> > > INET: Gerardo.Molina_at_schwab.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).
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Elliott, Patrick
> > INET: Patrick.Elliott_at_bestbuy.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).
> >
> > --
> > 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).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Elliott, Patrick
> INET: Patrick.Elliott_at_bestbuy.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).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Dan Mills
  INET: mills.dan_at_home.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).