BackgroundPatching is one of the most important steps you can take to keep your database and server running. It is highly recommended that the Database Server's OS and DB are patched in a timely and controlled manner. Using tools that can create virtual environments that duplicate your production and development systems for practice will save you many headaches. Dependant on the support level you have for the version of Oracle you are using, all patches can be obtained from
Metalink.
Patchsets are the largest and most important types of patches. They contain all patches required to upgrade a base installation to a new minor version of Oracle (such as going from 10.2.0.2 to 10.2.0.4) and are issued by OS and Major DB version. Often they are larger than the original install media. These come out rarely for reasons such as the quarterly updates are getting too large or a major change is needed.
Bundle Patch Updates (formally known as Cumulative Patch Updates[CPU]) usually come out quarterly and are issued by OS and Minor DB Version. They contain most patches issued sinces the patchset for the Minor DB Version came out. These updates can be difficult to install the first time as they often require tools such as Opatch and Perl to be updated before they can be applied.
Normal Patches are usually specific to a OS and Minor DB Version. They may interfere with other patches, and so may not be included in a Bundle even after being out for several months. They can be very simple to install (running a script) or very complex (shutting down DB, replacing files, changing parameters in init.ora, restart DB, test performance, tweek settings, etc.) You should only install these if you feel the need exists.
OS Patches should also be installed. These will often improve or even solve performance issues.
Before You Start (This Includes OS Patches too!) - Do a Database Export, then do a complete cold backup of the server and store them for at least a month. This will save you a world of trouble if something goes wrong.
- Do a reboot of the server and test everything. If there is already a problem, you want to identify and correct it before you introduce new varibles. Reboots tend to show problems outside of the database, or in its configuration.
- Run utlprp.sql to identify and correct problems inside the database.
How to Avoid Locked Files During Patching Process In Windows
- Make sure all Oracle Services are Stopped
- Make sure the following Sevices are Stopped and Disabled (to keep them from auto-restarting) after you document their original status (so you can change them back when done)
- Backup Agents (such as Backup Exec Oracle Agent)
- Distributed Transaction Coordinator
- HP Insight Foundation Agent
- Windows Management Instrumentation
- World Wide Web Publishing
- You might need to Disable the Oracle Services too, then reboot to unlock files
- In addition, you might need to change the ORACLE_HOME varible to point to something other than the Oracle Home, then reboot to unlock files. (Change the ORACLE_HOME back after rebooting, or tools like Opatch won't work.)
- Double check your file permissions. Check the Windows Security Event Log for violations if files refuse to overwrite.
In Un*x
Other Hints -
Copy all patch installation media to a local harddrive and install from there. Bad CD media will ruin your day if you are patching from it.
-
Set the ORACLE_HOME, ORACLE_SID, and LOCAL (called TWO_TASK in Un*x) enviromental varibles permanently.
-
You will likely need to install the latest version of Opatch again after installing a Patchset.
-
Clients can be patched too! If you use ODBC, patch your client.
-
Reboot and test when you are done. Do another Database Export and Full Cold Backup of the Server if you have the time.