YUM UPDATE stopped DB mit dNFS

Seit vielen Jahren - mit älteren Oracle Linux / RedHat Distributionen - war es durchaus üblich ein YUM UPDATE durchzuführen, während die Oracle Datenbank Services noch gelaufen sind, um die Downtime (wegen dem Server Reboot) zu minimieren. In den vielen, vielen Jahren, wo wir das schon so machen, hat es - auch bei unseren Kunden - nie ein größeres Problem damit gegeben. Natürlich bestand die Möglichkeit, dass es auf Grund von inkompatiblen Aufrufen zu einem Fehler oder sogar System-Crash kommen könnte, nur ist uns dies nie passiert.

Und dann kommt systemd

Grundsätzlich ist ja auch der Systemd nichts neues und wir haben auch hier über viele Jahre wie gewohnt unser YUM UPDATE im Vorfeld einer Downtime durchgeführt, nur plötzlich waren alle Datenbanken weg!

Auf Grund des Zeitpunkts - kurz vor dem Ende des YUM UPDATES - war der Zusammenhang nicht vor der Hand zu weisen. Ein Blick in /var/log/messages zeigt den direkten Zusammenhang:

...

Nov 17 08:48:05 mydbserver yum[21149]: Updated: 1:grub2-tools-minimal-2.02-0.87.0.3.el7.x86_64

Nov 17 08:48:05 mydbserver yum[21149]: Updated: 7:device-mapper-event-libs-1.02.170-6.0.3.el7.x86_64

Nov 17 08:48:05 mydbserver yum[21149]: Updated: 1:grub2-tools-2.02-0.87.0.3.el7.x86_64

Nov 17 08:48:06 mydbserver systemd: Reloading.

Nov 17 08:48:06 mydbserver systemd: Stopping RPC bind service...

Nov 17 08:48:06 mydbserver systemd: Stopping Oracle Datenbank Service...

Nov 17 08:48:06 mydbserver systemd: Stopped RPC bind service.

Nov 17 08:48:06 mydbserver stop_all.sh: Processing Database instance "mydb": log file /u01/app/oracle/product/19.0.0/dbhome_SE/rdbms/log/shutdown.log

Nov 17 08:48:36 mydbserver systemd: Stopped Oracle Datenbank Service.

Nov 17 08:48:36 mydbserver systemd: Stopping NFS status monitor for NFSv2/3 locking....

...

Analyse: was ist passiert?

Die Oracle Datenbank wird mit dNFS betrieben, sprich die Datenbank liegt auf NFS Shares. Obwohl bei dNFS die Oracle Datenbank die NFS Mounts selbst durchführt, und NICHT vom Operating System NFS abhängig ist, wird auf Grund der NFS Dependency im systemd Service File, das Datenbank Service gestoppt!

Schauen wir einmal in unser systemd Servicefile:

[Unit]

Description=Oracle Datenbank Service

Requires=rpc-statd.service network.target nfs.service nfs-mountd.service local-fs.target remote-fs.target

After=syslog.target network.target nfs.service nfs-mountd.service local-fs.target rpc-statd.service remote-fs.target

...

Da steht ganz klar bei Requires nfs.service sowie nfs-mountd.service! Aber stimmt das auch für Oracle dNFS? Leider Ja, weil Oracle - ausgenommen auf Windows - für dNFS voraussetzt, dass die NFS Mounts am OS vorhanden sind. Dies ist als "Fallback" gedacht. Zusätzlich fällt noch ins Gewicht, dass wir sowohl die DIAG Destination als auch die FRA - Flash Recovery Area - auf NFS liegen haben, und hier kein dNFS greift. Wir brauchen als die NFS Mounts!

Zusammenfassung

Sofern man die DIAG Destination und auch die Flash Recovery Area (sofern dort Files wie SPFILE, PWDFILE, SnapShot Controlfile, etc. liegen) nicht auf lokalen Disken ablegen kann oder will, muss man die Requires Abhängigkeiten belassen. Liegen wirklich nur die zur Datenbank gehörenden Files (DBF, OLOG, TEMP, CNTRL,...) auf NFS und man nutzt Oracle dNFS, könnte man die NFS Abhängigkeit aus dem Systemd Servicefile entfernen.

Lessions Learned

Mit Systemd und Oracle auf NFS darf man kein YUM UPDATE im Vorfeld einer Downtime machen, man muss auf die Downtime warten!

Breadcrumb