ALTER AVAILABILITY GROUP (Transact-SQL)

  • Artikel

Ändert eine vorhandene AlwaysOn-Verfügbarkeitsgruppe in SQL Server 2012. 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.

Themenlink (Symbol) 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
   | 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 

<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 },
       FAILOVER_MODE = { AUTOMATIC | MANUAL }
       [ , <add_replica_option> [ ,...n ] ]
    ) 

  <add_replica_option>::=
       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 } 
          } )
     | SESSION_TIMEOUT = seconds 


<modify_replica_spec>::=
  <server_instance> WITH
    (  
       ENDPOINT_URL = 'TCP://system-address:port' 
     | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT } 
     | FAILOVER_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 } 
          } )
     | SESSION_TIMEOUT = seconds 
    )  


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

  <network_subnet_option> ::=
     ‘four_part_ipv4_address’, ‘four_part_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| SECONDARY | NONE }
    Legt fest, wie ein Sicherungsauftrag das primäre Replikat auswerten soll, wenn ausgewählt wird, wo Sicherungen ausgeführt werden müssen. Sie können einen gegebenen Sicherungsauftrag erstellen, um die automatisierte Sicherungseinstellung zu berücksichtigen. Die Einstellung wird nicht von SQL Server erzwungen und weist deshalb keine Auswirkungen auf Ad-hoc-Sicherungen auf.

    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 hilfreich, wenn Sie Sicherungsfunktionen benötigen, z. B. das Erstellen differenzieller Sicherungen, die nicht unterstützt werden, wenn die Sicherung auf einem sekundären Replikat ausgeführt wird.

      Wichtiger HinweisWichtig

      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 es sich beim primären Replikat um das einzige Onlinereplikat handelt, darf keine Sicherung 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.

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

    Wichtiger HinweisWichtig

    Die Einstellung AUTOMATED_BACKUP_PREFERENCE wird nicht erzwungen. 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).
    HinweisHinweis

    Um die automatisierte Sicherungseinstellung einer vorhandenen Verfügbarkeitsgruppe anzuzeigen, wählen Sie die Spalte automated_backup_preference oder automated_backup_preference_desc der Katalogsicht sys.availability_groups aus. Darüber hinaus können Sie mit sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) das bevorzugte Sicherungsreplikat ermitteln. Diese Funktion gibt immer 1 für mindestens eines der Replikate zurück, selbst 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 auf Verfügbarkeitsreplikaten relevant, die für den Verfügbarkeitsmodus mit synchronen Commits (AVAILIBILITY_MODE = SYNCHRONOUS_COMMIT) konfiguriert sind. Weiterhin können Fehlerbedingungen ein automatisches Failover nur 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 Funktionsweise: AlwaysOn-Leasetimeout bei SQL Server.

    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 wurde ü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.
    HinweisHinweis

    Das Fehlen einer Reaktion auf Clientanforderungen durch eine SQL Server-Instanz 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 = milliseconds
    Gibt die Wartezeit (in Millisekunden) für die gespeicherte sp_server_diagnostics-Systemprozedur an, um Informationen über den Serverzustand zurückzugeben, ehe das WSFC-Cluster annimmt, dass die Serverinstanz langsam oder blockiert ist. 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 (AVAILIBILITY_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 minimale Wert beträgt 15.000 Millisekunden (15 Sekunden) und der maximale Wert 4.294.967.295 Millisekunden.

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

    Wichtiger HinweisWichtig

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

  • ADD DATABASE database_name
    Gibt eine Liste von Benutzerdatenbanken an, die Sie der Verfügbarkeitsgruppe hinzufügen möchten. Diese Datenbanken müssen sich auf 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 zu den von einer Verfügbarkeitsgruppe unterstützten Datenbanktypen finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server). In der replica_id-Spalte in der sys.databases-Katalogsicht können Sie herausfinden, welche lokalen Datenbanken bereits zu einer Verfügbarkeitsgruppe gehören.

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

    HinweisHinweis

    Nachdem Sie eine Verfügbarkeitsgruppe erstellt haben, müssen Sie wiederum eine Verbindung zu jeder Serverinstanz herstellen, die ein sekundäres Replikat hostet, und anschließend jede sekundäre Datenbank vorbereiten und mit der Verfügbarkeitsgruppe verknüpfen. Weitere Informationen finden Sie unter Starten der Datenverschiebung auf einer sekundären AlwaysOn-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 den 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 vier 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 die Instanz die Standardinstanz oder eine benannte Instanz ist und ob es eine eigenständige Instanz oder eine Failoverclusterinstanz (FCI) ist. 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 eine SQL Server-Zielinstanz befindet. Dieser Computer muss ein WSFC-Knoten sein.

    • FCI_network_name
      Ist der Netzwerkname, der verwendet wird, um auf einen SQL Server-Failovercluster zuzugreifen. Verwenden Sie diesen Namen, wenn die Serverinstanz als SQL Server-Failoverpartner beteiligt ist. Wenn SELECT @@SERVERNAME in einer FCI-Serverinstanz ausgeführt wird, wird die gesamte 'FCI_network_name[\instance_name]'-Zeichenfolge zurückgegeben (dabei handelt es sich um den vollständigen Replikatnamen).

    • instance_name
      Ist der Name einer SQL Server-Instanz, die von system_name oder FCI_network_name gehostet wird und für 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.

    • \
      Ist ein Trennzeichen, das nur bei der Angabe von instance_name verwendet wird, um den Namen von system_name oder FCI_network_name zu trennen.

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

  • ENDPOINT_URL = 'TCP://system-address:port'
    Gibt den URL-Pfad des Datenbankspiegelungsendpunkts in der SQL Server-Instanz an, die das Verfügbarkeitsreplikat, das Sie hinzufügen oder ändern, hostet.

    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://system-address: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
      Ist eine Zeichenfolge, beispielsweise ein Systemname, ein vollqualifizierter Domänenname oder eine IP-Adresse, ie das Zielcomputersystem eindeutig identifiziert.

    • port
      Ist eine Portnummer, die dem Spiegelungsendpunkt der Serverinstanz (für die ENDPOINT_URL-Option) oder der Portnummer, die von Database Engine (Datenbankmodul) der Serverinstanz (für die READ_ONLY_ROUTING_URL-Option) verwendet wird, zugeordnet ist.

  • AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
    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.

    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 (AlwaysOn-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 zwei Verfügbarkeitsreplikate angeben, einschließlich des primären Replikats.

      HinweisHinweis

      SQL Server-Failoverclusterinstanzen (FCIs) unterstützen kein automatisches Failover durch Verfügbarkeitsgruppen. Daher können die Verfügbarkeitsreplikate, die von einer FCI gehostet werden, nur für manuelles Failover konfiguriert werden.

    • 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 (AlwaysOn-Verfügbarkeitsgruppen).

  • 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 ist im Bereich von "0..100" und 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 (AlwaysOn-Verfügbarkeitsgruppen).

  • SECONDARY_ROLE ( … )
    Gibt rollenspezifische Einstellungen an, die wirksam werden, wenn dieses Verfügbarkeitsreplikat die sekundäre Rolle (d. h. wenn es gerade ein sekundäres Replikat ist) gerade besitzt. 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.:

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

      • READ_ONLY
        Verbindungen mit den Datenbanken im sekundären Replikat sind nur zulässig, wenn die Anwendungsabsicht-Eigenschaft auf ReadOnly festgelegt ist. Weitere Informationen zu dieser Eigenschaft finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit 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 (AlwaysOn-Verfügbarkeitsgruppen).

    • READ_ONLY_ROUTING_URL = 'TCP://system-address: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 das SQL Server-Datenbankmodul überwacht. In der Regel überwacht die Standardinstanz des SQL Server-Datenbankmoduls auf TCP-Port 1433.

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

      HinweisHinweis

      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 zum Lauschen an einem bestimmten TCP-Port (SQL Server-Konfigurations-Manager).

  • PRIMARY_ROLE ( … )
    Gibt rollenspezifische Einstellungen an, die wirksam werden, wenn dieses Verfügbarkeitsreplikat die primäre Rolle (d. h. wenn es gerade ein primäres Replikat ist) gerade besitzt. 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 die Anwendungsabsicht auf ReadOnly festgelegt ist, werden nicht zugelassen. Wenn die Eigenschaft für die Anwendungsabsicht auf ReadWrite festgelegt ist oder keine Verbindungseigenschaft für die Anwendungsabsicht festgelegt wurde, wird die Verbindung zugelassen. Weitere Informationen zur Verbindungseigenschaft für die Anwendungsabsicht finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit 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.

      • NONE
        Gibt an, dass, wenn dieses Verfügbarkeitsreplikat das primäre Replikat ist, schreibgeschütztes 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.

  • SESSION_TIMEOUT **=**seconds
    Gibt den Zeitraum für das Sitzungstimeout in Sekunden an. Wenn Sie die Option nicht angeben, beträgt der Timeoutzeitraum standardmäßig 10 Sekunden. Der Wert muss mindestens 5 Sekunden betragen.

    Wichtiger HinweisWichtig

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

    Weitere Informationen zum Sitzungstimeout finden Sie unter Übersicht über AlwaysOn-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.

    HinweisHinweis

    Wenn Sie ein Replikat im nicht verfügbaren oder fehlerhaften Status entfernen, erkennt es, dass es nicht mehr zur Verfügbarkeitsgruppe gehört, wenn es wieder online ist.

  • 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 der Verfügbarkeitsgruppe noch nicht hinzugefügt 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, auf dem Sie einen Failoverzielbefehl eingeben, wird als das Failoverziel bezeichnet. 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.

    HinweisHinweis

    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

    VorsichtshinweisVorsicht

    Das Erzwingen eines Failovers kann zu Datenverlusten führen und ist daher ausschließlich als Notfallwiederherstellungsmethode vorgesehen. Daher empfehlen wir dringend, dass Sie nur Failover erzwingen, wenn das primäre Replikat nicht mehr ausgeführt wird, da Sie bereitwillig Datenverluste riskieren. Außerdem müssen Sie den Dienst sofort für die 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 das 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.

    HinweisHinweis

    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.

    Wichtiger HinweisWichtig

    Vor dem Erstellen des ersten Listeners empfehlen wir dringend, dass Sie Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server) 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 ihn in Verbindungszeichenfolgen verwenden, wenn sie Clientverbindungen zu dieser Verfügbarkeitsgruppe anfordern.

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

    Bei dns_name handelt es sich um einen 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 AG1 wäre ein sinnvoller DNS-Hostname z. B. ag1-listener.

    Wichtiger HinweisWichtig

    NetBIOS erkennt nur die ersten 15 Zeichen im dns_name. Wenn Sie zwei WSFC-Cluster verwenden, die vom gleichen Active Directory gesteuert werden, und Sie versuchen, Verfügbarkeitsgruppenlistener in beiden Clustern mit Namen mit mehr als 15 Zeichen und einem identischen 15-Zeichen-Präfix zu erstellen, erhalten Sie eine Fehlermeldung mit dem Hinweis, dass die VNN-Ressource nicht online geschaltet werden konnte. Informationen zu Präfix-Benennungsregeln für DNS-Namen finden Sie unter Zuweisen von Domänennamen.

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

      Wichtiger HinweisWichtig

      DHCP wird in einer Produktionsumgebung nicht empfohlen. Wenn es zu einer Ausfallzeit kommt und das DHCP-IP-Leasing abläuft, ist eine Verlängerung erforderlich, um die neue DHCP-Netzwerk-IP-Adresse zu registrieren, die dem DNS-Namen des Listener zugeordnet ist, was sich auf die Clientkonnektivität auswirkt. DHCP ist eignet sich jedoch gut zum Einrichten der Entwicklungs- und Testumgebung, um grundlegende Funktionen von Verfügbarkeitsgruppen und die Integration mit Ihren Anwendungen zu überprüfen.

      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.

      Beispiel:

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

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

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

  • RESTART LISTENER ‘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 bei Datenbanken mit synchronem Commit.

    Nachdem eine Verfügbarkeitsgruppe offline geschaltet wurde, sind 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 Kreuzclustermigration 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).

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird[Nach oben]

Voraussetzungen und Einschränkungen

Informationen zu Voraussetzungen und Einschränkungen für Verfügbarkeitsreplikate und deren Hostserverinstanzen und Computer finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Informationen zu Einschränkungen in Bezug auf die AVAILABILITY GROUP-Transact-SQL-Anweisungen finden Sie unter Übersicht über Transact-SQL-Anweisungen für AlwaysOn-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.

Beispiele

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

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

ALTER AVAILABILITY GROUP AccountsAG JOIN;
GO

B.Erzwingen eines Failovers einer Verfügbarkeitsgruppe

Im folgenden Beispiel wird ein Failover der AccountsAG-Verfügbarkeitsgruppe zum sekundären Replikat erzwungen, mit dem Sie verbunden sind.

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
GO

Siehe auch

Verweis

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)

Konzepte

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

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server)