VERFÜGBARKEITSGRUPPE ÄNDERN (Transact-SQL)

Gilt für:SQL Server

Ändert eine vorhandene Always On-Verfügbarkeitsgruppe in SQL Server. Die meisten ALTER AVAILABILITY GROUP Argumente werden nur für das aktuelle primäre Replikat unterstützt. Die JOINFAILOVERArgumente und Argumente FORCE_FAILOVER_ALLOW_DATA_LOSS werden jedoch nur für sekundäre Replikate unterstützt.

Transact-SQL-Syntaxkonventionen

Syntax

ALTER AVAILABILITY GROUP group_name
  {
     SET ( <set_option_spec> )
   | ADD DATABASE database_name
   | REMOVE DATABASE database_name
   | ADD REPLICA ON <add_replica_spec>
   | MODIFY REPLICA ON <modify_replica_spec>
   | REMOVE REPLICA ON <server_instance>
   | JOIN
   | JOIN AVAILABILITY GROUP ON <add_availability_group_spec> [ , ...2 ]
   | MODIFY AVAILABILITY GROUP ON <modify_availability_group_spec> [ , ...2 ]
   | GRANT CREATE ANY DATABASE
   | DENY CREATE ANY DATABASE
   | FAILOVER
   | FORCE_FAILOVER_ALLOW_DATA_LOSS
   | ADD LISTENER 'dns_name' ( <add_listener_option> )
   | MODIFY LISTENER 'dns_name' ( <modify_listener_option> )
   | RESTART LISTENER 'dns_name'
   | REMOVE LISTENER 'dns_name'
   | OFFLINE
  }
[ ; ]

<set_option_spec> ::=
    AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY | SECONDARY | NONE }
  | FAILURE_CONDITION_LEVEL  = { 1 | 2 | 3 | 4 | 5 }
  | HEALTH_CHECK_TIMEOUT = milliseconds
  | DB_FAILOVER  = { ON | OFF }
  | DTC_SUPPORT  = { PER_DB | NONE }
  | REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = { integer }
  | ROLE = SECONDARY
  | CLUSTER_CONNECTION_OPTIONS = 'key_value_pairs> [ ;... ] '

<server_instance> ::=
 { 'system_name [ \instance_name ] ' | 'FCI_network_name [ \instance_name ] ' }

<add_replica_spec>::=
  <server_instance> WITH
    (
       ENDPOINT_URL = 'TCP://system-address:port' ,
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY } ,
       FAILOVER_MODE = { AUTOMATIC | MANUAL }
       [ , <add_replica_option> [ , ...n ] ]
    )

  <add_replica_option>::=
       SEEDING_MODE = { AUTOMATIC | MANUAL }
     | BACKUP_PRIORITY = n
     | SECONDARY_ROLE ( {
            [ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL } ]
        [ , ] [ READ_ONLY_ROUTING_URL = 'TCP://system-address:port' ]
     } )
     | PRIMARY_ROLE ( {
            [ ALLOW_CONNECTIONS = { READ_WRITE | ALL } ]
        [ , ] [ READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ , ...n ] ) | NONE } ]
        [ , ] [ READ_WRITE_ROUTING_URL = 'TCP://system-address:port' ]
     } )
     | SESSION_TIMEOUT = integer

<modify_replica_spec>::=
  <server_instance> WITH
    (
       ENDPOINT_URL = 'TCP://system-address:port'
     | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
     | FAILOVER_MODE = { AUTOMATIC | MANUAL }
     | SEEDING_MODE = { AUTOMATIC | MANUAL }
     | BACKUP_PRIORITY = n
     | SECONDARY_ROLE ( {
          [ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }  ]
        | [ READ_ONLY_ROUTING_URL = { 'TCP://system-address:port' | NONE } ]
          } )
     | PRIMARY_ROLE ( {
          [ ALLOW_CONNECTIONS = { READ_WRITE | ALL }   ]
        | [ READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ , ...n ] ) | NONE } ]
        | [ READ_WRITE_ROUTING_URL = { 'TCP://system-address:port' | NONE }  ]
          } )
     | SESSION_TIMEOUT = seconds
    )

<add_availability_group_spec>::=
 <ag_name> WITH
    (
       LISTENER_URL = 'TCP://system-address:port' ,
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT } ,
       FAILOVER_MODE = MANUAL ,
       SEEDING_MODE = { AUTOMATIC | MANUAL }
    )

<modify_availability_group_spec>::=
 <ag_name> WITH
    (
       LISTENER = 'TCP://system-address:port'
       | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
       | SEEDING_MODE = { AUTOMATIC | MANUAL }
    )

<add_listener_option> ::=
   {
      WITH DHCP [ ON ( <network_subnet_option> ) ]
    | WITH IP ( { ( <ip_address_option> ) } [ , ...n ] ) [ , PORT = listener_port ]
   }

  <network_subnet_option> ::=
     'ipv4_address' , 'ipv4_mask'

  <ip_address_option> ::=
     {
        'four_part_ipv4_address' , 'four_part_ipv4_mask'
      | 'ipv6_address'
     }

<modify_listener_option>::=
    {
       ADD IP ( <ip_address_option> )
     | PORT = listener_port
     | REMOVE IP ( 'ipv4_address' | 'ipv6_address')
    }

Argumente

group_name

Gibt den Namen der neuen Verfügbarkeitsgruppe an. group_name muss ein gültiger SQL Server-Bezeichner und in allen Verfügbarkeitsgruppen im WSFC-Cluster eindeutig sein.

AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SEKUNDÄR | NONE }

Gibt eine Einstellung an, wie ein Sicherungsauftrag das primäre Replikat auswertet, wenn Sie auswählen, wo Sicherungen ausgeführt werden sollen. Sie können einen gegebenen Sicherungsauftrag erstellen, um die automatisierte Sicherungseinstellung zu berücksichtigen. Es ist wichtig zu verstehen, dass die Präferenz nicht von SQL Server erzwungen wird, sodass sie keine Auswirkungen auf Ad-hoc-Sicherungen hat.

Wird nur für das primäre Replikat unterstützt.

Mit den Parametern werden folgende Werte angegeben:

Primär

Gibt an, dass die Sicherungen immer im primären Replikat auftreten. Diese Option ist nützlich, wenn Sie Sicherungsfeatures benötigen, z. B. das Erstellen differenzieller Sicherungen, die nicht unterstützt werden, wenn die Sicherung auf einem sekundären Replikat ausgeführt wird.

Wichtig

Wenn Sie den Protokollversand verwenden möchten, um sekundäre Datenbanken für eine Verfügbarkeitsgruppe vorzubereiten, legen Sie die automatisierte Sicherungseinstellung so Primary fest, dass alle sekundären Datenbanken vorbereitet und der Verfügbarkeitsgruppe beigetreten sind.

SECONDARY_ONLY

Gibt an, dass Sicherungen nie im primären Replikat auftreten. Wenn das primäre Replikat das einzige Onlinereplikat ist, tritt die Sicherung nicht auf.

SEKUNDÄR

Gibt an, dass Sicherungen in einem sekundären Replikat auftreten, es sei denn, das primäre Replikat ist das einzige Replikat online. In diesem Fall tritt die Sicherung auf dem primären Replikat auf. Dies ist das Standardverhalten.

Keine

Gibt an, dass Sicherungsaufträge die Rolle der Verfügbarkeitsreplikate ignorieren sollen, wenn sie das Replikat zum Durchführen der Sicherungen auswählen. Sicherungsaufträge können andere Faktoren auswerten, wie z. B. die Sicherungspriorität jedes Verfügbarkeitsreplikats in Verbindung mit seinem Betriebszustand und Verbindungsstatus.

Wichtig

Es gibt keine Erzwingung der AUTOMATED_BACKUP_PREFERENCE Einstellung. Die Interpretation dieser Einstellung hängt ggf. von der Logik ab, die Sie in Sicherungsaufträge für die Datenbanken in einer bestimmten Verfügbarkeitsgruppe erstellen. Die Einstellung für die automatische Sicherung hat keine Auswirkungen auf Ad-hoc-Sicherungen. Weitere Informationen finden Sie unter Konfigurieren von Sicherungen auf sekundären Replikaten einer AlwaysOn-Verfügbarkeitsgruppe.

Hinweis

Um die automatisierte Sicherungseinstellung einer vorhandenen Verfügbarkeitsgruppe anzuzeigen, wählen Sie die automated_backup_preference oder automated_backup_preference_desc Spalte der sys.availability_groups Katalogansicht aus. Darüber hinaus können sys.fn_hadr_backup_is_preferred_replica verwendet werden, um das bevorzugte Sicherungsreplikat zu ermitteln. Diese Funktion gibt immer für mindestens eines der Replikate zurück 1 , auch wenn AUTOMATED_BACKUP_PREFERENCE = NONE.

FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }

Gibt an, welche Fehlerbedingungen ein automatisches Failover für diese Verfügbarkeitsgruppe auslösen. FAILURE_CONDITION_LEVEL wird auf Gruppenebene festgelegt, ist aber nur für Verfügbarkeitsreplikate relevant, die für den Synchron-Commit-Verfügbarkeitsmodus (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT) konfiguriert sind. Darüber hinaus können Fehlerbedingungen ein automatisches Failover nur auslösen, wenn sowohl die primären als auch sekundären Replikate für den automatischen Failovermodus (FAILOVER_MODE = AUTOMATIC) konfiguriert sind und das sekundäre Replikat derzeit mit dem primären Replikat synchronisiert wird.

Wird nur für das primäre Replikat unterstützt.

Die Fehlerbedingungsebenen (1–5) reichen von der Ebene 1 mit den wenigsten Einschränkungen bis zur Ebene 5 mit den meisten Einschränkungen. Jede Bedingungsebene umfasst stets auch sämtliche weniger restriktiven Ebenen. Daher schließt die strengste Bedingungsebene 5 die vier Bedingungsebenen mit weniger Einschränkungen (1-4) ein, Ebene 4 schließt die Ebenen 1-3 ein usw. In der folgenden Tabelle wird die Fehlerbedingung beschrieben, die jeder Ebene entspricht.

Ebene	Fehlerbedingung
1	Gibt an, dass ein automatisches Failover initiiert wird, wenn eine der folgenden Aktionen auftritt: Der SQL Server -Dienst ist ausgefallen. Die Lease der Verfügbarkeitsgruppe für die Verbindung mit dem WSFC-Cluster läuft ab, da keine `ACK` von der Serverinstanz empfangen wird. Weitere Informationen finden Sie unter How It Works: SQL Server Always On Lease Timeout (Funktionsweise: SQL Server Always On-Leasetimeout).
2	Gibt an, dass ein automatisches Failover initiiert wird, wenn eine der folgenden Aktionen auftritt: Die Instanz von SQL Server stellt keine Verbindung mit dem Cluster her, und der vom Benutzer angegebene `HEALTH_CHECK_TIMEOUT` Schwellenwert der Verfügbarkeitsgruppe wird überschritten. Das Verfügbarkeitsreplikat weist einen fehlerhaften Status auf.
3	Gibt an, dass ein automatisches Failover bei kritischen INTERNEN SQL Server-Fehlern initiiert wird, z. B. verwaiste Spinlocks, schwerwiegende Schreibzugriffsverletzungen oder zu viel Dumping. Dies ist das Standardverhalten.
4	Gibt an, dass ein automatisches Failover bei moderaten internen SQL Server-Fehlern initiiert wird, z. B. eine dauerhafte Out-of-Memory-Bedingung im internen SQL Server-Ressourcenpool.
5	Gibt an, dass ein automatisches Failover unter allen qualifizierten Fehlerbedingungen initiiert wird, einschließlich: Erschöpfung der SQL Engine-Arbeitsthreads. Erkennung eines unlösbaren Deadlocks.

Hinweis

Fehlende Antwort durch eine Instanz von SQL Server auf Clientanforderungen ist für Verfügbarkeitsgruppen nicht relevant.

Die FAILURE_CONDITION_LEVEL Werte HEALTH_CHECK_TIMEOUT definieren eine flexible Failoverrichtlinie für eine bestimmte Gruppe. Diese flexible Failoverrichtlinie bietet eine präzise Kontrolle der Bedingungen, die ein automatisches Failover verursachen müssen. Weitere Informationen finden Sie unter Konfigurieren einer flexiblen automatischen Failoverrichtlinie für eine AlwaysOn-Verfügbarkeitsgruppe.

`HEALTH_CHECK_TIMEOUT` = Millisekunden

Gibt die Wartezeit in Millisekunden an, damit die gespeicherte sp_server_diagnostics Systemprozedur Serverintegritätsinformationen zurückgibt, bevor der WSFC-Cluster davon ausgeht, dass die Serverinstanz langsam ist oder nicht reagiert. Auf Gruppenebene festgelegt HEALTH_CHECK_TIMEOUT , aber es ist nur für Verfügbarkeitsreplikate relevant, die Sie für den Synchron-Commit-Verfügbarkeitsmodus mit automatischem Failover (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT) konfigurieren. Darüber hinaus kann ein Timeout zur Integritätsprüfung ein automatisches Failover nur auslösen, wenn sowohl die primären als auch sekundären Replikate für den automatischen Failovermodus (FAILOVER_MODE = AUTOMATIC) konfiguriert sind und das sekundäre Replikat derzeit mit dem primären Replikat synchronisiert wird.

Der Standardwert HEALTH_CHECK_TIMEOUT ist 30.000 Millisekunden (30 Sekunden). Der Mindestwert beträgt 15.000 Millisekunden (15 Sekunden), und der Maximalwert beträgt 4.294.967.295 Millisekunden.

Wird nur für das primäre Replikat unterstützt.

Wichtig

sp_server_diagnostics führt keine Integritätsprüfungen auf Datenbankebene durch.

DB_FAILOVER = { EIN | AUS }

Gibt die Antwort an, die akzeptiert wird, wenn eine Datenbank auf dem primären Replikat offline ist. Bei Festlegung auf ON" wird ein anderer Status als ONLINE für eine Datenbank in der Verfügbarkeitsgruppe ein automatisches Failover ausgelöst. Wenn Sie diese Option auf OFFfestlegen, löst nur die Integrität der Instanz das automatische Failover aus.

Weitere Informationen zu dieser Einstellung finden Sie in der Failoveroption zur Integritätserkennung auf Verfügbarkeitsgruppenebene.

DTC_SUPPORT = { PER_DB | KEINE }

Gibt an, ob verteilte Transaktionen für diese Verfügbarkeitsgruppe aktiviert sind. Verteilte Transaktionen werden ab SQL Server 2016 (13.x) nur für Datenbanken für Verfügbarkeitsgruppen unterstützt, und datenbankübergreifende Transaktionen werden erst ab SQL Server 2016 (13.x) SP2 unterstützt. PER_DB erstellt die Verfügbarkeitsgruppe mit Unterstützung für diese Transaktionen und fördert automatisch datenbankübergreifende Transaktionen, die Datenbanken in die Verfügbarkeitsgruppe einbeziehen, in verteilte Transaktionen. NONE verhindert die automatische Heraufstufung von datenbankübergreifenden Transaktionen auf verteilte Transaktionen und registriert die Datenbank nicht mit einer stabilen RMID in DTC. Verteilte Transaktionen werden nicht verhindert, wenn die Einstellung NONE verwendet wird. Datenbankfailover und automatische Wiederherstellung sind unter bestimmten Umständen jedoch nicht erfolgreich. Weitere Informationen finden Sie unter Transaktionen – Verfügbarkeitsgruppen und Datenbankspiegelung.

Hinweis

Unterstützung zum Ändern der DTC_SUPPORT Einstellung einer Verfügbarkeitsgruppe wurde in SQL Server 2016 (13.x) Service Pack 2 eingeführt. Diese Option kann nicht mit früheren Versionen verwendet werden. Um diese Einstellung in früheren Versionen von SQL Server zu ändern, müssen DROP Sie die Verfügbarkeitsgruppe und CREATE die Verfügbarkeitsgruppe erneut ändern.

Wichtig

DTC ist auf 32 Eintragung pro verteilter Transaktion beschränkt. Da jede Datenbank innerhalb einer Verfügbarkeitsgruppe mit dem DTC separat aufgeführt wird, wenn Ihre Transaktion mehr als 32 Datenbanken umfasst, können Sie den folgenden Fehler erhalten, wenn SQL Server versucht, die 33. Datenbank aufzuführen:

Enlist operation failed: 0x8004d101(XACT_E_TOOMANY_ENLISTMENTS). SQL Server could not register with Microsoft Distributed Transaction Coordinator (MS DTC) as a resource manager for this transaction. The transaction may have been stopped by the client or the resource manager.

Weitere Informationen zu verteilten Transaktionen in SQL Server finden Sie unter Verteilte Transaktionen.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Wurde in SQL Server 2017 (14.x) eingeführt. Legt die Mindestanzahl der synchronen sekundären Replikate fest, die erforderlich sind, bevor das primäre Replikat einen Commit für die Transaktion ausführt. Garantiert, dass die SQL Server-Transaktion wartet, bis die Transaktionsprotokolle für die Mindestanzahl von sekundären Replikaten aktualisiert werden.

Standardwert: 0. Bietet das gleiche Verhalten wie SQL Server 2016 (13.x).
Mindestwert: 0
Höchstwert: Anzahl der Replikate minus 1

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT bezieht sich auf Replikate im synchronen Commit-Modus. Wenn sich Replikate im synchronen Commitmodus befinden, warten Schreibvorgänge auf dem primären Replikat, bis Schreibvorgänge auf den synchronen Replikaten per Commit an das Transaktionsprotokoll der Replikatdatenbank übergeben werden. Wenn ein SQL Server, der ein sekundäres synchrones Replikat hostet, nicht mehr reagiert, wird der SQL Server, der das primäre Replikat hostet, als sekundäres Replikat NOT SYNCHRONIZED gekennzeichnet und fortgesetzt. Wenn die nicht reagierende Datenbank wieder online ist, befindet sie sich im Zustand "Nicht synchronisiert", und das Replikat wird als fehlerhaft markiert, bis die primäre Datenbank erneut synchronisiert werden kann. Diese Einstellung garantiert, dass das primäre Replikat erst fortgesetzt wird, wenn die Mindestanzahl der Replikate jede Transaktion zugesichert hat. Wenn die Mindestanzahl von Replikaten nicht verfügbar ist, tritt ein Commit für den primären Fehler auf. Für den Clustertyp EXTERNAL wird diese Einstellung geändert, wenn die Verfügbarkeitsgruppe der Clusterressource hinzugefügt wird. Weitere Informationen finden Sie unter Hochverfügbarkeit und Schutz von Daten für Verfügbarkeitsgruppenkonfigurationen.

Ab SQL Server 2022 (16.x) können Sie für eine verteilte Verfügbarkeitsgruppe festlegen REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT . Diese Einstellung wird für CREATE AVAILABILITY GROUP. Sie können zum Festlegen REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMITverwendenALTER AVAILABILITY GROUP. Zum Beispiel:

ALTER AVAILABILITY GROUP [<name>]
  SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = <integer>);

Rolle

Der einzige gültige Parameter ist SECONDARY, und diese SET Option ist nur in verteilten Verfügbarkeitsgruppen gültig. Verwenden Sie sie, um eine verteilte Verfügbarkeitsgruppe zu überschlagen.

CLUSTER_CONNECTION_OPTIONS

Gilt für: SQL Server 2025 (17.x) und spätere Versionen

Verwenden Sie die Klausel, um die CLUSTER_CONNECTION_OPTIONSTLS 1.3-Verschlüsselung für die Kommunikation zwischen dem Windows Server-Failovercluster und Ihren Verfügbarkeitsgruppenreplikaten zu erzwingen. Geben Sie die Optionen als Liste der Schlüsselwertpaare an, getrennt durch Semikolons. Verwenden Sie die Schlüssel-Wert-Paare, um die Verbindungszeichenfolgenverschlüsselung für die Verfügbarkeitsgruppe zu konfigurieren.

Um zur Standardverschlüsselung zurückzukehren, legen Sie die CLUSTER_CONNECTION_OPTIONS Klausel auf eine leere Zeichenfolge fest. SQL Server 2025 (17.x) setzt standardmäßig auf Encrypt=Mandatory, und TrustServerCertificate=Yes für Verbindungen zu Verfügbarkeitsgruppen-Replikaten und Listenern.

Weitere Informationen erfahren Sie, wie Sie eine Verbindung mit einer Verfügbarkeitsgruppe mit strenger Verschlüsselung und TDS 8.0 herstellen.

In der folgenden Tabelle werden die Schlüssel-Wert-Paare beschrieben, die Sie in der CLUSTER_CONNECTION_OPTIONS Klausel verwenden können:

Key	Unterstützte Werte	Description
`Encrypt`	`Mandatory`, `StrictOptional`	Gibt an, wie die Verschlüsselung für die Verfügbarkeitsgruppe erzwungen wird. Wenn der Server die Verschlüsselung nicht unterstützt, schlägt die Verbindung fehl. Wenn Sie die Verschlüsselung `Mandatory`auf "Ja" festlegen, muss sie `TrustServerCertificate` auf "Ja" festgelegt sein. Wenn Sie die Verschlüsselung `Strict`auf festlegen, wird sie `TrustServerCertificate` ignoriert. Hinweis: Dieses Schlüsselwertpaar ist erforderlich.
`HostNameInCertificate`	Replikatname oder AG-Listenername	Gibt den Replikatnamen oder den Verfügbarkeitsgruppenlistenernamen im Zertifikat an, das für die Verschlüsselung verwendet wird. Dieser Wert muss mit dem Wert im alternativen Antragstellernamen des Zertifikats übereinstimmen. Wenn der Servername im Zertifikat aufgeführt ist, können Sie das `HostNameInCertificate` Schlüsselwertpaar weglassen. Wenn der Servername nicht im Zertifikat aufgeführt ist, müssen Sie das `HostNameInCertificate` Schlüsselwertpaar mit dem Servernamen angeben. Hinweis: Dieses Schlüsselwertpaar ist optional.
`TrustServerCertificate`	`Yes`, `No`	Bei Festlegung auf `yes` überprüft der Treiber das TLS-/SSL-Serverzertifikat nicht. Wenn `no`, überprüft der Treiber das Zertifikat. Weitere Informationen erfahren Sie unter TDS 8.0. Hinweis: Dieses Schlüsselwertpaar ist optional.
`ServerCertificate`	Pfad zu Ihrem Zertifikat	Wenn Sie dies nicht verwenden `HostNameInCertificate`möchten, können Sie den Pfad zu Ihrem Zertifikat übergeben. Das Clusterdienstkonto muss über die Berechtigung zum Lesen des Zertifikats vom angegebenen Speicherort verfügen. Hinweis: Dieses Schlüsselwertpaar ist optional.
`CLUSTER_CONNECTION_OPTIONS`	Leere Zeichenfolge (`''`)	Löscht die vorhandene Konfiguration und wird auf die Standardverschlüsselungseinstellungen von `Encrypt=Mandatory` und `TrustServerCertificate=Yes`zurückgesetzt.

In den Beispielen erfahren Sie, wie Sie die CLUSTER_CONNECTION_OPTIONS Klausel verwenden.

DATENBANK-database_name HINZUFÜGEN

Gibt eine Liste von Benutzerdatenbanken an, die Sie der Verfügbarkeitsgruppe hinzufügen möchten. Diese Datenbanken müssen sich in der Instanz von SQL Server befinden, die das aktuelle primäre Replikat hostet. Sie können mehrere Datenbanken für eine Verfügbarkeitsgruppe angeben, aber jede Datenbank kann nur zu einer Verfügbarkeitsgruppe gehören. Informationen zum Typ der Datenbanken, die eine Verfügbarkeitsgruppe unterstützen kann, finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen. Wenn Sie herausfinden möchten, welche lokalen Datenbanken bereits zu einer Verfügbarkeitsgruppe gehören, lesen Sie die replica_id Spalte in der Katalogansicht "sys.databases ".

Wird nur für das primäre Replikat unterstützt.

Hinweis

Nachdem Sie die Verfügbarkeitsgruppe erstellt haben, müssen Sie eine Verbindung mit jeder Serverinstanz herstellen, die ein sekundäres Replikat hosten. Bereiten Sie dann jede sekundäre Datenbank vor, und verbinden Sie sie mit der Verfügbarkeitsgruppe. Weitere Informationen finden Sie unter Starten der Datenverschiebung in einer sekundären Always On-Datenbank (SQL Server).

DATENBANK-database_name ENTFERNEN

Entfernt die angegebene primäre Datenbank und die entsprechenden sekundären Datenbanken aus der Verfügbarkeitsgruppe. Wird nur für das primäre Replikat unterstützt.

Informationen zu empfohlenen Schritten nach dem Entfernen einer Verfügbarkeitsdatenbank aus einer Verfügbarkeitsgruppe finden Sie unter Entfernen einer primären Datenbank aus einer AlwaysOn-Verfügbarkeitsgruppe.

REPLIKAT HINZUFÜGEN EIN

Gibt eine bis acht SQL Server-Instanzen an, in denen sekundäre Replikate in einer Verfügbarkeitsgruppe gehostet werden sollen. Jedes Replikat wird durch die Serverinstanzadresse gefolgt von einer WITH (...) Klausel angegeben.

Wird nur für das primäre Replikat unterstützt.

Sie müssen jedes neue sekundäre Replikat mit der Verfügbarkeitsgruppe verknüpfen. Weitere Informationen finden Sie in der Beschreibung der JOIN Option weiter unten in diesem Abschnitt.

<server_instance>

Gibt die Adresse der Instanz von SQL Server an, die der Host für ein Replikat ist. Das Adressformat hängt davon ab, ob es sich bei der Instanz um die Standardinstanz oder eine benannte Instanz handelt und ob es sich um eine eigenständige Instanz oder um eine Failoverclusterinstanz (FCI) handelt. Die Syntax lautet wie folgt:

{ 'system_name[\instance_name]' | 'FCI_network_name[\instance_name]' }

Diese Adresse weist die folgenden Komponenten auf:

system_name

Der NetBIOS-Name des Computersystems, auf dem sich die Zielinstanz von SQL Server befindet. Dieser Computer muss ein WSFC-Knoten sein.

FCI_network_name

Der Netzwerkname, den Sie für den Zugriff auf einen SQL Server-Failovercluster verwenden. Verwenden Sie diesen Namen, wenn die Serverinstanz als SQL Server-Failoverpartner teilnimmt. Beim SELECT @@SERVERNAME Ausführen einer FCI-Serverinstanz wird die gesamte Zeichenfolge "FCI_network_name[\instance_name]" zurückgegeben (dies ist der vollständige Replikatname).

Weitere Informationen finden Sie unter @@SERVERNAME.

instance_name

Der Name einer Instanz eines SQL Server, der Hosts system_name oder FCI_network_name und die AlwaysOn aktiviert ist. Bei einer Standardserverinstanz ist instance_name optional. Bei dem Instanznamen wird die Groß-/Kleinschreibung berücksichtigt. Bei einer eigenständigen Serverinstanz ist dieser Wertname identisch mit dem wert, der durch Ausführen SELECT @@SERVERNAMEzurückgegeben wird.

\

Ein Trennzeichen, das nur beim Angeben von instance_nameverwendet wird, um es von system_name oder FCI_network_namezu trennen.

Informationen zu den Voraussetzungen für WSFC-Knoten und -Serverinstanzen finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen.

ENDPOINT_URL = 'TCP:// systemadresse:port'

Gibt den URL-Pfad für den Datenbankspiegelungsendpunkt in der Instanz von SQL Server an, die das Verfügbarkeitsreplikat hosten, das Sie hinzufügen oder ändern.

ENDPOINT_URL ist in der ADD REPLICA ON Klausel und optional in der MODIFY REPLICA ON Klausel erforderlich. Weitere Informationen finden Sie unter Angeben der Endpunkt-URL – Hinzufügen oder Ändern des Verfügbarkeitsreplikats.

'TCP://Systemadresse:Port'

Gibt eine URL zum Bestimmen einer Endpunkt-URL oder einer URL für das schreibgeschützte Routing an. Die URL-Parameter lauten wie folgt:

Systemadresse

Eine Zeichenfolge, z. B. ein Systemname, ein vollqualifizierter Domänenname oder eine IP-Adresse, die das Zielcomputersystem eindeutig identifiziert.

Hafen

Eine Portnummer, die dem Spiegelungsendpunkt der Serverinstanz (für die ENDPOINT_URL Option) oder der vom Datenbankmodul der Serverinstanz (für die READ_ONLY_ROUTING_URL Option) verwendeten Portnummer zugeordnet ist.

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

Gibt an, ob das primäre Replikat auf das sekundäre Replikat wartet, um die Härtung (Schreiben) der Protokolldatensätze auf den Datenträger zu bestätigen, bevor das primäre Replikat die Transaktion für eine bestimmte primäre Datenbank übernehmen kann. Die Transaktionen auf anderen Datenbanken über dasselbe primäre Replikat können unabhängig einen Commit ausführen.

SYNCHRONOUS_COMMIT

Gibt an, dass das primäre Replikat darauf wartet, Transaktionen zu übernehmen, bis sie auf dieses sekundäre Replikat (synchroner Commit-Modus) gehärtet werden. Sie können bis zu drei Replikate angeben SYNCHRONOUS_COMMIT , einschließlich des primären Replikats.

ASYNCHRONOUS_COMMIT

Gibt an, dass das primäre Replikat einen Commit für Transaktionen ausführt, ohne zu warten, bis dieses sekundäre Replikat das Protokoll verstärkt (Verfügbarkeitsmodus mit synchronem Commit). Sie können bis zu fünf Verfügbarkeitsreplikate angeben ASYNCHRONOUS_COMMIT , einschließlich des primären Replikats.

CONFIGURATION_ONLY

Gibt an, dass das primäre Replikat konfigurationsmetadaten der Verfügbarkeitsgruppe synchron in die master Datenbank dieses Replikats übernehmen. Das Replikat enthält keine Benutzerdaten. Diese Option:

Kann auf einer beliebigen Edition von SQL Server, darunter Express Edition gehostet werden.
Erfordert den Datenspiegelungsendpunkt des CONFIGURATION_ONLY Replikats als Typ WITNESS.
Kann nicht geändert werden.
Ist ungültig, wenn CLUSTER_TYPE = WSFC.

Weitere Informationen finden Sie unter High availability and data protection for Availability Group configurations (Hochverfügbarkeit und Datenschutz für Verfügbarkeitsgruppenkonfigurationen).

AVAILABILITY_MODE ist in der ADD REPLICA ON Klausel und optional in der MODIFY REPLICA ON Klausel erforderlich. Weitere Informationen finden Sie unter Unterschiede zwischen Verfügbarkeitsmodi für eine Always On-Verfügbarkeitsgruppe.

FAILOVER_MODE = { AUTOMATISCH | HANDBUCH }

Gibt den Failovermodus des Verfügbarkeitsreplikats an, das Sie definieren.

AUTOMATISCH

Aktiviert das automatische Failover. AUTOMATIC wird nur unterstützt, wenn Sie auch angeben AVAILABILITY_MODE = SYNCHRONOUS_COMMIT. Sie können für drei Verfügbarkeitsreplikate angeben AUTOMATIC , einschließlich des primären Replikats.

Hinweis

Vor SQL Server 2016 (13.x) sind Sie auf zwei automatische Failoverreplikate beschränkt, einschließlich des primären Replikats.
SQL Server-Failoverclusterinstanzen (FCIs) unterstützen kein automatisches Failover durch Verfügbarkeitsgruppen, sodass jedes Verfügbarkeitsreplikat, das ein FCI-Hosts nur für manuelles Failover konfiguriert werden kann.

MANUELL

Ermöglicht manuelles Failover oder erzwungenes manuelles Failover (erzwungenes Failover) durch den Datenbankadministrator.

Sie müssen in der ADD REPLICA ON Klausel angebenFAILOVER_MODE. Sie können sie optional in der MODIFY REPLICA ON Klausel angeben. Es gibt zwei Arten von manuellem Failover: manuelles Failover ohne Datenverlust und erzwungenes Failover (mit möglichen Datenverlusten). Unterschiedliche Bedingungen unterstützen diese Typen. Weitere Informationen finden Sie unter Failover und Failovermodi (Always On-Verfügbarkeitsgruppen).

SEEDING_MODE = { AUTOMATISCH | HANDBUCH }

Gibt an, wie für das sekundäre Replikat zuerst ein Seeding durchgeführt wird.

AUTOMATISCH

Ermöglicht direktes Seeding. Diese Methode startet das sekundäre Replikat über das Netzwerk. Diese Methode erfordert nicht, dass Sie eine Kopie der primären Datenbank im Replikat sichern und wiederherstellen.

Hinweis

Für direktes Seeding müssen Sie die Datenbankerstellung für jedes sekundäre Replikat zulassen, indem Sie die GRANT CREATE ANY DATABASE Option aufrufenALTER AVAILABILITY GROUP.

MANUELL

Gibt das manuelle Seeding an (Standard). Bei dieser Methode müssen Sie eine Sicherungskopie der Datenbank auf dem primären Replikat erstellen und diese manuell auf dem sekundären Replikat wiederherstellen.

BACKUP_PRIORITY = n

Gibt die Priorität für die Ausführung von Sicherungen auf diesem Replikat in Relation zu den anderen Replikaten in derselben Verfügbarkeitsgruppe an. Der Wert liegt im Bereich von 0 bis 100 und ist eine ganze Zahl. Diese Werte haben die folgenden Bedeutungen:

1..100 gibt an, dass das Verfügbarkeitsreplikat für die Durchführung von Sicherungen ausgewählt werden kann. 1 gibt die niedrigste Priorität und 100 die höchste Priorität an. Wenn BACKUP_PRIORITY = 1das Verfügbarkeitsreplikat nur zum Ausführen von Sicherungen ausgewählt wird, wenn derzeit keine Replikate mit höherer Priorität verfügbar sind.
0 gibt an, dass dieses Verfügbarkeitsreplikat nie zum Ausführen von Sicherungen ausgewählt wird. Diese Option ist z. B. nützlich für ein Remoteverfügbarkeitsreplikat, für das Keine Sicherungen fehlschlagen sollen.

Weitere Informationen finden Sie unter Auslagern von unterstützten Sicherungen auf sekundäre Replikate einer Verfügbarkeitsgruppe.

SECONDARY_ROLE ( ... )

Gibt rollenspezifische Einstellungen an, die wirksam werden, wenn dieses Verfügbarkeitsreplikat derzeit die sekundäre Rolle besitzt (wenn es sich um ein sekundäres Replikat handelt). Geben Sie innerhalb der Klammern eine oder beide sekundäre Rollenoptionen an. Wenn Sie beide angeben, verwenden Sie eine durch Trennzeichen getrennte Liste.

Folgende Optionen stehen für die sekundäre Rolle zur Verfügung:

ALLOW_CONNECTIONS = { NEIN | READ_ONLY | ALLE }

Gibt an, ob die Datenbanken eines bestimmten Verfügbarkeitsreplikats, das die sekundäre Rolle ausführt (als sekundäres Replikat fungieren), Verbindungen von Clients akzeptieren können, eine von:

Nein

Es werden keine Verbindungen mit sekundären Datenbanken dieses Replikats zugelassen. Sie sind für den Lesezugriff nicht verfügbar. Dies ist das Standardverhalten.

Nur-Lesen

Es sind nur Verbindungen mit den Datenbanken im sekundären Replikat zulässig, auf die die Application Intent-Eigenschaft festgelegt ReadOnlyist. Weitere Informationen zu dieser Eigenschaft finden Sie unter Using Connection String Keywords with SQL Server Native Client.

ALLE

Für alle Verbindungen mit den Datenbanken im sekundären Replikat ist der schreibgeschützte Zugriff zugelassen.

Weitere Informationen finden Sie unter Auslagern von schreibgeschützten Workloads auf ein sekundäres Replikat einer Always On-Verfügbarkeitsgruppe.

READ_ONLY_ROUTING_URL = { 'TCP:// systemadresse:port' | NONE }

Gibt die URL an, die für das Routing von Leseabsichtsverbindungsanforderungen an dieses Verfügbarkeitsreplikat verwendet werden soll. Diese URL ist der Ort, an dem das SQL Server-Datenbankmodul lauscht. In der Regel überwacht die Standardinstanz der SQL Server-Datenbank-Engine auf TCP-Port 1433.

Ab SQL Server 2025 (17.x) können Sie als NONE Ziel festlegenREAD_ONLY_ROUTING_URL, um das angegebene Nur-Lese-Routing für das Verfügbarkeitsreplikat zurückzusetzen und den Datenverkehr basierend auf dem Standardverhalten zu routen.

Fragen Sie für eine benannte Instanz die port Spalten und type_desc Spalten der sys.dm_tcp_listener_states dynamische Verwaltungsansicht ab, um die Portnummer abzurufen. Die Serverinstanz verwendet den Transact-SQL Listener (type_desc='TSQL').

Weitere Informationen zum Berechnen der schreibgeschützten Routing-URL für ein Verfügbarkeitsreplikat finden Sie unter Berechnen von read_only_routing_url für Always On.

Hinweis

Konfigurieren Sie für eine benannte Instanz von SQL Server den Transact-SQL Listener so, dass ein bestimmter Port verwendet wird. Weitere Informationen finden Sie unter Konfigurieren eines Servers zur Überwachung eines bestimmten TCP-Ports.

PRIMARY_ROLE ( ... )

Gibt rollenspezifische Einstellungen an, die wirksam werden, wenn dieses Verfügbarkeitsreplikat derzeit die primäre Rolle besitzt (wann immer es sich um das primäre Replikat handelt). Geben Sie innerhalb der Klammern eine oder beide primäre Rollenoptionen an. Wenn Sie beide angeben, verwenden Sie eine durch Trennzeichen getrennte Liste.

Folgende Optionen stehen für die primäre Rolle zur Verfügung:

ALLOW_CONNECTIONS = { READ_WRITE | ALLE }

Gibt den Verbindungstyp an, den die Datenbanken eines bestimmten Verfügbarkeitsreplikats, das die primäre Rolle (als primäres Replikat fungiert) von Clients annehmen kann, eine von:

Lesen_Schreiben

Verbindungen, bei denen die Application Intent-Verbindungseigenschaft festgelegt ist, ReadOnly sind unzulässig. Wenn die Application Intent-Eigenschaft auf ReadWrite oder die Application Intent-Verbindungseigenschaft nicht festgelegt ist, ist die Verbindung zulässig. Weitere Informationen zur Verbindungseigenschaft für die Anwendungsabsicht finden Sie unter Using Connection String Keywords with SQL Server Native Client.

ALLE

Für die Datenbanken im primären Replikat sind alle Verbindungen zugelassen. Dies ist das Standardverhalten.

READ_ONLY_ROUTING_LIST = { ('<server_instance>' [ , ... n ] ) | NONE }

Gibt beim Ausführen unter der sekundären Rolle eine durch Trennzeichen getrennte Liste von Serverinstanzen an, die Verfügbarkeitsreplikate für diese Verfügbarkeitsgruppe hosten, die die folgenden Anforderungen erfüllt:

Sie können so konfiguriert werden, dass alle Verbindungen oder schreibgeschützte Verbindungen zulässig sind (siehe das ALLOW_CONNECTIONS Argument der SECONDARY_ROLE Option, zuvor in diesem Artikel).
Lassen Sie ihre schreibgeschützte Routing-URL definiert (siehe das READ_ONLY_ROUTING_URL Argument der SECONDARY_ROLE Option, zuvor in diesem Artikel).

Die READ_ONLY_ROUTING_LIST Werte sind wie folgt:

<server_instance>

Gibt die Adresse der Instanz von SQL Server an, die der Host für ein Verfügbarkeitsreplikat ist, bei dem es sich um ein lesbares sekundäres Replikat handelt, wenn es sich bei der Ausführung unter der sekundären Rolle um ein lesbares sekundäres Replikat handelt.

Verwenden Sie eine durch Trennzeichen getrennte Liste, um alle der Serverinstanzen anzugeben, die ein lesbares sekundäres Replikat hosten könnten. Schreibgeschütztes Routing erfolgt in der Reihenfolge, in der Serverinstanzen in der Liste angegeben werden. Wenn Sie die Hostserverinstanz eines Replikats auf der schreibgeschützten Routingliste des Replikats einschließen, ist es eine empfohlene Vorgehensweise, diese Serverinstanz am Ende der Liste zu platzieren, damit Verbindungen für beabsichtigte Lesevorgänge bei Verfügbarkeit zu einem sekundären Replikat wechseln.

Beginnend mit SQL Server 2016 (13.x) können Sie einen Lastenausgleich für Anforderungen von beabsichtigten Lesevorgängen über lesbare sekundäre Replikate durchführen. Dies können Sie angeben, indem Sie die Replikate in geschachtelten Klammern innerhalb der schreibgeschützten Routingliste platzieren. Weitere Informationen und Beispiele finden Sie unter Configure load-balancing across read-only replicas (Konfigurieren des Lastenausgleichs für mehrere schreibgeschützte Replikate).

Keine

Gibt an, dass bei diesem Verfügbarkeitsreplikat das primäre Replikat das schreibgeschützte Routing nicht unterstützt wird. Dies ist das Standardverhalten. Bei Verwendung mit MODIFY REPLICA ONdiesem Wert wird ggf. eine vorhandene Liste deaktiviert.

{ READ_WRITE_ROUTING_URL = 'TCP:// systemadresse:port' | NONE }

Gilt für: SQL Server 2019 (15.x) und höhere Versionen

Gibt bei Ausführung unter der primären Rolle Serverinstanzen an, die Verfügbarkeitsreplikate für diese Verfügbarkeitsgruppe hosten, die die folgenden Anforderungen erfüllen:

Die Replikatspezifikation PRIMARY_ROLE enthält READ_WRITE_ROUTING_URL.
Die Verbindungszeichenfolge ist ReadWrite, entweder indem ApplicationIntent als ReadWrite definiert wird oder indem ApplicationIntent nicht festgelegt und somit der Standard (ReadWrite) wirksam wird.

Ab SQL Server 2025 (17.x) können Sie als NONE Ziel angebenREAD_WRITE_ROUTING_URL, um das angegebene Lese-Schreib-Routing für das Verfügbarkeitsreplikat zurückzusetzen und den Verkehr basierend auf dem Standardverhalten zu routen.

Weitere Informationen finden Sie unter Umleitung von Lese-/Schreibverbindungen vom sekundären zum primären Replikat (Always On-Verfügbarkeitsgruppen).

SESSION_TIMEOUT = Sekunden

Gibt den Zeitraum für das Sitzungstimeout in Sekunden an. Wenn Sie diese Option nicht angeben, beträgt der Standardzeitraum 10 Sekunden. Der Wert muss mindestens 5 Sekunden betragen.

Wichtig

Halten Sie den Timeoutzeitraum bei 10 Sekunden oder höher.

Weitere Informationen zum Sitzungstimeoutzeitraum finden Sie unter Was ist eine AlwaysOn-Verfügbarkeitsgruppe?

ÄNDERN DES REPLIKATS AUF

Ändert ein beliebiges Replikat der Verfügbarkeitsgruppe. Die Liste der zu ändernden Replikate enthält die Serverinstanzadresse und eine WITH (...) Klausel für jedes Replikat.

Wird nur für das primäre Replikat unterstützt.

ENTFERNEN DES REPLIKATS BEI

Entfernt das angegebene sekundäre Replikat aus der Verfügbarkeitsgruppe. Sie können das aktuelle primäre Replikat nicht aus einer Verfügbarkeitsgruppe entfernen. Wenn Sie ein Replikat entfernen, werden keine Daten mehr empfangen. Die sekundären Datenbanken des Replikats werden aus der Verfügbarkeitsgruppe entfernt und geben den Status ein RESTORING .

Wird nur für das primäre Replikat unterstützt.

Hinweis

Wenn Sie ein Replikat entfernen, während es nicht verfügbar oder fehlgeschlagen ist, erkennt es, wenn es wieder online ist, dass es nicht mehr zur Verfügbarkeitsgruppe gehört.

VERBINDEN

Bewirkt, dass die lokale Serverinstanz ein sekundäres Replikat in der angegebenen Verfügbarkeitsgruppe hostet.

Wird nur für ein sekundäres Replikat unterstützt, das noch nicht der Verfügbarkeitsgruppe beigetreten ist.

Weitere Informationen finden Sie unter Verbinden eines sekundären Replikats mit einer AlwaysOn-Verfügbarkeitsgruppe.

FAILOVER

Initiiert ein manuelles Failover der Verfügbarkeitsgruppe ohne Datenverlust an das sekundäre Replikat, mit dem Sie verbunden sind. Das Replikat, das das primäre Replikat hostt, ist das Failoverziel. Das Failoverziel übernimmt die primäre Rolle und stellt seine Kopie jeder Datenbank wieder her und stellt sie als neue primäre Datenbanken online bereit. Das frühere primäre Replikat geht gleichzeitig in die sekundäre Rolle über, und seine Datenbanken werden sekundäre Datenbanken und werden sofort angehalten. Möglicherweise können diese Rollen durch eine Reihe von Fehlern hin- und herwechseln.

Failover wird nur für ein synchrones commit-sekundäres Replikat unterstützt, das derzeit mit dem primären Replikat synchronisiert wird. Damit ein sekundäres Replikat synchronisiert werden kann, muss das primäre Replikat auch im Modus für synchrone Commits ausgeführt werden.

Für zwei SQL Server-Instanzen in einer Verfügbarkeitsgruppe können Sie den Failoverbefehl entweder für das primäre oder das sekundäre Replikat ausgeben. Für Instanzen, die über den Link "Verwaltete Instanz" repliziert wurden, müssen Sie den Failoverbefehl für das primäre Replikat ausgeben.

Hinweis

Bei einer Verfügbarkeitsgruppe wird ein Failoverbefehl zurückgegeben, sobald das Failoverziel den Befehl akzeptiert. Die Datenbankwiederherstellung tritt jedoch asynchron auf, nachdem die Verfügbarkeitsgruppe einen Fehler beendet hat.
Bei einem Verknüpfungsfailover für verwaltete Instanzen gibt der Failoverbefehl nach einem erfolgreichen Failover zurück, bei dem die Rollen für Quell- und Zielswitche ausgeführt werden, oder wenn der Failoverbefehl nach den Failoverbedingungsprüfungen fehlschlägt.
Sie können den Failoverbefehl nicht für ein geplantes Failover einer verteilten Verfügbarkeitsgruppe zwischen zwei SQL Server-Instanzen verwenden.

Informationen zu den Einschränkungen, Voraussetzungen und Empfehlungen zum Ausführen eines geplanten manuellen Failovers finden Sie unter Ausführen eines geplanten manuellen Failovers einer AlwaysOn-Verfügbarkeitsgruppe (SQL Server).

FORCE_FAILOVER_ALLOW_DATA_LOSS

Achtung

Initiieren Sie nur ein erzwungenes Failover als Notfallwiederherstellungsmaß, da es zu Datenverlust führen kann. Erzwingen des Failovers sollte nur ausgeführt werden, wenn das primäre Replikat nicht verfügbar ist, Sie bereit sind, potenzielle Datenverluste zu akzeptieren, und Sie müssen den Dienst sofort in der Verfügbarkeitsgruppe wiederherstellen.

Wird nur für ein Replikat unterstützt, dessen Rolle sich SECONDARY im Oder RESOLVING Zustand befindet. Das Replikat, auf dem Sie einen Failoverbefehl eingeben, ist das Failoverziel.

Erzwingt ein Failover der Verfügbarkeitsgruppe zum Failoverziel (mit möglichem Datenverlust). Das Failoverziel übernimmt die primäre Rolle und stellt seine Kopie jeder Datenbank wieder her und stellt sie als neue primäre Datenbanken online bereit. Auf jeglichen verbleibenden sekundären Replikaten wird jede sekundäre Datenbank angehalten, bis sie manuell fortgesetzt wird. Wenn das ehemalige primäre Replikat verfügbar ist, wechselt es zur sekundären Rolle, und seine Datenbanken werden angehaltene sekundäre Datenbanken.

Für Instanzen, die über den Link "Verwaltete Instanz" repliziert wurden, müssen Sie den FORCE_FAILOVER_ALLOW_DATA_LOSS Befehl für das sekundäre Replikat (das Failoverziel) ausgeben.

Hinweis

Ein Failoverbefehl wird zurückgegeben, sobald das Failoverziel den Befehl akzeptiert. Die Datenbankwiederherstellung tritt jedoch asynchron auf, nachdem die Verfügbarkeitsgruppe einen Fehler beendet hat.

Informationen zu den Einschränkungen, Voraussetzungen und Empfehlungen für das Erzwingen von Failover und die Auswirkungen eines erzwungenen Failovers auf die ehemaligen primären Datenbanken in der Verfügbarkeitsgruppe finden Sie unter Ausführen eines erzwungenen manuellen Failovers einer AlwaysOn-Verfügbarkeitsgruppe (SQL Server).

ADD LISTENER 'dns_name' ( <add_listener_option> )

Definiert einen neuen Verfügbarkeitsgruppenlistener für diese Verfügbarkeitsgruppe. Wird nur für das primäre Replikat unterstützt.

Wichtig

Bevor Sie Ihren ersten Listener erstellen, lesen Sie " Konfigurieren eines Listeners für eine AlwaysOn-Verfügbarkeitsgruppe".

Führen Sie nach dem Erstellen eines Listeners für eine bestimmte Verfügbarkeitsgruppe die folgenden Schritte aus:

Bitten Sie den Netzwerkadministrator, die IP-Adresse des Listeners zur exklusiven Verwendung zu reservieren.
Geben Sie den DNS-Hostnamen des Listeners an Anwendungsentwickler weiter, damit diese den Namen in Verbindungszeichenfolgen zum Anfordern von Clientverbindungen mit dieser Verfügbarkeitsgruppe verwenden.

dns_name

Gibt den DNS-Hostnamen des Verfügbarkeitsgruppenlisteners an. Der DNS-Name des Listeners muss in der Domäne und NetBIOS eindeutig sein.

dns_name ist ein Zeichenfolgenwert. Dieser Name darf nur alphanumerische Zeichen, Bindestriche (-) und Unterstriche (_) enthalten (in beliebiger Reihenfolge). Bei DNS-Hostnamen muss die Groß-/Kleinschreibung beachtet werden. Die maximale Länge beträgt 63 Zeichen.

Geben Sie eine aussagekräftige Zeichenfolge an. Für eine Verfügbarkeitsgruppe mit dem Namen AG1wäre ein sinnvoller DNS-Hostname z. B. ag1-listener.

Wichtig

NetBIOS erkennt nur die ersten 15 Zeichen in der dns_name. Wenn Sie über zwei WSFC-Cluster verfügen, die von demselben Active Directory gesteuert werden, und Sie versuchen, Verfügbarkeitsgruppenlistener in beiden Clustern mithilfe von Namen mit mehr als 15 Zeichen und einem identischen Präfix von 15 Zeichen zu erstellen, erhalten Sie eine Fehlerberichterstattung, dass die Virtual Network Name-Ressource nicht online gebracht werden konnte. Informationen zu Präfix-Benennungsregeln für DNS-Namen finden Sie unter Zuweisen von Domänennamen.

VERFÜGBARKEITSGRUPPE BEITRETEN BEI

Tritt einer verteilten Verfügbarkeitsgruppe bei. Wenn Sie eine verteilte Verfügbarkeitsgruppe erstellen, ist die Verfügbarkeitsgruppe auf dem Cluster, in dem Sie sie erstellen, die primäre Verfügbarkeitsgruppe. Die Verfügbarkeitsgruppe, die der verteilten Verfügbarkeitsgruppe beitritt, ist die sekundäre Verfügbarkeitsgruppe.

<ag_name>

gibt den Namen der Verfügbarkeitsgruppe an, die eine Hälfte der verteilten Verfügbarkeitsgruppe ausmacht.

LISTENER = 'TCP:// systemadresse:port'

Gibt den URL-Pfad für den Listener an, der der Verfügbarkeitsgruppe zugeordnet ist.

Die LISTENER Klausel ist erforderlich.

'TCP:// systemadresse:port'

Gibt eine URL für den Listener an, der der Verfügbarkeitsgruppe zugeordnet ist. Die URL-Parameter lauten wie folgt:

Systemadresse

Eine Zeichenfolge, z. B. ein Systemname, ein vollqualifizierter Domänenname oder eine IP-Adresse, die den Listener eindeutig identifiziert.

Hafen

Eine Portnummer, die dem Spiegelungsendpunkt der Verfügbarkeitsgruppe zugeordnet ist. Dies ist nicht der Port des Listeners.

VERFÜGBARKEITSMODUS = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

Gibt an, ob das primäre Replikat auf die sekundäre Verfügbarkeitsgruppe wartet, um die Härtung (Schreiben) der Protokolldatensätze auf den Datenträger zu bestätigen, bevor das primäre Replikat die Transaktion für eine bestimmte primäre Datenbank übernehmen kann.

SYNCHRONOUS_COMMIT

Gibt an, dass das primäre Replikat darauf wartet, Transaktionen zu übernehmen, bis es eine Bestätigung erhält, dass die Transaktionen in der sekundären Verfügbarkeitsgruppe gehärtet werden. Sie können bis zu zwei Verfügbarkeitsgruppen angeben SYNCHRONOUS_COMMIT , einschließlich der primären Verfügbarkeitsgruppe.

ASYNCHRONOUS_COMMIT

Gibt an, dass das primäre Replikat Transaktionen ausführt, ohne zu warten, bis diese sekundäre Verfügbarkeitsgruppe das Protokoll verstärkt. Sie können bis zu zwei Verfügbarkeitsgruppen angeben ASYNCHRONOUS_COMMIT , einschließlich der primären Verfügbarkeitsgruppe.

Die AVAILABILITY_MODE Klausel ist erforderlich.

FAILOVER_MODE = { MANUELL }

Gibt den Failovermodus der verteilten Verfügbarkeitsgruppe an.

MANUELL

Ermöglicht ein geplantes manuelles Failover oder ein erzwungenes manuelles Failover (üblicherweise als erzwungenes Failover bezeichnet) durch den Datenbankadministrator.

Automatisches Failover zur sekundären Verfügbarkeitsgruppe wird nicht unterstützt.

SEEDING_MODE = { AUTOMATISCH | HANDBUCH }

Gibt an, wie für die sekundäre Verfügbarkeitsgruppe zuerst ein Seeding durchgeführt wird.

AUTOMATISCH

Ermöglicht das automatische Seeding. Diese Methode startet die sekundäre Verfügbarkeitsgruppe über das Netzwerk. Diese Methode erfordert nicht, dass Sie eine Kopie der primären Datenbank in den Replikaten der sekundären Verfügbarkeitsgruppe sichern und wiederherstellen.

MANUELL

Gibt das manuelle Seeding an. Diese Methode erfordert, dass Sie eine Sicherung der Datenbank im primären Replikat erstellen und diese Sicherung auf den Replikaten der sekundären Verfügbarkeitsgruppe manuell wiederherstellen.

ÄNDERN DER VERFÜGBARKEITSGRUPPE AUF

Ändert Verfügbarkeitsgruppeneinstellungen einer verteilten Verfügbarkeitsgruppe. Die Liste der zu ändernden Verfügbarkeitsgruppen enthält den Namen der Verfügbarkeitsgruppe und eine WITH (...) Klausel für jede Verfügbarkeitsgruppe.

Wichtig

Sie müssen diesen Befehl sowohl für die primäre Verfügbarkeitsgruppe als auch für sekundäre Verfügbarkeitsgruppeninstanzen ausführen.

GEWÄHRUNG ZUM ERSTELLEN EINER BELIEBIGEN DATENBANK

Ermöglicht der Verfügbarkeitsgruppe das Erstellen von Datenbanken im Auftrag des primären Replikats, das direkte Seeding (SEEDING_MODE = AUTOMATIC) unterstützt. Führen Sie diesen Parameter für jedes sekundäre Replikat aus, das direkte Seeding unterstützt, nachdem die sekundäre Gruppe der Verfügbarkeitsgruppe beigetreten ist. Erfordert die CREATE ANY DATABASE-Berechtigung.

VERWEIGERN ERSTELLEN EINER DATENBANK

Entzieht der Verfügbarkeitsgruppe die Erlaubnis, Datenbanken für das primäre Replikat zu erstellen.

<add_listener_option>

ADD LISTENER verwendet eine der folgenden Optionen:

MIT DHCP [ AUF { ('four_part_ipv4_address','four_part_ipv4_mask') } ]

Gibt an, dass der Verfügbarkeitsgruppenlistener das Dynamic Host Configuration-Protokoll (DHCP) verwendet. Verwenden Sie optional die ON Klausel, um das Netzwerk zu identifizieren, in dem dieser Listener erstellt wird. DHCP ist auf ein einzelnes Subnetz beschränkt, das für jede Serverinstanz verwendet wird, die ein Verfügbarkeitsreplikat in der Verfügbarkeitsgruppe hostet.

Wichtig

Nutzen Sie DHCP nicht in einer Produktionsumgebung. Wenn Ausfallzeiten vorliegen und die DHCP-IP-Lease abläuft, ist zusätzliche Zeit erforderlich, um die neue DHCP-Netzwerk-IP-Adresse zu registrieren, die dem DNS-Namen des Listeners zugeordnet ist und sich auf die Clientkonnektivität auswirkt. DHCP eignet sich jedoch gut zum Einrichten der Entwicklungs- und Testumgebung, um grundlegende Funktionen von Verfügbarkeitsgruppen und die Integration in Ihre Anwendungen zu überprüfen.

Zum Beispiel:

WITH DHCP ON ('10.120.19.0','255.255.254.0')

WITH IP ( { ('four_part_ipv4_address','four_part_ipv4_mask') | ('ipv6_address') } [ , ... n ] ) [ , PORT = listener_port ]

Statt DHCP zu verwenden, verwendet der Verfügbarkeitsgruppenlistener eine oder mehrere statische IP-Adressen. Um eine Verfügbarkeitsgruppe über mehrere Subnetze zu erstellen, erfordert jedes Subnetz in der Listenerkonfiguration eine statische IP-Adresse. Für ein angegebenes Subnetz kann die statische IP-Adresse entweder eine IPv4-Adresse oder eine IPv6-Adresse sein. Wenden Sie sich an Ihren Netzwerkadministrator, um eine statische IP-Adresse für jedes Subnetz abzurufen, das ein Verfügbarkeitsreplikat für die neue Verfügbarkeitsgruppe hostt.

Zum Beispiel:

WITH IP ( ('10.120.19.155','255.255.254.0') )

ipv4_address

Eine vierteilige IPv4-Adresse für einen Verfügbarkeitsgruppenlistener. Beispiel: 10.120.19.155.

ipv4_mask

Eine vierteilige IPv4-Maske für einen Verfügbarkeitsgruppenlistener. Beispiel: 255.255.254.0.

ipv6_address

Eine IPv6-Adresse für einen Verfügbarkeitsgruppenlistener. Beispiel: 2001::4898:23:1002:20f:1fff:feff:b3a3.

ANSCHLUSS = listener_port

Die Portnummer (listener_port), die von einem Verfügbarkeitsgruppenlistener verwendet werden soll, den die WITH IP Klausel angibt. PORT ist optional.

Die Standardportnummer wird 1433unterstützt. Sie können jedoch eine andere Portnummer auswählen.

Beispiel: WITH IP ( ('2001::4898:23:1002:20f:1fff:feff:b3a3') ) , PORT = 7777

MODIFY LISTENER 'dns_name' ( <modify_listener_option> )

Ändert einen vorhandenen Verfügbarkeitsgruppenlistener für diese Verfügbarkeitsgruppe. Wird nur für das primäre Replikat unterstützt.

<modify_listener_option>

MODIFY LISTENER verwendet eine der folgenden Optionen:

ADD IP { ('four_part_ipv4_address','four_part_ipv4_mask') | ('ipv6_address') }

Fügt die angegebene IP-Adresse dem von dns_name angegebenen Verfügbarkeitsgruppenlistener hinzu.

ANSCHLUSS = listener_port

Die Beschreibung dieses Arguments finden Sie weiter oben in diesem Abschnitt.

REMOVE IP { ('four_part_ipv4_address') | ('ipv6_address') }

Gilt für: SQL Server 2025 (17.x) und spätere Versionen

Entfernt die angegebene IP-Adresse aus dem angegebenen Verfügbarkeitsgruppenlistener.

LISTENER NEU STARTEN 'dns_name'

Startet den Listener neu, der dem angegebenen DNS-Namen zugeordnet ist. Wird nur für das primäre Replikat unterstützt.

LISTENER "dns_name" ENTFERNEN

Entfernt den Listener, der dem angegebenen DNS-Namen zugeordnet ist. Wird nur für das primäre Replikat unterstützt.

OFFLINE

Schaltet eine Onlineverfügbarkeitsgruppe offline. Es gibt keinen Datenverlust für synchrone Commitdatenbanken.

Wenn eine Verfügbarkeitsgruppe offline ist, werden ihre Datenbanken für Clients nicht verfügbar, und Sie können die Verfügbarkeitsgruppe nicht wieder online schalten. Verwenden Sie daher die OFFLINE Option nur während einer clusterübergreifenden Migration von AlwaysOn-Verfügbarkeitsgruppen, wenn Sie Verfügbarkeitsgruppenressourcen zu einem neuen WSFC-Cluster migrieren.

Weitere Informationen finden Sie unter Offlineschalten einer Verfügbarkeitsgruppe (SQL Server).

Voraussetzungen und Einschränkungen

Informationen zu Voraussetzungen und Einschränkungen für Verfügbarkeitsreplikate und auf ihren Hostserverinstanzen und -computern finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen.

Informationen zu Einschränkungen für die AVAILABILITY GROUP Transact-SQL-Anweisungen finden Sie unter Transact-SQL Anweisungen für Always On-Verfügbarkeitsgruppen.

Berechtigungen

Sie benötigen ALTER AVAILABILITY GROUP berechtigungen für die Verfügbarkeitsgruppe, CONTROL AVAILABILITY GROUP die Berechtigung, die Berechtigung, ALTER ANY AVAILABILITY GROUP die Berechtigung oder CONTROL SERVER die Berechtigung. Sie benötigen ALTER ANY DATABASE auch die Berechtigung.

Beispiele

Ein. Verknüpfen eines sekundären Replikats mit einer Verfügbarkeitsgruppe

Im folgenden Beispiel wird ein sekundäres Replikat verknüpft, mit dem Sie mit der AccountsAG-Verfügbarkeitsgruppe verbunden sind.

ALTER AVAILABILITY GROUP AccountsAG JOIN;
GO

B. Erzwingen des Failovers einer Verfügbarkeitsgruppe

Im folgenden Beispiel wird erzwungen, dass die AccountsAG Verfügbarkeitsgruppe mit dem sekundären Replikat fehlschlägt, mit dem Sie verbunden sind.

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
GO

C. Erzwingen der Verschlüsselung in Verbindungen mit der Verfügbarkeitsgruppe

Die Beispiele in diesem Abschnitt erzwingen die Verschlüsselung in Verbindungen mit der AccountsAG Verfügbarkeitsgruppe.

Wenn der Servername in jedem Zertifikat wie durch eine der Methoden definiert angezeigt wird, können Sie die HostNameInCertificate Option weglassen:

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict')

Wenn Sie die Methode 1 befolgt haben, den Servernamen jedoch nicht als alternative Antragstellernamen im Zertifikat aufgeführt haben, müssen Sie den Wert angeben, der im Alternativen Antragstellernamen in der HostNameInCertificate Option angezeigt wird:

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict;HostNameInCertificate=<Subject Alternative Name>')

Wenn Sie die Methode 1 befolgt haben und die ServerCertificate Eigenschaft verwenden möchten, anstatt einen Wert für HostNameInCertificate:

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict;ServerCertificate=C:\Users\admin\SqlAGCertificate.cer')

Feedback

War diese Seite hilfreich?

Last updated on 2026-01-06

Teilen über

VERFÜGBARKEITSGRUPPE ÄNDERN (Transact-SQL)

Syntax

Argumente

group_name

AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SEKUNDÄR | NONE }

Primär

SECONDARY_ONLY

SEKUNDÄR

Keine

FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }

HEALTH_CHECK_TIMEOUT = Millisekunden

DB_FAILOVER = { EIN | AUS }

DTC_SUPPORT = { PER_DB | KEINE }

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Rolle

CLUSTER_CONNECTION_OPTIONS

DATENBANK-database_name HINZUFÜGEN

DATENBANK-database_name ENTFERNEN

REPLIKAT HINZUFÜGEN EIN

<server_instance>

system_name

FCI_network_name

instance_name

\

ENDPOINT_URL = '*TCP:// systemadresse:*port'

'TCP://Systemadresse:Port'

Systemadresse

Hafen

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

CONFIGURATION_ONLY

FAILOVER_MODE = { AUTOMATISCH | HANDBUCH }

AUTOMATISCH

MANUELL

SEEDING_MODE = { AUTOMATISCH | HANDBUCH }

AUTOMATISCH

MANUELL

BACKUP_PRIORITY = n

SECONDARY_ROLE ( ... )

ALLOW_CONNECTIONS = { NEIN | READ_ONLY | ALLE }

Nein

Nur-Lesen

ALLE

READ_ONLY_ROUTING_URL = { '*TCP:// systemadresse:*port' | NONE }

PRIMARY_ROLE ( ... )

ALLOW_CONNECTIONS = { READ_WRITE | ALLE }

Lesen_Schreiben

ALLE

READ_ONLY_ROUTING_LIST = { ('<server_instance>' [ , ... n ] ) | NONE }

<server_instance>

Keine

{ READ_WRITE_ROUTING_URL = '*TCP:// systemadresse:*port' | NONE }

SESSION_TIMEOUT = Sekunden

ÄNDERN DES REPLIKATS AUF

ENTFERNEN DES REPLIKATS BEI

VERBINDEN

FAILOVER

FORCE_FAILOVER_ALLOW_DATA_LOSS

ADD LISTENER 'dns_name' ( <add_listener_option> )

dns_name

VERFÜGBARKEITSGRUPPE BEITRETEN BEI

<ag_name>

LISTENER = '*TCP:// systemadresse:*port'

'*TCP:// systemadresse:*port'

Systemadresse

Hafen

VERFÜGBARKEITSMODUS = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

FAILOVER_MODE = { MANUELL }

MANUELL

SEEDING_MODE = { AUTOMATISCH | HANDBUCH }

AUTOMATISCH

MANUELL

ÄNDERN DER VERFÜGBARKEITSGRUPPE AUF

GEWÄHRUNG ZUM ERSTELLEN EINER BELIEBIGEN DATENBANK

VERWEIGERN ERSTELLEN EINER DATENBANK

<add_listener_option>

`HEALTH_CHECK_TIMEOUT` = Millisekunden

ENDPOINT_URL = 'TCP:// systemadresse:port'

READ_ONLY_ROUTING_URL = { 'TCP:// systemadresse:port' | NONE }

{ READ_WRITE_ROUTING_URL = 'TCP:// systemadresse:port' | NONE }

LISTENER = 'TCP:// systemadresse:port'

'TCP:// systemadresse:port'