Problembehandlung für die AlwaysOn-Verfügbarkeitsgruppenkonfiguration (SQL Server)

Gilt für: SQL Server

Dieses Thema enthält Informationen, um Sie beim Beheben typischer Probleme beim Konfigurieren von Serverinstanzen für Always On-Verfügbarkeitsgruppenzu unterstützen. Zu typischen Konfigurationsproblemen zählen beispielsweise: Always On-Verfügbarkeitsgruppen sind deaktiviert, Konten sind falsch konfiguriert, Datenbankspiegelungsendpunkte sind nicht vorhanden, es kann nicht auf Endpunkte zugegriffen werden (SQL Server-Fehler 1418), es ist kein Netzwerkzugriff vorhanden oder bei einem Befehl zum Verknüpfen einer Datenbank tritt ein Fehler auf (SQL Server-Fehler 35250).

In diesem Thema:

AlwaysOn-Verfügbarkeitsgruppen ist nicht aktiviert

Die Funktion Always On-Verfügbarkeitsgruppen muss auf allen Instanzen von SQL Serveraktiviert werden.

Wenn das Feature „Always On-Verfügbarkeitsgruppen“ nicht aktiviert ist, wird die folgende Fehlermeldung ausgegeben, wenn Sie versuchen, eine Verfügbarkeitsgruppe auf SQL Server zu erstellen.

The Always On Availability Groups feature must be enabled for server instance 'SQL1VM' before you can create an availability group on this instance. To enable this feature, open the SQL Server Configuration Manager, select SQL Server Services, right-click on the SQL Server service name, select Properties, and use the Always On Availability Groups tab of the Server Properties dialog. Enabling Always On Availability Groups may require that the server instance is hosted by a Windows Server Failover Cluster (WSFC) node. (Microsoft.SqlServer.Management.HadrTasks)

Die Fehlermeldung weist klar darauf hin, dass das Verfügbarkeitsgruppen-Feature nicht aktiviert ist, und Sie erhalten auch Anweisungen, wie Sie es aktivieren. Neben dem offensichtlichen Zustand, dass die Verfügbarkeitsgruppen nicht an erster Stelle aktiviert war, gibt es zwei Szenarien, um in diesen Zustand zu gelangen.

1. Wenn SQL Server installiert wurde und das Feature „Always On-Verfügbarkeitsgruppen“ aktiviert wurde, bevor das Feature „Windows-Failoverclustering“ installiert wurde, wird möglicherweise dieser Fehler ausgegeben, wenn Sie versuchen, eine Always On-Verfügbarkeitsgruppe zu erstellen.
2. Wenn Sie ein vorhandenes Feature „Windows-Failoverclustering“ entfernen und neu erstellen, während für SQL Server noch Always On-Verfügbarkeitsgruppen konfiguriert sind, kann dieser Fehler auftreten, wenn Sie versuchen, Verfügbarkeitsgruppe erneut zu verwenden.

In solchen Fällen können Sie die folgenden Schritte ausführen, um ihn zu beheben:

1. Deaktivieren Sie das AG-Feature.
2. Starten Sie den SQL Server-Dienst neu.
3. Aktivieren Sie das AG-Features erneut.
4. Starten Sie den SQL-Dienst neu.

Weitere Informationen finden Sie unter Aktivieren und Deaktivieren von Always On-Verfügbarkeitsgruppen (SQL Server).

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. Falls sich die Partner im selben Domänenkonto befinden, sind die richtigen Benutzeranmeldeinformationen automatisch in beiden master-Datenbanken vorhanden. Dies vereinfacht die Sicherheitskonfiguration und wird empfohlen.

   2. Wenn zwei Serverinstanzen in unterschiedlichen Konten ausgeführt werden, muss jedes Konto in der master-Datenbank auf der Remoteserverinstanz erstellt werden. Diesem Dienstprinzipal müssen CONNECT-Berechtigungen gewährt werden, damit eine Verbindung mit dem Datenbankspiegelungs-Endpunkt dieser Serverinstanz hergestellt werden kann. Weitere Informationen finden Sie unter Einrichten von Anmeldekonten für die Datenbankspiegelung oder Always On-Verfügbarkeitsgruppen (SQL Server). Mithilfe der folgenden Abfrage können Sie auf jeder Instanz überprüfen, ob die Anmeldungen über CONNECT-Berechtigungen verfügen:

   SELECT 
     perm.class_desc,
     prin.name,
     perm.permission_name,
     perm.state_desc,
     prin.type_desc as PrincipalType,
     prin.is_disabled
   FROM sys.server_permissions perm
     LEFT JOIN sys.server_principals prin ON perm.grantee_principal_id = prin.principal_id
     LEFT JOIN sys.tcp_endpoints tep ON perm.major_id = tep.endpoint_id
   WHERE 
     perm.class_desc = 'ENDPOINT'
     AND perm.permission_name = 'CONNECT'
     AND tep.type = 4    
   

2. Wenn SQL Server in einem integrierten Konto – z. B. „Lokales System“, „Lokaler Dienst“ oder „Netzwerkdienst“ – oder in einem Nichtdomänenkonto ausgeführt wird, müssen Sie Zertifikate für die Endpunktauthentifizierung verwenden. Wenn die Dienstkonten Domänenkonten in derselben Domäne verwenden, können Sie CONNECT-Zugriff für jedes Dienstkonto an allen Replikatspeicherorten gewähren oder Zertifikate 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 Instanz von SQL Server , die ein Verfügbarkeitsreplikat hosten wird (jeder Replikatspeicherort) einen Datenbankspiegelungs-Endpunkt besitzt. Um festzustellen, ob auf einer bestimmten Serverinstanz bereits ein Datenbankspiegelungs-Endpunkt vorhanden ist, verwenden Sie die Katalogsicht sys.database_mirroring_endpoints:

   SELECT name, state_desc FROM sys.database_mirroring_endpoints  
   

   Weitere Informationen zum Erstellen von Endpunkten finden Sie entweder unter Erstellen eines Datenbankspiegelungs-Endpunkts für die Windows-Authentifizierung (Transact-SQL) oder Verwenden von Zertifikaten für ausgehende Verbindungen für einen Datenbankspiegelungs-Endpunkt erlauben (Transact-SQL).

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

   Verwenden Sie die folgende Transact-SQL-Anweisung, um den Port zu identifizieren, der derzeit dem Datenbankspiegelungs-Endpunkt einer Serverinstanz zugeordnet ist:

   SELECT type_desc, port FROM sys.tcp_endpoints;  
   GO  
   

3. Bei schwierig zu erklärenden Problemen mit der Einrichtung von Always On-Verfügbarkeitsgruppen empfiehlt es sich, für jede Serverinstanz zu ermitteln, ob sie die richtigen Ports überwacht.

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

   Hinweis

   In einigen Fällen, wenn der Endpunkt gestartet wird, aber die AG-Replikate nicht kommunizieren, versuchen Sie möglicherweise, den Endpunkt zu beenden und neu zu starten. Sie können ALTER ENDPOINT [Endpoint_Mirroring] STATE = STOPPED verwenden, gefolgt von ALTER ENDPOINT [Endpoint_Mirroring] STATE = STARTED

5. 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;   
   

6. Stellen Sie sicher, dass in der Endpunkt-URL der richtige Servername verwendet wird.

   Es wird empfohlen, den vollqualifizierten Domänennamen (FQDN) als Servernamen in einer Endpunkt-URL zu verwenden. Sie können aber auch jeden beliebigen Namen verwenden, der den Computer eindeutig identifiziert. Die Serveradresse kann ein NetBIOS-Name 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 die empfohlene Option.

   Wenn Sie bereits eine Endpunkt-URL definiert haben, können Sie diese folgendermaßen abfragen:

   select endpoint_url from sys.availability_replicas
   

   Als Nächstes vergleichen Sie die Ausgabe von „endpoint_url“ mit dem Servernamen (NetBIOS-Name oder FQDN). Führen Sie zum Abfragen des Servernamens die folgenden Befehle in einer PowerShell lokal auf dem Replikat aus:

   $env:COMPUTERNAME
   [System.Net.Dns]::GetHostEntry([string]$env:computername).HostName
   

   Um den Servernamen auf einem Remotecomputer zu überprüfen, führen Sie diesen Befehl in PowerShell aus.

   $servername_from_endpoint_url = "server_from_endpoint_url_output"
   
   Test-NetConnection -ComputerName $servername_from_endpoint_url
   

   Weitere Informationen finden Sie unter Angeben der Endpunkt-URL beim Hinzufügen oder Ändern eines Verfügbarkeitsreplikats (SQL Server).

Netzwerkzugriff

Jeder Serverinstanz, die ein Verfügbarkeitsreplikat hostet, muss der Zugriff auf den Port aller anderen Serverinstanzen über TCP ermöglicht werden. Dies ist insbesondere von Bedeutung, wenn sich die Serverinstanzen in unterschiedlichen Domänen befinden, die sich nicht vertrauen (nicht vertrauenswürdige Domänen). Überprüfen Sie mithilfe der folgenden Schritte, ob Sie eine Verbindung mit den Endpunkten herstellen können:

• Verwenden Sie „Test-NetConnection“ (entspricht Telnet), um die Konnektivität zu überprüfen. Hier sehen Sie Beispiele für Befehle, die Sie verwenden können:

  $server_name = "your_server_name"
  $IP_address = "your_ip_address"
  $port_number = "your_port_number"
  
  Test-NetConnection -ComputerName $server_name -Port $port_number
  Test-NetConnection -ComputerName $IP_address -Port $port_number
  

• Wenn der Endpunkt lauscht und die Verbindung hergestellt wurde, wird „TcpTestSucceeded : True“ angezeigt. Wenn nicht, wird „TcpTestSucceededed : False“ angezeigt.

• Wenn die Test-NetConnection (Telnet)-Verbindung mit der IP-Adresse, jedoch nicht mit dem Servernamen hergestellt werden kann, liegt wahrscheinlich ein DNS-Problem oder ein Problem bei der Namensauflösung vor

• Wenn die Verbindung mit dem Servernamen, jedoch nicht mit der IP-Adresse hergestellt werden kann, sind möglicherweise auf dem Server mehrere Endpunkte definiert (eventuell eine andere SQL-Instanz), die an diesem Port lauschen. Obwohl der Status des Endpunkts für die betreffende Instanz „STARTED“ lautet, ist der Port möglicherweise an eine andere Instanz gebunden, sodass die richtige Instanz nicht lauschen und TCP-Verbindungen herstellen kann.

• Wenn Test-NetConnection keine Verbindung herstellen kann, suchen Sie nach Firewall- und/oder Virenschutzsoftware, die den betreffenden Endpunktport möglicherweise blockiert. Überprüfen Sie die Firewalleinstellung, um zu ermitteln, ob sie die Endpunktportkommunikation zwischen den Serverinstanzen, auf denen das primäre Replikat gehostet wird, und dem sekundären Replikat (standardmäßig Port 5022) zulässt. Führen Sie das folgende PowerShell-Skript aus, um nach deaktivierten Regeln für eingehenden Datenverkehr zu suchen:

• Wenn Sie SQL Server auf einer Azure-VM ausführen, müssen Sie außerdem sicherstellen, dass die Netzwerksicherheitsgruppe (NSG) den Datenverkehr an den Endpunktport zulässt. Überprüfen Sie die Firewalleinstellung (und NSG, im Falle einer Azure-VM), um zu ermitteln, ob sie die Endpunktportkommunikation zwischen den Serverinstanzen, auf denen das primäre Replikat gehostet wird, und dem sekundären Replikat (standardmäßig Port 5022) zulässt.

  Get-NetFirewallRule -Action Block -Enabled True -Direction Inbound |Format-Table
  

• Erfassen Sie die Ausgabe des Cmdlets „Get-NetTCPConnection“ (entspricht NETSTAT -a), und vergewissern Sie sich, dass der Status der IP:Port-Adresse des angegebenen Endpunkts LISTENING oder ESTABLISHED lautet.

  Get-NetTCPConnection 
  

Listener

Für die richtige Konfiguration eines Verfügbarkeitsgruppenlisteners befolgen Sie die Anleitung unter Konfigurieren eines Listeners für Always On-Verfügbarkeitsgruppen.

1. Sobald der Listener konfiguriert ist, können Sie die IP-Adresse und den Port, an dem er lauscht, anhand der folgenden Abfrage überprüfen:

   $server_name = $env:computername  #replace this with your sql instance "server\instance"
   
   sqlcmd -E -S$server_name -Q"SELECT dns_name AS AG_listener_name, port, ip_configuration_string_from_cluster 
   FROM sys.availability_group_listeners"
   

2. Mithilfe der folgenden Abfrage können Sie auch die Listenerinformationen zusammen mit den SQL Server-Ports abrufen:

   $server_name = $env:computername      #replace this with your sql instance "server\instance"
   
   sqlcmd -E -S($server_name) -Q("SELECT  convert(varchar(32), SERVERPROPERTY ('servername')) servername, convert(varchar(32),ip_address) ip_address, port, type_desc,state_desc, start_time 
   FROM sys.dm_tcp_listener_states 
   WHERE ip_address not in ('127.0.0.1', '::1') and type <> 2")
   

3. Wenn Sie die Konnektivität mit dem Listener einrichten möchten und vermuten, dass ein Port blockiert ist, können Sie einen Test mithilfe des PowerShell-Cmdlets „Test-NetConnection“ (entspricht Telnet) ausführen.

   $listener_name = "your_ag_listener"
   $IP_address = "your_ip_address"
   $port_number = "your_port_number"
   
   Test-NetConnection -ComputerName $listener_name -Port $port_number
   Test-NetConnection -ComputerName $IP_address -Port $port_number
   

4. Überprüfen Sie schließlich, ob der Listener am angegebenen Port lauscht:

   $port_number = "your_port_number"
   
   Get-NetTCPConnection -LocalPort $port_number -State Listen
   

Endpunktzugriff (SQL Server-Fehler 1418)

In dieser SQL Server-Meldung wird angegeben, dass die in der Endpunkt-URL angegebene Servernetzwerkadresse nicht erreichbar oder nicht vorhanden ist. Es wird vorgeschlagen, den Namen der Netzwerkadresse zu überprüfen und den Befehl erneut auszuführen.

Fehler beim Verknüpfen der Datenbank (SQL Server-Fehler 35250)

Dieser Abschnitt erläutert die möglichen Ursachen und die Lösung des Fehlers beim Verknüpfen von sekundären Datenbanken mit einer Verfügbarkeitsgruppe aufgrund einer inaktiven Verbindung mit dem primären Replikat. Dies ist die vollständige Fehlermeldung:

Msg 35250 The connection to the primary replica is not active. The command cannot be processed.

Lösung:

Die Zusammenfassung der Schritte finden Sie unten.

Eine ausführliche Schritt-für-Schritt-Anleitung finden Sie in der Beschreibung des Engine-Fehlers MSSQLSERVER_35250.

1. Stellen Sie sicher, dass der Endpunkt erstellt und gestartet wird.
2. Überprüfen Sie, ob Sie über Telnet eine Verbindung mit dem Endpunkt herstellen können, und stellen Sie sicher, dass keine Firewallregeln die Konnektivität blockieren.
3. Überprüfen Sie das System auf Fehler. Sie können sys.dm_hadr_availability_replica_states nach „last_connect_error_number“ abfragen, um das Verbindungsproblem zu diagnostizieren.
4. Stellen Sie sicher, dass der Endpunkt so definiert ist, dass er mit der IP/dem Port übereinstimmt, die oder den die Verfügbarkeitsgruppe verwendet.
5. Überprüfen Sie, ob das Netzwerkdienstkonto über die CONNECT-Berechtigung für den Endpunkt verfügt.
6. Führen Sie eine Überprüfung auf mögliche Probleme bei der Namensauflösung durch.
7. Stellen Sie sicher, dass ein aktueller Build von SQL Server (vorzugsweise der neueste Build) ausgeführt wird, um bereits behobene Probleme zu vermeiden.

Schreibgeschütztes Routing funktioniert nicht ordnungsgemäß

1. Stellen Sie sicher, dass Sie schreibgeschütztes Routing eingerichtet haben, indem Sie das Dokument Schreibgeschütztes Routing konfigurieren befolgen.

2. Sicherstellen der Unterstützung von Clienttreibern

   Die Clientanwendung muss einen Clientanbieter verwenden, der den ApplicationIntent-Parameter unterstützt. Weitere Informationen finden Sie unter Unterstützung für Treiber- und Clientkonnektivität für Verfügbarkeitsgruppen.

   Hinweis

   Wenn Sie eine Verbindung mit einem DNN-Listener (distributed network name, Name des verteilten Netzwerks) herstellen, muss der Anbieter auch den MultiSubnetFailover-Parameter unterstützen.

3. Sicherstellen, dass die Eigenschaften der Verbindungszeichenfolgen ordnungsgemäß festgelegt sind

   Damit schreibgeschütztes Routing funktioniert, muss Ihre Clientanwendung diese Eigenschaften in der Verbindungszeichenfolge verwenden:

   • Ein Datenbankname, der zur Verfügbarkeitsgruppe gehört
   • Den Namen eines Verfügbarkeitsgruppenlisteners
     • Wenn Sie einen DNN verwenden, müssen Sie den DNN-Listenernamen und die DNN-Portnummer <DNN name,DNN port> angeben.
   • „ApplicationIntent“ auf „ReadOnly“ festgelegt
   • Für einen DNN ist es erforderlich, dass „MultiSubnetFailover“ auf „TRUE“ festgelegt ist.

   Beispiele

   Dieses Beispiel veranschaulicht die Verbindungszeichenfolge für den .NET-Anbieter „System.Data.SqlClient“ für einen VNN-Listener (Virtual Network Name, Name des virtuellen Netzwerks):

   Server=tcp:VNN_AgListener,1433;Database=AgDb1;ApplicationIntent=ReadOnly;MultiSubnetFailover=True
   

   Dies veranschaulicht die Verbindungszeichenfolge für den .NET-Anbieter „System.Data.SqlClient“ für einen DNN-Listener (Distributed Network Name):

   Server=tcp:DNN_AgListener,DNN_Port;Database=AgDb1;ApplicationIntent=ReadOnly;MultiSubnetFailover=True
   

   Hinweis

   Wenn Sie Befehlszeilenprogramme wie SQLCMD verwenden, stellen Sie sicher, dass Sie die richtigen Schalter für den Servernamen angeben. In SQLCMD müssen Sie z. B. den Großbuchstabenschalter „-S“ verwenden, der den Servernamen angibt, und nicht den Kleinbuchstabenschalter „-s“, der für das Spaltentrennzeichen verwendet wird.
   Beispiel: sqlcmd -S AG_Listener,port -E -d AgDb1 -K ReadOnly -M

4. Stellen Sie sicher, dass der Listener der Verfügbarkeitsgruppe online ist. Um sicherzustellen, dass der Listener der Verfügbarkeitsgruppe online ist, wenden Sie die folgende Abfrage auf das primäre Replikat an:

   SELECT * FROM sys.dm_tcp_listener_states;
   

   Wenn Sie feststellen, dass der Listener offline ist, können Sie versuchen, ihn mit einem Befehl wie dem folgenden online zu schalten:

   ALTER AVAILABILITY GROUP myAG RESTART LISTENER 'AG_Listener';
   

5. Stellen Sie sicher, dass READ_ONLY_ROUTING_LIST ordnungsgemäß aufgefüllt ist. Stellen Sie für das primäre Replikat sicher, dass READ_ONLY_ROUTING_LIST nur Serverinstanzen enthält, die ein lesbares sekundäres Replikat hosten.

   Um die Eigenschaften der einzelnen Replikate anzuzeigen, können Sie diese Abfrage ausführen und den Konnektivitätsendpunkt (URL) des schreibgeschützten Replikats untersuchen.

   SELECT replica_id, replica_server_name, secondary_role_allow_connections_desc, read_only_routing_url 
   FROM sys.availability_replicas;   
   

   So zeigen Sie eine schreibgeschützte Routingliste an und vergleichen sie mit der Endpunkt-URL

   SELECT * FROM sys.availability_read_only_routing_lists;
   

   Zum Ändern einer schreibgeschützten Routingliste können Sie eine Abfrage wie diese verwenden:

   ALTER AVAILABILITY GROUP [AG1]   
   MODIFY REPLICA ON  
   N'COMPUTER02' WITH   
   (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02')));  
   

   Weitere Informationen finden Sie unter Konfigurieren des schreibgeschützten Routings für eine Verfügbarkeitsgruppe – SQL Server Always On.

6. Überprüfen Sie, ob der Port READ_ONLY_ROUTING_URL geöffnet ist. Stellen Sie sicher, dass die Windows-Firewall den Port READ_ONLY_ROUTING_URL nicht blockiert. Konfigurieren Sie eine Windows-Firewall für den Zugriff auf die Datenbank-Engine für jedes Replikat in „read_only_routing_list“ und für alle Clients, die sich mit diesen Replikaten verbinden sollen.

   Hinweis

   Wenn Sie SQL Server auf einer virtuellen Azure-VM ausführen, müssen Sie zusätzliche Konfigurationsschritte ausführen. Vergewissern Sie sich, dass die Netzwerksicherheitsgruppe (NSG) jeder Replikations-VM den Datenverkehr zum Port des Endpunkts und des DNN-Ports zulässt, wenn Sie den DNN-Listener verwenden. Wenn Sie VNN-Listener verwenden, müssen Sie sicherstellen, dass der Lastenausgleich richtig konfiguriert ist.

7. Stellen Sie sicher, dass die READ_ONLY_ROUTING_URL (TCP://systemadresse:port) den richtigen vollqualifizierten Domänennamen (FQDN) und die richtige Portnummer enthält. Thema

   • Berechnen von „read_only_routing_url“ für AlwaysOn
   • sys.availability_replicas (Transact-SQL)
   • ALTER AVAILABILITY GROUP (Transact-SQL)

8. Stellen Sie im SQL Server-Konfigurations-Manager eine ordnungsgemäße SQL Server-Netzwerkkonfiguration sicher.

   Prüfen Sie für jedes Replikat in „read_only_routing_list“ Folgendes:

   • SQL Server-Remotekonnektivität aktiviert
   • TCP/IP aktiviert
   • IP-Adressen ordnungsgemäß konfiguriert

   Hinweis

   Sie können schnell überprüfen, ob alle diese Funktionen richtig konfiguriert sind, wenn Sie mit der Syntax TCP:SQL_Instance von einem Remotecomputer aus eine Verbindung mit dem Instanznamen SQL Server eines sekundären Zielreplikats herstellen können.

Weitere Informationen finden Sie unter Konfigurieren eines Servers für das Überwachen eines bestimmten TCP-Ports (SQL Server-Konfigurations-Manager) und Anzeigen oder Ändern von Servereigenschaften (SQL Server)

Related Tasks

• Erstellung und Konfiguration von Verfügbarkeitsgruppen (SQL Server)

• Erstellen eines Endpunkts der Datenbankspiegelung für Windows-Authentifizierung (Transact-SQL)

• Angeben der Endpunkt-URL beim Hinzufügen oder Ändern eines Verfügbarkeitsreplikats (SQL Server)

• Manuelles Vorbereiten einer sekundären Datenbank auf eine Verfügbarkeitsgruppe (SQL Server)

• Problembehandlung bei einem fehlgeschlagenen Vorgang zum Hinzufügen einer Datei (Always On-Verfügbarkeitsgruppen)

• Verwaltung von Anmeldungen und Aufträgen für die Datenbanken einer Verfügbarkeitsgruppe (SQL Server)

• Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einer anderen Serverinstanz (SQL Server)

Verwandte Inhalte

• Anzeigen von Ereignissen und Protokollen für einen Failovercluster

• Get-ClusterLog-Failovercluster-Cmdlet

• SQL Server Always On Team Blog: The official SQL Server Always On Team Blog (SQL Server Always On-Teamblog: Der offizielle SQL Server Always On-Teamblog)

Weitere Informationen

Transportsicherheit für Datenbankspiegelung und Always On-Verfügbarkeitsgruppen (SQL Server)
Client-Netzwerkkonfiguration
Voraussetzungen, Einschränkungen und Empfehlungen für Always On-Verfügbarkeitsgruppen (SQL Server)