Autonomous Database - Dedicated : Getting Started with Operational Maintenance Policies

As many of you realize, Oracle Autonomous Database has two deployment choices; Serverless and Dedicated.

Autonomous Serverless is meant to get database users up and running quickly with zero interaction in anything related to administration. Serverless is in a sense traditional cloud, a multi-tenant database service using shared resources. In many respects, Serverless is the pinnacle of what Oracle means to “go Autonomous” with database in cloud, you simply get a secure connection and start using the database for your applications or data warehouses, there is minimal to zero interaction with the administrative side of running the database service. 

On the other hand, Autonomous Dedicated deployments are a step beyond traditional cloud, designed to provide the ultimate in resource isolation, performance and allows database users a way thru policy controls to influence how Oracle’s Autonomous operations function.

With Autonomous Dedicated, at a macro level Fleet Administrators can budget dedicated resources to different work groups (LOBs, Project Teams) within a single tenant. Fleet Administrators then turn over access to the budgeted resources to the work group for a granular level of self-service, an experience that has a parallel to the experience of Oracle’s Autonomous Serverless. However, it’s not multi-tenanted, all IaaS resources are dedicated to the single tenant, yet in the same self-service format. Autonomous Dedicated brings the ultimate corporate level governance and regulatory capabilities while removing the red tap commonly known to reduce business agility.  

Autonomous Dedicated policy controls make it possible to influence the level of resource isolation, database software versioning and lifecycle, over provisioning and peak usage of a database’s underlying resources. Let’s talk about database software versioning and lifecycle and get into an example of how to influence the Autonomous operations. In the next blog, we will then show an example of integrating notifications about autonomous operations into a Slack channel or other preferred methods of receiving service notifications.

With Serverless, Oracle sets all policies on software versioning and lifecycle. The exact software version, how and when it gets updated is completely opaque to the service consumers. With Dedicated, policy controls on software versioning and lifecycle make it possible for database service users to set policies so that mission critical applications can treat development and test separately from pre-production and production databases. For example, policies can influence Oracle Autonomous Database operations to update development and test with the very latest software versions, while pre-production uses a revision level update that applies 30 days before that same revision applies to production. Complex applications then have an ability to run regressions in pre-production and only apply validated revisions to the actual production. This only begins to touch on the way database users can influence how Autonomous operations run. 

Lets take a quick walk thru of how to setup these software versioning lifecycles. This is easily done by setting up lifecycle defaults. Using the API, CLI, SDK or Console it’s easy to configure the defaults. Below is a series of screen shots from the console.

Head on over to one of the Autonomous Database workloads:

Once at the Autonomous Database resource page, you will notice 3 different Autonomous Database resources.  Autonomous Exadata Infrastructure (AEI), Autonomous Container Database (ACD), Autonomous Database (ADB).  The AEI and ACD are Autonomous Dedicated specific service resources and are where to setup the software version lifecycle. The ADB service resource is common for both Serverless and Dedicated.

Fleet Administrator sets up the default software version maintenance schedule at the AEI level during provisioning, although the defaults can be modified at any time for an existing AEI. Click on the Create Autonomous Exadata Infrastructure button.

At the bottom of the AEI provisioning screen, you will see a Configure the Automatic Maintenance section, where you should click on the Modify Schedule button. If you do not customize the schedule, then it behaves like Serverless and Oracle will set a schedule.

Clicking that Modify Schedule button brings up a calendaring system to set maintenance window preferences. If desired, you can narrow the window down to a specific start time. The schedule is inherited from the AEI to the ACD and in a future release there will be a separation of schedule for the AEI and ACD.

Similarly, a Fleet Administrator or a Database Admin sets up the software version policy at the ACD level during provisioning, although the defaults can be modified at any time for an existing ACD. Click on the Create Autonomous Container Database button.

At the bottom of the ACD provisioning screen, you will again see a Configure the Automatic Maintenance section, where you should click on the Modify Maintenance Type button. If you do not customize the Maintenance Type, Oracle will default to Release Update to keep you on the latest available software version. In a future release, you will be able to select an exact software version and Oracle will honor the implied strategy of applying the next Update or Revision based on your previous selection. Critical updates related to security or other service related issues will also appear in the same way, a unique version that can be selected, which will initially become available as a new custom scheduled update.  

Modify Maintenance Type to your preference of Release Update or Update Revision, then click the Update Automatic Maintenance button to save your policy.

Even though you've set all these defaults during provisioning, using the ACD resource list (which you can get to using the bread crumbs at the top of the Details page), you can Navigate to any given ACD details (below you would click on PrePRod or FLEET_ACD links), including maintenance where you can change your defaults and change timing and other aspects of scheduled maintenance.

On the details page, you can find links to view your current settings, see maintenance that is currently scheduled to occur and view a history of maintenance actions.

You will see details like the following, where you have controls to take various actions to change defaults, software versions, schedules, defer etc. 

OK, it's that simple, now you know how to setup a software version lifecycle for a specific AEI / ACD and you can understand how different AEI / ACD can be given unique policies on how a development and test environment should be treated as opposed to pre-production and production instances. For example, schedules for production can be setup to mirror the pre-production schedule and version, but with a 1 month delay in the operation. If an issue arises in your application as a combination of your application changes and a particular software version update, it would be detected in your pre-production, you can then defer the production operation until the issue is resolved. 

This flexibility in managing separation of software version, scheduling allows new adopters of Autonomous Database Services to mitigate any perceived risk in moving the most mission critical application databases to Oracle Cloud.

Source: oracle.com