Studies show that many corporations world-wide expect their IT footprint to grow in the coming years. They expect more servers, more databases, more data, and more of everything.
They require more floor space in their data centers, and also the corresponding greater power footprint. Have you heard of a data center where no more servers can be added because the power supply has reached its limit, or the UPS (Uninterruptible Power Supply) can no longer cope? This story is not new.
The growth seems to be endless, and this is fuelled by today's information age, where larger and larger volumes of data need to be stored and distributed to satisfy an ever-growing demand. More applications are coming to use those databases, on more and more application servers.
So for the IT Manager, this will mean more of everything in his/her data center. There may be different hardware platforms, there may be different operating systems (e.g. Solaris, Linux, IBM-AIX, Microsoft Windows), and in each case there may be different versions – such as the different flavors of Linux supplied by different vendors including Oracle Enterprise Linux, Red Hat, SUSE Linux, and so on.
To add to the complexity, nothing placed in production should be treated as static. Software changes in development cycles, enhancements take place, or security/functional issues are found. For almost anything in the IT world, new patches are bound to be released. These will also need to be applied to production, test, reporting, staging, and development environments in the Data Center on an ongoing basis.
For the Database side of things, Oracle releases quarterly a combination of security fixes known as the Critical Patch Update (CPU). Other patches are bundled together and released every quarter in the form of a Patch Set Update (PSU), and this also includes the CPU for that quarter.
Oracle strongly recommends applying either the PSU or the CPU every calendar quarter. If you prefer to apply the CPU, continue doing so. If you wish to move to the PSU, you can do so, but in that case continue only with the PSU.
The quarterly patching requirement, as a direct recommendation from Oracle, is followed by many companies which prefer to have their Databases secured with the latest security fixes. This underscores the importance of patching.
However, if there are hundreds of development, test, staging and production Databases in the Data Center to be patched, the situation quickly turns into a major manual exercise every three months. DBAs and their Managers start planning for the patch exercise in advance, and a lot of resources are allocated to make it happen – with the Administrators working on each Database serially, at times overnight and at times over the weekend.
There are a number of steps involved in patching each Database, such as locating the appropriate patch in My Oracle Support (MOS), downloading the patch, transferring it to each of the target servers, upgrading the OPATCH facility in each Oracle Home, shutting down the Databases and Listeners running from that Home, applying the patch, starting each of the Databases in restricted mode, applying any supplied SQL scripts, restarting the Databases in normal mode, and checking the patch inventory.
These steps have to be manually repeated on every Database Home on every server, and on every Database in that Home. Dull repetition of these steps in patching the hundreds of servers in a data center is a very monotonous task, and it can lead to an increase in human errors.
To avoid these issues inherent in manual patching, some companies decide not to apply the quarterly patches on their Databases. They wait for a year, or a couple of years, before they consider patching, and some even prefer to apply year-old patches instead of the latest patches. This is counter-productive and leads to their Databases being insecure and vulnerable to attacks, since the latest recommended CPUs from Oracle have not been applied.
What then is the solution, to convince these companies to apply patches regularly? If the patching process can be mostly automated (but still under the control of the DBAs), it would reduce the quarterly patching effort to a great extent. Companies would then have the confidence that their existing team of DBAs would be able to manage the patching of hundreds of Databases in a controlled and automated manner, keeping human error to a minimum.
The Database Lifecycle Management pack for Oracle Enterprise Manager Cloud Control 12c is able to achieve this via its Patch Automation capability. We will now look into Patch Automation and the close integration of Enterprise Manager with My Oracle Support.
For the full Oracle Technet article, refer to http://www.oracle.com/technetwork/articles/oem/havewala-patching-oem12c-1864147.html