Oracle Database Release Update by Using Ansible Playbooks

Ansible to Rule Them All

I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there.

In the previous post "Oracle Grid Software Patching by using Ansible Playbooks", I mentioned how Ansible orchestration can be used to make Oracle Grid Software Patching a cleaner and simpler process.

Now I will also patch database software using Ansible Playbooks.

In this post, 

I will use the blt01 host as the ansible host. The target environment is a two-node RAC database (gns01, gns02). I will patch the grid software to 19.22 using the out-of-place methodology with no downtime. 

Although there are lots of useful blog posts about how you may use Ansible for automating tasks, there is not much about complete Oracle database software patching. 

Ansible is simply installed by running "yum install ansible"  from the EPEL repository. Add your hosts (gns01, gns02) in the hosts file under /etc/ansible/hosts and create ssh equivalency for the oracle and root users.

We need:

    * OPatch -  p6880880_122010_Linux-x86-64.zip

    * 19.22 RU - p35940989_190000_Linux-x86-64.zip (GIRU System Patch involves DBRU)

    * A sample one-off patch (555.1 Recommended) - p34672698_1922000DBRU_Linux-x86-64.zip

    * OJVM patch (555.1 Recommended) - p35926646_190000_Linux-x86-64.zip

    * Database home Setup - LINUX.X64_193000_db_home.zip

Let's start with creating a new database directory. Here is the first playbook we will run.

As new database homes are created on target servers, I will unzip 19.3 db_home.zip and apply Release updates and one-off patches on top of it with the below playbook.

Run root.sh with the root user on all nodes. New database homes are getting ready for switching.

We will copy the files we need from the old dbhome to the new dbhome and update the .bashrc file to use new dbhome values. Since all databases in my environment use pure unified auditing, it is time to relink new homes with the unified auditing option on. Now all databases will be modified with the srvctl utility and oracle_home values will be updated. Instances will be started from new dbhomes on both nodes. The recovery process (MRP) will be started on standby databases. Here is the playbook that takes care of everything.

For primary databases, it is time to run datapatch. The following playbook will be run on only the first nodes of primary databases.

It is time to say goodbye to old database homes. We will remove them by simply running the deinstall command. This one is a little bit tricky, as we will use the expect module for replying to prompt questions. Here it is.

All database software patching is complete. It is a wonderful example of an automate-first approach. With this approach, you decrease the chances of human error and increase productivity. -----------------------------Revised on March 23, 2024;I have incorporated valuable feedback and revised all my playbooks to adhere to some best practices.* Ensured that all tasks consistently refer to the same variables.* Improved the playbook's readability and formatting for better clarity.* Replaced some shell module commands with the cmd module for better compatibility and robustness.* Replaced unzip commands with the unarchive module for better management of archives.* Converted Ansible variables to lowercase for consistency and clarity.* Adopted the ansible.builtin format for built-in modules to ensure compatibility across different Ansible versions, enhance readability, future-proof playbooks, and prevent potential conflicts with custom or user-defined modules.Also, consolidated all playbooks into a single file as shown below.

Hope it helps.