In an earlier blog post, I talked about how you can take advantage of early access to upcoming patches in Autonomous Database Serverless (ADB-S) to make sure your ADB instances remain regression-proof. As a quick recap on that post, customers do not have to worry about patching their databases to receive new features, bug fixes, or security enhancements in ADB-S. Thanks to its fully managed nature, ADB-S does it all for you while you can focus on your application development or business analytics. To make sure this continuous evolution does no harm to the production systems, customers rightfully prefer to test their workloads against these upcoming patches in advance.
 

Did you know that Autonomous Database has a special program to further enhance the customer experience and take it to the next level when it comes to early patch access?

The Oracle Aviator Program for Autonomous Database Serverless is designed to support customers who are running enterprise and mission-critical workloads with Autonomous Database. We provide expert-led advice and guidance on how to successfully design and rollout a comprehensive patch testing framework.

The Aviator Team will proactively work with and help you utilize early access environment to access latest software changes a week before production rollout.


Today, we are going to take this use case one step further and see how Autonomous Database can help you automate testing your workloads against upcoming patches. Once again, the goal is simple: automatically run the production workload against each upcoming patch to make sure there are no regressions. Before we talk more about the details of this automation flow, I’d like to revisit the importance of early patch access in ADB-S.

Key Benefits of Early Access to Upcoming Patches

  • Provisioning your dev and test databases on Early patch level allows you to run your regression tests against an upcoming patch one week before the patch reaches your production database on Regular patch level.
     
  • You can use the state-of-the-art Real Application Testing feature to automatically capture a workload on your production database and replay it on your dev/test database that is on Early patch level on an ongoing basis to make sure there is no performance impact on your workload introduced by the upcoming patch.
     
  • Autonomous Database offers zero-regression service level objective (SLO). What this means is that if you identify a regression issue raised by a patch on a database that is on Early patch level and report it via a service request, Oracle will use commercially reasonable efforts to address the problem so that the same issue does not occur in your production database.

For the remainder of this blog, I’m going to focus on the second item in this list, which is how to quickly take advantage of this automation in your Autonomous Databases.

Using Automatic Workload Capture/Replay

Autonomous Database lets you configure a repeating weekly schedule to capture your production workload and replay it in another database that is on Early patch level. This automation eliminates the hassle of manually capturing and replaying your workloads every week for regression testing. Here’s how easy it is to configure at a high level:

  • Create a refreshable clone of your production database on Early patch level
     
  • On your production database, enable workload auto-replay by providing the following details:
    • Target DB OCID (i.e., OCID of the refreshable clone)
    • Capture duration
    • Capture day (i.e., day of the week, Monday through Sunday)
    • Capture time in UTC
       
  • Check DBA_CAPTURE_REPLAY_HISTORY view access your capture and replay reports after each capture and replay. Optionally, you can also subscribe to ADB-S information events to get notified about these workload captures and replays.

In other words, you start with a source database (i.e., your production DB in this case) that is on Regular patch level and a target database on Early patch level, which is a refreshable clone of the source DB. The information you provide in the steps above ensures that a workload will be captured for the specified duration at the specified day and time every week until disable this feature or terminate either of those databases.

In conclusion, the ability to access upcoming patches a week in advance has significant advantages in safeguarding your ADB instances against regressions. The automatic workload testing against the weekly patches combined with our zero-regression SLO underscores our commitment to ensuring the continuous evolution of production systems without disruptions. To learn more about automatic workload capture capability in ADB-S and more details on the steps we covered above, check out our documentation.