Konfiguriert man anhand des „Oracle Grid Infrastructure Installation and Upgrade Guides 19c for Linux“ die doch recht bekannten Kernel Parameter wie bspw. shmall, shmmax semmni oder file-max entsprechend der Vorgaben aus dem Installation Guide, so kann man im Eifer des Gefechtes schnell übersehen, dass explizit für das SUSE Linux Enterprise Server System auch der Parameter vm.hugetlb_shm_group gesetzt werden muss.
Ist die Gruppenidentifikationsnummer der Gruppe „oinstall“ bspw. 1000, so trägt man diesen Wert für den Parameter /proc/sys/vm/hugetlb_shm_group wie folgt ein:
# echo 1000 > /proc/sys/vm/hugetlb_shm_group
Der Parameter vm.hugetlb_shm_group=1000 muss anschließend noch mit einem Editor in die Kernel Parameter Datei, z. B. unter /etc/sysctl.d/97-oracle-database-sysctl.conf hinzugefügt und als root mit dem Befehl
# /sbin/sysctl --system
aktiviert werden.
Seit der Version SLES 12 ist der DefaultTasksMax Parameter standardmäßig auf den Wert 512 eingestellt. Das kann zu einer Fehlfunktion der Services führen, da diese nicht mehr als 512 Prozesse oder Threads erzeugen können. So kann es beim Starten einer Datenbankinstanz via srvctl zu den im My Oracle Support (MOS) unter der Doc Id 2340986.1 genannten Fehlern wie
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
verbunden mit einem kurz danach stattfindenden Abbruch der Instanz kommen, da der Oracle High Availability Service Daemon (ohasd) nicht mehr als 512 Prozesse erzeugen darf.
In Bild 1 wird aber ersichtlich, dass der ohasd im Alltagsbetrieb weit mehr als die 512 Prozesse erzeugt.
Bild 1: Statusabfrage des ohasd und DefaultTasksMax
Abhilfe kann geschafft werden, indem man den Wert für den Parameter DefaultTasksMax in der Datei /etc/systemd/system.conf ausreichend hoch (65535) setzt, so dass der ohasd in der Lage ist, mehr als die 512 Prozesse zu erzeugen. Nach Setzen des Parameters muss der ohasd neu gestartet werden, um die Änderung zu aktivieren.
Eine weitere Thematik ist die Hardware Lock Elision bei den Intel CPUs. Gemäß SuSE Document ID 7022289 „How to disable Hardware Lock Elision“ existiert ein Bug in einigen Intel CPUs, der die korrekte Ausführung der Lock Elision nicht ermöglicht. Weiter heißt es dort, dass die Oracle Grid Software anfällig für diesen Bug sei und es demzufolge während der Initialisierung zu einem Crash kommen kann. Um also Fehler wie
CRS-8503 [__lll_unlock_elision()+48] [Signal/Exception: 11] [Instruction Addr: 0x7f517e0b05e0] [Memory Addr: (nil)] [] [] [] [] [] [] [] []
zu vermeiden, ist es ratsam, vor Beginn der Installation die Hardware Lock Elision zu deaktivieren. Dies erreicht man, indem man auf den Knoten im Clusterverbund in der Datei /etc/ld.so.conf.d/noelision.conf den Wert /lib64/noelision einträgt und anschließend mit „Idconfig“ die Systembibliotheken in der Binärdatei /etc/ld.so.cache aktualisiert.
FoC_node:/etc/ld.so.conf.d # ls -l
total 4
-rw-r--r-- 1 root root 17 Dec 10 08:46 noelision.conf
FoC_node:/etc/ld.so.conf.d # cat noelision.conf
/lib64/noelision
detest1:/etc/ld.so.conf.d #
Da die Lock Elision die „libpthread“ Bibliotheken benutzt, sollten diese nach der erfolgreichen Aktualisierung wie folgt angezeigt werden:
FoC_node:/etc # ldconfig -p | grep noelision
libpthread.so.0 (libc6,x86-64, OS ABI: Linux 3.0.0) => /lib64/noelision/libpthread.so.0
Ruft man „gridSetup.sh“ auf kann es bei der Konfiguration des Clusters (Schritt 4 von 17) zu folgender Fehlermeldung kommen:
[INS-06006] Passwordless SSH connectivity not set up between the following node(s): [<racnode2>].
Man wundert sich darüber, hatte man doch bereits im Vorfeld mit ssh-keygen die passwortlose Verbindung von einem zum anderen Rechner (und umgekehrt) eingerichtet und mit ssh auch schon erfolgreich getestet. Auch ein anschließender Versuch die SSH-Verbindung über die GUI einzurichten und anschließend zu testen, scheitert. Die Installation der Oracle 19.3c GI bricht an dieser Stelle ab.
Grund für den Abbruch ist das Vorhandensein von OpenSSH_7.2p2 in Kombination mit dem Betriebssystem SLES Linux 12 SP4.
FoC_node:~ # ssh -V
OpenSSH_7.2p2, OpenSSL 1.0.2p-fips 14 Aug 2018
Diesen Fehler umgeht man, indem man wie im MOS unter Doc_Id 2555697.1 beschrieben, die originäre Datei /usr/bin/scp umbenennt, anschließend eine neue leere „scp“ Datei erzeugt und diese neu erzeugte Datei mit einem Verweis und der Option „-T $*“ auf die originäre Datei versieht
mv /usr/bin/scp /usr/bin/scp.orig
vi /usr/bin/scp
cat /usr/bin/scp
/usr/bin/scp.orig -T $*
Nach Fertigstellung der GI Installation darf man nicht vergessen, diese Änderungen durch Umbenennung der originären Datei auf den alten Namen wieder rückgängig zu machen:
mv /usr/bin/scp.orig /usr/bin/scp
Das Aufspüren und das Abstellen von – auch vermeintlich kleinen und weniger bekannten - Fehlerquellen ist im Vorfeld einer Clusterware-Installation ein wichtiger Arbeitsschritt, damit im Nachhinein die Installation selbst auf Anhieb gelingt und fehlerfrei durchgeführt werden kann.
Wenden Sie sich an unsere erfahrenen DBAs und Consultants. Wir beraten Sie gerne in allen Themen rund um Ihre Cluster-Installation.
In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den
Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.
