8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » Misc » Here

Automation Patterns for Typical DBA Tasks

This post describes some common automation patterns I use when automating typical DBA tasks. Not surprisingly, they look very much like the manual processes they replace.


There are some general tools we will use as we build up our automations. The specific tools are not that important. The important point is we have a tool that serves each role.

I can't stress enough, the specific tool selection is not important. It's the role the tool plays that is important.

Database Patches

Over the last few years we've managed to standardise our database deployments, such that patching is identical across the all our Oracle databases.

Database Patches

The top-level process is as follows.

The patching process is as follows.

You can read more about database patching here.

APEX Patches

APEX patching is relatively simple, but it is awkward making sure the static files (image, CSS etc) are distributed to all the middle tier servers.

APEX Patches

The top-level process is as follows.

We use ORDS running in containers as our PL/SQL gateway, which also presents the APEX static files. We keep the static files on the host servers, and present them to the containers, which allows us to alter the static images without redeploying the containers, making the delivery of the static images much simpler.

Tomcat Patches

We try to use containers for our middle tiers where possible, but we have some 3rd party products that are not supported in containers, so we have to do more traditional patching. We have a lot of Tomcat servers, so although Tomcat patching is simple, it's quite labour intensive to manually patch all the servers in an environment.

Tomcat Patches

The top-level process is as follows.

The patching process is as follows.

Container Builds and Deploys

We have several container images for different services, but the process of building them is similar.

Container Image Builds

The top-level image build process looks like this.

Remember, the build of the image is separate to the deploy of a container using this image, so the builds are completed before any deployments happen.

Deployments of containers can vary a little. In some cases the DBAs are in control of them, so we treat them like a traditional patching window. In some cases the developers are in control of them, so they pull the latest container image as part of their application deployment. Either way, TeamCity is the trigger.

Container Image Deploys

The top-level deployment process looks like this.

The container deployments are really simple, because we never amend existing containers. They are removed and recreated.


Here are some things to consider.

For more information see:

Hope this helps. Regards Tim...

Back to the Top.