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.