Oarcle patching new oracle_home with running DB

[Former Member]

Hi all!

We are currently looking into upgrading our servers from oracle 10.2.0.4 to oracle 11.2.0.2 (about time!) using the upgrade guide provided by SAP. (on Windows Server 2003/2008 machines)

Doing it the right way, seems to be quite a lenghty process unfortunately, so i'm looking into ways of speeding up the upgrades to persuide our customers to do have it done rather sooner than later.

I was thinking that installing the new Oracle Server software (chapter 4 of the upgrade guide) and patching it before starting the actual DB upgrade, might be a good idea to save some precious upgrade time, since the rest of the manual requires downtime unfortunately.

So far, I've been succesfull in installing the Oracle 11.2.0.2 server software with SAP and Oracle 10.2.0.4 still running. After that, it's time to patch the newly installed Oarcle home, but here's the catch: in order to apply patches using opatch, Opatch requires the environment variable ORACLE_HOME to point to the newly installed oracle_home (11202) and it requires the Oracle 11 services to stop.

So far; I've figured out that opatch can be told to patch a specific home using commandline:

opatch apply <patchid> -oh <patch to oracle home to be patched>

..so that issue would be solved by that. However, the Oracle documentation that comes with the Oracle patches also states that Oracle needs a clean shutdown before patching, including Windows services. Sure, the newly installed Oracle 11 services can be stopped without problems (since the DB hasn't been upgraded, these aren't actually doing anything) but the MS Distributed transaction coordinator is still in use at this point by the old 10.2.0.4 database. So, we won't be able to stop that service.

Will the MSDTC service be in use by the newly installed Oracle home, or will i be able to patch it without stopping the MSDTC service? Is my opatch commandline assumption correct, or will this cause problems? Another option would be to temporarily change the new ORACLE_HOME environment variable using SET in a dosbox, patch the new Ora_home, change it back afterwards, but i have no idea of what the effect would be on the running Oracle DB when doing that.

Any thoughts/ideas on this approach?

[Former Member · Accepted solution]

Thanks both!

i agree, it will not save us that great amount of time, but being able to install Oracle beforhand saves us some precious upgrade time. I did get the fact the system needs to be stopped for the steps following the installation and patching of the new oracle home. But any way to limit downtime/create extra time for troubleshooting an upgrade, if nessesary off course, would be most welcome, right?

Regarding the MSDTC service, will this give us any trouble? Or was my assumption about it right? (not in use for new Oracle home) Just making sure.

[Former Member · Accepted solution]

Hi guys, thanks for the answers so far! I have another question awell.. If i follow the upgrade guide, it tells us to install oracle, patch it with most current patches and then upgrade the DB. However, if i read the readme supplied with the Oracle patches, i see several post installation instructions, i.e. reloading packages in the DB. Since there IS no DB at the time of patching (after all, the DB is upgraded in a later phase), am i right to assume these actions can be skipped entirely? These post installation instructions shouldn't be applied at all, since the DB is already being upgraded with the newly patched Oracle home. is this assumption right? Thanks again and kind regards!

[markus_doehr2 · Accepted solution]

Yes.

Do the steps to install the software/patches only.

Markus

[Former Member · Accepted solution]

Hi Markus,

Thank you very much yet again, you're a lifesaver! Glad i won't be having to perform the follow up activities of the patches.

Regards!

[markus_doehr2]

> Another option would be to temporarily change the new ORACLE_HOME environment variable using SET in a dosbox, patch the new Ora_home, change it back afterwards, but i have no idea of what the effect would be on the running Oracle DB when doing that.

This doesn't do anything because the environment is just valid for this cmd.exe and not for the full system. So this is actually the way to go, you can install and patch and if everything is finished you can run dbua.

Markus

[Former Member]

Installation of Oracle 'software' and 'patching' just the 'software' to a higher patchset etc. is just 20% of the whole Oracle upgrade Procedure, this is what I think. I don't think I could reduce the sap downtime to that much level by doing these workarounds. I would have gone by normal upgrade procedure.

Rest, our other colleagues here will help you.

Thanks