Hochverfügbarkeit

In diesem Abschnitt werden bekannte Probleme mit der Hochverfügbarkeits-Datenbank (HADB) und zugehörige Lösungen erläutert.

HADB-Konfiguration in zweifachen Netzwerken. (Keine Fehlernummer)

Unter Solaris SPARC ist eine HADB-Konfiguration für zwei Netzwerke in zwei Teilnetzen problemlos möglich. Auf Solaris x86- und Linux-Plattformen führen jedoch Betriebssystem- bzw. Netzwerktreiberprobleme dazu, dass eine doppelte Netzwerkkonfiguration nicht immer einwandfrei ausgeführt wird. Dadurch entstehen folgende HADB-Probleme:

• Unter Linux werden bei der Meldungsübermittlung einige der HADB-Prozesse blockiert. Dadurch werden HADB-Knoten neu gestartet und eine Netzwerkpartitionierung durchgeführt.

• Unter Solaris x86 führt ein Netzwerkfehler dazu, dass nicht auf die andere Netzwerkschnittstelle gewechselt werden kann. Da dies nicht andauernd passiert, ist es immer noch besser, anstelle nur eines Netzwerks zwei Netzwerke zu haben. Diese Probleme sind in Solaris 10 teilweise gelöst.

• Abschneiden wird nicht unterstützt.

• HADB unterstützt keine doppelte Netzwerkkonfiguration unter Windows 2003 (Nr. 5103186).

Die Erstellung der HADB-Datenbank schlägt fehl. (Keine Fehlernummer)

Die Erstellung einer neuen Datenbank kann fehlschlagen und folgenden Fehler ausgeben, der besagt, dass zu wenig gemeinsame Speichersegmente verfügbar sind:

HADB-E-21054: Systemressource nicht verfügbar: HADB-S-05512: Anhängen des gemeinsamen Speichersegments mit Schlüssel "xxxxx" fehlgeschlagen, OS-Status=24 OS-Fehlermeldung: Zu viele Dateien geöffnet.

Lösung

Stellen Sie sicher, dass der gemeinsame Speicher konfiguriert wurde und die Konfiguration funktioniert. Prüfen Sie insbesondere unter Solaris 8 die Datei /etc/system und stellen Sie sicher, dass der Wert der Variable shmsys:shminfo_shmseg mindestens die sechsfache Anzahl der Knoten pro Host beträgt.

Gemeinsam verwendete Arbeitsspeichersegmente gesperrt und können nicht ausgelagert werden. (Nr. 5052548)

HADB 4.3-0.16 und höher ist für die Verwendung von beim Erstellen und Anfügen von gemeinsam verwendeten Arbeitsspeichersegmenten konfiguriert (verwendet das Flag SHM_SHARE_MMU ). Die Verwendung dieses Flag hat als wesentliche Wirkung, dass die gemeinsam verwendeten Arbeitsspeichersegmente im physischen Speicher gesperrt werden und nicht ausgelagert werden können. Die kann bei Installationen auf weniger leistungsstarken Computern schnell zu Problemen führen.

Wenn also einem Entwickler ein Computer mit 512 MB Arbeitsspeicher und einem recht großen Auslagerungbereich bei Verwendung von Application Server7.0 EE zur Verfügung steht, und 7.1 EE oder höher installiert wird, treten Probleme bei der Konfiguration des Standardclusters clsetup auf. Dieses erstellt zwei HADB-Knoten, jeweils mit einer devicesize von 512, was dazu führt, dass nicht genügend physischer RAM zur Verfügung steht, um den gemeinsamen Speicher zu unterstützen, die beide Knoten benötigen.

Lösung

Stellen Sie sicher, dass Sie über Arbeitsspeicher im empfohlenen Umfang verfügen, wenn Sie Application Server und HADB auf demselben Rechner installieren. Weitere Informationen finden Sie unter HADB-Anforderungen und unterstützte Plattformen.

hadbm set prüft Ressourcenverfügbarkeit nicht (Festplatte und Arbeitsspeicher). (Nr. 5091280)

Das Verwaltungssystem prüft beim Erstellen von Datenbanken und beim Hinzufügen von Knoten die Ressourcenverfügbarkeit. Die Verfügbarkeit der Ressourcen wird jedoch nicht geprüft, wenn mit hadbm set die Puffergröße des Geräts oder des Hauptspeichers geändert wird.

Lösung

Stellen Sie sicher, dass auf allen Hosts genügend freier Festplatten-/Arbeitsspeicher zur Verfügung steht, bevor Sie die Konfigurationsattribute devicesize bzw. buffersize erhöhen.

Heterogene Pfade für packagepath nicht unterstützt. (Nr. 5091349)

Es ist nicht möglich, ein und dasselbe Software-Paket unter demselben Namen in verschiedenen Pfaden auf unterschiedlichen Hosts zu registrieren, zum Beispiel:

hadbm registerpackage test --packagepath=/var/install1 --hosts europa11
Paket erfolgreich registriert.
hadbm registerpackage test --packagepath=/var/install2 --hosts europa12
hadbm:Fehler 22171: Ein Software-Paket wurde bereits unter dem Paketnamen test registriert.

Lösung

HADB unterstützt keine heterogenen Pfade für Knoten eines Datenbank-Clusters. Stellen Sie sicher, dass das Installationsverzeichnis des HADB-Servers (--packagepath) auf allen teilnehmenden Hosts identisch ist.

createdomain schlägt möglicherweise fehl. (Nr. 6173886, 6253132)

Wenn der Management-Agent auf einem Host mit mehreren Netzwerkschnittstellen ausgeführt wird, kann der Befehl createdomain fehlschlagen, wenn sich nicht alle Netzwerkschnittstellen im selben Teilnetz befinden:

hadbm:Fehler 22020: Die Management-Agents konnten keine
Domäne herstellen. Prüfen Sie, ob die Hosts mit UDP Multicast kommunizieren können.

Die Management-Agenten verwenden (falls nicht anders konfiguriert) die "erste" Schnittstelle für UDP-Multicasts (die "erste" gemäß Definition durch das Ergebnis von java.net.NetworkInterface.getNetworkInterfaces() ).

Lösung

Die beste Lösung besteht darin, dem Management-Agenten vorzuschreiben, welches Teilnetz er verwenden soll (setzen Sie ma.server.mainternal.interfaces in der Konfigurationsdatei, z. B. ma.server.mainternal.interfaces=10.11.100.0). Alternativ kann der Router zwischen den Teilnetzen so konfiguriert werden, dass er Multicast-Pakete weiterleitet (der Management-Agent verwendet die Multicast-Adresse 228.8.8.8).

Bevor Sie einen Versuch mit einer neuen Konfiguration der Management-Agenten unternehmen, müssen Sie eventuell die Management-Agent-Repository bereinigen. Beenden Sie alle Agenten in der Domäne und löschen Sie alle Dateien und Verzeichnisse im Repository-Verzeichnis (wird durch repository.dr.path in der Konfigurationsdatei des Management-Agenten identifiziert). Dies muss auf allen Hosts durchgeführt werden, bevor die Agenten mit einer neuen Konfigurationsdatei erneut gestartet werden.

Verzeichnisse müssen nach dem Löschen einer HADB-Instanz bereinigt werden. (Nr. 6190878)

Nach dem Löschen einer HADB-Instanz schlagen spätere Versuche, neue Instanzen mit dem Befehl configure-ha-cluster zu erstellen, fehl. Das Problem besteht darin, dass alte Verzeichnisse aus der ursprünglichen HADB-Instanz in ha_install_dir/rep/* und ha_install_dir/config/hadb/instance_name übrig bleiben.

Lösung

Achten Sie darauf, diese Verzeichnisse nach dem Löschen einer HADB-Instanz ebenfalls zu löschen.

Starten, Anhalten oder Neukonfiguration von HADB schlagen fehl oder führen dazu, dass das System nicht mehr reagiert. (Nr. 6230792, 6230415)

Unter Solaris 10 Opteron kann das Starten, Stoppen und erneute Konfigurieren der HADB mit dem Befehl hadbm fehlschlagen oder das System nicht mehr reagieren, wobei einer der folgenden Fehler ausgegeben wird:

hadbm:Fehler 22009: Der ausgegebene Befehl erzielte in den letzten 
300 Sekunden keinen Fortschritt.
HADB-E-21070: Der Vorgang konnte innerhalb des Zeitlimits nicht abgeschlossen werden, 
wurde jedoch nicht abgebrochen und wird eventuell zu einem späteren Zeitpunkt abgeschlossen.

Dies tritt u. U. auf, wenn es Unstimmigkeiten hinsichtlich des Lesens/Schreibens in eine Datei (nomandevice) gibt, die vom Prozess clu_noman_srv verwendet wird. Dieses Problem kann erkannt werden, indem in den HADB-Protokolldateien nach den folgenden Meldungen gesucht wird:

n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Untergeordneter Prozess noman3 
733 reagiert nicht.
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Keine Reaktion von ihm in 
104.537454 Sek.
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Untergeordneter Prozess noman3 
733 wurde nicht gestartet.

Lösung

Die folgende Problemlösung wurde noch nicht verifiziert, da das Problem noch nicht manuell reproduziert wurde. Jedoch sollte durch Ausführung dieses Befehls für den betroffenen Knoten das Problem gelöst werden.

hadbm restartnode --level=clear nodeno dbname

Beachten Sie, dass alle Geräte für den Knoten neu initialisiert werden. Eventuell müssen Sie den Knoten stoppen, bevor Sie ihn neu initialisieren.

Der Management-Agent wird mit dem Ausnahmefehler "IPV6_MULTICAST_IF fehlgeschlagen" beendet. (Nr. 6232140)

Beim Start auf einem Host, auf dem Solaris 8 ausgeführt wird und verschiedene NIC-Karten installiert sind, kann es passieren, dass bei Vorhandensein einer Mischung von Karten mit aktiviertem IPv6 und IPv4 der Management-Agent beendet wird und der Ausnahmefehler "IPV6_MULTICAST_IF fehlgeschlagen" auftritt."

Lösung

Legen Sie die Umgebungsvariable JAVA_OPTIONS auf -Djava.net.preferIPv4Stack=true fest; zum Beispiel:

export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true"

Alternativ verwenden Sie Solaris 9 oder höher. Dort tritt dieses Problem nicht auf.

clu_trans_srv kann nicht unterbrochen werden. (Nr. 6249685)

In der 64-Bit-Version von Red Hat Enterprise Linux 3.0 gibt es einen Bug, der dazu führt, dass der Prozess clu_trans_srv in einem Modus endet, der nicht unterbrochen werden kann, wenn asynchrones I/O ausgeführt wird. Das bedeutet, dass der Befehl kill -9 nicht funktioniert und das Betriebssystem neu gebootet werden muss.

Lösung

Verwenden Sie eine 32-Bit-Version von Red Hat Enterprise Linux 3.0.

hadbm unterstützt keine Passwörter, die Großbuchstaben enthalten. Nr. 6262824)

Großbuchstaben in Passwörtern werden in Kleinbuchstaben umgewandelt, wenn das Passwort in hadb gespeichert wird.

Lösung

Verwenden Sie keine Passwörter, die Großbuchstaben enthalten.

Beim Downgrading von HADB-Version 4.4.2.5 auf HADB-Version 4.4.1.7 schlägt M-A mit verschiedenen Fehlercodes fehl. (Nr. 6265419)

Beim Downgrading auf eine vorherige HADB-Version kann der Management-Agent mit verschiedenen Fehlercodes fehlschlagen.

Lösung

Es ist zwar möglich, einen Downgrade der HADB-Datenbank auszuführen, jedoch kann kein Downgrade für den Management-Agent ausgeführt werden, wenn Änderungen an den Repository-Objekten vorgenommen wurden. Nach einem Downgrade müssen Sie weiter den Management-Agent von der letzten HADB-Version verwenden.

Installation/Deinstallation und symlink-Beibehaltung. (Nr. 6271063)

Hinsichtlich der Installation/Deinstallation des HADB c-Pakets (Solaris: SUNWhadbc, Linux: sun-hadb-c) Version <m.n.u-p> wird symlink /opt/SUNWhadb/<m> niemals angefasst, sobald sie existiert. Daher ist es möglich, dass eine verwaiste symlink vorhanden ist.

Lösung

Löschen Sie symlink vor der Installation oder nach der Deinstallation; es sei denn, die Datei wird verwendet.

Management-Agenten in globalen und lokalen Zonen können stören. (Nr. 6273681)

Unter Solaris 10 wird durch Stoppen eines Management-Agenten mittels Verwendung des ma-initd-Skripts in einer globalen Zone der Management-Agent in der lokalen Zone ebenfalls angehalten.

Lösung

Installieren Sie den Management-Agent nicht sowohl in der globalen als auch der lokalen Zone.

hadbm/ma sollte eine bessere Fehlermeldung ausgeben, wenn ein Sitzungsobjekt die Zeitsperre überschritten hat und bei M-A gelöscht wurde. (Nr. 6275103)

Mitunter kann es durch einen Ressourcenkonflikt auf dem Server dazu kommen, dass der Management-Client getrennt wird. Bei der erneuten Verbindungsherstellung wird u. U. eine irreführende Fehlermeldung "hadbm:Fehler 22184: Zum Herstellen der Verbindung mit dem Management-Agenten ist ein Passwort erforderlich" zurückgegeben.

Lösung

Prüfen Sie, ob ein Ressourcenproblem auf dem Server vorliegt, ergreifen Sie geeignete Maßnahmen (z. B. fügen Sie weitere Ressourcen hinzu) und führen Sie den Vorgang erneut aus.

Nicht-Root-Benutzer können HADB nicht verwalten. (Nr. 6275319)

Die Installation mit Java Enterprise System (als Root) gibt von Root verschiedenen Benutzern keine Benutzerrechte zum Verwalten von HADB.

Lösung

Melden Sie sich immer als Root an, um HADB zu verwalten.

Der Management-Agent sollte keine besonderen Schnittstellen verwenden. (Nr. 6293912)

Schnittstellen für besondere Zwecke mit IP-Adressen wie 0.0.0.0 sollten nicht als gültige Schnittstellen registriert werden, die für HADB-Knoten im Management-Agenten verwendet werden. Die Registrierung solcher Schnittstellen kann zu Problemen führen, wenn an diesen Schnittstellen HADB-Knoten eingerichtet werden, indem ein Benutzer einen hadbm create-Befehl mithilfe von Hostnamen anstelle von IP-Adressen aufruft. Die Knoten können dann nicht kommunizieren und führen dazu, dass der create-Befehl hängt.

Lösung

Wenn Sie hadbm create auf Hosts mit mehreren Schnittstellen verwenden, müssen Sie immer die IP-Adressen angeben, die ausdrücklich die DDN-Notation verwenden.

Reassemblierungsfehler unter Windows. (Nr. 6291562)

Auf der Windows-Plattform kann es bei bestimmten Konfigurationen zu einer großen Anzahl von Reassemblierungsfehlern im Betriebssystem kommen. Das Problem trat bei Konfigurationen von mehr als zwanzig Knoten auf, als mehrere Tabellenscans (select *) gleichzeitig ausgeführt wurden. Symptome können sein, dass die Transaktionen häufig abbrechen, die Reparatur oder Wiederherstellung lange Zeit in Anspruch nehmen kann und es zu häufigen Zeitüberschreitungen an verschiedenen Stellen im System kommt.

Lösung

Um das Problem zu beheben, kann die Windows-Registrierungsvariable HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters auf einen Wert festgelegt werden, der höher ist als der Standardwert 100. Es wird empfohlen, diesen Wert auf 0x1000 (4096) zu erhöhen. Weitere Informationen finden Sie unter. Artikel 811003 der Microsoft-Supportseiten.

Bei der Ausführung von hadbm start <DB-Name> wird ein Teil des eingegebenen Passworts unmaskiert angezeigt. (Nr. 6303581, 6346059, 6307497)

Wenn ein Rechner stark ausgelastet ist, kann es vorkommen, dass der Maskierungsmechanismus versagt, und einige Zeichen des eingegebenen Passworts sichtbar sind. Dies stellt ein gewisses Sicherheitsrisiko dar und das Passwort sollte stets maskiert sein.

Lösung

Legen Sie die Passwörter in eigenen Passwortdateien ab (die normalerweise seit Application Server 8.1 empfohlene Methode) und beziehen Sie sich darauf mit den Optionen --adminpassword bzw. --dbpasswordfile.

Zugriff auf JES5 HADB bei Installation in globaler Zone von lokalen Sparse-Zonen aus nicht möglich (Nr. 6460979)

Wenn Application Server in einer globalen Solaris-Zone unter /usr/SUNWappserver installiert wird, ist die mit dieser Instanz von Application Server installierte HADB-Komponente nicht in lokalen Sparse-Zonen verfügbar.

Das Problem besteht darin, dass HADB unter /opt/SUNWhadb in der globalen Zone installiert wird, dieses Verzeichnis von lokalen Sparse-Zonen aus jedoch nicht lesbar ist. Leider kann das HADB-Bündel in JES5 nicht an einen anderen Ort verlagert werden.

Lösung

Da die HADB-Komponente von Application Server nicht verlagert werden kann, muss sie in jeder lokalen Sparse-Zone aus, von der aus auf HADB zugegriffen werden soll, separat installiert werden.