In diesem Abschnitt werden bekannte Probleme mit der Hochverfügbarkeits-Datenbank (HADB) und zugehörige Lösungen erläutert.
Bug-ID |
Zusammenfassung |
|||
---|---|---|---|---|
keine ID |
HADB-Konfiguration mit Doppelnetzwerken. 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:
|
|||
keine ID |
Die Erstellung der HADB-Datenbank schlägt fehl. 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. |
|||
5052548 |
Gemeinsam verwendete Arbeitsspeichersegmente gesperrt und können nicht ausgelagert werden. 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 Anwendungsserver7.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. |
|||
5091280 |
hadbm set prüft Ressourcenverfügbarkeit nicht (Festplatte und Arbeitsspeicher). 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. |
|||
5091349 |
Heterogene Pfadangaben für packagepath werden nicht unterstützt. Es ist nicht möglich, ein und dasselbe Software-Paket unter demselben Namen in verschiedenen Pfaden auf unterschiedlichen Hosts zu registrieren, zum Beispiel:
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. |
|||
6173886, 6253132 |
createdomain schlägt u. U. fehl. 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:
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. |
|||
6190878 |
Verzeichnisse müssen nach dem Löschen einer HADB-Instanz bereinigt werden. 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. |
|||
6230792, 6230415 |
Das Starten, Stoppen und erneute Konfigurieren der HADB kann fehlschlagen oder nicht mehr reagieren. 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:
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:
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.
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. |
|||
6232140 |
Der Management-Agent wird mit dem Ausnahmefehler "IPV6_MULTICAST_IF fehlgeschlagen" beendet. 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:
Alternativ verwenden Sie Solaris 9 oder höher. Dort tritt dieses Problem nicht auf. |
|||
6249685 |
clu_trans_srv kann nicht unterbrochen werden. 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. |
|||
6262824 |
hadbm unterstützt keine Passwörter, die Großbuchstaben enthalten. 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. |
|||
6265419 |
Beim Downgrading von HADB-Version 4.4.2.5 auf HADB-Version 4.4.1.7 schlägt M-A mit verschiedenen Fehlercodes fehl. 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. |
|||
6271063 |
Installation/Deinstallation und symlink-Erhaltung. 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. |
|||
6273681 |
Management-Agenten in globalen und lokalen Zonen können stören. 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. |
|||
6275103 |
hadbm/ma sollte eine bessere Fehlermeldung ausgeben, wenn ein Sitzungsobjekt die Zeitsperre überschritten hat und bei M-A gelöscht wurde. 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. |
|||
6275319 |
Von Root verschiedene Benutzer können HADB nicht verwalten. 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. |
|||
6293912 |
Der Management-Agent sollte keine besonderen Schnittstellen verwenden. 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. |
|||
6291562 |
Unter Windows schlägt die Reassemblierung fehl. 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. |
|||
6303581, 6346059, 6307497 |
Beim Ausführen von hadbm start <db_name>, wird ein Teil des eingegebenen Passworts unmaskiert angezeigt. 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 Anwendungsserver 8.1 empfohlene Methode) und beziehen Sie sich darauf mit den Optionen --adminpassword bzw. --dbpasswordfile. |