1

Applying Oracle Patches in PeopleSoft

1. Overview

Patch sets are a mechanism for delivering fully tested and integrated product fixes on a regular basis. Patch sets provide bug fixes only; they do not include new functionality, and do not require certification on the target system. Patch sets include all the libraries that have been rebuilt to implement the bug fixes in the set. All the fixes in the patch set have been tested and are certified to work with each other.

Patch sets contain the same set of generic fixes across all platforms. Patch sets may also include additional patches specific to the platform on which they are released.

Oracle provides both 32-bit and 64-bit versions of the Oracle9i database server on the Solaris operating system. The 32-bit version of the database can be run on the 32-bit or 64-bit version of the operating system per certification. The 64-bit version of the database can only be run on the 64-bit version of the operating system.

The 32-bit version of the patch set must only be installed on the 32-bit version of the database, regardless of whether the operating system is 32-bit or 64-bit. The 64-bit version of the patch set must only be installed on the 64-bit version of the database which runs on the 64-bit operating system.

Although Oracle release fixes but it is highly recommended to check Oracle Support for PeopleSoft Certification and Tools release for supported versions of Oracle platform. 

2. Assumptions

The following variables are used in this document:

1. HOST_ORACLE_HOME : This variable denotes the directory where Oracle has been installed on the client’s system
2. DMO – PeopleSoft Demo Database
3. DEV – PeopleSoft Development Database
4. TST – PeopleSoft Test Database
5. QA – PeopleSoft Quality Assurance Database(typically used for User Acceptance Testing) 

3. The Challenges 

With proper testing, proactively applying patches to the development, test, Certification and finally production environments, can avoid some of the Problems. Patches raise many questions:

• What are the latest patches to apply on the production system?
• Is it really needed to apply the latest patches?
• What is the impact of a particular patch?
• What did the patch change?
• How to revert from a patch applied?
• What effects will the patch have on the database?
• What are the dependencies between different environments?
• How to ensure a patch was successful?
• What if the patch overwrites customizations?
• What are the possible scenarios for refreshing or restoring a patch environment? 

4. Patch fix policy

The goal is to maximize the stability of the application, and part of that is taking a cautious approach toward changes to the existing system. Most patches & fixes applied in the Hosting are applied as part of problem resolution.  If a customer, consultant or Customer Support Analyst determines that a patch is the best solution to a problem, it is recommended to follow the steps below.

Research: Before any patch or fix is applied, the DBA researches the issue and determines the best course of action.  If the decision is made to apply a patch, specific processes are followed.

Test: Patches & fixes are always first applied to a DMO, DEV and TST databases.  Then the Hosting staff/Client thoroughly tests the application to see that the patch solves the issue it was tasked to solve.  If it meets the standards, then only it is recommended to move to User Test.  If it does not then research or rework needs to be done.

User test: Once the patch has been tested in the DEV and TST environments, it is passed on for User Test. The User test is typically conducted in the QA database.  Once the fix meets the expectations (Functionally and technically), the fix is ready to be moved to Production database.  If it does not, immediate corrective measures should be taken.

Move to Production: Once the patch or fix has passed the tests, it is moved from TST to PRD.  Once in PRD, it is again thoroughly tested by Hosting staff.  If it passes the tests, then the customer (or consulting team) can perform the final tests.  If it does not pass, then it’s recommended to reconvene to determine another way to solve the issue. 

5. Patch Fixing Strategies

A well-defined patching strategy has three major parts: patch application, Patch testing and patch information management.

 a. Patch Application

a. Predict the impact of a patch
b. Determine any configuration dependencies
c. Determine if the patch makes changes to the “technology stack” components

b. Patch testing

a. What to test and where to test (check list)

c. Patch information management

“As is” and “to be” environment comparison.
The key to these strategy parts is a current and updated patch repository. It helps to plan ahead.

6. De-Installation of the Patch Set

There is no mechanism provided for de-installing patch sets. Oracle recommends to back up the software installation before applying the patch set.

For de-installing a patch set, Oracle recommends one of the following procedures (in order of preference):

• Restore the HOST_ORACLE_HOME from backup.
• Re-install the baseline release and any patch sets previously applied, up to but not including this patch set.

Regardless of how a patch set is de-installed, please contact Oracle Support Services to verify that the problem is being addressed.

 7. Conclusion

Oracle patch fixes must be applied cautiously by checking in test environments and then applied to production.