Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Applying patches - minimizing database down time
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).Received on Thu Feb 08 2001 - 14:25:04 CST