Oracle, automated
Codifying how an Oracle database is patched and installed, not just the commands: the change ticket, the checks, the downtime, the patch and the notifications, as separate Ansible pieces.
- Two public repositories
- 2022–2024
- Author
- All work
What it does
Two sets of Ansible playbooks from my database administration work. One patches an Oracle database; the other installs the Oracle Database software on a new server.
Patching runs as one gated sequence: it validates the change ticket in ServiceNow before touching anything, checks that the database is in the inventory, runs the prerequisite checks, stops and starts the instance, applies the patch, and posts a card to a Microsoft Teams channel at each step.
- Targets are passed in at run time, so one playbook serves any server in the inventory.
- A ServiceNow change record has to be in the right state before patching starts.
- A prerequisites-only run checks a server without changing it.
- Installation cleans up before and after laying down the database binaries.
- Every stage reports its start, success or failure as a Teams card.
The problem
Patching and installing Oracle databases are repeatable procedures in which consistency, change control, prerequisite checks and telling people what is happening matter as much as the commands themselves. Done by hand, every run depends on the person running it.
The decisions
Automate the workflow, not just the commands
Instead of one monolithic patch script, the patching repository splits the lifecycle into pieces: prerequisite validation, the database patch, instance (SID) control, the change-ticket check and notification. The installation repository takes the same approach to laying down the database software, with its own playbook and roles.
Turned down: a single script that runs the patch commands faster but still leaves the checks, the change control and the communication to a person.
Check everything before the downtime
The checks run before anything is shut down: the required packages, that the running database belongs to the expected owner, OPatch's conflict check against the Oracle home, and whether the Release Update is already applied. If it is, the run reports "skipped; unneeded" instead of failing. A prerequisites-only playbook runs the same checks without changing anything.
Put change control inside the workflow
Before patching starts, the playbook looks up the change record in ServiceNow and stops unless it is Scheduled or in Implement. The change is part of the run, not a step someone has to remember.
Tell people as it happens
Each phase posts a Microsoft Teams card when it starts, succeeds or fails, carrying the job, the database and the host (and, when patching, the change ticket). Every failure path cleans up its staged files and posts its card before the run stops.
What it covers
- Oracle Database 19c, 12.2 and 12.1, on Linux and AIX.
- The Database Release Update and the Oracle JavaVM Release Update, applied with OPatch and then datapatch, which is retried once on a known JavaVM error.
- Silent installation of the database software, followed by the same patches.
- Targets passed in at run time, and long patch steps run asynchronously and polled, so one job can wait out a long patch.
What it doesn't do
There is no rollback: a failure cleans up and alerts, but it doesn't undo a patch. The initialization role is copied between the two repositories rather than shared, and neither repository has automated tests or more than a one-line README.