RE: Opatch and downtime (was: RE: Metalink and availability)
- To: <jeremiah@xxxxxxxxxxx>, <mvetmp-ora@xxxxxxxxx>, "Oracle-L Freelists" <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 30 May 2006 09:07:40 -0700
Would you still have to take down time in order to run post patch sql
scripts? Or is there around that as well?
Thanks!
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jeremiah Wilton
Sent: Tuesday, May 30, 2006 9:02 AM
To: mvetmp-ora@xxxxxxxxx; 'Oracle-L Freelists'
Subject: Opatch and downtime (was: RE: Metalink and availability)
Vitaliy <mvetmp-ora@xxxxxxxxx> 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
http://www.ora-600.net
--- Jeremiah Wilton <jeremiah@xxxxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
