Freigeben über

ALTER AVAILABILITY GROUP (Transact-SQL)

  • Artikel

Gilt für:SQL Server

Ändert eine vorhandene Always On-Verfügbarkeitsgruppe in SQL Server. Die meisten ALTER AVAILABILITY GROUP-Argumente werden nur von dem aktuellen primäre Replikat unterstützt. Die JOIN-, FAILOVER- und FORCE_FAILOVER_ALLOW_DATA_LOSS-Argumente werden hingegen nur auf sekundären Replikaten 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
  
<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'   
          } )  
     | 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 = 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  
    }

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 auswerten soll, 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 Einstellung 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:

PRIMARY

Gibt an, dass die Sicherungen immer auf dem primären Replikat erfolgen müssen. 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 auf eine Verfügbarkeitsgruppe vorzubereiten, legen Sie die Voreinstellung für automatisierte Sicherungen auf Primär fest, bis alle sekundären Datenbanken vorbereitet und mit der Verfügbarkeitsgruppe verknüpft worden sind.

SECONDARY_ONLY

Gibt an, dass Sicherungen nie auf dem primären Replikat ausgeführt werden dürfen. Wenn das primäre Replikat das einzige Onlinereplikat ist, sollte die Sicherung nicht erfolgen.

SECONDARY

Gibt an, dass Sicherungen auf einem sekundären Replikat erfolgen müssen, außer wenn es sich beim primären Replikat um das einzige Onlinereplikat handelt. In diesem Fall muss die Sicherung auf dem primären Replikat erfolgen. 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 von der Logik ab, die Sie ggf. per Skript in Sicherungsaufträge für die Datenbanken in einer angegebenen Verfügbarkeitsgruppe integriert haben. Die Voreinstellung für die automatisierte Sicherung hat keine Auswirkungen auf Ad-hoc-Sicherungen. Weitere Informationen finden Sie unter Konfigurieren der Sicherung auf Verfügbarkeitsreplikaten (SQL Server).

Hinweis

Um die automatisierte Sicherungseinstellung einer vorhandenen Verfügbarkeitsgruppe anzuzeigen, wählen Sie die Spalten automated_backup_preference oder automated_backup_preference_desc der Katalogsicht sys.availability_groups aus. Darüber hinaus kann sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) verwendet werden, um das bevorzugte Sicherungsreplikat zu bestimmen. Diese Funktion gibt immer 1 für mindestens eines der Replikate zurück, sogar wenn AUTOMATED_BACKUP_PREFERENCE = NONE ist.

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 auf Verfügbarkeitsreplikaten relevant, die für den Verfügbarkeitsmodus mit synchronen Commits (AVAILIBILITY_MODE = SYNCHRONOUS_COMMIT) konfiguriert sind. Weiterhin können Fehlerbedingungen nur ein automatisches Failover auslösen, wenn das primäre und das sekundäre Replikat für den automatischen Failovermodus konfiguriert sind (FAILOVER_MODE = AUTOMATIC) und das sekundäre Replikat gerade 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 der jeweiligen Ebene entspricht.

Ebene Fehlerbedingung
1 Gibt an, dass in einem der folgenden Fälle ein automatisches Failover initiiert werden muss:

Der SQL Server -Dienst ist ausgefallen.

Das Leasing der Verfügbarkeitsgruppe für die Verbindung mit dem WSFC-Cluster läuft ab, da keine ACK-Meldung 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 in einem der folgenden Fälle ein automatisches Failover initiiert werden muss:

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 werden soll, z. B. verwaisten Spinlocks, schwerwiegenden Schreibzugriffsverletzungen oder zu vielen Sicherungen.

Dies ist das Standardverhalten.
4 Gibt an, dass ein automatisches Failover bei mittelschweren internen SQL Server-Fehlern initiiert werden soll, z. B. bei dauerhaft unzureichendem Arbeitsspeicher im internen SQL Server-Ressourcenpool.
5 Gibt an, dass ein automatisches Failover bei sämtlichen qualifizierten Fehlerbedingungen initiiert werden soll, 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.

Der FAILURE_CONDITION_LEVEL- und der HEALTH_CHECK_TIMEOUT-Wert definieren eine flexible Failoverrichtlinie für eine angegebene Gruppe. Diese flexible Failoverrichtlinie bietet eine präzise Kontrolle der Bedingungen, die ein automatisches Failover verursachen müssen. Weitere Informationen finden Sie unter Flexible Failoverrichtlinie für automatisches Failover einer Verfügbarkeitsgruppe (SQL Server).

HEALTH_CHECK_TIMEOUT = Millisekunden

Gibt die Wartezeit (in Millisekunden) für die gespeicherte Systemprozedur sp_server_diagnostics an, um Informationen über den Serverzustand zurückzugeben, ehe das WSFC-Cluster annimmt, dass die Serverinstanz langsam ist oder nicht reagiert. HEALTH_CHECK_TIMEOUT wird auf Gruppenebene festgelegt, ist aber nur für Verfügbarkeitsreplikate relevant, die für den Verfügbarkeitsmodus für synchrone Commits mit automatischem Failover (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT) konfiguriert sind. Weiterhin kann ein Integritätsprüfungstimeout nur ein automatisches Failover auslösen, wenn das primäre und das sekundäre Replikat für den automatischen Failovermodus konfiguriert sind (FAILOVER_MODE = AUTOMATIC) und das sekundäre Replikat gerade mit dem primären Replikat synchronisiert wird.

Der standardmäßige HEALTH_CHECK_TIMEOUT-Wert beträgt 30.000 Millisekunden (30 Sekunden). Der Mindestwert beträgt 15000 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 = { ON | OFF }

Gibt die Antwort an, die akzeptiert wird, wenn eine Datenbank auf dem primären Replikat offline ist. Wenn diese Option auf ON festgelegt ist, löst jeder Status außer ONLINE für eine Datenbank in der Verfügbarkeitsgruppe ein automatisches Failover aus. Wenn diese Option auf OFF festgelegt ist, wird nur die Integrität der Instanz verwendet, um ein automatisches Failover auszulösen.

Weitere Informationen zu dieser Einstellung finden Sie unter Integritätserkennung auf Datenbankebene.

DTC_SUPPORT = { PER_DB | NONE }

Legt fest, 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 mit Datenbanken in der Verfügbarkeitsgruppe 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 Datenbankübergreifende Transaktionen und verteilte Transaktionen für Always On-Verfügbarkeitsgruppen und Datenbankspiegelung (SQL Server).

Hinweis

Unterstützung für die Änderung 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 Sie die Verfügbarkeitsgruppe mit DROP und CREATE löschen und erneut erstellen.

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 Commitmodus. 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 synchronisiertes Replikat hostet, nicht mehr reagiert, markiert der SQL Server, der das erste primäre Replikat hostet, dieses sekundäre Replikat als NOT SYNCHRONIZED und setzt den Vorgang fort. Wenn die nicht reagierende Datenbank wieder online geschaltet wird, befindet sie sich im Zustand „nicht synchronisiert“, und das Replikat wird als fehlerhaft markiert, bis die primäre Instanz das Replikat wieder synchronisieren 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 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT für eine verteilte Verfügbarkeitsgruppe festlegen. Diese Einstellung wird für CREATE AVAILABILITY GROUP nicht unterstützt. Sie können ALTER AVAILABILITY GROUP verwenden, um REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT festzulegen. Zum Beispiel:

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

ROLE

Der einzige gültige Parameter ist SECONDARY, und diese SET-Option ist nur in verteilten Verfügbarkeitsgruppen gültig. Es wird verwendet, um eine verteilte Verfügbarkeitsgruppe wie hier dokumentiert zu überschlagen: ALTER AVAILABILITY GROUP

ADD DATABASE database_name

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 über die Datenbanktypen, für die eine Verfügbarkeitsgruppe Unterstützung bietet, finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für Always On-Verfügbarkeitsgruppen (SQL Server). In der Spalte replica_id in der sys.databases-Katalogsicht können Sie überprüfen, welche lokalen Datenbanken bereits zu einer Verfügbarkeitsgruppe gehören.

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 und dann jede sekundäre Datenbank vorbereiten und der Verfügbarkeitsgruppe beitreten. Weitere Informationen finden Sie unter Starten der Datenverschiebung in einer sekundären Always On-Datenbank (SQL Server).

REMOVE DATABASE database_name

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 Verfügbarkeitsgruppe (SQL Server).

ADD REPLICA ON

Gibt eine bis acht SQL Server-Instanzen an, in denen sekundäre Replikate in einer Verfügbarkeitsgruppe gehostet werden sollen. Jedes Replikat wird von seiner 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 als Host für ein Replikat fungiert. 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, der für den Zugriff auf einen SQL Server-Failovercluster verwendet wird. Verwenden Sie diesen Namen, wenn die Serverinstanz als SQL Server-Failoverpartner beteiligt ist. Bei Ausführung von SELECT @@SERVERNAME in einer FCI-Serverinstanz wird die gesamte Zeichenfolge „FCI_network_name[\instance_name]“ zurückgegeben (dabei handelt es sich um den vollständigen Replikatnamen).

instance_name

Der Name einer Instanz eines SQL Server, der von system_name oder FCI_network_name gehostet wird und die AlwaysOn aktiviert ist. Bei einer Standardserverinstanz ist instance_name optional. Bei dem Instanznamen wird die Groß-/Kleinschreibung berücksichtigt. In einer eigenständigen Serverinstanz stimmt der Name dieses Werts mit dem Wert überein, der beim Ausführen von SELECT @@SERVERNAME zurü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 Always On-Verfügbarkeitsgruppen (SQL Server).

ENDPOINT_URL = 'TCP://systemadress: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 erforderlich und in der MODIFY REPLICA ON-Klausel optional. Weitere Informationen finden Sie unter Angeben der Endpunkt-URL beim Hinzufügen oder Ändern eines Verfügbarkeitsreplikats (SQL Server).

'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:

system-address

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

port

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

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

Gibt an, ob das primäre Replikat auf das sekundäre Replikat warten muss, um das Verstärken (Schreiben) der Protokolldatensätze auf einem Datenträger zu bestätigen, bevor das primäre Replikat die Transaktion auf einer bestimmten primären Datenbank ausführen 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 mit der Ausführung von Transaktionen wartet, bis sie auf diesem sekundären Replikat (Modus mit synchronem Commit) verstärkt wurden. Sie können SYNCHRONOUS_COMMIT für bis zu drei Replikate angeben, 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 ASYNCHRONOUS_COMMIT für bis zu fünf Verfügbarkeitsreplikate angeben, einschließlich des primären Replikats.

CONFIGURATION_ONLY

Gibt an, dass das primäre Replikat synchron Die Konfigurationsmetadaten der Verfügbarkeitsgruppe an die Masterdatenbank dieses Replikats angibt. Das Replikat enthält keine Benutzerdaten. Diese Option:

  • Kann auf einer beliebigen Edition von SQL Server, darunter Express Edition gehostet werden.

  • Erfordert, dass der Datenbankspiegelungs-Endpunkt des CONFIGURATION_ONLY-Replikats vom Typ WITNESS ist.

  • Kann nicht geändert werden.

  • Ist ungültig, wenn CLUSTER_TYPE = WSFC.

    Weitere Informationen finden Sie unter Configuration only replica (Configuration only-Replikat).

AVAILABILITY_MODE ist in der ADD REPLICA ON-Klausel erforderlich und in der MODIFY REPLICA ON-Klausel optional. Weitere Informationen finden Sie unter Verfügbarkeitsmodi (Always On-Verfügbarkeitsgruppen).

FAILOVER_MODE = { AUTOMATIC | MANUAL }

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

AUTOMATIC

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

Hinweis

  • Vor SQL Server 2016 waren 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 von einer FCI gehostet wird, nur für manuelles Failover konfiguriert werden kann.

MANUAL

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

FAILOVER_MODE ist in der ADD REPLICA ON-Klausel erforderlich und in der MODIFY REPLICA ON-Klausel optional. Zwei Typen manuellen Failovers sind vorhanden, manuelles Failover ohne Datenverlust und erzwungenes Failover (mit möglichem Datenverlust), die unter anderen Bedingungen unterstützt werden. Weitere Informationen finden Sie unter Failover und Failovermodi (Always On-Verfügbarkeitsgruppen).

SEEDING_MODE = { AUTOMATIC | MANUAL }

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

AUTOMATIC

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

Hinweis

Um das direkte Seeding zu ermöglichen, müssen Sie die Datenbankerstellung auf jedem sekundären Replikat zulassen, indem Sie den Befehl ALTER AVAILABILITY GROUP mit der Option GRANT CREATE ANY DATABASE aufrufen.

MANUAL

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 zum Ausführen von Sicherungen ausgewählt werden könnte. 1 gibt die niedrigste Priorität und 100 die höchste Priorität an. Wenn BACKUP_PRIORITY = 1, würde das Verfügbarkeitsreplikat nur zum Ausführungen von Sicherungen ausgewählt werden, wenn gerade keine höheren Prioritätsverfügbarkeitsreplikate verfügbar sind.

  • 0 gibt an, dass dieses Verfügbarkeitsreplikat nie zum Ausführen von Sicherungen ausgewählt wird. Dies ist zum Beispiel für ein Remoteverfügbarkeitsreplikat hilfreich, für das keine Failover bei Sicherungen auftreten sollen.

Weitere Informationen finden Sie unter Aktive sekundäre Replikate: Sicherung auf sekundären Replikaten (Always On-Verfügbarkeitsgruppen).

SECONDARY_ROLE ( ... )

Gibt rollenspezifische Einstellungen an, die wirksam werden, wenn dieses Verfügbarkeitsreplikat derzeit die sekundäre Rolle besitzt (d. a. 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 = { NO | READ_ONLY | ALL }

Gibt an, ob die Datenbanken eines bestimmten Verfügbarkeitsreplikats, das die sekundäre Rolle einnimmt (das heißt, als sekundäres Replikat dient), Verbindungen von Clients akzeptieren können, z. B.:

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.

READ_ONLY

Verbindungen mit den Datenbanken im sekundären Replikat sind nur zulässig, wenn die Eigenschaft für die Anwendungsabsicht auf ReadOnly festgelegt ist. Weitere Informationen zu dieser Eigenschaft finden Sie unter Using Connection String Keywords with SQL Server Native Client.

ALL

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

Weitere Informationen finden Sie unter Aktive sekundäre Replikate: Lesbare sekundäre Replikate (Always On-Verfügbarkeitsgruppen).

READ_ONLY_ROUTING_URL = 'TCP://systemadress:Port'

Gibt die URL an, die zum Weiterleiten von Verbindungsanforderungen für beabsichtigte Lesevorgänge zu diesem Verfügbarkeitsreplikat verwendet werden soll. Dies ist die URL, die die SQL Server-Datenbank-Engine überwacht. In der Regel überwacht die Standardinstanz der SQL Server-Datenbank-Engine auf TCP-Port 1433.

Für eine benannte Instanz können Sie die Portnummer durch das Abfragen der Spalten port und type_desc der dynamischen sys.dm_tcp_listener_states-Verwaltungssicht abrufen. 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

Für eine benannte Instanz von SQL Server sollte der Transact-SQL-Listener konfiguriert werden, um einen bestimmten Port zu verwenden. Weitere Informationen finden Sie unter Konfigurieren eines Servers zur Überwachung eines bestimmten TCP-Ports (SQL Server-Konfigurations-Manager).

PRIMARY_ROLE ( ... )

Gibt rollenspezifische Einstellungen an, die wirksam werden, wenn dieses Verfügbarkeitsreplikat derzeit die primäre Rolle besitzt (d. a. wenn 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 | ALL }

Gibt den Verbindungstyp an, den die Datenbanken eines bestimmten Verfügbarkeitsreplikats, das die primäre Rolle einnimmt (das heißt, als primäres Replikat dient), von Clients akzeptieren können, z. B.:

READ_WRITE

Verbindungen, bei denen die Verbindungseigenschaft für den Anwendungszweck auf ReadOnly festgelegt ist, werden nicht zugelassen. Wenn die Application Intent-Eigenschaft auf ReadWrite- festgelegt ist 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.

ALL

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:

  • Wird konfiguriert, um alle Verbindungen oder schreibgeschützte Verbindungen (siehe das obige ALLOW_CONNECTIONS-Argument der SECONDARY_ROLE-Option) zuzulassen.

  • Die schreibgeschützte Routing-URL wurde definiert (siehe das obige READ_ONLY_ROUTING_URL-Argument der SECONDARY_ROLE-Option).

Die READ_ONLY_ROUTING_LIST-Werte lauten wie folgt:

<server_instance>

Gibt die Adresse der Instanz von SQL Server an, die als Host für ein Verfügbarkeitsreplikat fungiert, das ein lesbares sekundäres Replikat ist, wenn es unter der sekundären Rolle ausgeführt wird.

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. Wenn dieser Wert zusammen mit MODIFY REPLICA ON verwendet wird, aktiviert er ggf. die vorhandene Liste.

READ_WRITE_ROUTING_URL = 'TCP://systemadress:Port'

Gilt für: SQL Server (ab SQL Server 2019 (15.x))

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.

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 Zeitraum standardmäßig 10 Sekunden. Der Wert muss mindestens 5 Sekunden betragen.

Wichtig

Es wird empfohlen, einen Timeoutzeitraum von 10 Sekunden oder mehr zu wählen.

Weitere Informationen zum Sitzungstimeout finden Sie unter Übersicht über Always On-Verfügbarkeitsgruppen (SQL Server).

MODIFY REPLICA ON

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

REMOVE REPLICA ON

Entfernt das angegebene sekundäre Replikat aus der Verfügbarkeitsgruppe. Das aktuelle primäre Replikat kann nicht aus einer Verfügbarkeitsgruppe entfernt werden. Das Replikat empfängt keine Daten mehr, wenn es entfernt wird. Seine sekundären Datenbanken werden aus der Verfügbarkeitsgruppe entfernt und nehmen den Status RESTORING an.

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.

JOIN

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 mit der Verfügbarkeitsgruppe verknüpft wurde.

Weitere Informationen finden Sie unter Verknüpfen eines sekundären Replikats mit einer Verfügbarkeitsgruppe (SQL Server).

FAILOVER

Initiiert ein manuelles Failover der Verfügbarkeitsgruppe ohne Datenverlust an das sekundäre Replikat, mit dem Sie verbunden sind. Das Replikat, von dem das primäre Replikat gehostet wird, wird das Failoverziel. Das Failoverziel übernimmt die primäre Rolle und stellt seine Kopie jeder Datenbank wieder her und schaltet sie als neue primäre Datenbanken online. 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. Zwischen diesen Rollen kann möglicherweise durch eine Reihe von Fehlern hin- und hergeschaltet werden.

Wird nur auf einem sekundären Replikat mit synchronem Commit unterstützt, das derzeit mit dem primären Replikat synchronisiert ist. Hinweis: Damit das sekundäre Replikat synchronisiert werden kann, muss das primäre Replikat ebenfalls im Modus mit synchronem Commit ausgeführt werden.

Hinweis

Ein Failoverbefehl gibt einen Wert zurück, sobald das Failoverziel den Befehl akzeptiert hat. Die Datenbankwiederherstellung tritt jedoch asynchron auf, nachdem die Verfügbarkeitsgruppe aufgehört hat, ein Failover auszuführen.

Informationen zu Einschränkungen, Voraussetzungen und Empfehlungen in Bezug auf das Ausführen eines geplanten manuellen Failovers finden Sie unter Ausführen eines geplanten manuellen Failovers einer Verfügbarkeitsgruppe (SQL Server).

FORCE_FAILOVER_ALLOW_DATA_LOSS

Achtung

Das Erzwingen eines Failovers kann zu Datenverlusten führen und ist daher ausschließlich als Notfallwiederherstellungsmethode vorgesehen. Daher wird dringend empfohlen, das Failover nur dann zu erzwingen, wenn das primäre Replikat nicht mehr ausgeführt wird. Sie sind bereit, Datenverlust zu riskieren, und Sie müssen den Dienst sofort in der Verfügbarkeitsgruppe wiederherstellen.

Wird nur auf einem Replikat unterstützt, dessen Rolle sich im Status SECONDARY oder RESOLVING befindet. Das Replikat, auf dem Sie einen Failoverzielbefehl eingeben, wird als Failoverziel bezeichnet.

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 schaltet sie als neue primäre Datenbanken online. Auf jeglichen verbleibenden sekundären Replikaten wird jede sekundäre Datenbank angehalten, bis sie manuell fortgesetzt wird. Wenn das frühere primäre Replikat verfügbar wird, wechselt es zur sekundären Rolle, und seine Datenbanken werden angehaltene sekundäre Datenbanken.

Hinweis

Ein Failoverbefehl gibt einen Wert zurück, sobald das Failoverziel den Befehl akzeptiert hat. Die Datenbankwiederherstellung tritt jedoch asynchron auf, nachdem die Verfügbarkeitsgruppe aufgehört hat, ein Failover auszuführen.

Informationen zu den Einschränkungen, Voraussetzungen und Empfehlungen zum Erzwingen eines Failovers sowie den Auswirkungen eines erzwungenen Failovers auf die zuvor primären Datenbanken in der Verfügbarkeitsgruppe finden Sie unter Ausführen eines erzwungenen manuellen Failovers einer 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

Wir empfehlen Ihnen dringend, vor dem Erstellen Ihres ersten Listeners den Artikel Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server) zu lesen.

Nachdem Sie einen Listener für eine Verfügbarkeitsgruppe erstellt haben, empfehlen wir dringend, folgende Schritte auszuführen:

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

Wir empfehlen, dass Sie eine sinnvolle Zeichenfolge angeben. 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 im 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.

JOIN AVAILABILITY GROUP ON

Tritt einer verteilten Verfügbarkeitsgruppe bei. Wenn Sie eine verteilte Verfügbarkeitsgruppe erstellen, ist die Verfügbarkeitsgruppe auf dem Cluster, in dem sie erstellt wird, 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://systemadress: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:

system-address

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

port

Eine Portnummer, die dem Spiegelungsendpunkt der Verfügbarkeitsgruppe zugeordnet ist. Beachten Sie, dass dies nicht der Port des Listeners ist.

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

Gibt an, ob das primäre Replikat auf die sekundäre Verfügbarkeitsgruppe warten muss, um das Verstärken (Schreiben) der Protokolldatensätze auf einem Datenträger zu bestätigen, bevor das primäre Replikat die Transaktion auf einer bestimmten primären Datenbank ausführen kann.

SYNCHRONOUS_COMMIT

Gibt an, dass das primäre Replikat mit der Ausführung von Transaktionen wartet, bis sie auf dieser sekundären Verfügbarkeitsgruppe verstärkt wurden. Sie können SYNCHRONOUS_COMMIT für bis zu zwei Verfügbarkeitsgruppen angeben, 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 ASYNCHRONOUS_COMMIT für bis zu zwei Verfügbarkeitsgruppen angeben, einschließlich der primären Verfügbarkeitsgruppe.

Die AVAILABILITY_MODE-Klausel ist erforderlich.

FAILOVER_MODE = { MANUAL }

Gibt den Failovermodus der verteilten Verfügbarkeitsgruppe an.

MANUAL

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 = { AUTOMATIC | MANUAL }

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

AUTOMATIC

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

MANUAL

Gibt das manuelle Seeding an. Bei dieser Methode müssen Sie eine Sicherungskopie der Datenbank auf dem primären Replikat erstellen und diese manuell auf dem Replikat/den Replikaten der sekundären Verfügbarkeitsgruppe wiederherstellen.

MODIFY AVAILABILITY GROUP ON

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

Wichtig

Dieser Befehl muss in den Instanzen der primären und der sekundären Verfügbarkeitsgruppe wiederholt werden.

GRANT CREATE ANY DATABASE

Erlaubt der Verfügbarkeitsgruppe die Erstellung von Datenbanken für das primäre Replikat, welches das direkte Seeding unterstützt (SEEDING_MODE = AUTOMATIC). Dieser Parameter muss nach dem Beitritt des sekundären Replikats zur Verfügbarkeitsgruppe auf allen sekundären Replikaten ausgeführt werden, die das direkte Seeding unterstützen. Erfordert die CREATE ANY DATABASE-Berechtigung.

DENY CREATE ANY DATABASE

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:

WITH DHCP [ ON { ('four_part_ipv4_address','four_part_ipv4_mask') } ]

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

Wichtig

Es wird nicht empfohlen, DHCP in der Produktionsumgebung zu verwenden. Wenn eine Downzeit vorhanden ist und die DHCP-IP-Lease abläuft, ist zusätzliche Zeit erforderlich, um die neue DHCP-Netzwerk-IP-Adresse zu registrieren, die dem Listener-DNS-Namen 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 ]

Gibt an, dass, der Listener der Verfügbarkeitsgruppe statt DHCPr eine oder mehrere statische IP-Adressen verwendet. 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 zu erhalten, das ein Verfügbarkeitsreplikat für die neue Verfügbarkeitsgruppe hostet.

Zum Beispiel:

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

ipv4_address

Gibt eine vierteilige IPv4-Adresse für einen Verfügbarkeitsgruppenlistener an. Beispiel: 10.120.19.155.

ipv4_mask

Gibt eine vierteilige IPv4-Maske für einen Verfügbarkeitsgruppenlistener an. Beispiel: 255.255.254.0.

ipv6_address

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

PORT = listener_port

Gibt die Portnummer (listener_port) an, die von einem Verfügbarkeitsgruppenlistener verwendet wird, der anhand einer WITH IP-Klausel angegeben wird. PORT ist optional.

Die Standardportnummer 1433 wird unterstützt. Wenn Sie jedoch Sicherheitsbedenken hegen, empfehlen wir die Verwendung einer anderen Portnummer.

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') | ('dns_nameipv6_address__')_}

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

PORT = listener_port

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

LISTENER neu starten 'dns_name'

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

REMOVE LISTENER 'dns_name'

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.

Nachdem eine Verfügbarkeitsgruppe offline ist, werden ihre Datenbanken für Clients nicht mehr verfügbar, und Sie können die Verfügbarkeitsgruppe nicht wieder online schalten. Verwenden Sie die OFFLINE-Option daher nur während einer clusterübergreifenden Migration von Always On-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 bei Verfügbarkeitsreplikaten sowie zu deren Hostserverinstanzen und -computern finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für Always On-Verfügbarkeitsgruppen (SQL Server).

Informationen zu Einschränkungen bei den AVAILABILITY GROUP-Transact-SQL-Anweisungen finden Sie unter Übersicht über Transact-SQL-Anweisungen für Always On-Verfügbarkeitsgruppen (SQL Server).

Sicherheit

Berechtigungen

Erfordert die ALTER AVAILABILITY GROUP-Berechtigung für die Verfügbarkeitsgruppe, die CONTROL AVAILABILITY GROUP-Berechtigung, die ALTER ANY AVAILABILITY GROUP-Berechtigung oder die CONTROL SERVER-Berechtigung. Erfordert außerdem die ALTER ANY DATABASE-Berechtigung.

Beispiele

A. 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 eines 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

Weitere Informationen

CREATE AVAILABILITY GROUP (Transact-SQL)
ALTER DATABASE SET HADR (Transact-SQL)
DROP AVAILABILITY GROUP (Transact-SQL)
sys.availability_replicas (Transact-SQL)
sys.availability_groups (Transact-SQL)
Problembehandlung für die AlwaysOn-Verfügbarkeitsgruppenkonfiguration (SQL Server)
Übersicht über Always On-Verfügbarkeitsgruppen (SQL Server)
Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server)