Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Opatch and downtime (was: RE: Metalink and availability)

RE: Opatch and downtime (was: RE: Metalink and availability)

From: Khemmanivanh, Somckit <somckit.khemmanivanh_at_weyerhaeuser.com>
Date: Tue, 30 May 2006 10:13:17 -0700
Message-ID: <65C0D8935651CB4D96E97CEFAC5A12B9022F132B@wafedixm10.corp.weyer.pri>

Thanks Jeremiah.

I had also seen your DBA Disaster Diary presentation and read your guide about pre-building the Oracle executables...but I couldn't figure out how to pre-run the SQL scripts...

I was trying to make the whole patching process as efficient as possible (but some SQL scripts will take awhile to run)...

Thanks!
-----Original Message-----
From: Jeremiah Wilton [mailto:jeremiah_at_ora-600.net] Sent: Tuesday, May 30, 2006 10:05 AM
To: Khemmanivanh, Somckit; 'Oracle-L Freelists' Subject: RE: Opatch and downtime (was: RE: Metalink and availability)

Khemmanivanh, Somckit <somckit.khemmanivanh_at_weyerhaeuser.com> wrote:

> Would you still have to take down time in order to run post patch sql
> scripts? Or is there around that as well?

I guess it depends on the content of the SQL. I can't think of a way that
you could safely run changes to DBA views, packages and procedures that are
being frequently run and loaded into the library cache, or which are dependencies of such objects. However, if a patch's post-sql consists of a
single change to a view that nothing you are running is dependent on, it is
probably OK to do it, since large numbers of cursors and objects will not
get invalidated.

I guess my advice is to look at the SQL, and if you are NOT 100% certain that running that SQL will not impact the running service, then run it in
restrict mode as directed.

--
Jeremiah Wilton
ORA-600 Consulting
http://www.ora-600.net

--- Jeremiah Wilton <jeremiah_at_ora-600.net> wrote:

> The thing that takes the most time with the CPU patches on Unix is
that
> Opatch patches and relinks one binary at a time serially. Having the
> database down is completely unnecessary for many of these binaries,
such
> as sqlplus etc. Furthermore, even running binaries like oracle and
> tnslsnr can be relinked with the databases open and running, and
staged as
> alternately named files (oracle-new, tnslsnr-new). You can then move
them
> all into place during a very brief outage for all instances.
>
> There are a number of tricks that you can use to greatly reduce the
apply
> time for the CPU patches. Start with the one-off patch apply
guidelines
> in my paper:
>
> http://www.ora-600.net/articles/stayinalive.pdf
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l
Received on Tue May 30 2006 - 12:13:17 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US