DB2 Universal Database - Systemverwaltung


Fehlerbehebung

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.
  1. Stellen Sie sicher, daß in der Konfigurationsdatei hadb2tab der korrekte Exemplartyp angegeben ist. Wenn zum Beispiel eine Datei db2nodes.cfg für ein administratives EE-Exemplar vorhanden ist, verursacht dies Probleme. Die HA-Agentenmethoden können diese Probleme nicht überwinden.
  2. Stellen Sie sicher, daß die Datei .rhosts vorhanden ist und gültige Einträge enthält.
  3. Stellen Sie sicher, daß das HA-NFS-Dateisystem mit Root-Berechtigung von allen Maschinen im Cluster gemeinsam benutzt werden kann.
  4. Überprüfen Sie die Kernel-Parameter, und stellen Sie sicher, daß sie korrekt sind.
  5. Stellen Sie sicher, daß die Datei /etc/services Einträge für das Exemplar enthält.
Das Exemplar funktioniert nur auf einer Maschine.
  • Die numerische uid für das Exemplar ist vielleicht nicht auf allen Maschinen im Cluster gleich.
  • Die Kernel-Parameter sind vielleicht nicht auf jeder Maschine im Cluster gültig.
  • Die Datei hadb2tab ist vielleicht nicht auf jeder Maschine im Cluster gleich.
  • Andere Konfigurationsdateien, wie zum Beispiel die Datei vfstab für logische Hosts, sind vielleicht nicht auf jeder Maschine im Cluster gleich.

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.
  • Die Datei .profile für das Exemplar ist eventuell nicht su-"freundlich".
  • Es gibt ein bekanntes Problem mit der Bourne-Shell (/bin/sh), in der der Befehl su manuell, jedoch nicht über den HA-Agenten funktioniert.

  • Versuchen Sie mit Root-Berechtigung diesen Befehl manuell auszuführen, und stellen Sie sicher, daß er funktioniert, bevor Sie den Versuch über den HA-Agenten wiederholen.
  • Wechseln Sie zur Korn-Shell (/bin/ksh), falls erforderlich.

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


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]