Every quarter, Oracle releases a quarterly CPU patch (Critical Patch Update) and PSU (Patch Set Update) as security updates and fixes to flaws for remediation of Oracle security vulnerabilities. As expected, Oracle advertises DBAs should apply these patches to the binaries as “highly recommended” or “critical”.
However, a recent survey of Oracle DBAs indicated that only one-third of DBAs have ever applied a CPU or PSU patch. So, are these “critical” patches really that necessary? Short answer: YES!
Benefits of Patching
Oracle recommends that customers apply the Critical Patch Updates when they become available to ensure proper security measures and address any known security risks. However, immediate and systematic application of every security patch on an ongoing basis for all production systems may be difficult for some organizations because of the complexity of the environment or due to production requirements. Therefore, Oracle has intentionally designed the Oracle Database Server, Oracle Application Server, Oracle Enterprise Manager, and Oracle E-Business Suite R12 patches to be cumulative. As a result, each CPU for these products contains the security fixes from ALL previous Critical Patch Updates. The benefit for customers is clear: applying the most recent Critical Patch Update will install all the fixes that were previously released for these products.
DBAs, who are applying the most recent patch sets also get the benefit of previously released security fixes. That is because security fixes are also included in patch sets and in new product releases (Oracle’s policy is to first fix security vulnerabilities in the current code, i.e., the code used for the next release of the product). The inclusion of security fixes in patch sets and product releases provides customers more patching flexibility, effectively allowing those who are planning to deploy the most recent patch set to “skip” applying of a Critical Patch Update.
It is best practice to apply the patches to lower environments prior to the production environment. After sufficient testing and analysis are completed, then the patch may be applied to the production environment. It is always a good idea to check AWR and ADDR reports for the databases and compare significant differences before patch applications into a production environment such as optimizer paths.
Disadvantages of Patching
So why don’t DBAs or companies require DBAs to keep current with the known security flaws and apply the patches quarterly?
The most significant reason is time. The time to apply the patches varies for each patch and the size of the database. Some patches simply update the binaries and a bounce of the database, while others require the binary update and a data dictionary update and can sometimes take a bit of time. Multiply that by 2-5 lower environments and suddenly you’re talking about a significant amount of time to implement these patches (not to mention time for testing). Some organizations simply cannot afford the time for patches.
The decision to regularly apply the CPU or PSU patches rests with management and business owners depending on whether the risk of possible security breaches is worth the time to apply the patches. It’s an ongoing discussion. Most security-conscious organizations require mandatory patching regardless of all other considerations.
Most DBAs and organizations that do not regularly apply security patches are wary of the complications that may be introduced to the environment. Oracle has done a commendable job lately to mitigate these concerns, and CPU and PSU patching has become much less complicated and much more straightforward.
Need support applying Oracle database patches? Contact our experience Oracle database team today. We can give you the support you need when you need so you can continue to focus on strategic initiatives that will move your organization forward.
Subscribe to Our Blog
Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.
Most people will encounter this error when their application tries to connect to an Oracle database service, but it can also be raised by one database instance trying to connect to another database service via a database link.
Imagine over 100 logins on the source server, you need to migrate them to the destination server. Wouldn’t it be awesome if we could automate the process?