Oracle Database Release Update by Using Ansible Playbooks

-

Ansible to Rule Them All

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 more clean and simple way.

Now I will also patch database software by using Ansible Playbooks.

Database Patching with Ansible

In this post, 

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

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

Ansible is simply installed by "yum install ansible"  from EPEL repository. Add your hosts(gns01, gns02) in the hosts file under /etc/ansible/hosts and create ssh equivalency for 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


Lets start with creating 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 root user on all nodes. New database homes are getting ready for switching.

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

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

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

All database software patching is complete. It is a wonderful example of automate-first approach. With this approach, you decrease 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.

Comments

Post a Comment

Popular posts from this blog

Using table stats hint to force a direct path read but with a rownum predicate surprise

-
Image
Manipulating table statistics for the statement period On my blog post " Who makes the decisions? I thought it was Optimizer ", I used parallel hint to force a direct path read. This time i will try to make use of table_stats hint to force a direct path read. There is not much documentation about the usage of this hint. Roger Macnicol blog post ( Correct syntax for the table_stats hint  ) offers up some useful information about it. These are the variables play role in direct path read decision.  STT stands for small table threshold = _db_block_buffers * 0,02 =  3875820 * 0,02 = 77516 MTT stands for medium table threshold = _small_table_threshold * 5 = 77516 * 5 = 387580 VLOT stands for Very Large Object Threshold = _db_block_buffers * 5  = 3875820 * 5 = 19379100 I will show how the thresholds effect the direct path decision. We will use nsmtio (non smart IO) event  to trace the direct path or non-direct path/buffered decision.   Before 11.2.0.2 release, the direct path read d
Read more

Oracle Grid Release Update by using Ansible Playbooks

-
Image
Ansible is a friend in need and a friend indeed for DBAs. In this blog post, I will mention about Redhat Ansible and show how you can patch your grid infrastructure by using it. Ansible is an open source, command-line IT automation software application written in Python. It can configure systems, deploy software, and orchestrate advanced workflows to support application deployment, system updates, and more. Ansible's main strengths are simplicity and ease of use. It is a little bit similar to dcli commands in Exadata environments, but much more powerful as you may run playbooks which consist of different tasks. Ansible stands out from other configuration management tools because it doesn't need agents installed on target hosts. Instead, it leverages SSH for connecting to them and executes commands directly through the shell. This means Ansible communicates with remote hosts securely using SSH, eliminating the need for additional software on the managed machines. It's like h
Read more