Unter Linux (Debian) bricht eine zuvor funktionierende Oracle-Datenbank beim Hochfahren plötzlich ab. Die Meldung lautet:

ORA-00845: MEMORY_TARGET not supported on this system

Im Netz wird in Blogs als Lösung genannt, man möge /dev/shm mounten

# mount -t tmpfs tmpfs -o size=2g /dev/shm

oder, falls /dev/shm bereits gemountet ist, den Speicher vergrößern

# mount -o remount,size=2g /dev/shm

Dies hat beides allerdings nicht geholfen, da es eine weitere Fehlerursache gibt. Die Meldung im alert_<DB>.log zu dem Fehler lautet:

WARNING: You are trying to use the MEMORY_TARGET feature. This feature
requires the /dev/shm file system to be mounted for at least
1275068416 bytes. /dev/shm is either not mounted or is mounted with
available space less than this size. Please fix this so that MEMORY_TARGET
can work as expected. Current available is 0 and used is 0 bytes.
Ensure that the mount point is /dev/shm for this directory.

Der entscheidende Punkt in der Meldung, welcher zur Lösung führt, ist, dass Oracle keinen verfügbaren Speicher erkennt ("Current available is 0 and used is 0 bytes") und dass der Mountpoint exakt /dev/shm sein muss ("Ensure that the mount point is /dev/shm for this directory").

Letztere Bedingung war auf dem Debian-System (testing) nicht erfüllt:

# df -h /dev/shm
Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 3.0G     0  3.0G   0% /run/shm

Als Mountpoint wird hier nicht /dev/shm angezeigt, sondern /run/shm, weil /dev/shm lediglich ein Symlink auf /run/shm ist:

# ls -l /dev/shm
lrwxrwxrwx 1 root root 8 Aug 7 09:37 /dev/shm -> /run/shm

Mit diesem Setup kommt der Oracle-Kernel (11.2.0.1.0) nicht klar. Er erkennt (aus nicht weiter erforschten Gründen) die Größe des Shared-Memory-Bereichs nicht.

Der Fix besteht darin, im Oracle-Kernel alle Vorkommen von /dev/shm durch /run/shm zu ersetzen:

# cd $ORACLE_HOME/bin
# cp oracle oracle.bak
# sed 's|/dev/shm|/run/shm|g' oracle.bak >oracle

Danach fährt die Datenbank wieder hoch:

$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Fri Aug 7 13:29:21 2020

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 1272213504 bytes
Fixed Size		    1336260 bytes
Variable Size		  805309500 bytes
Database Buffers	  452984832 bytes
Redo Buffers		   12582912 bytes
Database mounted.
Database opened.

Links

• Oracle Database Software Downloads
• Oracle Database Documentation

Gegeben ist eine Tabelle <table> mit einer Kolumne <x>, deren Wert frei manipuliert werden kann, und einer Kolumne <y>, deren Wert funktional von <x> abhängt (also nicht frei manipuliert werden kann). Die Abbildung von <x> auf <y> ist in einer Lookup-Tabelle <lookup_table> definiert, die jedem Wert <x> den entsprechenden Wert <y> zuordnet.

Aufgabe: Der <y>-Wert soll in <table> gespeichert werden und stets konstitent zu <x> sein. Der Wert von <y> soll nicht erst bei Abfrage ermittelt werden. Im Prinzip ist das eine unerwüschte Redundanz, die aber aus praktischen Gründen sinnvoll sein kann.

Die Anforderung lässt sich durch einen BEFORE INSERT OR UPDATE-Trigger erfüllen, der beim Einfügen oder Ändern in <table> den <y>-Wert via <x> in <lookup_table> ermittelt und auf <table>.<y> überträgt.

Es folgt die Lösung für Oracle und PostgreSQL.

Oracle

 1 CREATE OR REPLACE TRIGGER <tigger> BEFORE INSERT OR UPDATE
 2     ON <table> FOR EACH ROW
 3 BEGIN
 4     SELECT
 5         <y>
 6     INTO
 7         :new.<y>
 8     FROM
 9         <lookup_table>
10     WHERE
11         <x> = :new.<x>;
12 END;

PostgreSQL

 1 CREATE FUNCTION <trigger_func>() RETURNS trigger AS $$
 2 BEGIN
 3     SELECT
 4         <y>
 5     INTO STRICT
 6         NEW.<y>
 7     FROM
 8         <lookup_table>
 9     WHERE
10         <x> = NEW.<x>;
11 
12     RETURN NEW;
13 END;
14 $$ LANGUAGE plpgsql;
15 
16 CREATE TRIGGER <trigger> BEFORE INSERT OR UPDATE
17     ON <table> FOR EACH ROW
18     EXECUTE PROCEDURE <trigger_func>();

Der Code ist bei beiden Datenbanksystemen ähnlich, die Unterschiede sind im Wesentlichen:

• Die Prozedur kann bei Oracle als Teil des Trigger definiert werden, was den Code einfach und elegant macht. Bei PostgreSQL ist eine spezielle, vom Trigger getrennte Prozedurdefinition erforderlich.

• Der Bezeichner für die neue Tabellenzeile ist bei Oracle :new, bei PostgreSQL NEW. Bei PostgreSQL muss diese Zeile von der Trigger-Prozedur zurückgeliefert werden. Bei Oracle wird nichts zurückgeliefert.

• PostgreSQL generiert bei INTO STRICT automatisch eine Exception, wenn durch das SELECT keine oder mehr als eine Zeile getroffen wird. Dies ist ein kostenloser Paranoia-Test für die Daten in <lookup_table>.

Eine Anleitung zum Installieren von Oracle 11g unter Debian, die versucht, mögliche Probleme von vornherein auszuschließen, dafür aber umfangreiche Vorarbeiten verlangt, findet sich hier: http://edin.no-ip.com/blog/hswong3i/oracle-database-11g-release-1-debian-sid-howto

Meine Anleitung hat das Ziel, die Voraussetzungen für den Aufruf des Installers zu schaffen. Da der Installer selbst den Softwarestand und die Kernelparameter prüft, können Anpassungen auch bei laufender Installation vogenommen werden.

Abbildung 1: Allgemeine Konfigurationsangaben im Installer

Schritt 1: Download

Dateien von Oracle.com herunterladen: Download 11g Enterprise Edition (Hierfür ist ein OTN-Konto nötig)

Schritt 2: Oracle-Benutzer und DBA-Gruppe erzeugen

# addgroup --system dba
# adduser --system --home /opt/oracle --shell /bin/bash --ingroup dba
  --gecos 'Oracle DBA' oracle
# passwd oracle

Schritt 3: Dateien entpacken

Auf Benutzer oracle wechseln, unter dessen Rechten wird die weitere Installation durchgeführt:

# su - oracle
$ unzip linux_11gR2_database_1of2.zip
$ unzip linux_11gR2_database_2of2.zip

Die Dateien werden von unzip in ein Unterverzeichnis database entpackt. Wo entpackt wird, ist egal. Die entpackten Dateien werden nur während der Installation gebraucht. Nach der Installtion kann das gesamte Verzeichnis gelöscht werden.

Schritt 4: Installer ausführen

Wichtig: Wurde der Desktop unter einem anderen Benutzer als oracle gestartet, muss der Benutzer den Desktop für den Zugriff des Benutzers oracle freigeben, da dieser den Installer aufruft. Geschieht die Freigabe nicht, stirbt der Installer nach einigen Sekunden mit der wenig aussagekräftigen Fehlermeldung

No protocol specified
[Java Stacktrace]

Die Freigabe erfolgt mit dem Kommando:

<user>$ xhost +

Als Benutzer oracle ausführen:

$ cd database
$ ./runInstaller

Der Installer führt den Benutzer durch die Installation, nimmt zahlreiche Prüfungen vor und schreibt ein Logfile, das bei Problemen konsultiert werden kann.

Unstimmigkeiten können parallel behoben werden, Prüfungen und fehlgeschlagene Schritte können immer wieder neu durchgeführt werden bis es klappt.

Abbildung 2: Kernel- und Software-Prüfungen durch den Installer

Installierte Dateien

Konfigurationsdateien in /etc

/etc/oraInst.loc
/etc/oratab

Die eigentliche Installation

/opt/oracle/app/*

Hilfsprogramme

/usr/local/bin/oraenv
/usr/local/bin/coraenv
/usr/local/bin/dbhome

Datenbank-Dateien

/var/opt/oracle/<DATABASE>/*