Oracle Grid Infrastructure und SLES

Während einer Neuinstallation eines Clusters mit der Oracle Grid Infrastructure 19.4 bei einem Kunden zeigte sich ein seltsamer Effekt. Die Datenbanken ließen sich mittels SQL*Plus wie gewohnt stoppen und starten, auch das Stoppen mittels "srvctl" funktionierte problemlos. Jedoch gab es Probleme beim Starten mit "srvctl" und auch beim Reboot eines Servers.Das stellte sich etwa wie folgt dar:

oracle@proddb20:~> srvctl start database -db db3p
PRCR-1079 : Failed to start resource ora.db3p.db
CRS-5017: The resource action "ora.db3p.db start" encountered the following error:
ORA-00444: background process "PXMN" failed while starting
ORA-27300: OS system dependent operation:fork failed with status: 11
. For details refer to "(:CLSN00107:)" in "/u01/app/grid/diag/crs/proddb20/crs/trace/crsd_oraagent_oracle.trc".

Um diesem Problem auf den Grund zu gehen, führte der erste Weg ins alert.log der Datenbank. Dort fanden sich etwas detailliertere Meldungen.

oracle@proddb20:~> tail /u01/app/oracle/diag/rdbms/db3p/db3p/trace/alert_db3p.log
2019-10-08T13:20:56.263194+02:00
Errors in file /u01/app/oracle/diag/rdbms/db3p/db3p/trace/db3p_psp0_187365.trc:
ORA-27300: OS system dependent operation:fork failed with status: 11
ORA-27301: OS failure message: Resource temporarily unavailable
ORA-27302: failure occurred at: skgpspawn3
2019-10-08T13:20:57.237250+02:00
Process LREG died, see its trace file
USER (ospid: ): terminating the instance due to ORA error
2019-10-08T13:20:58.269727+02:00
Instance terminated by USER, pid = 187344

Allerdings können diese Meldungen variieren, die fehlerhafte Funktion des ORA-27302 ist nicht immer dieselbe. Im Tracefile zur Fehlermeldung finden sich weitere Details.

oracle@proddb20:~> cat /u01/app/oracle/diag/rdbms/db3p/db3p/trace/db3p_psp0_187365.trc
Trace file /u01/app/oracle/diag/rdbms/db3p/db3p/trace/db3p_psp0_187365.trc
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Build label:    RDBMS_19.3.0.0.0DBRU_LINUX.X64_190417
ORACLE_HOME:    /u01/app/oracle/product/19.3.0/db_ee_1
System name:    Linux
Node name:      proddb20
Release:        4.4.166-3.g849dcaf-default
Version:        #1 SMP Fri Dec 7 15:18:32 UTC 2018 (849dcaf)
Machine:        x86_64
Instance name: db3p
Redo thread mounted by this instance: 0 <none>
Oracle process number: 4
Unix process pid: 187365, image: oracle@proddb20 (PSP0)


*** 2019-10-08T13:20:56.240852+02:00
*** SESSION ID:(61.55718) 2019-10-08T13:20:56.240872+02:00
*** CLIENT ID:() 2019-10-08T13:20:56.240876+02:00
*** SERVICE NAME:() 2019-10-08T13:20:56.240879+02:00
*** MODULE NAME:() 2019-10-08T13:20:56.240882+02:00
*** ACTION NAME:() 2019-10-08T13:20:56.240885+02:00
*** CLIENT DRIVER:() 2019-10-08T13:20:56.240887+02:00

Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 11
ORA-27301: OS failure message: Resource temporarily unavailable
ORA-27302: failure occurred at: skgpspawn3
OS - DIAGNOSTICS
----------------
loadavg : 0.27 0.12 0.11
Memory (Avail / Total) = 118346.89M / 128328.88M
Swap (Avail / Total) = 16386.00M /  16386.00M
Max user processes limits(s / h) =  65536 / 65536
----------------

Die erste Vermutung war, das Kernelparameter oder ulimits nicht korrekt gesetzt wurden, dies war jedoch nicht der Fall. Alle Einstellungen waren in Ordnung. 

Daher bemühten wir nun My Oracle Support und fanden recht schnell SLES 12: Database Startup Error with ORA-27300 ORA-27301 ORA-27303 While Starting using Srvctl (Doc ID 2340986.1). Dort wird auf eine neue Funktionalität namens "cgroup controller" in SLES 12 hingewiesen. Diese beschränkt die maximale Anzahl von Tasks pro Prozess (PID). Per Default werden hier 512 Tasks pro Prozess erlaubt. Für die Grid Infrastructure im Grundzustand ohne laufende Datenbanken stellt sich das wie folgt dar:

proddb20:~ # systemctl status ohasd
ohasd.service - LSB: Start and Stop Oracle High Availability Service
   Loaded: loaded (/etc/init.d/ohasd; bad; vendor preset: disabled)
   Active: active (exited) since Fri 2019-10-04 14:30:19 CEST
     Docs: man:systemd-sysv-generator(8)
  Process: 4024 ExecStart=/etc/init.d/ohasd start (code=exited, status=0/SUCCESS)
    Tasks: 471 (limit: 512) 

Man sieht sofort, das bereits mit einer laufenden Grid Infrastructure bereits recht viele Tasks laufen und man sich schon stark dem Limit nähert. Folgerichtig schlägt dann das Starten einer Datenbank fehl, da damit das Limit überschritten wird. 

Eingestellt wird dieses Limit über die Datei "/etc/systemd/system.conf", dort muss entsprechend der Wert für "DefaultTasksMax" erhöht werden.

proddb20:~ # grep DefaultTasksMax /etc/systemd/system.conf 
#DefaultTasksMax=512

proddb20:~ # vi DefaultTasksMax /etc/systemd/system.conf 

proddb20:~ # grep DefaultTasksMax /etc/systemd/system.conf 
DefaultTasksMax=65535

nach einem Reboot des Servers ist die neue Einstellung aktiv und die Grid Infrastructure darf wesentlich mehr Tasks starten. Dementsprechend starten nun auch die Datenbanken beim Start des Servers und lassen sich auch per "srvct" nunmehr nicht nur beenden, sondern auch starten.

proddb20:~ # systemctl status ohasd
ohasd.service - LSB: Start and Stop Oracle High Availability Service
   Loaded: loaded (/etc/init.d/ohasd; bad; vendor preset: disabled)
   Active: active (exited) since Tue 2019-10-08 14:30:19 CEST; 1min 12s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 4024 ExecStart=/etc/init.d/ohasd start (code=exited, status=0/SUCCESS)
    Tasks: 463 (limit: 65535)

Ist ist also eine gute Idee, das Limit noch vor der initialen Installation zu setzen um Probleme beim weiteren Aufbau des Clusters zu vermeiden.