Oracle FAQ Your Portal to the Oracle Knowledge Grid

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: <>
Date: Tue, 30 May 2006 17:39:36 -0000
Message-ID: <>

Once upon a time I was considering using split-mirror and TTS(transportable tablespaces) techniques to upgrade database. In theory the downtime for patch.sql is replaced by the downtime to export/import tablespace(s) metadata. And (in my understanding) Oracle supports TTS'es between different Oracle versions.

The whole point is in assuming that Oracle does no changes in datafiles except of marking datafile headers with version number(at least this is what Oracle says)  

-----Original Message-----
From: [] On Behalf Of Khemmanivanh, Somckit Sent: 30. maí 2006 17:13
To: Jeremiah Wilton; Oracle-L Freelists
Subject: RE: Opatch and downtime (was: RE: Metalink and availability)

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)...

-----Original Message-----
From: Jeremiah Wilton [] 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 <> 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

--- Jeremiah Wilton <> wrote:

> The thing that takes the most time with the CPU patches on Unix is
> Opatch patches and relinks one binary at a time serially. Having the
> database down is completely unnecessary for many of these binaries,
> 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
> 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
> time for the CPU patches. Start with the one-off patch apply
> in my paper:
-- -- Fyrirvari/Disclaimer --
Received on Tue May 30 2006 - 12:39:36 CDT

Original text of this message