Installing a new Oracle Home on a Windows server with an existing one can affect applications and users of the resident databases. Ideally, this could be done before an outage window to reduce the impact on the business.
There are also complications to be aware of when removing old homes.
This page is specifically about installing a new Oracle Home, (eg to move from 126.96.36.199 to 188.8.131.52.21), rather than applying a bundle to an existing Oracle Home.
I recommend a few extra precautions after the usual checks for space, etc.
Check the registry and environment variables for:
- TNS_ADMIN. If TNS_ADMIN is not used, then copy TNSNAMES.ORA and SQLNET.ORA from the current Oracle Home to the new %ORACLE_HOME%/network/admin .
- SQLPATH. Safer to unset for the installation session and check it doesn’t point to the Oracle Home that will be removed later.
- ORACLE_HOME. If set, this may have to be unset at the system level (although I had success changing it for only the installation session). Refer to MOS 1630653.1. Some applications rely on this to be set at a system level, so an outage may be required before installing the new Oracle Home.
- Initialisation parameter file locations for each database
Record the PATH environment variable. Get this from Computer Properties – Advanced System Settings, not from the command prompt, to preserve variables used in the PATH. When the new Oracle Home is installed, the PATH variable will automatically be updated to have the new Oracle Home at the front. This could affect any processes that use the first Oracle binaries and DLLs in the PATH, (eg SQL*Plus or the Windows Management Instrumentation service), before we are ready to switch over in a controlled manner. If you want to proceed before an outage, then be prepared to restore the PATH to the original value after it has been changed by the installer.
If there are links to init.ora or spfiles, then these may need to be managed if using DBUA
Determine the relevant listener’s Oracle Home and the location of the listener.ora file.
Use Sysinternals Process Explorer to see which non-Oracle processes are using Oracle DLLs, and confirm which Oracle Homes are used. (Eg, search for oci.dll and then for each Oracle Home). They should be using the first Oracle Home in the PATH variable.
Check if the OracleMTSRecoveryService is running. During the installation of a new Oracle RDBMS Home, this service will be stopped and replaced. If an application is using this service to manage distributed transactions, then you need an outage just to install the new binaries.
Update the anti-virus exclusions to include the new Oracle Home. (I have been blocked by McAfee when trying to patch an unused Oracle Home with OPatch because the anti-virus kept scanning the Oracle DLLs each time OPatch checked each to see if they were locked by another process).
At this point, the new Oracle Home can be installed, remembering to remove the new Oracle Home from the PATH afterwards if it is not ready to be used yet. (Eg if further patches are to be applied to the new Oracle Home, then we don’t want anything locking the files yet).
Databases can be switched to the new Oracle Home one at a time. This can with DBUA or manually, with ORADIM, SQL*Plus, etc.
Listeners have to be recreated with NetCA.
Various non-Oracle services/processes should be restarted after the PATH has been updated to the have latest Oracle Home before the older Oracle Homes. Eg:
- Windows Management Instrumentation service (WMIPRVSE.exe).
(Dependent services: IP Helper and SMS Agent Host)
- SNMP service
- Distributed Transaction Coordinator (msdtc)
- COM+ System Application
- VMWare Tools
Migrate the ADR schema to allow purging of listener logs, eg:
C:\Windows\system32>adrci ADRCI: Release 184.108.40.206.0 - Production on Tue Jan 5 11:40:36 2016 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. ADR base = "C:\ORACLE" adrci> set base c:\oracle\11.2.0 adrci> show home ADR Homes: diag\clients\user_SYSTEM\host_1981999348_76 diag\tnslsnr\ORASERVER01\listener adrci> set home diag\tnslsnr\ORASERVER01\listener adrci> purge DIA-48322: Relation [INCIDENT] of ADR V incompatible with V tool DIA-48210: Relation Not Found DIA-48166: error with opening ADR block file because file does not exist [c:\oracle\11.2.0\diag\tnslsnr\ORASERVER01\listener\metadata\INCIDENT.ams]  adrci> migrate schema Schema migrated. adrci> purge adrci>
De-Installing the Old Oracle Home
Nasty Oracle Base Removal Bug
When removing the old Oracle Home, consider the warning in the Database Upgrade guide:
Known Issue with the Deinstallation Tool for This Release
Cause: After upgrading from 220.127.116.11 or 18.104.22.168 to 22.214.171.124, deinstallation of the Oracle home in the earlier release of Oracle Database may result in the deletion of the old Oracle base that was associated with it. This may also result in the deletion of data files, audit files, etc., which are stored under the old Oracle base.
Action: Before deinstalling the Oracle home in the earlier release, edit the orabase_cleanup.lst file found in the $Oracle_Home/utl directory and remove the “oradata” and “admin” entries. Then, deinstall the Oracle home using the 126.96.36.199 deinstallation tool.
This issue didn’t affect me, despite the orabase_cleanup.lst file containing admin, diag, oradata and flash_recovery_area. The deinstall script output said:
The Oracle Base directory ‘C:\ora’ will not be removed on local node. The directory is in use by Oracle Home ‘C:\ora\188.8.131.52_db1’.
However, I suggest playing it safe and removing the unnecessary lines from orabase_cleanup.lst. Folders can always be removed manually if necessary.
Incorrect Listener Removal
11.2 Deinstall Removes Listeners Running from Other ORACLE_HOMEs (Doc ID 1067622.1)
The de-installation script requires a listener name to shut down.
This is a problem when TNS_ADMIN is set and shared by multiple Oracle homes.
I ran into this issue and successfully worked around it by un-setting the TNS_ADMIN variable in the DOS window before running the de-installation script.