Oracle Autonomous Database Serverless (ADB-S) is a fully managed database service on Oracle Cloud Infrastructure (OCI) that is optimized for different workload types such as transaction processing, analytics, batch processing, document-oriented application development, and so on. One of the primary benefits of Autonomous Database is to shift the burden of database patching from customers' shoulders to Oracle. As you may already know, each Autonomous Database is patched weekly during the maintenance window assigned to it. Patching in Autonomous Database is an online operation, meaning the database remains available during this time, and our customers love not having to worry about applying these patches themselves, which deliver not only new features but also critical bug fixes and sometimes even security enhancements. This is all great (and, at the same time, old news), so why are we here discussing this relatively well-known topic? When a database gets patched this frequently, there is a valid question that could arise for some customers: how do I make sure a given patch doesn't introduce a regression on my production database? The purpose of this blog is to answer that question.
Today, we are going to be talking about a feature that we released almost two years ago, and that lets you access an upcoming patch one week in advance. The idea behind this capability is straightforward: You tell us if a database should be receiving these patches one week ahead during provisioning a new database or cloning an existing one, and we make sure that the database receives any upcoming patch one week earlier than other databases that do not have this special designation. We call this concept "setting the patch level", and the databases on Regular patch level receive any patch on the regular schedule while the databases on Early patch level get the same patch a week ahead. In remaining part of this blog, we'll review the key benefits of this capability and how to use it.
We already briefly mentioned why you might want to take advantage of this feature, but let's summarize all the key benefits:
You can set the patch level for an Autonomous Database either during provisioning a new instance or when cloning an existing instance.
When provisioning a new instance, you can follow Create Autonomous Database -> Show advanced options -> Maintenance -> Patch level as shown below:
When cloning an existing instance, you can follow Create clone -> Show advanced options -> Maintenance -> Patch level as shown below:
If you'd like to find out what patch level a given instance is on, you can check the maintenance section on Autonomous Database details page:
How can you change the patch level of an existing instance? Even though changing the patch level of an existing instance is currently not possible, you can clone an instance that is on Regular patch level into the Early patch level. If your goal is to avoid any connection string changes during this operation, you can drop the source database and rename the clone to use dropped database's name as described in one of previous blog posts. Not to mention, using TLS authentication (aka walletless connections) will simplify the whole process. Last but not least, Early patch level is available in the following regions at the time of writing this blog post: Ashburn, Frankfurt, London, Phoenix, and Singapore.
To summarize, Autonomous Database offers fully automated weekly patching without any downtime, which saves a significant amount of time and effort in return for our customers. This agility and rapid access to new features and bug fixes understandably bring up questions about performance stability and regressions on production databases. Early patch level is a capability that is tailored to ensure there are no regressions introduced by those weekly patches and is further strengthened by our zero-regression SLO. If you'd like to learn more about patching in Autonomous Database, check out our documentation.
Can is a Principal Product Manager for Oracle Autonomous Database (ADB-S) and has been with the company since 2014. Prior to joining the ADB-S team, he worked on the Oracle Multitenant and Oracle Query Optimizer teams. Can holds a MS (Computer Science) from Case Western Reserve University and a BS (Computer Engineering) from Bilkent University.