Installation von Grid Infrastruktur 19.17 auf Windows 2022 hängt mit Cluster Update State [ROLLING PATCH]

Bei einer Neuinstallation der Grid Infrastruktur 19.17 auf einem Windows 2022 Server kann es dazu kommen, dass die Installation mit „The cluster upgrade state is [ROLLING PATCH]“ hängen bleibt.

Aber fangen wir von Anfang an: Die Windows 2022 Server wurden neu installiert, die benötigten SAN Luns angebunden. Bei der Installation der Grid Infrastruktur 19.3 gab es kein Probleme. Nachdem der Grid Infrastruktur Cluster erfolgreich gelaufen ist mit dem Einspielen des 19.17 CPU weiter machen:

Node1

In einer CMD.EXE Command Line

set ORACLE_HOME=c:\oracle\product\19c\grid
set LD_LIBRARY_PATH=%ORACLE_HOME%\lib
set PERL5LIB=	
set PATH=%ORACLE_HOME%\perl\bin;%PATH%
%ORACLE_HOME%\crs\install\rootcrs.bat -prepatch

net stop msdtc
net stop OraFenceService
net start | findstr /i ora

cd C:\oracle\stage\19.17_p34468114_190000_MSWIN-x86-64\34468114
C:\oracle\product\19c\grid\OPatch\opatch apply -local

c:\oracle\product\19c\grid\bin\crssetup.exe deinstallfence
c:\oracle\product\19c\grid\bin\crssetup.exe installfence

net start OraFenceService
net start msdtc

%ORACLE_HOME%\crs\install\rootcrs.bat -postpatch

%ORACLE_HOME%\OPatch\opatch lspatches

%ORACLE_HOME%\bin\crsctl query crs activeversion -f
Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [ROLLING PATCH]. The cluster active patch level is [842068830].

Das einspielen den Critical Patch Update vom Oct2022 (19.17) hat auf der Node1 problemlos funktioniert. Da der zweite Knoten noch gepatched werden muss, ist der Status [ROLLING PATCH] korrekt. Der Patch Level wird erkannt [842068830], also weiter zum zweiten Knoten.

Node2

Genau die gleichen Befehle (Cut/Past) eingeben – auf der Console ist keine Fehlermeldung zurück gekommen, aber …

%ORACLE_HOME%\bin\crsctl query crs activeversion -f 
Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [ROLLING PATCH]. The cluster active patch level is [0].

Wie man hier sieht, wird auf dem zweiten Knoten das Patch-Level nicht erkannt. Der Cluster bleibt im Status [ROLLING PATCH] hängen! In den verschiedenen Log- und Tracefiles gibt es leider keine sinnvolle Fehlermeldungen…

Workaround / Lösung (nur auf der Node2!)

Nach langen debuggen war die Lösung den CPU 19.17 sauber zu deinstallieren und dann nochmals zu installieren – hier die Vorgehensweise:

Rollback von 19.17 Patch

set ORACLE_HOME=c:\oracle\product\19c\grid
set LD_LIBRARY_PATH=%ORACLE_HOME%\lib
%ORACLE_HOME%\crs\install\rootcrs.bat -prepatch

net stop msdtc
net stop OraFenceService

%ORACLE_HOME%\OPatch\opatch rollback -id 34468114

%ORACLE_HOME%\bin\crssetup.exe deinstallfence
%ORACLE_HOME%\bin\crssetup.exe installfence

net start OraFenceService
net start msdtc
			
%ORACLE_HOME%\crs\install\rootcrs.bat -postpatch -rollback

Using configuration parameter file: C:\oracle\product\19c\grid\crs\install\crsconfig_params
The log of current session can be found at:
C:\oracle\grid_base\crsdata\node2\crsconfig\crs_postpatch_node2_2022-11-11_11-11-09AM.log 2022/11/11 11:11:33 CLSRSC-196: ACFS driver install actions failed Died at C:\oracle\product\19c\grid\crs\install/crspatch.pm line 1339.

Auch das Rollback führt zu einem Fehler, aber diesen ignorieren wir einmal.

Erneutes Einspielen von 19.17 Patch

%ORACLE_HOME%\crs\install\rootcrs.bat -prepatch

net stop msdtc
net stop OraFenceService

cd C:\oracle\stage\19.17_p34468114_190000_MSWIN-x86-64\34468114
%ORACLE_HOME%\OPatch\opatch apply -local

%ORACLE_HOME%\bin\crssetup.exe deinstallfence
%ORACLE_HOME%\bin\crssetup.exe installfence

net start OraFenceService
net start msdtc

%ORACLE_HOME%\crs\install\rootcrs.bat -postpatch

%ORACLE_HOME%\bin\crsctl query crs activeversion -f
Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [NORMAL]. The cluster active patch level is [842068830].

Geschafft, der Cluster ist erfolgreich gepatched!

Es dürfte im Hintergrund beim Patchen von Node2 ein Fehler passiert sein weshalb der Cluster den nicht richtig erkannt hat obwohl alles gepasst hat. Erst durch den ROLLBACK (wichtig erst durch „rootcrs.bat -postpatch -rollback“ , ohne dem hat es nichts gebracht) und dem erneuten einspielen konnte das behoben werden. Es waren – wie schon gesagt – beim ersten Einspielen des Patches keine Fehler zu finden.

Warum kann man den Cluster nicht in [ROLLING PATCH] belassen?

  • Man kann in der Cluster Configuration nichts ändern (keine Datenbanken/Services anlegen, löschen oder modifizieren).
  • Das gleiche gilt auch für ASM Diskgroups, etc.
  • Das einspielen von weiteren Patches ist nicht mehr möglich.

Ob dieses Problem nur mit den RUs 19.16 und 19.17 auftritt ist uns nicht bekannt, mit älteren Oracle 19c Versionen ist dieser Fehler nicht aufgetreten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

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