Oracle FAQ Your Portal to the Oracle Knowledge Grid

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

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

From: Jeremiah Wilton <>
Date: Tue, 30 May 2006 09:02:13 -0700
Message-ID: <058c01c68402$6b12e800$0301a8c0@flbp7000a>

Vitaliy <> wrote
> I had a concern about patching ORACLE_HOME while the instance is running
> (as described in your article by modifying patch scripts and oracle make-
> files). I think that replacing shared libraries that oracle binaries
> depend on might cause some side-effects on the running instance(s).

I agree, and the solution is to treat shared libraries like binaries. The targets in the makefiles for shared libraries can be modified in a way similar to the binaries, and you can follow the same procedure of swapping them out during a brief downtime.

> It's also not supported as the patch clearly states that all processes
> must be down.

Oracle BDE and support have always supported me in this procedure when I explained it to them. Sometimes Oracle will work with you to support tactics that provide higher availability, even when those tactics don't follow the exact procedure Oracle has proscribed.

> Instead, I would suggest to pre-stage a copy of patched ORACLE_HOME that
> was built on a different server, shutdown all running instances and
> quickly switch ORACLE_HOMEs then apply DB portion of the upgrade (if any).

This is also a fine method. My problem with it has always been that one-off patches are often less than a few Mb in size. My method is very efficient and requires a lot less prep time on the part of the DBA. Copying around your 2Gb master ORACLE_HOME is pretty inefficient and time-consuming in comparison. However, as you point out, your method leaves you in a state that requires very little explanation to support.

Jeremiah Wilton
ORA-600 Consulting

--- Jeremiah Wilton <> 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:
Received on Tue May 30 2006 - 11:02:13 CDT

Original text of this message