Category Archives: Upgrade

21c, Zero-Downtime Oracle Grid Infrastructure Patching – Silent Mode

Recently I made two posts about the process for patch/upgrading your 21 Grid Infrastructure (GI) while the databases continue to be running. The first post shows how to do this using the GUI interface, and the second one show more details about the process for AFD/ACFS Kernel Driver Update. But here in this post, I will show how to do the Zero-Downtime Patch (zeroDowntimeGIPatching – ZDGIP) in silent mode.

This way to do the patch is important because allows you to automatize it. You can create your own script and call it (using Ansible, Puppet, Chief, etc.) to upgrade your servers (or farms) remotely.

Current Environment

The current environment is the same of the first post:

  • OEL 8.4 Kernel 5.4.17-2102.201.3.el8uek.x86_64.
  • Oracle GI 21c, version 21.3 with no one-off or patches installed.
  • Oracle Database 21c, RU 21.5 (with OCW 21.5).
  • TFA version is 21.4 (last available in March 2022).
  • Nodes are not using Transparent HugePages.
  • Is a RAC installation, with two nodes.

You can see the output for the info above in this txt file.

And I will apply the same RU 21.5 (21.5.0.0.220118) for GI which is patch 33531909.

Patch Process

The patch process is almost the same as the first post, the main change is the response file and the way to call the gridSetup.sh. So, for this reason, I recommend for you read the first (and second) post. Below you will see a quick review of previous steps and a focus on the new 

Click here to read more…

21c, updateosfiles after Grid Infrastructure Patch

Recently I made one post about how to use the new feature -zeroDowntimeGIPatching when patching the Grid Infrastructure for 21c. It is a new feature/option that allows your database continues to be running while the grid is patched. You can see my post here. But during that post I talked about the usage of -updateosfiles when calling the rootcrs.sh and want to clarify some details and provide better examples.

Current environment

For this post, my environment is:

  • OEL 8.4 Kernel 5.4.17-2102.201.3.el8uek.x86_64.
  • Oracle GI 21c, version 21.5.
  • Is a RAC installation, with two nodes.

The GI was upgraded from 21.3 to 21.5 as demonstrated in my post.

Compatibility Matrix

Before you think about upgrading the ACFS/AFD drivers you need to check if they are compatible with the version or kernel that you are running. The only place to check this is the MOS note ACFS Support On OS Platforms (Certification Matrix). (Doc ID 1369107.1). On that note, you will see tables for each major version (18c, 19c, 21c), and you can see the versions of Linux Version and Kernel versions that are compatible. Below is marked for OEL 8:

And you can see that my version of Linux Kernel is compatible. If your version is not compatible, not update the ACFS/AFD kernel drivers.

Click here to read more…

21c, Zero-Downtime Oracle Grid Infrastructure Patching

Oracle 21c delivered a lot of new features and for Grid infrastructure one of the most interesting is the zero-downtime patch (zeroDowntimeGIPatching). This basically allows your database continues to be running while you patch/upgrade your GI. The official doc can be seen here. Let’s say that is an evolution of the Out of Place (OOP) patch for GI.

In this post I will show how to do that, but some details before starting:

  • This post shows how to do the zero-downtime patch using GUI mode.
  • I will do another post showing how to do in silent mode the same procedure. So, it can be automatized.
  • In a third post, I will detail how the zero-downtime works behind the scenes and will discuss some logs.

Click here to read more…

21c Grid Infrastructure Upgrade

With the release of the 21c of Oracle Database is time to study new features. The 21c version of Grid Infrastructure (and ASM) was released and an upgrade from orders versions can be executed. It is not a complex task, but some details need to be verified. In this post, I will show the steps to upgrade the Grid Infrastructure to 21c. If you need to upgrade from 18c to 19c you can check my previous post.

Planning

The first step that you need to do is plan everything. You need to check the requirements, read the docs, download files, and plan the actions. While I am writing this post, there is no official MOS docs about how to upgrade the GI to 19c. The first place to the procedure is the official doc for GI Installation and Upgrade, mainly chapter 11. And another good example is 19c Grid Infrastructure and Database Upgrade steps for Exadata Database Machine running on Oracle Linux (Doc ID 2542082.1).

So, what you need to consider:

  • OS version: If it is compatible with 21c and if you are using asmlib or asm filter, check kernel modules and certification matrix.
  • Current GI: Maybe you need to apply some patches. The best practice recommends using the last version.
  • Used features (like AFD, HAIP, Resources): Check compatibilities of the old features with 21c. Maybe you need to remove HAIP or change your crs resources.
  • 21c requirements for GI: Check memory, space, and database versions.
  • Oracle Home patches (for databases running): Check if you need to apply some patches for your database to be compatible with GI 21c.
  • Backup of your Databases: Just in case you need to roll back something.

My environment

The environment that I am using for this example is:

  • Oracle Linux 8.4.
  • GI cluster with two nodes.
  • ASM Filter for disk access.
  • 19.11 for GI.
  • 19.12 for Oracle Home database.

I personally recommend upgrading your current GI to 19c before upgrade or apply one of the last PSU for your running version. This avoids a lot of errors since most of the know bugs will be patched. Check below my environment:

Click here to read more…

ZDLRA + MAA, Protection for Platinum Architecture

The Platinum architecture is the last defined at MAA references and is the highest level of protection that you can achieve for MAA. It goes beyond the Gold protection (that I explained in my previous post) and you can have application continuity even version upgrade for your database.

The image above was taken from https://www.oracle.com/a/tech/docs/maa-overview-onpremise-2019.pdf

Click here to read more…

Patch ODA from 18.3 to 19.8. Part 4 – 19.7 to 19.8

The process of patch ODA is not complicated but requires attention over some steps. The 19.6 version was the first that was possible to patch from 18.8 version, and the version that allows upgrades to newer. If you want to go directly to 19.5 you need to reimage of the appliance. In this post, I will cover the process that I made recently to patch from 18.3 to 19.8 version.

The fourth part covers the upgrade from 19.7 to 19.8. I separate so you can use this as a direct guide from 19.6 to 19.7 if you need to do just this update. Parts of this post are similar to the upgrade from 19.6 to 19.7 that I described in the previous post.

Patch Matrix

The matrix of what can be done can be found at this post from ODA blog, and you can check below:

Another important detail is to check the MOS note ODA: Quick Reference Matrix for Linux Release and Kernel by ODA Hardware Type and Version (Doc ID 2680219.1) and verify if your hardware is still compatible.

Remember that in this process, the ODA will reboot several times, so, you need to inform your teams that databases will be unavailable during the process.

Click here to read more…

Patch ODA from 18.3 to 19.8. Part 3 – 19.6 to 19.7

This is the third part of the ODA patch series, from 18.3 to 19.8. I separate in multiple parts and you can use this part as a direct guide to patch ODA from 19.6 to 19.7. Each part can be used alone since they cover all the needed steps. Some steps of this post are similar to the upgrade from 18.8 to 19.6 that I described in the previous post.

The process of patch ODA is not complicated but requires attention over some steps. The 19.6 version was the first that was possible to patch from 18.8 version, and the version that allows upgrades to newer. If you want to go directly to 19.5 you need to reimage of the appliance. In this post, I will cover the process that I made recently to patch from 18.3 to 19.8 version. 

Click here to read more…

Patch ODA from 18.3 to 19.8. Part 2 – 18.8 to 19.6

This is the second part of the ODA patch series, from 18.3 to 19.8. I separate in multiple parts and you can use this second as a direct guide to patch ODA from 18.8 to 19.6. Each part can be used alone since they cover all the needed steps. Parts of this post are similar to the upgrade from 18.3 to 18,8 that I described in my previous post.

The process of patch ODA is not complicated but requires attention over some steps. The 19.6 version was the first that was possible to patch from 18.8 version, and the version that allows upgrades to newer. If you want to go directly to 19.5 you need to reimage of the appliance. In this post, I will cover the process that I made recently to patch from 18.3 to 19.8 version.

Click here to read more…

Patch ODA from 18.3 to 19.8. Part 1 – 18.3 to 18.8

The process of patch ODA is not complicated but requires attention over some steps. The 19.6 version was the first that was possible to patch from 18.8 version, and the version that allows upgrades to newer. If you want to go directly to 19.5 you need to reimage of the appliance. In this post, I will cover the process that I made recently to patch from 18.3 to 19.8 version.

The first part covers the upgrade from 18.3 to 18.8.

Patch Matrix

The matrix of what can be done can be found at this post from ODA blog, and you can check below:

Another important detail is to check the MOS note ODA: Quick Reference Matrix for Linux Release and Kernel by ODA Hardware Type and Version (Doc ID 2680219.1) and verify if your hardware is still compatible.

Remember that in this process, the ODA will reboot several times, so, you need to inform your teams that databases will be unavailable during the process.

Click here to read more…

ZDLRA, Patch/Update the Recovery Appliance

The process of patch ZDLRA is not complicated, but it is important to be aware of some details. The most important is from where you are until where you want to go. This is crucial because it will define what commands you will need to execute.

If you read the previous post about the process, you can notice that I was running the ZDLRA 12.2 version, and forwarded to 19.2 version. In that case, I needed to use the upgrade path since I was changing the major release and the racli commands had the “upgrade” parameter.

In this post I will show how to do a simple update (or patch apply) for ZDLRA, this means that I will remain inside the same major release for recovery appliance library. Some steps and checks are the same.

Whatever you need to do (patch or upgrade), the startup point it is the note 1927416.1 that cover the supported versions for ZDLRA. There it is possible to find all the supported versions for the recovery appliance library as well as the Exadata versions. Please, not upgrade the Exadata stack with a version that is not listed on this page.

Click here to read more…