In der folgenden Tabelle werden Probleme aufgeführt, die auftreten können,
ihre wahrscheinlichen Ursachen beschrieben und Maßnahmen zu ihrer Behebung
erläutert.
Tabelle 61. Fehlerbehebung bei hoher Verfügbarkeit unter Sun Cluster 2.2
Symptom | Mögliche Ursache | Maßnahme |
---|---|---|
Dateisystem von logischem Host läßt sich nicht anhängen. | Das Dateisystem des logischen Hosts wird normalerweise während der Funktionsübernahme eines logischen Hosts angehängt und abgehängt. Während der Funktionsübernahme sollten keine aktiven Prozesse oder geöffneten Dateien unter dem Dateisystem des logischen Hosts vorhanden sein. In seltenen Fällen haben Prozesse, die nicht zwangsweise beendet werden können, ihr aktuelles Arbeitsverzeichnis unter dem Dateisystem des logischen Hosts. Verwenden Sie fuser(1m) oder ein GNU-Dienstprogramm namens lsof, um herauszufinden, ob ein Prozeß unter dem Mount-Punkt vorhanden ist. Fehlernachrichten werden generiert, wenn das Dateisystem des logischen Hosts nicht angehängt werden kann.a | Starten Sie das System erneut oder versetzen Sie das Dateisystem des logischen Hosts in einen anderen Namen und erstellen Sie es erneut. Dadurch kann der eingefrorene Prozeß unter dem Verzeichnis bleiben (da er nicht abgebrochen werden kann), und das Anhängen kann stattfinden.b |
Das Zeitlimit für db2start oder db2stop funktioniert nicht. | Ein Signal SIGALRM kann eventuell nicht aus einem blockierenden Systemaufruf ausbrechen. Statt dessen wird der Systemaufruf erneut gestartet so, als wäre die Markierung (Flag) SA_RESTART mit sigaction() gesetzt. Dies bewirkt, daß Zeitlimits für die DB2-HA-Agenten ignoriert werden und die Agentenmethode blockiert, anstatt einen blockierten Befehl db2start oder db2stop zu beheben. | Wenden Sie die erforderliche Programmkorrektur (Patch) 105210-17 (oder eine spätere) für Solaris 2.6 an. |
Anmelden in Exemplar blockiert. | Obwohl es zahlreiche Ursachen hierfür geben kann, gehören zu den häufigsten Ursachen NFS-Probleme und das Programm /usr/sbin/quota. | Überprüfen Sie die angehängten NFS, um sicherzustellen, daß sie ordnungsgemäß funktionieren, und suchen Sie nach Quota-Prozessen, die dem Exemplareigner gehören. Das Problem kann eventuell durch eine Änderung des Quota-Programms in eine symbolische Verbindung zu /bin/true behoben werden, was jedoch im Ermessen des Systemadministrators liegt. Dies ist keine empfohlene Lösung, aber sie funktioniert vielleicht. |
Nach der Einrichtung eines EEE-Exemplars läßt sich dieses nicht starten. | Der Befehl hadb2_setup fügt keine Ports in der Datei /etc/services ein. Es wird erwartet, daß der Administrator diese manuell hinzufügt. Es wird eine Fehlernachricht zurückgegeben.c | Stellen Sie sicher, daß Sie die richtigen Ports in der Datei /etc/services eingetragen haben. |
Methode START_NET kann DB2 nicht starten. |
| Schalten Sie die Fehlerüberwachung aus, um sicherzustellen, daß das
Exemplar nicht übernommen wird. Melden Sie sich als Exemplareigner an,
und versuchen Sie DB2 manuell zu starten.
|
Das Exemplar funktioniert nur auf einer Maschine. |
| Wenn keine dieser Ursachen zuzutreffen scheint, versuchen Sie, sich als Exemplareigner anzumelden und DB2 manuell zu starten. Für EE-Exemplare sollte dies funktionieren, wenn der logische Host, der dem Exemplar zugeordnet ist, auf der aktuellen Maschine aktiv ist. Für EEE-Exemplare sollte dies von jeder Maschine im Cluster aus funktionieren, die die Datenbankpartitionen übernehmen kann. |
su - <exemplar> -c "db2start" funktioniert nicht. |
|
|
Das EEE-Exemplar kann nicht starten, aber das Ausgangsverzeichnis wird angehängt. | Das HA-NFS-Verzeichnis wurde eventuell nicht mit der Root-Berechtigung an die Maschinen im Cluster exportiert. Sowohl für DB2 als auch für die HA-Agenten muß dieses Verzeichnis ordnungsgemäß arbeiten. | Versuchen Sie testweise, eine Datei (als Root) unter dem Ausgangsverzeichnis des Exemplareigners zu erstellen. |
Der Versuch eines Zugriffs auf das EEE-Exemplarverzeichnis liefert eine Fehlernachricht "Stale NFS file handle". | Es gibt eventuell noch Prozesse unter dem Ausgangsverzeichnis des Exemplareigners. | Hängen Sie das Ausgangsverzeichnis des Exemplareigners ab, und lassen Sie den HA-Agenten es erneut anhängen. Der HA-Agent hängt es wieder an, wenn der Service hadb2 inaktiviert und wieder aktiviert wird (Siehe Beschreibung des Schalters -s in Der Befehl hadb2_setup). |
Steuermethoden werden durch SC2.2 nicht erfolgreich ausgeführt. | Der Service hadb2 ist eventuell nicht bei der Sun Cluster-Software registriert oder er ist inaktiviert. | Wenn es scheint, als könnten die Steuermethoden über die Befehlszeile
normal ausgeführt werden, prüfen Sie die SYSLOG-Dateien auf Fehlernachrichten,
die helfen, das Problem zu erklären. Stellen Sie sicher, daß der
Service hadb2 bei der Sun Cluster-Software registriert ist und daß
er aktiviert ist.
Die manuelle Ausführung der Methoden ist zur Lösung eines Problems hilfreich.d Die Methoden sollten mit Root-Berechtigung und den entsprechenden Befehlszeilenparametern ausgeführt werden. Wenn die Liste logischer Host leer ist, sollte der Parameter als "" angegeben werden. Doppelte Anführungszeichen ohne Leerzeichen als Trenner bezeichnen ein leeres Argument. Beispiel: hadb2_startnet log0,log1 "" 600 Das erste Argument log0,log1 teilt der Methode hadb2_startnet mit, daß die logischen Hosts log0 und log1 auf der aktuellen Maschine aktiv sind. Das zweite Argument ist leer, was der Methode hadb2_startnet anzeigt, daß es keine anderen logischen Hosts gibt, die auf anderen Maschinen im Cluster aktiv sind (alle sind auf der aktuellen Maschine aktiv). Das dritte Argument teilt der Methode mit, daß SC2.2 ein Zeitlimit von 600 Sekunden setzt. |
Benutzerprozeduren lassen sich nicht ausführen. | Die Benutzerprozeduren können nur ausgeführt werden, wenn sie in den richtigen Verzeichnissen vorhanden und ausführbar sind. | Überprüfen Sie die Eigentumsrechte und Attribute der Dateien. Wenn eine Prozedur sich nicht ausführen läßt, wenden Sie sich an den IBM Kundendienst. Leiten Sie ein Verzeichnislisting der Prozedur, die sich nicht ausführen läßt und die SYSLOG-Ausgabe für eine Funktionsübernahme bzw. einer Äderung der Clusterkonfiguration weiter, durch die die Prozedur hätte ausgeführt werden müssen. |
Informationen werden nicht in der in /etc/syslog.conf angegebenen Datei protokolliert. |
| Verwenden Sie touch(1) zur Erstellung der Datei, die in der Datei /etc/syslog.conf angegeben ist, und starten Sie den SYSLOG-Dämon erneut. |
a Fehlernachrichten, die generiert werden, wenn das Dateisystem des logischen Hosts nicht angehängt werden kann, können etwa wie folgt aussehen: Aug 17 11:14:01 rash ID[SUNWcluster.loghost.1170]: importing data1 Aug 17 11:14:06 rash ID[SUNWcluster.scnfs.3040]: mount -F ufs -o "" /dev/vx/dsk/data1/data1-stat /log1 failed. Aug 17 11:14:07 rash ID[SUNWcluster.ccd.ccdd.5304]: error freeze cmd = /opt/SUNWcluster/bin/loghost_sync CCDSYNC_POST_ADDU LOGHOST_CM:log1:rash /etc/opt/SUNWcluster/conf/ccd.database 2 "0 1" 1 error code = 1 b Beispiel: scadmin@rash(218)# ps -fe | egrep db2 db2ee 1984 1 0 0:01 <defunct> Lösung: scadmin@rash(229)# cd / scadmin@rash(230)# mv /log1 /log1.bkp scadmin@rash(231)# mkdir /log1 c Die Fehlernachricht kann etwa wie folgt aussehen: SQL6030N Der Befehl START oder STOP DATABASE MANAGER ist fehlgeschlagen. Ursachencode: "13". d Wenn die Methode hadb2_startnet zum Beispiel libdb2.so.1 nicht finden kann, aber über die Sun Cluster-Software normal ausgeführt wird, werden keine Fehlernachrichten gemeldet. Eine manuelle Ausführung der Methode führt zu folgendem Ergebnis: scadmin@crackle(213)# hadb2_startnet '''log0,log1' 600 ld.so.1: hadb2_startnet: fatal: libdb2.so.1: open failed: No such file or directory Killed |