Share This:

The Database Automation team is pleased to announce the availability of BDA 2019 Release 1

This release includes product enhancements, security improvements, and expanded platform support. It also includes a change in the version numbering we use for our products.  This blog post will give you all the information you need to understand what’s new in this release.  

Further down in this blog post, you’ll find a full list of all the updates included in 2019 Release 1. But, before I share that with you, I’d like to spend a moment focusing on one of the most exciting updates in this release…. Parallel Patching for Oracle.


Parallel Patching for Oracle dramatically improves the experience of patching your databases.  It makes the process faster, easier, and more reliable. 

To explain how Parallel Patching does this, I’ll provide a description of how a patching job is executed moving forward.   Here’s the process that’s followed once a patching job is executed.

  • All databases on a node within the job will be stopped
  • All databases on that node will be patched simultaneously
  • If patching fails on any node (for example due to a missing pre-requisite), patching will continue on all other nodes until the full job is complete.  This ensures that any node capable of being patched, will be patched, as part of the first run of the job.    (Note: In earlier versions of BDA, the patching job would end immediately upon any error or failure leaving the remaining nodes unpatched. Parallel Processing eliminates this issue)
  • Regardless of whether patching fails or succeeds on a node, all services that were shut down as part of the job will be restarted immediately after patching has completed (or failed) for that node.   This ensures the databases are returned to a functional state regardless of whether the patching succeeded for failed, and without having to wait for the entire job to complete.
  • For any job where patching of a node has failed, the job status will be set to “Failed”. This informs the administrator that one or more of the nodes in a job was not successfully patched.  The administrator will then determine the cause of the failure(s), address the issue, and re-run the job to ensure all systems are fully patched.


So the takeaway here is that you’ll spend less time managing Oracle patch jobs and your users will experience smaller maintenance windows thanks to this new feature.


In our next release, we plan to extend this functionality to work with Microsoft SQL Server.  We’ll also updated the process to dramatically reduce the size of the maintenance window needed for re-running jobs where one or more nodes couldn’t be patched. In the current release, when you re-run a job, BDA will go through the full process of stopping services, attempting to patch, and restarting the services for every node.   In the upcoming release, we are planning to add a pre-check so that BDA will take actions only on those nodes that have failed.  This will dramatically reduce the size of the maintenance window needed for the re-run. 


So that’s Parallel Patching for Oracle … but that’s not all we’ve delivered in 2019 Release 1.   Here are the other updates delivered in this version: 

  • Support for Microsoft Windows Server 2019
  • Support for DB2 11.1 (Enterprise Server Edition, Advanced Enterprise Server Edition and Advanced Workgroup Server Edition)
  • Support Windows Server Failover Clusters using PowerShell rather than cluster.exe
  • Multiple security enhancements including updates to gridapp.conf file
  • Support for Java OpenJDK 11


Lastly, you’ve probably noticed that we’ve changed method we use for version numbering.   The “old school” method of version numbering that we used previously was devised to communicate the scope of change in a particular release.  A “9.0” release had more change than a “9.1” release.  And that had more change than a “9.1.3” release.   With BDA now releasing updates on a much more frequent and consistent cadence, the “old school” method no longer provides meaningful value since each release contains approximately the same amount of change.    With this in mind, we will now provide our release number in terms of the year of the release, and the release order.  For example, BDA 2019 Release 1 is our first release of the product for 2019.    Our second release will be 2019 Release 2, and so on until 2020 when our first release will be BDA 2020 Release 1.


Our entire team is very excited to provide you with these updates to BDA and we are confident they will help you more effectively secure, provision, patch and manage your database environments.   We’re also looking forward to your feedback on this release.  So please share any thoughts or questions you may have here in the Bladelogic Database Automation community.   


Thank you for providing us with the opportunity to continually earn your business!   I look forward to hearing from you.