As I wrote last week, ask any Oracle DBA and they’ll tell you that the bane of their existence — well, one of them at least — is keeping up with Oracle’s continuous stream of patches and upgrades. Will the fixes actually work? Will they break other unrelated systems? Welcome to the life of the DBA!
I asked for your opinions of the process and suggestions for improving it and received some interesting responses, such as:
- “Haven’t we always wanted Oracle to do a better job regression testing their released code? And haven’t we always wanted to know about a critical flaw before RMAN is involved?But who has the time to pour over metalink looking for possible (recent) hits? I think they’re going in the right direction, with automated patch downloads and SR generation. Human DBAs will never be able to scale the possible permutations to predictively find an appropriate available patch. Let alone the ramifications of applying it.”
- “Patching was a real pain until we came up with a technique for creating a Gold Oracle home and cloning this home. This technique saves a LOT of DBA time, reduces system downtime, and makes patches easy.”
- “Patching the RDBMS is manageable . . . [if you] download and install it on TEST server first. . . . As for automatic patch update like Microsoft Windows, forget it.”
- “Oracle has a tool that does patch management: it’s call Grid Control.”
- “Life would be much easier as a DBA if the products undergo extensive security tests and fixes before release.”
- and a lot more
If you have any additional thoughts, tips or best practices, let’s hear them!