Freigeben über

Problembehandlung bei Failoverclustern

  • Artikel

Aktualisiert: 17. Juli 2006

In diesem Thema finden Sie Informationen zu den folgenden Punkten:

  • Grundlegende Schritte bei der Problembehandlung.
  • Wiederherstellung bei einem fehlerhaften Failovercluster.
  • Lösungen für die häufigsten Probleme bei der Failover-Clusterunterstützung.
  • Verwenden von erweiterten gespeicherten Prozeduren und COM-Objekten.

Grundlegende Schritte bei der Problembehandlung

Bei Verwendung der Failover-Clusterunterstützung von SQL Server 2005 müssen Sie bedenken, dass der Servercluster aus einer Failoverclusterinstanz besteht, die unter Microsoft Clusterdienste (MSCS, Microsoft Cluster Service) ausgeführt wird. Die SQL Server-Instanz wird möglicherweise von Microsoft MSCS-basierten Knoten gehostet, die den Microsoft Servercluster bereitstellen.

Wenn es Probleme auf den Knoten gibt, die den Servercluster hosten, werden diese Probleme möglicherweise im Zusammenhang mit der Failoverclusterinstanz sichtbar. Um diese Probleme zu untersuchen und zu lösen, führen Sie eine Problembehandlung für einen SQL Server-Failovercluster in der folgenden Reihenfolge durch:

  1. Hardware: Überprüfen Sie die Systemereignisprotokolle von Microsoft Windows.
  2. Betriebssystem: Überprüfen Sie die System- und Anwendungsereignisprotokolle von Windows.
  3. Netzwerk: Überprüfen Sie die System- und Anwendungsereignisprotokolle von Windows. Überprüfen Sie die aktuelle Konfiguration mit dem Knowledge Base-Artikel Empfehlungen für die private Heartbeat-Konfiguration auf einem Clusterserver.
  4. Sicherheit: Überprüfen Sie die Anwendungs- und Sicherheitsereignisprotokolle von Windows.
  5. MSCS: Überprüfen Sie die System-, Anwendungsereignis- und Clusterprotokolle von Windows.
  6. SQL Server: Führen Sie wie gewohnt eine Problembehandlung durch, nachdem die Überprüfung der Grundlagen der Hardware, des Betriebssystems, des Netzwerks, der Sicherheit und von MSCS keine Probleme gezeigt hat.

Wiederherstellen bei einem Failovercluster-Fehler

Failovercluster-Fehler sind üblicherweise auf eine von zwei Ursachen zurückzuführen:

  • Hardwarefehler in einem Knoten eines Zwei-Knoten-Clusters. Die Ursache für diesen Hardwarefehler könnte beispielsweise ein Fehler auf der SCSI-Karte oder im Betriebssystem sein.
    Zum Beheben dieses Fehlers entfernen Sie den fehlerhaften Knoten mithilfe des SQL Server-Setupprogramms vom Failovercluster, behandeln Sie den Hardwarefehler, während der Computer offline ist, fahren Sie den Computer wieder hoch, und fügen Sie dann der Failoverclusterinstanz den reparierten Knoten wieder hinzu.
    Weitere Informationen finden Sie unter Vorgehensweise: Erstellen eines neuen SQL Server 2005-Failoverclusters (Setup) und Vorgehensweise: Wiederherstellen bei einem Failovercluster-Fehler in Szenario 1.
  • Betriebssystemfehler. In diesem Fall ist der Knoten offline, aber nicht unwiederbringlich beschädigt.
    Um eine Wiederherstellung nach einem Betriebssystemfehler durchzuführen, stellen Sie den Knoten wieder her, und testen Sie das Failover. Wenn für die SQL Server-Instanz kein ordnungsgemäßes Failover ausgeführt wird, müssen Sie das SQL Server-Setupprogramm zum Entfernen von SQL Server vom Failovercluster verwenden, notwendige Reparaturen vornehmen, den Computer wieder hochfahren und dann der Failoverclusterinstanz den reparierten Knoten wieder hinzufügen.
    Das Wiederherstellen nach einem Betriebssystemfehler auf diese Art kann Zeit kosten. Falls die Wiederherstellung nach dem Betriebssystemfehler problemlos möglich ist, sollten Sie dieses Verfahren vermeiden.
    Weitere Informationen finden Sie unter Vorgehensweise: Erstellen eines neuen SQL Server 2005-Failoverclusters (Setup) und Vorgehensweise: Wiederherstellen bei einem Failovercluster-Fehler in Szenario 2.

Berücksichtigen Sie außerdem die folgenden Änderungen der Failover-Clusterunterstützung in SQL Server 2005:

Lösen häufig auftretender Probleme

In der folgenden Liste werden häufig auftretende Probleme bei der Verwendung sowie deren Behebung beschrieben.

Problem: Falsche Verwendung der Eingabeaufforderungssyntax für die Installation von SQL Server 2005

Problem 1: Setupprobleme sind schwer zu diagnostizieren, wenn der /qn-Schalter an der Eingabeaufforderung verwendet wird. /qn unterdrückt alle Benutzeroberflächen-Dialogfelder und Fehlermeldungen. Wenn der /qn-Schalter angegeben ist, werden alle Setupmeldungen, einschließlich aller Fehlermeldungen, in die Setupprotokolldateien geschrieben. Weitere Informationen zu Protokolldateien finden Sie unter Vorgehensweise: Anzeigen der SQL Server 2005-Setupprotokolldateien.

Lösung 1: Verwenden Sie anstelle des /qn-Schalters den /qb-Schalter. Wenn Sie den /qb-Schalter verwenden, wird bei jedem Schritt die Standardbenutzeroberfläche mit allen Fehlermeldungen angezeigt.

Problem 2: Nichteinhalten des in der Datei template.ini verwendeten Formats (diese befindet sich im Stammverzeichnis des SQL Server 2005-Installationsmediums).

Lösung 2: Obwohl unerwartete Zeichen durch das Setupprogramm ignoriert werden, geben Sie in Ihrem Installationsbefehl alle notwendigen Variablen an.

Zwischen einer Variablen und deren Wert darf sich in der Befehlszeile kein Leerzeichen befinden. Beispiel: In "ADDLOCAL=ALL" ist kein Leerzeichen vorhanden. Wird "ADDLOCAL = ALL" verwendet, erzeugt die Installation einen Fehler. Ein weiteres Beispiel ist IP und der zugeordnete Wert. "IP=www.xxx.yyy.zzz,Local Area Connection" ist richtig. Wenn nach "," ein Leerzeichen eingefügt wird, erzeugt die Installation einen Fehler.

Problem: SQL Server 2005 kann sich nach der Migration auf einen anderen Knoten nicht am Netzwerk anmelden

Problem 1: Von SQL Server-Dienstkonten kann kein Kontakt mit einem Domänencontroller hergestellt werden.

Lösung 1: Überprüfen Sie die Ereignisprotokolle in Hinblick auf Netzwerkprobleme wie Adapterfehler oder DNS-Probleme. Überprüfen Sie, ob Sie Ihren Domänencontroller pingen können.

Problem 2: Die SQL Server-Dienstkontokennwörter stimmen nicht auf allen Clusterknoten überein, oder vom Knoten wird kein SQL Server-Dienst erneut gestartet, der von einem fehlerhaften Knoten migriert worden ist.

Lösung 2: Ändern Sie die SQL Server-Dienstkontokennwörter mithilfe des SQL Server-Konfigurations-Managers. Andernfalls müssen Sie nach dem Ändern der Kennwörter für SQL Server-Dienstkonten auf einem Knoten auch die Kennwörter auf allen anderen Knoten ändern. Vom SQL Server-Konfigurations-Manager wird dies automatisch ausgeführt.

Problem: SQL Server kann nicht auf die Clusterdatenträger zugreifen

Problem 1: Die Firmware oder Treiber sind nicht auf allen Knoten aktualisiert.

Lösung 1: Überprüfen Sie, ob von allen Knoten die ordnungsgemäßen Firmwareversionen und die gleichen Treiberversionen verwendet werden.

Problem 2: Ein Knoten kann Clusterdatenträger nicht wiederherstellen, die von einem fehlerhaften Knoten auf einem freigegebenen Clusterdatenträger mit einem unterschiedlichen Laufwerkbuchstaben migriert worden sind.

Lösung 2: Die Laufwerkbuchstaben für die Clusterdatenträger müssen auf beiden Servern identisch sein. Überprüfen Sie andernfalls die ursprüngliche Installation des Betriebssystems und von Microsoft Clusterdienste (MSCS, Microsoft Cluster Service).

Problem: Ein Fehler eines SQL Server-Dienstes verursacht ein Failover

Lösung: Um zu verhindern, dass der Fehler eines bestimmten Dienstes zu einem Failover der SQL Server-Gruppe führt, konfigurieren Sie diese Dienste mithilfe der Clusterverwaltung unter Windows wie folgt:

  • Deaktivieren Sie im Eigenschaftendialogfeld für Volltext auf der Registerkarte Erweitert das Kontrollkästchen Die Gruppe beeinflussen. Wenn SQL Server allerdings ein Failover verursacht, wird die Volltextsuche erneut gestartet.

Problem: SQL Server startet nicht automatisch

Lösung: Verwenden Sie die Clusterverwaltung unter MSCS, um automatisch einen Failovercluster zu starten. Der SQL Server-Dienst sollte auf manuelles Starten festgelegt werden, und die Clusterverwaltung sollte in MSCS zum Starten des SQL Server-Dienstes konfiguriert werden.

Problem: Die Netzwerknamenressource ist offline, und Sie können keine Verbindung zu SQL Server mithilfe von TCP/IP herstellen

Problem 1: DNS erzeugt aufgrund einer Clusterressource einen Fehler, die DNS erfordert.

Lösung 1: Beheben Sie die DNS-Probleme.

Problem 2: Auf dem Netzwerk ist ein Name doppelt vorhanden.

Lösung 2: Verwenden Sie NBTSTAT zum Lokalisieren des Doppelnamens, und beheben Sie dann das Problem.

Problem 3: Von SQL Server wird keine Verbindung mithilfe von Named Pipes hergestellt.

Lösung 3: Für die Verbindung mithilfe von Named Pipes erstellen Sie mit dem SQL Server-Konfigurations-Manager einen Alias, um eine Verbindung zum entsprechenden Computer herzustellen. Wenn Sie beispielsweise über einen Cluster mit zwei Knoten (Knoten A und Knoten B) und einer Failoverclusterinstanz (Virtsql) mit einer Standardinstanz verfügen, können Sie die Verbindung mit dem Server, auf dem die Netzwerknamenressource offline ist, wie folgt herstellen:

  1. Ermitteln Sie mithilfe der Clusterverwaltung den Knoten, auf dem die Gruppe mit der Instanz von SQL Server ausgeführt wird. In diesem Beispiel ist es Knoten A.
  2. Starten Sie den SQL Server-Dienst auf diesem Computer mithilfe von net start. Weitere Informationen zum Verwenden von net start finden Sie unter Manuelles Starten von SQL Server.
  3. Starten Sie den SQL Server-Konfigurations-Manager auf Knoten A. Zeigen Sie den Pipenamen an, der vom Server überwacht wird. Er sollte so oder ähnlich lauten: \\.\$$\VIRTSQL\pipe\sql\query.
  4. Starten Sie den SQL Server-Konfigurations-Manager auf dem Clientcomputer.
  5. Erstellen Sie den Alias SQLTEST1, um über Named Pipes eine Verbindung mit diesem Pipenamen herzustellen. Geben Sie dazu Knoten A als Servernamen ein, und ändern Sie den Pipenamen in \\.\pipe\$$\VIRTSQL\sql\query.
  6. Stellen Sie mithilfe des Alias SQLTEST1 als Servernamen eine Verbindung mit dieser Instanz her.

Problem: SQL Server-Setup führt auf einem Cluster zum Fehler 1058

Problem: Durch das Deaktivieren des Taskplanerdienstes auf Clusterknoten schlägt das Setup mit dem Fehler 1058 fehl. Der folgende Eintrag befindet sich in der Datei core.log:

Error: SetTargetComputer on \\machinename failed with
Unable to start service (1058)
Error: RunRemoteProcess Received return code 1058 from STPCOMPAQ3790N2

Die letzte Zeile des Protokolls lautet:

<EndFunc Name='DwLaunchMsiExec' Return='1058' GetLastError='183'>

Lösung: Verwenden Sie den Cluster-Manager zum Aktivieren des Taskplanerdienstes auf allen Clusterknoten. Weitere Informationen finden Sie unter Vorgehensweise: Aktivieren des Windows-Taskplanerdienstes.

Problem: SQL Server-Setup führt auf einem Cluster zum Fehler 11001

Problem: Ein verwaister Registrierungsschlüssel in [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\Cluster]

Lösung: Stellen Sie sicher, dass die MSSQL.X-Registrierungsstruktur zurzeit nicht verwendet wird, und löschen Sie dann den Clusterschlüssel.

Problem: Fehler beim Cluster-Setup: "Die Privilegien von Installer reichen nicht aus, um auf dieses Verzeichnis zuzugreifen": <Laufwerk>\Microsoft SQL Server. Die Installation kann nicht fortgesetzt werden. Melden Sie sich als Administrator an, oder wenden Sie sich an Ihren Systemadministrator"

Problem: Dieser Fehler wird durch ein freigegebenes SCSI-Laufwerk verursacht, das nicht ordnungsgemäß partitioniert ist.

Lösung: Erstellen Sie eine neue, einzelne Partition auf dem freigegebenen Datenträger, indem Sie die folgenden Schritte ausführen:

  1. Löschen Sie die Datenträgerressource vom Cluster.
  2. Löschen Sie alle Partitionen vom Datenträger.
  3. Überprüfen Sie in den Datenträgereigenschaften, ob es sich um eine Basisfestplatte handelt.
  4. Erstellen Sie auf dem freigegebenen Datenträger eine Partition, formatieren Sie den Datenträger, und weisen Sie ihm einen Laufwerkbuchstaben zu.
  5. Fügen Sie den Datenträger mithilfe der Clusterverwaltung (cluadmin) dem Cluster hinzu.
  6. Führen Sie SQL Server Setup aus.

Problem: SQL Server 2005-Ressourcen werden von Anwendungen nicht in eine verteilte Transaktion eingetragen.

Problem: Weil Microsoft Distributed Transaction Coordinator (MS DTC) in Windows nicht vollständig konfiguriert wird, werden von Anwendungen SQL Server 2005-Ressourcen nicht in einer verteilten Transaktion eingetragen. Dieses Problem kann sich auf verknüpfte Server, verteilte Abfragen und remote gespeicherte Prozeduren auswirken, die verteilte Transaktionen verwenden.

Lösung: Um solche Probleme zu vermeiden, müssen Sie die MS DTC-Dienste auf dem Server vollständig aktivieren, auf dem SQL Server 2005 installiert ist.

Führen Sie die folgenden Schritte aus, um MS DTC vollständig zu aktivieren:

  1. Öffnen Sie in der Systemsteuerung die Option Verwaltung, und öffnen Sie dann Computerverwaltung.
  2. Erweitern Sie im linken Bereich von Computerverwaltung Dienste und Anwendungen, und klicken Sie dann auf Dienste.
  3. Klicken Sie im rechten Bereich von Computerverwaltung mit der rechten Maustaste auf Distributed Transaction Coordinator, und wählen Sie Eigenschaften aus.
  4. Klicken Sie im Fenster Distributed Transaction Coordinator auf die Registerkarte Allgemein, und klicken Sie dann auf Beenden, um den Dienst zu beenden.
  5. Klicken Sie im Fenster Distributed Transaction Coordinator auf die Registerkarte Anmelden, und richten Sie das Anmeldekonto NT AUTHORITY\NetworkService ein.
  6. Klicken Sie auf Anwenden und OK, um das Fenster Distributed Transaction Coordinator zu schließen. Schließen Sie das Fenster Computerverwaltung. Schließen Sie das Fenster Verwaltung.
ms189117.note(de-de,SQL.90).gifHinweis:
Für Installationen von SQL Server 2005 auf Computern, die an Failoverclustern teilnehmen, muss MS DTC vollständig aktiviert und gruppiert sein, bevor Setup ausgeführt wird. Wenn MS DTC nicht gruppiert ist, erzeugt das Setup einen Fehler. Verwenden Sie vor dem Ausführen von Setup die Microsoft Clusterverwaltung, um sicherzustellen, dass MS DTC gruppiert worden ist.

Problem: Setupfehler bei der Installation von SQL Server 2005-Failovercluster von der CD

Problem: Beim Auswählen einer Failoverclusterkomponente und einer Clienttools-Komponente während des SQL Server 2005-Setups wird bei der Installation der Fehler "Fehler bei der Remoteinstallation" erzeugt, nachdem Sie CD 2 einlegen.

Lösung: Kopieren Sie die Installationsdateien von beiden CDs in dasselbe Verzeichnis auf dem aktiven Clusterknoten oder der Netzwerkfreigabe. Beispiel:

c:
cd\
md SQLENT

Kopieren Sie beide CDs in das SQLENT-Verzeichnis:

\SQLENT\Servers

\SQLENT\Tools

ms189117.note(de-de,SQL.90).gifHinweis:
Bei Installationen per DVD ist dies kein Problem.

Verwenden von erweiterten gespeicherten Prozeduren und COM-Objekten

Bei Verwendung erweiterter gespeicherter Prozeduren mit einer Failover-Clusterunterstützungskonfiguration müssen alle erweiterten gespeicherten Prozeduren auf einem von SQL Server abhängigen Clusterdatenträger installiert werden. Dadurch wird sichergestellt, dass beim Failover eines Knotens die erweiterten gespeicherten Prozeduren weiterhin verwendet werden können.

Wenn die erweiterten gespeicherten Prozeduren COM-Komponenten verwenden, muss der Systemadministrator die COM-Komponenten auf jedem Knoten des Clusters registrieren. Die Informationen zum Laden und Ausführen von COM-Komponenten müssen in der Registrierung des aktiven Knotens vorhanden sein, damit die Komponenten erstellt werden. Andernfalls verbleiben die Informationen in der Registrierung des Computers, auf dem die COM-Komponenten zuerst registriert wurden.

Siehe auch

Andere Ressourcen

Vorgehensweise: Anzeigen der SQL Server 2005-Setupprotokolldateien
How Extended Stored Procedures Work
Execution Characteristics of Extended Stored Procedures

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf

Version Verlauf

17. Juli 2006
Geänderter Inhalt:
  • Der Abschnitt zu Setupfehlern bei Verwendung von CD-Medien wurde hinzugefügt.