No matter what people tell you, keeping Oracle database on most recent security patches can be tricky.
Here’s how my efforts went this afternoon.
I wanted to apply the Jan 2010 Oracle security CPU patch to a instance running Oracle APEX. Jan 2010 CPU patch has a specific APEX patch as well as an Oracle database patch. I learned the hard way that the Oracle database patch needed to be applied first after encountering errors in the APEX patch. Maybe I should have guessed that there was a dependency here, but I glossed over the “Known Issues” section in the APEX patch and it wasn’t mentioned elsewhere…
I got everything completed on my target Windows machine: DB patch then Apex patch.
On to an Oracle database running on Solaris. I applied the Jan 2010 CPU DB patch. Went fine. Ooops, no it didn’t. At the end it spit out some errors that said they were covered in Metalink note 353150.1. Turns out the Metalink note says the errors are false positives, but it took about 15 minutes of reading through the note and running a small test to verify that.
So on to the APEX patch on the Solaris DB. My test instance had been running just fine, but it ran out of shared memory when applying the patch. I retreated momentarily and shutdown some other instances on the machine, add a bit more to the MEMORY_TARGET parameter and fired up the instance. I applied the patch again.
Still errors on Solaris. I looked at the Jan 2010 CPU documentation again. For Solaris, it appears that the bug fix I need is only in the new PSU Jan 2010 patch and not the CPU one. I hadn’t tried a PSU patch, but since this is a lab instance, I figured I’d try it out.
I uploaded the PSU patch and started in with that. The opatch commands kept coming back with an error, so I learned that the 18.104.22.168 opatch utility was no good for PSU patches. I needed the most recent opatch utility. I downloaded and applied that.
So ran the PSU patch on Solaris, which took over 1 hour on fairly fast hardware. I followed the post installation steps, which all went fine. Interestingly, the PSU patch did not have the same OS issue that the CPU patch during the verification section. Then I went back to the APEX patch on the same Solaris database instance. That went through without a hitch!
In sum, to patch Oracle APEX on windows and Solaris, I had to
> Apply Oracle on Windows CPU database patch.
> Apply APEX patch. Windows now done.
> On Solaris, download and apply new OPatch.
> On Solaris, apply PSU patch, including post-install steps.
> On Solaris apply Apex patch. Solaris now done.
Automating all this is possible, but certainly requires work if you do the scripting yourself, or money if you pay for OEM’s patching option or for a product like GridApp.