RE: Opatch and downtime (was: RE: Metalink and availability)
- From: "Khemmanivanh, Somckit" <somckit.khemmanivanh@xxxxxxxxxxxxxxxx>
- To: "Jeremiah Wilton" <jeremiah@xxxxxxxxxxx>, "Oracle-L Freelists" <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 30 May 2006 10:13:17 -0700
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@xxxxxxxxxxx]
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@xxxxxxxxxxxxxxxx> 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@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:
