Some Notes on Installing Oracle 12.2 GI

Some Notes on Installing Oracle 12.2 GI

Now that I have a few Oracle 12.2 GI installs/upgrades under my belt, I thought I'd share a few thoughts about my experiences. Note that while these comments are specific to Oracle 12.2 GI installs, a lot of the best practices I am suggesting apply to any version of Oracle GI, and even to Oracle Database.

What's Not in this Post - Installing GI - Blow by Blow

First, this is not going to be a blow by blow description of the install process - others have done that far better than I ever could. For a really good blow by blow description on installing Oracle GI and an Oracle RAC database, please check out Tim Hall's web site Oracle-Base here! I can't say enough good things about Tim's web site. Tim is an Oracle ACE Director and he really keeps his site fresh with the latest on the Oracle Database product set.

Another great source of new features knowledge is Mike Dietrich's blog. It looks like his blog might be moving soon, but this link still works for now!

What's in this Post Then?

In this post I'm going to share my opinion on a few topics:


1. Upgrade and patching documents of note
2. Dealing with ASM
3. Changes in the GI install process
4. The Initial GI software install

In future posts I'll discuss the actual GI upgrade itself. In following posts I'll discuss installing the 12.2 Oracle RAC Database software install and upgrade processes.

Upgrade and Patching Documents of Note

Before you do any Oracle GI install, there is a lot of reading to be done. Let me suggest the following as a good reading list to get started:

The Oracle 12.2 Upgrade Guide for Linux (other OS versions are available). 

Document 2239820.1 from Oracle Support - Titled: 12.2.0.1 Base Release - Availability and Known Issues. Provides some great information on patches and issues related to the base release of Oracle GI and Oracle Database version 12.2.0.1. This document is probably the easiest place to look for links to the most current Oracle RU patch that you will want to download and install.

Document 1591616.1 - from Oracle Support - Titled: Patch Installation and Deinstallation for 12.1.0.x.x GI PSU and Database Proactive Bundle Patch - I actually believe that some of the contents of this document should be included as part of the OCP exam objectives. It contains a gold mind of information on applying the Oracle GI and Database RU's in detail. Note that while the document says 12.1, it still largely applies to 12.2 patches and it is referenced in the most recent 12.2 RU. Keep an eye out of a 12.2 update to this document.

Document 2285557.1 from Oracle Support - Titled: Database 12.2.0.1 Proactive Patch Information

Each patch set has it's own "known issues" document. The "known issues" document number can be found in the read me file associated with each patch.  You can find a link to the read me file for each patch on the download page for that patch as seen here:

Dealing With ASM

I mentioned in an earlier post that ASM is a new requirement in Oracle Database 12r2, and made some suggestions on how to deal with it. If you are not using ASM right now, I can't underscore how important it is to get out in front of this long before  you start your 12.2 upgrade efforts.

Changes in the GI Install Process

The way you install the software related to Oracle GI 12.2 has changed (and this change is coming for the Oracle Database in Oracle Database 18c). Oracle now supplies the GI software install image on the install media, unzipped, and without an installer. You simply copy the image from the install media to your new GI home directory.

Once you have copied the image to your new GI home directory, then there is a setup script called gridSetup.sh that you use to start the OUI. This will start the familiar OUI for you, which will check all the Oracle GI per-requisites for you, and drive you crazy because  you KNOW you set things up correctly and yet, it managed to find something wrong. Drives me crazy every time. And, it's always something different on every machine.

When using this method to install the new GI software, you will need to install the GI software on each node, individually. The gridSetup.sh script does not copy the software to the other nodes of the cluster for you when you do a software only install (which is what I will discuss in further detail next). 

Note: I have not yet investigated using Rapid Home Provisioning to install the software only image, instead of manually installing it on each node. That's something I need to explore further. You can find information on Rapid Home Provisioning here.

The Initial GI Software Install

I strongly suggest that when you run gridSetup.sh to configure the GI software, that you do not upgrade your cluster at that time. This is because, at a minimum, you are going to want to install at least two patches before you start the configuration.

The reasons I like to patch before I upgrade the cluster, are many. First, if you look at some of the comments in various Oracle documents, this is how they suggest you upgrade a cluster. My personal preference when upgrading to a new version, or just patching an existing version, is to create a new GI home and load the new software and patches into that home, then upgrade the GH infrastructure. It can reduce mistakes, reduce the time you are in production "maintenance" mode and reduce the overall time that you are actually upgrading the cluster. Granted, a GH upgrade is a rolling upgrade (a database upgrade is not) - but even then, I think the arguments of using a separate GH for each patch update are compelling.

Another point for installing and then patching, before upgrading, is that if you reduce the risk of initial product instability issues and the impacts that can have on your cluster by applying the patch before actually upgrading the cluster itself. This eliminates bugs that might be present in the base install image. Since RU's are designed to be minimally invasive with respect to new change, and since they contain a number of stability related bug fixes, installing the current RU comes with low risk and pretty high reward.

Patching before you upgrade provides the ability to deal with any issues related to patching without putting your cluster in any kind of real jeopardy. In short, get your cluster to a known and stable state before you upgrade the configuration.

And - of course - I assume you will be testing all of this ahead of time anyway, right?

What patches to you need to apply? 

At a minimum, after you have installed the base GI software, there are two patches you will need to apply. The first is a patch for Opatch and the second is the latest RU. Other patches may appear in the documents I mentioned in the "Upgrade and Patching Documents of Note" section earlier in this post, though I know of none at the time I wrote about this. Let's look at Opatch and the RU in a bit more detail.

The Opatch Patch

The software that Oracle uses to patch the GI and database software is called opatch. A version of Opatch ships with the GI (and database) software, but you will need to update it in either the GH or database homes before you install pretty much any patch.

You can find the most current version of the Opatch software on Oracle's support site under bug number 6880880. Make sure you download the correct version of Opatch (each Oracle database version has one or more Opatch versions available for download under the 6880880 bug selection).

Patching Opatch with the downloaded patch is pretty easy. As of this writing (and for as long as I remember) you just go to the Oracle Home location that you want to patch, remove the existing OPatch directory contents and then unzip the contents of the Opatch zip file into that directory.

Of course, make sure you check the install instructions for Opatch before you install it on your system.

The RU Patches

Having updated Opatch, it's time to find the most current patch for Oracle GI and install it.

Starting with Oracle GI and Database 12.2 Oracle has changed it's patching nomenclature. Gone are Patch Set Updates (PSU's) and their ilk. Now, we have Release Upgrades (RU) and Release Update Revisions (RUR). Oracle addresses these new patching mechanisms in document 22854040.1. For information on the individual RU patches that are available, you can review document 2285557.1 in Metalink. I for one prefer to install RU's over RUR's. That may be a subject for another post.

A prerequisite to installing any RU into the GI home is running gridSetup.sh to install the GI software, which I discussed earlier in this post. This is because you can not apply an RU's to the pre-install image that you have just copied into the new GI home, the software, and the home it is assigned to, has to be configured first (which is not the same thing as upgrading to cluster). This configuration is done when you run gridSetup.sh with the install software only option (or, of course, if you have it go ahead and install and configure the cluster at the same time).

When gridSetup.sh runs, it will create the entries in the Oracle inventory that Opatch will need to apply the patches to the software image. Once the new GI home has been configured, then the Oracle inventory will be likewise configured and Opatch can find the correct Oracle GI Home to patch.

Once you have configured the software home, then you can install the RU updates. You will need to find the latest RU on the Oracle support site, download it and extract it. Applying the RU can be daunting - to say the least.  I will write another blog post on applying RU's.

Summary

Installing Oracle 12.2 GI has changed, somewhat, compared to previous versions - but a lot of the best practices are still the same. If I had a couple of pieces of advice to offer, they would be:

1. Read the documentation, MOS notes and then read them again.
2. Make sure you have a good test environment. Test things over and over.
3. Build a checklist that makes the upgrade process as easy as following steps 1,2,3. As complex as patching may seem, it is possible to build a really good checklist. 
4. Understand how patching works in Oracle database and understand the process of how patches are applied.