04/06/2020 Oracle Grid Infrastructure 18c patching part 1: Some history | DBA survival BLOG

DBA survival BLOG

Keep DBA job simple. Thanks.

Oracle Grid Infrastructure 18c patching

part 1: Some history
Posted on November 16, 2018

Down the memory lane

Although sometimes I think I have been working with Oracle Grid Infrastructure since it exists,
sometimes my memory does not work well. I still like to go through the Oracle RAC family
history from time to time:

8i -> no Oracle cluster did exist. RAC was leveraging 3rd party clusters (like Tru Cluster,
AIX HACMP, Sun Cluster)…
9i -> if I remember well, Oracle hired some developers of Tru Cluster after the acquisition
of Compaq by HP. Oracle CRS was born and was quite similar to Tru Cluster. (The
commands were almost the same: crs_stat instead of caa_stat, etc)
10g -> Oracle re-branded CRS to Clusterware
11g -> With the addition of ASM (and other components), Oracle created the concept of
“Grid Infrastructure”, composed by Clusterware and additional products. All the new
versions still use the name Grid Infrastructure and new products have been added
through the years (ACFS, RHP, QoS …)

But I have missing souvenirs. For example, I cannot remember having ever upgraded an
Oracle Cluster from 9i to 10g or from 10g to 11g. At that time I was working for several
customers, and every new release was installed on new Hardware.

My first, real upgrade (as far as I can remember) was from 11gR2 to 12c, where the upgrade
process was a nice, OUI-driven, out-of-place install.

The process was (still is ) nice and smooth:

The installer copies, prepares and links the binaries on all the nodes in a new Oracle
Home
The upgrade process is rolling: the first node puts the cluster in upgrade mode
The last node does the final steps and exists the cluster from the upgrade mode.
Privacy & Cookies Policy
www.ludovicocaldara.net/dba/gi18c-patching-part1/ 1/8
04/06/2020 Oracle Grid Infrastructure 18c patching part 1: Some history | DBA survival BLOG

This is about Upgrading to a new release. But what about patching?

In-place patching

Patching of Grid Infrastructure has always been in-place and, I will not hide it, quite painful.

If you wanted to patch a Grid Infrastructure before release 12cR2, you had to:

read the documentation carefully and check for possible conflicts

backup the Grid Home
copy the patch on the host
evacuate all the services and databases from the cluster node that you want to patch
patch the binaries (depending on the versions and patches, this might be easy with
opatchauto or quite painful with manual unlocking/locking and manual opatch steps)
restart/relocate the services back on the node
repeat the tasks for every node

The disadvantages of in-place patching are many:

Need to stage the patch on every node

Need to repeat the patching process for every node
No easy rollback (some bad problems might lead to deconfiguring the cluster from one
node and then adding it back to the cluster)

Out-of-place patching

Out-of-place patching is proven to be much a better solution. I am doing it regularly since a

while for Oracle Database homes and I am very satisfied with it. I am implementing it at CERN
as well, and it will unlock new levels of server consolidation

I have written a blog series here, and presented about it a few times.

But out-of-place patching for Grid Infrastructure is VERY recent.

12cR2: opatchauto

Oracle 12cR2 introduced out-of-place patching as a new feature of opatchauto.

This MOS document explains it quite in detail:

Grid Infrastructure Out of Place ( OOP ) Patching using opatchauto (Doc ID 2419319.1)

The process is the following:

a preparation process clones the active Oracle Home on the current node and patches it
a switch process switches the active Oracle Home from the old one to the prepared clone
those two phases are repeated for each node

Privacy & Cookies Policy

www.ludovicocaldara.net/dba/gi18c-patching-part1/ 2/8
04/06/2020 Oracle Grid Infrastructure 18c patching part 1: Some history | DBA survival BLOG

The good thing is that the preparation can be done in advance on all the nodes and the switch
can be triggered only if all the clones are patched successfully.

However, the staging of the patch, the cloning and patching must still happen on every node,
making the concept of golden images quite useless for patching.

It is worth to mention, at this point, that Grid Infrastructure Golden Images ARE A THING, and
that they have been introduced by Rapid Home Provisioning release 12cR2, where cluster
automatic provisioning has been included as a new feature.

This Grid Infrastructure golden images have already been mentioned here and here.

I have discussed about Rapid Home provisioning itself here, but I will ad a couple of thoughts in
the next paragraph.

18c and the brand new Independent local-mode Automaton

I have been early tester of the Rapid Home Provisioning product, when it has been released
with Oracle 12.1.0.2. I have presented about it at UKOUG and as a RAC SIG webinar.
https://www.youtube.com/watch?v=vaB4RWjYPq0
http://www.ludovicocaldara.net/dba/rhp-presentation/

I liked the product A LOT, despite a few bugs due to the initial release. The concept of out-of-
placing patching that RHP uses is the best one, in my opinion, to cope with frequent patches
and upgrades.

Now, with Oracle 18c, the Rapid Home Provisioning Independent Local-mode Automaton
comes to play. There is not that much documentation about it, even in the Oracle
documentation, but a few things are clear:

The Independent local-mode automaton comes without additional licenses as it is not part
of the RHP Server/Client infrastructure
It is 100% local to the cluster where it is used
Its main “job” is to allow moving Grid Infrastructure Homes from a non-patched version to
an out-of-place patched one. Privacy & Cookies Policy
www.ludovicocaldara.net/dba/gi18c-patching-part1/ 3/8
04/06/2020 Oracle Grid Infrastructure 18c patching part 1: Some history | DBA survival BLOG

1 $ rhpctl move gihome –sourcehome Oracle_home_path -destinationhome Oracle_h

I will not disclore more here, as the rest of this blog series is focused on this new product

Stay tuned for details, examples and feedback from its usage at CERN

Ludo

Bio Latest Posts

Ludovico
Oracle ACE Director and Principal Consultant at Trivadis

Ludovico is an Oracle ACE Director, frequent speaker and community

contributor, working as Principal Consultant for Trivadis, the leading
Oracle consulting firm in Switzerland and German-speaking Europe.

This entry was posted in ACED, Oracle Database, Oracle Database 18c, Real Application
Cluster by Ludovico. Bookmark the permalink [http://www.ludovicocaldara.net/dba/gi18c-
patching-part1/] .

12 THOUGHTS ON “ORACLE GRID INFRASTRUCTURE 18C PATCHING PART 1: SOME HISTORY”

Michael Lewis
on November 28, 2018 at 2:23 am said:

Ludovico,

Looking forward to seeing your content on Local-mode Automaton.

Do you consider RHP Server ready to be used for deploying Grid?

Using 12.2.0.1… my experience using RHP to deploy DB homes and move between
them has been great.

In contrast my experience with using RHP to move grid homes hasn’t been that great.
When using RHP to move GI Homes… I have had inconsistent results across non-prod,
standby and prod clusters. Which has eroded my trust in this tool.

I am going to look at 18C version and see if it is more stable.

Regards

Michael Lewis Privacy & Cookies Policy

www.ludovicocaldara.net/dba/gi18c-patching-part1/ 4/8
04/06/2020 Oracle Grid Infrastructure 18c patching part 1: Some history | DBA survival BLOG

Ludovico
on November 30, 2018 at 5:04 pm said:

Hi Michael,
to be honest, I gave it just a small try with Grid Infrastructure deployments while
working at Trivadis. Because it was not stable in its initial release, I opted for custom
solutions to cope with my customer requirements.
Now I expect the 18c release to be better, but at CERN now we have already a fully
automated cluster installation (including storage, network and other prereqs), so we will
probably stick on our solution rather than trying to introduce the full RHP framework.
The local-mode automaton by opposite is exactly what I was looking for

Best regards
—
Ludovico

Norbert Gößwein
on April 29, 2019 at 1:52 pm said:

Hello,
I am looking for a place in the documentation that describes that the “Independent
local-mode automaton” is not part of the Lifecycle Management Pack. Can you please
name the reference to which your statement refers?

Best regards
Norbert Gößwein

Ludovico
on April 29, 2019 at 2:41 pm said:

Hi Norbert, Look at it the other way around:

the Database Licensing Information User Manual says that RHP is included in EE and
does not need Lifecycle Management Pack except if it is a cross-cluster deployment:
Privacy & Cookies Policy
www.ludovicocaldara.net/dba/gi18c-patching-part1/ 5/8
04/06/2020 Oracle Grid Infrastructure 18c patching part 1: Some history | DBA survival BLOG

“EE and EE-ES: When deployed across multiple clusters, requires Oracle Database
Lifecycle Management Pack for Oracle Database on targets”

https://docs.oracle.com/en/database/oracle/oracle-database/18/dblic/Licensing-
Information.html#GUID-0F9EB85D-4610-4EDF-89C2-4916A0E7AC87

As the local-mode automaton is local-only and not managed by a RHP server, it is

included in EE.

dinesh
on July 31, 2019 at 4:37 pm said:

In oracle 18c they mentioned Zero impact grid patching but dont find any details in
metalink or documentation could you do a post on oracle 18c grid zero impact
patching,it would be really helpful for the community

Ludovico
on August 23, 2019 at 2:51 pm said:

Hi dinesh, I will try to get more info about it then for sure!

Ken
on September 21, 2019 at 4:26 pm said:

memory lane correction if you care, oracle 8.0.x came out with OPS aka Oracle parallel
server, that was the 1st attempt by Oracle in building active-active cluster.
i like to look around heavy user of RHP like me to see what i can do better.

Ludovico
on October 25, 2019 at 10:13 am said: Privacy & Cookies Policy
www.ludovicocaldara.net/dba/gi18c-patching-part1/ 6/8
04/06/2020 Oracle Grid Infrastructure 18c patching part 1: Some history | DBA survival BLOG

Hi Ken, of course you are right. My memory lane was about the cluster layer. If I
remember correctly, OPS had no cluster layer (voting disks, quorums) also because no
cache fusion at the time. The disk sharing was assured by 3rd party clusters (veritas?)

Pratheek
on November 27, 2019 at 9:04 am said:

Hi,

Is there any testing completed on RHP in local mode, starting 19c this seems a very
good option (considering traditional OOP) to handle the gold images better.

Thanks

Ludovico
on November 27, 2019 at 2:45 pm said:

Yes, see Oracle Grid Infrastructure 18c patching part 2: Independent Local-mode
Automaton architecture and activation and Oracle Grid Infrastructure 18c patching part
3: Executing out-of-place patching with the local-mode automaton

Rajendra Giri
on February 16, 2020 at 7:06 pm said:

Hi Ludovico,

you mentioned that at CERN you have fully automated cluster installation/patching
including the infrastructure , Kindly share some detail about the solution if possible as I
am also looking something like this for our environment.

Many thanks
Raj

Privacy & Cookies Policy

www.ludovicocaldara.net/dba/gi18c-patching-part1/ 7/8
04/06/2020 Oracle Grid Infrastructure 18c patching part 1: Some history | DBA survival BLOG

Ludovico
on February 17, 2020 at 12:52 pm said:

Hi Raj,
once the servers are ready in the rack, their information is updated in a central
inventory.
As first step, the servers are automatically installed using PXE/TFTP using an OS
image. The install process include the puppet agent.
When we need to install a new cluster, we put the servers in a puppet hostgroup that
triggers the modules that set all the requirements (packages, parameters, users,
volumes, etc.). Then we run a rundeck job where we pass in input the hosts, the cluster
name and the Grid Infrastructure golden image.
The rundeck job itself is a series of script that prepares the ASM volumes, sets up the
firewall for the cluster, etc.. and then runs the gridSetup, the root.sh and the post config.
Sorry, I cannot share all the details, it would take a couple of books
—
Ludo

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Privacy & Cookies Policy

www.ludovicocaldara.net/dba/gi18c-patching-part1/ 8/8