|
ASK THE EXPERT-MR. DATABASE
KEEPING UP WITH PATCHING
BY ERIC GROSS, DBA
Patches that are released on a regular basis add a new wrinkle to the DBA’s plate. Once the next patchset is released the cycle starts all over again. Procedures that used to take months must be reduced to days or weeks; otherwise your patching will never be able to keep up with the new patches being released by the vendor. There are many similarities from one patch to the next in terms of the installation procedure and other requirements, but things regularly change too.
The Oracle Critical Patch Updates (CPUs) are the driving force behind reducing the vulnerabilities of Oracle software. While the concept remains the same, the way that these patches are structured and used has been changing over time, and is likely to continue into the future. In 2007 the method used to install the patchset changed – what used to be a standard OPatch apply command is now a new command - napply. This new patch installation method takes into consideration that what is being deployed is a set of entities (each is called a molecule) rather than a single entity. This change forces a change to the installation procedure used. Each CPU consists of a set of molecules – and since each CPU is cumulative – there are necessarily new OPatch features available. When installing the patch the administrator can ignore molecules that are already installed. In addition molecules that are already installed that have been upgraded in the new CPU can be replaced. In some cases there are molecules that cannot be applied for one reason or another, adding another complexity when installing the patchset.
Before a DBA can be confident that a patch can be installed without unexpected problems in production the same exact procedure (and parameters such as the molecules to ignore) must be properly tested in a non-production environment. This requires the ability to repeatedly execute the patching procedure with a fixed set of inputs (and perhaps some inputs that need to be changed from environment to environment). Also important is the ability to store a record of each patching activity so that issues discovered down the road can be investigated with prior successful attempts available for reference. Without the proper automation framework all of this is quite time consuming and prone to error.
GridApp Clarity ships with the intrinsic ability to apply CPUs, and just with all activities, the results are stored centrally – available for reference at any time. GridApp’s DBAs and development staff keep on top of the changes that are pushed down from the vendor, updating the procedure, so that you can take advantage of automation without spending the resources required to maintain functionality across all popular platforms and versions of database software. Patching clusters (CRS, Veritas, Microsoft) forces an even more complex patching plan because activities between many nodes needs to be synchronized and recorded. Creating a system that can reliably patch complex environments is a challenge – one that has already been solved.
Newsletter Home
|
