Fehlerbehebung bei der Datenbankspiegelungskonfiguration (SQL Server)

Dieses Thema enthält Informationen, mit denen Sie Probleme beim Einrichten einer Datenbankspiegelungssitzung beheben können.

Hinweis

Stellen Sie sicher, dass Sie alle Voraussetzungen für die Datenbankspiegelung erfüllen.

Thema	Zusammenfassung
Fehlermeldung 1418	Diese SQL Server-Meldung gibt an, dass die Servernetzwerkadresse nicht erreicht werden kann oder nicht vorhanden ist, und es schlägt vor, den Namen der Netzwerkadresse zu überprüfen und den Befehl erneut aufzugeben. Weitere Informationen finden Sie im thema MSSQLSERVER_1418 .
Konten	Erläutert die Anforderungen für eine ordnungsgemäße Konfiguration der Konten, unter denen SQL Server ausgeführt wird.
Endpunkte	Erläutert die Anforderungen für die ordnungsgemäße Konfiguration des Datenbankspiegelungsendpunkts jeder Serverinstanz.
SystemAddress-	Fasst die Alternativen zum Angeben des Systemnamens einer Serverinstanz in einer Datenbankspiegelungskonfiguration zusammen.
Netzwerkzugriff	Dokumentiert die Anforderung, dass jede Serverinstanz auf die Ports der anderen Serverinstanz oder Instanzen über TCP zugreifen kann.
Vorbereitung der Spiegeldatenbank	Fasst die Anforderungen für die Vorbereitung der Spiegeldatenbank zusammen, um das Starten der Spiegelung zu ermöglichen.
Fehler beim Erstellen einer Datei	Beschreibt, wie auf einen fehlgeschlagenen Erstellungsdateivorgang reagiert wird.
Starten der Spiegelung mithilfe von Transact-SQL	Beschreibt die erforderliche Reihenfolge für ALTER DATABASE database_name SET PARTNER ='partner_server'- Anweisungen.
Datenbankübergreifende Transaktionen	Ein automatisches Failover könnte zu einer automatischen und möglicherweise falschen Auflösung von zweifelsfreien Transaktionen führen. Aus diesem Grund unterstützt die Datenbankspiegelung keine datenbankübergreifenden Transaktionen.

Konten

Die Konten, unter denen SQL Server ausgeführt wird, müssen ordnungsgemäß konfiguriert sein.

Verfügen die Konten über die richtigen Berechtigungen?
1. Wenn die Konten in derselben Domäne ausgeführt werden, ist die Wahrscheinlichkeit einer Fehlkonfiguration reduziert.
2. Wenn die Konten in unterschiedlichen Domänen ausgeführt werden oder keine Domänenkonten sind, muss die Anmeldung eines Kontos im master auf dem anderen Computer erstellt werden und diese Anmeldung muss CONNECT-Berechtigungen für den Endpunkt erhalten. Weitere Informationen finden Sie unter Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einer anderen Serverinstanz (SQL Server). Dazu gehört das Netzwerkdienstkonto.
Wenn SQL Server als Dienst ausgeführt wird, der das lokale Systemkonto verwendet, müssen Sie Zertifikate für die Authentifizierung verwenden. Weitere Informationen finden Sie unter Verwenden von Zertifikaten für einen Datenbankspiegelungs-Endpunkt (Transact-SQL).

Endpunkte

Endpunkte müssen ordnungsgemäß konfiguriert sein.

Stellen Sie sicher, dass jede Serverinstanz (der Prinzipalserver, der Spiegelserver und der Zeuge, falls vorhanden) über einen Datenbankspiegelungsendpunkt verfügt. Weitere Informationen finden Sie unter sys.database_mirroring_endpoints (Transact-SQL) und, je nach Authentifizierungsform, entweder Erstellen eines Datenbankspiegelungsendpunkts für die Windows-Authentifizierung (Transact-SQL) oder Verwenden von Zertifikaten für einen Datenbankspiegelungsendpunkt (Transact-SQL).
Überprüfen Sie, ob die Portnummern richtig sind.

Um den aktuell mit dem Datenbankspiegelungsendpunkt einer Serverinstanz verknüpften Port zu identifizieren, verwenden Sie die sys.database_mirroring_endpoints und sys.tcp_endpoints Katalogansichten.
Bei Problemen bei der Datenbankspiegelung, die schwierig zu erklären sind, empfehlen wir, jede Serverinstanz zu prüfen, um festzustellen, ob sie auf die richtigen Ports lauscht. Informationen zur Überprüfung der Portverfügbarkeit finden Sie unter MSSQLSERVER_1418.
Stellen Sie sicher, dass die Endpunkte gestartet wurden (STATE=STARTED). Verwenden Sie in jeder Serverinstanz die folgende Transact-SQL-Anweisung.
```
SELECT state_desc FROM sys.database_mirroring_endpoints  
```
Weitere Informationen zur state_desc-Spalte finden Sie unter sys.database_mirroring_endpoints (Transact-SQL).

Verwenden Sie zum Starten eines Endpunkts die folgende Transact-SQL-Anweisung.
```
ALTER ENDPOINT Endpoint_Mirroring   
STATE = STARTED   
AS TCP (LISTENER_PORT = <port_number>)  
FOR database_mirroring (ROLE = ALL);  
GO  
```
Weitere Informationen finden Sie unter ALTER ENDPOINT (Transact-SQL).
Überprüfen Sie, ob die ROLLE korrekt ist. Verwenden Sie in jeder Serverinstanz die folgende Transact-SQL-Anweisung.
```
SELECT role FROM sys.database_mirroring_endpoints;  
GO  
```
Weitere Informationen finden Sie unter sys.database_mirroring_endpoints (Transact-SQL).

Für die Anmeldung für das Dienstkonto aus der anderen Serverinstanz ist connect-Berechtigung erforderlich. Stellen Sie sicher, dass der Anmeldename auf dem anderen Server über CONNECT-Berechtigungen verfügt. Verwenden Sie für jede Serverinstanz die folgende Transact-SQL-Anweisung, um zu bestimmen, wer über die CONNECT-Berechtigung für einen Endpunkt verfügt.

SELECT 'Metadata Check';  
SELECT EP.name, SP.STATE,   
   CONVERT(nvarchar(38), suser_name(SP.grantor_principal_id))   
      AS GRANTOR,   
   SP.TYPE AS PERMISSION,  
   CONVERT(nvarchar(46),suser_name(SP.grantee_principal_id))   
      AS GRANTEE   
   FROM sys.server_permissions SP , sys.endpoints EP  
   WHERE SP.major_id = EP.endpoint_id  
   ORDER BY Permission,grantor, grantee;   
GO

Systemadresse

Für den Systemnamen einer Serverinstanz in einer Datenbankspiegelungskonfiguration können Sie einen beliebigen Namen verwenden, der das System eindeutig identifiziert. Die Serveradresse kann ein Systemname sein (wenn sich die Systeme in derselben Domäne befinden), ein vollqualifizierter Domänenname oder eine IP-Adresse (vorzugsweise eine statische IP-Adresse). Die Verwendung des vollqualifizierten Domänennamens ist garantiert funktionsfähig. Weitere Informationen finden Sie unter Angeben einer Servernetzwerkadresse (Datenbankspiegelung).

Netzwerkzugriff

Jede Serverinstanz muss auf die Ports der anderen Serverinstanz oder -instanzen über TCP zugreifen können. Dies ist besonders wichtig, wenn sich die Serverinstanzen in verschiedenen Domänen befinden, die einander nicht vertrauen (nicht vertrauenswürdige Domänen). Dies schränkt einen Großteil der Kommunikation zwischen den Serverinstanzen ein.

Vorbereitung der Spiegeldatenbank

Ob Sie die Spiegelung zum ersten Mal starten oder sie nach dem Entfernen der Spiegelung erneut starten, überprüfen Sie, ob die Spiegeldatenbank für die Spiegelung vorbereitet ist.

Stellen Sie beim Erstellen der Spiegeldatenbank auf dem Spiegelserver sicher, dass Sie die Sicherung der Prinzipaldatenbank wiederherstellen, die denselben Datenbanknamen MIT NORECOVERY angibt. Außerdem müssen alle nach dieser Sicherung erstellten Protokollsicherungen auch erneut MIT NORECOVERY angewendet werden.

Außerdem wird empfohlen, wenn möglich, der Dateipfad (einschließlich laufwerksbuchstaben) der Spiegeldatenbank mit dem Pfad der Prinzipaldatenbank identisch zu sein. Wenn sich die Dateipfade z. B. unterscheiden müssen, wenn sich die Prinzipaldatenbank auf laufwerk "F:" befindet, das Spiegelsystem jedoch kein F:-Laufwerk enthält, müssen Sie die MOVE-Option in die RESTORE-Anweisung einschließen.

Von Bedeutung

Wenn Sie die Datenbankdateien verschieben, wenn Sie die Spiegeldatenbank erstellen, können Sie der Datenbank möglicherweise später keine Dateien hinzufügen, ohne dass die Spiegelung angehalten wird.

Wenn die Datenbankspiegelung beendet wurde, müssen alle nachfolgenden Protokollsicherungen, die in der Prinzipaldatenbank erstellt wurden, auf die Spiegeldatenbank angewendet werden, bevor die Spiegelung neu gestartet werden kann.

Weitere Informationen finden Sie unter Vorbereiten einer Spiegeldatenbank auf die Spiegelung (SQL Server).

Fehlgeschlagener Create-File-Vorgang

Das Hinzufügen einer Datei ohne Auswirkung auf eine Spiegelungssitzung erfordert, dass der Pfad der Datei auf beiden Servern vorhanden ist. Wenn Sie die Datenbankdateien beim Erstellen der Spiegeldatenbank verschieben, schlägt ein späterer Add-File-Vorgang möglicherweise in der Spiegeldatenbank fehl und führt dazu, dass die Spiegelung angehalten wird.

So beheben Sie das Problem:

Der Datenbankbesitzer muss die Spiegelungssitzung entfernen und eine vollständige Sicherung der Dateigruppe wiederherstellen, die die hinzugefügte Datei enthält.
Der Besitzer muss dann das Protokoll sichern, das den Datei-Hinzufügungsvorgang auf dem Hauptserver enthält, und die Protokollsicherung manuell mit den Optionen WITH NORECOVERY und WITH MOVE in der Spiegeldatenbank wiederherstellen. Dadurch wird der angegebene Dateipfad auf dem Spiegelserver erstellt und die neue Datei an diesem Speicherort wiederhergestellt.
Um die Datenbank für eine neue Spiegelsitzung vorzubereiten, muss der Besitzer auch OHNE WIEDERHERSTELLUNG alle anderen ausstehenden Protokollsicherungen vom Prinzipalserver wiederherstellen.

Weitere Informationen finden Sie unter Entfernen der Datenbankspiegelung (SQL Server),Vorbereiten einer Spiegeldatenbank für Spiegelung (SQL Server), Einrichten einer Datenbankspiegelungssitzung mithilfe der Windows-Authentifizierung (Transact-SQL), Verwenden von Zertifikaten für einen Datenbankspiegelungsendpunkt (Transact-SQL), oder Einrichten einer Datenbankspiegelungssitzung mithilfe der Windows-Authentifizierung (SQL Server Management Studio).

Starten der Spiegelung mithilfe von Transact-SQL

Die Reihenfolge, in der die ALTER DATABASE database_name SET PARTNER ='partner_server' Anweisungen ausgegeben werden, ist sehr wichtig.

Die erste Anweisung muss auf dem Spiegelserver ausgeführt werden. Wenn diese Anweisung ausgegeben wird, versucht der Spiegelserver nicht, eine andere Serverinstanz zu kontaktieren. Stattdessen weist der Spiegelserver seine Datenbank an, zu warten, bis der Spiegelserver vom Prinzipalserver kontaktiert wurde.
Die zweite ALTER DATABASE-Anweisung muss auf dem Prinzipalserver ausgeführt werden. Diese Anweisung bewirkt, dass der Prinzipalserver versucht, eine Verbindung mit dem Spiegelserver herzustellen. Nachdem diese Verbindung erstellt wurde, versucht der Spiegel dann, eine Verbindung mit dem Prinzipalserver in einer anderen Verbindung herzustellen.

Weitere Informationen finden Sie unter ALTER DATABASE (Transact-SQL).

Hinweis

Informationen zur Verwendung von SQL Server Management Studio zum Starten der Spiegelung finden Sie unter Einrichten einer Datenbankspiegelungssitzung mit der Windows-Authentifizierung (SQL Server Management Studio).

Datenbankübergreifende Transaktionen

Wenn eine Datenbank im Hochsicherheitsmodus mit automatischem Failover gespiegelt wird, kann ein automatisches Failover zu einer automatischen und möglicherweise falschen Auflösung von zweifelsfreien Transaktionen führen. Wenn in einer der beiden Datenbanken ein automatisches Failover auftritt, während der Abschluss einer datenbankübergreifenden Transaktion übertragen wird, können logische Inkonsistenzen zwischen den Datenbanken auftreten.

Zu den Typen von datenbankübergreifenden Transaktionen, die von einem automatischen Failover betroffen sein können, gehören die folgenden:

Eine Transaktion, die mehrere Datenbanken in derselben Instanz von SQL Server aktualisiert.
Transaktionen, die einen Microsoft Distributed Transaction Coordinator (MS DTC) verwenden.

Weitere Informationen finden Sie unter Datenbankübergreifende Transaktionen, die für Datenbankspiegelung oder AlwaysOn-Verfügbarkeitsgruppen (SQL Server) nicht unterstützt werden.

Siehe auch

Einrichten der Datenbankspiegelung (SQL Server)
Transportsicherheit für Datenbankspiegelung und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Last updated on 2017-06-13

Freigeben über