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.


Über den Autor

Marco Mischke

Weitere Beiträge dieses Autors

Kommentare

Keine Kommentare

Kommentar schreiben

* Diese Felder sind erforderlich