Patching oracle software with less downtime using bolt plans

Patching oracle software with less downtime using bolt plans Ok, so you have set up your database servers using our Oracle modules and can apply changes to them consistently and controlled. You even support the development teams by enabling them to spin up their own Oracle database using vagrant and VirtualBox. Everything seems to be under control. Is it really….? It’s January 15th, and Oracle just released its quarterly Critical Patch Update for January 2020. You should really apply this because it’s been a while since you last patched your Oracle software. The security department found out it contains a patch that is critical for the security of your business application. So they are pushing you to patch fast. Oh, and by the way, business urges you to keep downtime to a minimum because downtime costs an increasing amount of money and extra calls to the helpdesk.

Oracle patching with Puppet

You could use the puppet classes and custom types available in ora_install and ora_profile to apply the patches. But this requires Puppet to stop all processes running from the oracle home, download and extract the zip file which is over 2GB(!), apply the patches, and start everything again. All-in-all, this will cost a considerable amount of downtime, which will not satisfy the business requirements. Aargh, how are you going to fix this?

Bolt to the rescue

Don’t worry. We got you covered. We have added puppet/bolt tasks and plans to the ora_install module, which will allow you to install a new oracle home and apply the patches to it. At a later time, when the maintenance window is there, you can run another plan to switch the database to this home and run the datapatch utility.

Here is how it works.

For installing a new oracle home including patches, you can use a single plan:

$ bolt plan run ora_install::install_oracle_home_and_patch -t dbserver \
    version=19.0.0.0 \
    file=LINUX.X64_193000_db_home \
    oracle_base=/u01/app/oracle/admin \
    oracle_home=/u01/app/oracle/product/19.0.0.0/db_home2 \
    ora_inventory_dir=/u01/app \
    puppet_download_mnt_point=/nfs_share/software \
    patch_file=p6880880_190000_Linux-x86-64.zip \
    opversion=12.2.0.1.17 \
    patch_list='{"/u01/app/oracle/product/19.0.0.0/db_home2: 30501910": {"source": "/nfs_share/software/p30501910_190000_Linux-x86-64.zip", "sub_patches": ["30557433","30557433"]}}'

This will:

  • install the new oracle home in /u01/app/oracle/product/19.0.0.0/db_home2 using the standard distributable for Oracle 19c;
  • install opatch version 12.2.0.1.17 from the specified patch_file;
  • and apply patches 30557433 and 30557433 from the zip file p30501910_190000_Linux-x86-64.zip to it.

When the maintenance windows is there you can use the following command to switch the database to use the new oracle home:

$ bolt plan run ora_install::switch_home_and_apply_psu -t dbserver \
    sid=DB190 \
    new_home=/u01/app/oracle/product/19.0.0.0/db_home2

This will:

  • stop the processes running from the old oracle home;
  • start them again in the new oracle home;
  • and run the datapatch utility to apply the sql patches inside the database.

The job is usually done within 10 minutes, depending on your setup.

All you need to do now is update your hiera data to reflect the changes that you have made, such that Puppet understands that the database is running from a different oracle home now.

What you have achieved

There you go, we just installed the Critical Patch Update with only a small amount of downtime. The business happy, security happy, and hopefully you still had a good night’s rest and even applied the patches.

What’s next?

In future releases of Puppet, functionality will be added to schedule plans like this, so you don’t even have to get out of bed for nightly maintenance windows.

Want to know more?

If you want to know more, contact us so we can show you this and more cool Puppet and Oracle stuff in a demo. If you like to experiment and learn on your own, request a FREE trial here