Problembehandlung für die Datenbankspiegelungskonfiguration (SQL Server)

Gilt für: SQL Server

Dieses Thema enthält Informationen, die Ihnen die Problembehandlung beim Einrichten einer Datenbank-Spiegelungssitzung erleichtern.

Konten

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

1. Verfügen die Konten über die richtigen Berechtigungen?

   1. Das Ausführen der Konten in den gleichen Domänenkonten reduziert das Risiko einer Fehlkonfiguration.

   2. Wenn die Konten in unterschiedlichen Domänen ausgeführt werden oder es sich nicht um Domänenkonten handelt, muss der Anmeldename eines Kontos in der master -Datenbank des anderen Computers erstellt werden, und diesem Anmeldenamen müssen CONNECT-Berechtigungen für den Endpunkt erteilt werden. Weitere Informationen finden Sie unter Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einer anderen Serverinstanz (SQL Server). Dies gilt auch für das Netzwerkdienstkonto.

2. Wird SQL Server als Dienst unter dem lokalen Systemkonto ausgeführt, 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.

1. Stellen Sie sicher, dass jede Serverinstanz (Prinzipalserver, Spiegelserver und ggf. Zeuge) über einen Endpunkt der Datenbankspiegelung verfügt. Weitere Informationen finden Sie unter sys.database_mirroring_endpoints (Transact-SQL) und, je nach Form der Authentifizierung, entweder unter Erstellen eines Endpunkts der Datenbankspiegelung für Windows-Authentifizierung (Transact-SQL) oder Verwenden von Zertifikaten für einen Datenbankspiegelungs-Endpunkt (Transact-SQL).

2. Überprüfen Sie, ob die Portnummern richtig sind.

   Verwenden Sie die sys.database_mirroring_endpoints -Katalogsicht und die sys.tcp_endpoints -Katalogsicht, um den Port zu identifizieren, der dem Endpunkt der Datenbankspiegelung einer Serverinstanz derzeit zugeordnet ist.

3. Bei Problemen mit der Einrichtung der Datenbankspiegelung, die schwer zu erklären sind, empfiehlt es sich, jede Serverinstanz zu prüfen, um zu ermitteln, ob die richtigen Ports von der Serverinstanz überwacht werden.

4. Stellen Sie sicher, dass die Endpunkte gestartet wurden (STATE=STARTED). Verwenden Sie auf jeder Serverinstanz 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 die folgende Transact-SQL-Anweisung, um einen Endpunkt zu starten.

   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).

5. Überprüfen Sie, ob die Rolle richtig ist. Verwenden Sie auf jeder Serverinstanz folgende Transact-SQL-Anweisung.

   SELECT role FROM sys.database_mirroring_endpoints;  
   GO  
   

   Weitere Informationen finden Sie unter sys.database_mirroring_endpoints (Transact-SQL).

6. Um sich von der anderen Serverinstanz unter dem Dienstkonto anzumelden, ist die CONNECT-Berechtigung erforderlich. Stellen Sie sicher, dass der Anmeldename auf dem anderen Server über CONNECT-Berechtigungen verfügt. Führen Sie auf jeder Serverinstanz die folgende Transact-SQL-Anweisung aus, um zu ermitteln, wer über CONNECT-Berechtigungen 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 Datenbank-Spiegelungskonfiguration können Sie jeden beliebigen Namen verwenden, der das System eindeutig bezeichnet. 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). Bei Verwendung des vollqualifizierten Domänennamens ist eine problemfreie Funktionsweise sichergestellt. Weitere Informationen finden Sie unter Angeben einer Servernetzwerkadresse (Datenbankspiegelung).

Netzwerkzugriff

Jede Serverinstanz muss über TCP auf die Ports der anderen Serverinstanz bzw. der anderen Serverinstanzen zugreifen können. Dies ist insbesondere von Bedeutung, wenn sich die Serverinstanzen in unterschiedlichen Domänen befinden, die sich nicht vertrauen (nicht vertrauenswürdige Domänen). Damit wird ein Großteil der Kommunikation zwischen den Serverinstanzen eingeschränkt.

Vorbereitung der Spiegeldatenbank

Überprüfen Sie, ob die Spiegeldatenbank für die Spiegelung vorbereitet ist, unabhängig davon, ob Sie die Spiegelung zum ersten Mal starten oder nach dem Entfernen der Spiegelung erneut starten.

Stellen Sie bei der Erstellung der Spiegeldatenbank auf dem Spiegelserver sicher, dass Sie die Sicherung der Prinzipaldatenbank wiederherstellen, wobei Sie mit WITH NORECOVERY denselben Datenbanknamen angeben. Darüber hinaus müssen alle Protokollsicherungen, die nach dieser Sicherung erstellt wurden, ebenfalls mithilfe von WITH NORECOVERY angewendet werden.

Außerdem sollte der Dateipfad (einschließlich des Laufwerkbuchstabens) der Spiegeldatenbank nach Möglichkeit mit dem Pfad der Prinzipaldatenbank übereinstimmen. Wenn sich die Pfade unterscheiden müssen, weil sich beispielsweise die Prinzipaldatenbank auf Laufwerk 'F': befindet, auf dem Spiegelsystem jedoch kein Laufwerk F: vorhanden ist, müssen Sie die MOVE-Option in die RESTORE-Anweisung einschließen.

Wurde die Datenbankspiegelung angehalten, müssen alle nachfolgenden Protokollsicherungen in der Prinizipaldatenbank auf die Spiegeldatenbank angewendet werden, ehe die Spiegelung erneut gestartet werden kann.

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

Fehler bei einem Dateierstellungsvorgang

Damit eine Datei ohne Auswirkung auf eine Spiegelungssitzung hinzugefügt werden kann, muss der Pfad der Datei auf beiden Servern vorhanden sein. Wenn Sie die Datenbankdateien bei der Erstellung der Spiegeldatenbank verschieben, kann bei einem später durchgeführten Vorgang zum Hinzufügen einer Datei in der Spiegeldatenbank ein Fehler auftreten oder die Spiegelung wird möglicherweise angehalten.

So beheben Sie das Problem:

1. Der Datenbankbesitzer muss die Spiegelsitzung entfernen und eine vollständige Sicherung der Dateigruppe wiederherstellen, die die hinzugefügte Datei enthält.

2. Anschließend muss der Besitzer das Protokoll mit dem Vorgang zum Hinzufügen der Datei auf dem Prinzipalserver sichern und die Protokollsicherung auf der Spiegeldatenbank mithilfe der Optionen WITH NORECOVERY und WITH MOVE manuell wiederherstellen. Dadurch wird der angegebene Dateipfad auf dem Spiegelserver erstellt, und die neue Datei wird an diesem Speicherort wiederhergestellt.

3. Um die Datenbank für eine neue Spiegelsitzung vorzubereiten, muss der Besitzer außerdem mit der Option WITH NO RECOVERY alle anderen ausstehenden Protokollsicherungen vom Prinzipalserver wiederherstellen.

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

Starten der Spiegelung mit Transact-SQL

Die Reihenfolge, in der ALTER DATABASE database_name SET PARTNER ='partner_server' -Anweisungen ausgegeben werden, ist von großer Bedeutung.

1. Die erste Anweisung muss auf dem Spiegelserver ausgeführt werden. Wird diese Anweisung ausgegeben, versucht der Spiegelserver nicht, Kontakt zu anderen Serverinstanzen aufzunehmen. Stattdessen weist der Spiegelserver die Datenbank an, so lange zu warten, bis der Prinzipalserver Kontakt mit dem Spiegelserver aufgenommen hat.

2. Die zweite ALTER DATABASE-Anweisung muss auf dem Prinzipalserver ausgeführt werden. Diese Anweisung veranlasst den Prinzipalserver, eine Verbindung mit dem Spiegelserver herzustellen. Nachdem diese Verbindung erstellt wurde, versucht der Spiegelserver, den Prinzipalserver über eine andere Verbindung zu kontaktieren.

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

Datenbankübergreifende Transaktionen

Wenn eine Datenbank im Modus für hohe Sicherheit mit automatischem Failover gespiegelt wird, kann ein automatisches Failover zu einer automatischen und möglicherweise falschen Auflösung von unsicheren Transaktionen führen. Falls auf einer der Datenbanken ein automatisches Failover stattfindet, während für eine datenbankübergreifende Transaktion gerade ein Commit ausgeführt wird, können zwischen den Datenbanken logische Inkonsistenzen auftreten.

Zu den Typen datenbankübergreifender Transaktionen, auf die sich ein automatisches Failover auswirken kann, zählen:

• Eine Transaktion, die mehrere Datenbanken in derselben Instanz von SQL Serveraktualisiert.

• Transaktionen, die Microsoft DTC (Microsoft Distributed Transaction Coordinator) verwenden.

Weitere Informationen finden Sie unter Datenbankübergreifende Transaktionen und verteilte Transaktionen für Always On-Verfügbarkeitsgruppen und Datenbankspiegelung (SQL Server).

Weitere Informationen

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