So today we had a Virtual-DBA client ask us to help them patch their Oracle Financials R12 for a bug they were having a problem with. So I thought I would share with you the process we used to patch their server.
They had sent me the patch number that Oracle support had recommended, so we went to Metalink and downloaded the patch. The patch readme itself basically just says to patch the server. Sometimes these readmes have pre and post tasks that need to be accomplished. This one was just to install the patch and restart the services. Though Oracle had some additional instructions to clear the mid-tier cache and restart the server.
After the patch was downloaded I used an SFTP client like Filezilla or Winscp to transfer the patch to their server. The patch was then placed in a directory wd could easily find again. Something like /u01/patches. The file was then uncompressed and it created it’s own sub directory.
This particular client had a refresh that runs and refreshes their QA environment so we made sure to disable that until they had time to test the patch after it was successfully applied.
We used adadmin and put the application server into maintenance mode. Which is as simple as typing adadmin on the command line and answering the series of questions about your particular environment. A lot of the defaults are correct until it asks you for your appsys user and system database user passwords.
Once the system is put into maintenance mode you can then change to your patch directory and apply your patch using adpatch inside the patch directory. You can use adpatch apply=n to just test the patch and see if there are going to be any errors and to also get a list of files the patch is going to change. We tested the patch with the adpatch apply=n and then went ahead and applied the patch.
After the patch successfully installed we then disabled maintenance mode by again running adadmin and then answering the questions again and selecting the disable maintenance mode opton.
We were then instructed by Oracle to clear the mid-tier cache. In 11i JSP pages were handled by apache jserv engine and in R12(our version) they are handled by OC4J. What that means is that if you just delete the $COMMON_TOP/_pages like you would in 11i. You will get a blank login page because AppsLocalLogin.jsp doesn’t get compiled by default. After you delete the _pages directory you can recompile by navigating to $JTF_TOP/admin/scripts and then running the below command:
perl ojspCompile.pl –compile –flush -p 20
We stopped the app services using adstpall.sh. We then cleared the cache and then rebooted the server as per Oracle’s instructions.
When the server came back online we started the mid-tier by using the start adstrtal.sh script. We then verified the application was up and running by logging into the web interface. We then tested the application to ensure the patch fixed the bug. It indeed did and that was the end of that.