Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Multi-AZ-Bereitstellungen für Amazon RDS für Microsoft SQL Server
<a name="USER_SQLServerMultiAZ"></a>

Multi-AZ-Bereitstellungen bieten eine erhöhte Verfügbarkeit, eine längere Lebensdauer von Daten sowie eine höhere Fehlertoleranz für DB-Instances. Im Falle einer geplanten Datenbankwartung oder einer ungeplanten Serviceunterbrechung führt Amazon RDS automatisch einen Failover zur up-to-date sekundären DB-Instance durch. Mit dieser Funktion können Datenbankoperationen schnell ohne manuellen Eingriff fortgesetzt werden. Die Primär- und Standby-Instances verwenden denselben Endpunkt, dessen physische Netzwerkadresse als Teil des Failoverprozesses am sekundären Replica gespiegelt wird. Sie müssen Ihre Anwendung nicht neu konfigurieren, wenn ein Failover auftritt.

Amazon RDS unterstützt Multi-AZ-Bereitstellungen für Microsoft SQL Server mithilfe von SQL Server Database Mirroring (DBM), Always On Availability Groups (AGs) oder Replikation auf Blockebene. Amazon RDS überwacht und pflegt die Integrität Ihrer Multi-AZ-Bereitstellung. Bei Problemen repariert RDS fehlerhafte DB-Instances automatisch, stellt die Synchronisierung neu her und initiiert Failover. Failover treten nur auf, wenn Standby- und Primär-Instance vollständig synchron sind. Sie müssen nichts verwalten.

Wenn Sie SQL Server Multi-AZ einrichten, konfiguriert RDS automatisch alle Datenbanken auf der Instance für die Verwendung von DBM oder Replikation auf Blockebene. AGs Amazon RDS verwaltet die primäre, die Zeugen-DB-Instance und die sekundäre DB-Instance für Sie, wenn Sie DBM konfigurieren oder AGs. Bei der Replikation auf Blockebene verarbeitet RDS die primäre und die sekundäre DB-Instance. Da die Konfiguration automatisch erfolgt, wählt RDS die DBM-, AGs Always-On-Replikation oder die Replikation auf Blockebene basierend auf der Version von SQL Server, die Sie bereitstellen.

Amazon RDS unterstützt Multi-AZ mit Always On AGs für die folgenden SQL Server-Versionen und -Editionen:
+ SQL Server 2022:
  + Standard Edition
  + Enterprise Edition
+ SQL Server 2019:
  + Standard Edition 15.00.4073.23 und höher
  + Enterprise Edition
+ SQL Server 2017:
  + Standard Edition 14.00.3401.7 und höher
  + Enterprise Edition 14.00.3049.1 und höher
+ SQL Server 2016: Enterprise Edition 13.00.5216.0 und höher

Amazon RDS unterstützt Multi-AZ mit DBM für die folgenden SQL Server-Versionen und -Editionen mit Ausnahme der zuvor erwähnten Versionen:
+ SQL Server 2019: Standard Edition 15.00.4043.16
+ SQL Server 2017: Standard und Enterprise Editions
+ SQL Server 2016: Standard und Enterprise Editions 

Amazon RDS unterstützt Multi-AZ mit Replikation auf Blockebene für SQL Server 2022 Web Edition 16.00.4215.2 und höher.

**Anmerkung**  
Nur neue DB-Instances, die mit 16.00.4215.2 oder höher erstellt wurden, unterstützen Multi-AZ-Bereitstellungen mit Replikation auf Blockebene. Die folgenden Einschränkungen gelten für bestehende SQL Server 2022 Web Edition-Instances:  
Für bestehende Instanzen der Version 16.00.4215.2 müssen Sie einen Snapshot auf einer neuen Instanz mit derselben oder einer höheren Nebenversion wiederherstellen, um die Replikation auf Blockebene zu aktivieren.
SQL Server 2022-Webinstanzen mit einer älteren Nebenversion können auf die Nebenversion 16.00.4215.2 oder höher aktualisiert werden, um die Replikation auf Blockebene zu ermöglichen.

Sie können die folgende SQL-Abfrage verwenden, um festzustellen, ob es sich bei Ihrer SQL Server-DB-Instance um Single-AZ, Multi-AZ mit DBM oder Multi-AZ mit Always On handelt. AGs Diese Abfrage gilt nicht für Multi-AZ-Bereitstellungen auf SQL Server Web Edition.

```
SELECT CASE WHEN dm.mirroring_state_desc IS NOT NULL THEN 'Multi-AZ (Mirroring)'
    WHEN dhdrs.group_database_id IS NOT NULL THEN 'Multi-AZ (AlwaysOn)'
    ELSE 'Single-AZ'
    END 'high_availability'
FROM sys.databases sd
LEFT JOIN sys.database_mirroring dm ON sd.database_id = dm.database_id
LEFT JOIN sys.dm_hadr_database_replica_states dhdrs ON sd.database_id = dhdrs.database_id AND dhdrs.is_local = 1
WHERE DB_NAME(sd.database_id) = 'rdsadmin';
```

Die Ausgabe sieht in etwa folgendermaßen aus:

```
high_availability
Multi-AZ (AlwaysOn)
```

## Hinzufügen von Multi-AZ zu einer Microsoft SQL Server-DB-Instance
<a name="USER_SQLServerMultiAZ.Adding"></a>

Wenn Sie eine neue SQL Server-DB-Instance mit dem erstellen AWS-Managementkonsole, können Sie Multi-AZ mit Datenbankspiegelung (DBM), Always On oder Replikation auf AGs Blockebene hinzufügen. **Wählen Sie dazu in der Multi-AZ-Bereitstellung die **Option Ja (Mirroring/Always On/Block Level Replication)** aus.** Weitere Informationen finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md).

**Wenn Sie eine vorhandene SQL Server-DB-Instance mithilfe der Konsole ändern, können Sie Multi-AZ mit DBM oder Replikation auf Blockebene hinzufügen AGs, indem Sie bei der **Multi-AZ-Bereitstellung** auf der Seite DB-Instance ändern die Option **Ja (Mirroring/Always On/Block Level Replication)** auswählen.** Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).

**Anmerkung**  
Wenn auf Ihrer DB-Instance Database Mirroring (DBM) und nicht Always On Availability Groups (AGs) ausgeführt wird, müssen Sie möglicherweise die speicherinterne Optimierung deaktivieren, bevor Sie Multi-AZ hinzufügen. Deaktivieren Sie die In-Memory-Optimierung mit DBM, bevor Sie Multi-AZ hinzufügen, wenn Ihre DB-Instance SQL Server 2016 oder 2017 Enterprise Edition ausführt und die In-Memory-Optimierung aktiviert ist.   
Wenn auf Ihrer DB-Instance eine Replikation auf Blockebene für SQL Server Web Editions ausgeführt AGs wird, ist dieser Schritt nicht erforderlich. 

## Entfernen von Multi-AZ aus einer Microsoft SQL Server-DB-Instance
<a name="USER_SQLServerMultiAZ.Removing"></a>

Wenn Sie eine vorhandene SQL Server-DB-Instance mithilfe von ändern AWS-Managementkonsole, können Sie Multi-AZ mit DBM oder Replikation AGs auf Blockebene entfernen. Sie können dies tun, indem Sie auf der Seite DB-Instance **ändern** unter **Multi-AZ-Bereitstellung** die Option **Nein (Spiegelung/Always On/Replikation auf Blockebene)** auswählen. Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).

# Einschränkungen, Hinweise und Empfehlungen für Microsoft SQL Server Multi-AZ-Bereitstellung
<a name="USER_SQLServerMultiAZ.Recommendations"></a>

Im Folgenden sind einige Einschränkungen beim Arbeiten mit Multi-AZ-Bereitstellungen auf RDS für SQL Server-DB-Instances aufgeführt:
+ Regionsübergreifende Multi-AZ wird nicht unterstützt.
+ Das Beenden einer DB-Instance von RDS für SQL Server in einer Multi-AZ-Bereitstellung wird nicht unterstützt.
+ Sie können die sekundäre DB-Instance nicht so konfigurieren, dass sie die Datenbankleseaktivität akzeptiert.
+ Multi-AZ mit Always-On-Verfügbarkeitsgruppen (AGs) unterstützt die speicherinterne Optimierung.
+ Multi-AZ mit Always-On-Verfügbarkeitsgruppen (AGs) unterstützt keine Kerberos-Authentifizierung für den Verfügbarkeitsgruppen-Listener. Dies liegt daran, dass der Listener keinen Service-Prinzipalnamen (SPN, Service Principal Name) hat.
+ Multi-AZ mit Replikation auf Blockebene wird derzeit nur für SQL Server Web Edition-Instanzen unterstützt.
+ Sie können eine Datenbank in einer SQL Server-DB-Instance nicht umbenennen, die sich in einer SQL Server-Multi-AZ-Bereitstellung befindet. Falls Sie eine Datenbank in einer derartigen Instance umbenennen müssen, deaktivieren Sie erst Multi-AZ für die DB-Instance und benennen dann die Datenbank um. Aktivieren Sie letztendlich Multi-AZ wieder für die DB-Instance. 
+ Sie können nur Multi-AZ-DB-Instances wiederherstellen, die mithilfe des vollständigen Wiederherstellungsmodells gesichert wurden.
+ Multi-AZ-Bereitstellungen haben ein Limit von 10 000 SQL-Server-Agent-Aufträgen.

  Wenn Sie ein höheres Limit benötigen, fordern Sie eine Erhöhung an, indem Sie sich an uns wenden Support. Öffnen Sie die Seite des [AWS Support -Centers](https://console.aws.amazon.com/support/home#/), melden Sie sich an und wählen Sie **Fall erstellen** aus. Wählen Sie **Service Limit increase (Erhöhung des Servicelimits)**. Füllen Sie das Formular aus und senden Sie es ab.
+ Sie können keine Offline-Datenbank auf einer DB-Instance von SQL Server haben, die sich in einer Multi-AZ-Bereitstellung von SQL Server befindet.
+ RDS für SQL Server repliziert keine MSDB-Datenbankberechtigungen auf die sekundäre Instance. Wenn Sie diese Berechtigungen für die sekundäre Instance benötigen, müssen Sie sie manuell neu erstellen.
+ Volume-Metriken sind für den sekundären Host der Instance, die Replikation auf Blockebene verwendet, nicht verfügbar.

Hinweise zur Arbeit mit Multi-AZ-Bereitstellungen auf RDS für SQL Server-DB-Instances:
+ Amazon RDS macht den [Listener-Endpunkt der AGs Always-On-Verfügbarkeitsgruppe verfügbar](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover). Der Endpunkt ist in der Konsole sichtbar und wird vom `DescribeDBInstances`-API-Vorgang als Eintrag im Feld mit den Endpunkten zurückgegeben.
+ Amazon RDS unterstützt [Failover bei mehreren Subnetzen in Verfügbarkeitsgruppen](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover).
+ Zur Verwendung von SQL Server-Multi-AZ mit einer SQL Server-DB-Instance in einer Virtual Private Cloud (VPC) erstellen Sie zuerst eine DB-Subnetzgruppe, die Subnetze in mindestens zwei verschiedenen Availability Zones aufweist. Sie weisen anschließend die DB-Subnetzgruppe dem primären Replica der SQL Server-DB-Instance zu. 
+ Wenn eine DB-Instance in eine Multi-AZ-Bereitstellung geändert wird, hat sie während der Änderung den Status **Modifying (Wird geändert …)**. Amazon RDS erstellt den Standby und erstellt ein Backup der primären DB-Instance. Wenn der Prozess abgeschlossen ist, ändert sich der Status der primären DB-Instance zu **Available (Verfügbar)**.
+ Multi-AZ-Bereitstellungen verwalten alle Datenbanken auf demselben Knoten. Bei einem Failover einer Datenbank auf dem primären Host erfolgt ein Failover für alle Ihre SQL Server-Datenbanken als Einheit auf Ihren Standby-Host. Amazon RDS stellt einen neuen fehlerfreien Host bereit und ersetzt den fehlerhaften Host.
+ Multi-AZ mit DBM oder Replikation auf Blockebene unterstützt ein einzelnes Standby-Replikat. AGs
+ Benutzer, Logins und Berechtigungen werden auf der sekundären Instance automatisch für Sie repliziert. Sie müssen sie nicht erneut erstellen. Benutzerdefinierte Serverrollen werden in DB-Instances repliziert, die Always-On-Replikation AGs oder Replikation auf Blockebene für Multi-AZ-Bereitstellungen verwenden. 
+ In Multi-AZ-Bereitstellungen erstellt RDS for SQL Server SQL Server-Logins, um AlwaysOn oder Datenbankspiegelung zu ermöglichen. AGs RDS erstellt Anmeldungen mit dem folgenden Muster: `db_<dbiResourceId>_node1_login`, `db_<dbiResourceId>_node2_login` und `db_<dbiResourceId>_witness_login`.
+ RDS für SQL Server erstellt eine SQL-Server-Anmeldung, um den Zugriff auf Lesereplikate zu ermöglichen. RDS erstellt eine Anmeldung mit dem folgenden Muster: `db_<readreplica_dbiResourceId>_node_login`.
+ In Multi-AZ-Bereitstellungen werden Aufträge von SQL Server Agent vom primären Host auf den sekundären Host repliziert, wenn die Auftragsreplikationsfunktion aktiviert ist. Weitere Informationen finden Sie unter [Aktivieren der Auftragsreplikation von SQL Server Agent](Appendix.SQLServer.CommonDBATasks.Agent.md#SQLServerAgent.Replicate).
+ Aufgrund der synchronen Datenreplikation kann es zu erhöhten Latenzen im Vergleich zur standardmäßigen Bereitstellung einer DB-Instance in einer einzigen Availability Zone kommen.
+ Die Failover-Zeiten sind von der Zeit abhängig, die für den Wiederherstellungsprozess benötigt wird. Große Transaktionen erhöhen die Failover-Zeit.
+ In SQL Server-Multi-AZ-Bereitstellungen wird bei einem Neustart mit Failover nur die primäre DB-Instance neu gestartet. Nach dem Failover wird die primäre DB-Instance zur neuen sekundären DB-Instance. Die Parameter werden für Multi-AZ-Instances möglicherweise nicht aktualisiert. Für einen Neustart ohne Failover starten sowohl die primäre als auch die sekundäre DB-Instance neu. Die Parameter werden nach dem Neustart aktualisiert. Wenn die DB-Instance nicht reagiert, empfehlen wir einen Neustart ohne Failover.

Empfehlungen für die Arbeit mit Multi-AZ-Bereitstellungen auf RDS für Microsoft SQL Server-DB-Instances:
+ Für Datenbanken, die in der Produktion oder Vorproduktion verwendet werden, empfehlen wir die folgenden Optionen:
  + Multi-AZ-Bereitstellungen für Hochverfügbarkeit
  + Provisioned IOPS für schnelle, konsistente Leistung
  + „Speicheroptimiert“ statt „Universell“
+ Sie können die Availability Zone (AZ) für die sekundäre Instance nicht auswählen. Berücksichtigen Sie dies daher bei der Bereitstellung von Anwendungshosts. Für Ihre Datenbank konnte kein Failover auf eine andere AZ durchgeführt werden, und die Anwendungshosts befinden sich möglicherweise nicht in derselben AZ wie die Datenbank. Aus diesem Grund empfehlen wir, dass Sie Ihre Anwendungshosts auf alle Hosts AZs in der jeweiligen Region verteilen. AWS 
+ Um eine optimale Leistung zu erzielen, sollten Sie während eines großen Datenladevorgangs keine Datenbankspiegelung AGs, Always On oder Replikation auf Blockebene aktivieren. Falls der Datenladevorgang so schnell wie möglich ablaufen soll, schließen Sie den Datenladevorgang ab, bevor Sie Ihre DB-Instance in eine Multi-AZ-Bereitstellung konvertieren. 
+ Anwendungen, die SQL Server-Datenbanken aufrufen, sollten über eine Ausnahmebehandlung verfügen, die Verbindungsfehler erfasst. Das folgende Codebeispiel zeigt einen try/catch Block, der einen Kommunikationsfehler abfängt. In diesem Beispiel beendet die Anweisung `break` die `while`-Schleife, wenn die Verbindung erfolgreich ist, versucht es jedoch bis zu zehnmal neu, wenn eine Ausnahme ausgelöst wird.

  ```
  int RetryMaxAttempts = 10;
  int RetryIntervalPeriodInSeconds = 1;
  int iRetryCount = 0;
  while (iRetryCount < RetryMaxAttempts)
  {
     using (SqlConnection connection = new SqlConnection(DatabaseConnString))
     {
        using (SqlCommand command = connection.CreateCommand())
        {
           command.CommandText = "INSERT INTO SOME_TABLE VALUES ('SomeValue');";
           try
           {
              connection.Open();
              command.ExecuteNonQuery();
              break;
           }
           catch (Exception ex) 
           {
              Logger(ex.Message);
              iRetryCount++;
           }
           finally {
              connection.Close();
           }
        }
     }
     Thread.Sleep(RetryIntervalPeriodInSeconds * 1000);
  }
  ```
+ Verwenden Sie den `Set Partner Off` Befehl nicht, wenn Sie mit Multi-AZ-Instances arbeiten, die DBM oder verwenden. AGs Dieser Befehl wird auf Instances, die Replikation auf Blockebene verwenden, nicht unterstützt. Unterlassen Sie beispielsweise Folgendes: 

  ```
  --Don't do this
  ALTER DATABASE db1 SET PARTNER off
  ```
+ Setzen Sie den Wiederherstellungsmodus nicht auf `simple`. Unterlassen Sie beispielsweise Folgendes: 

  ```
  --Don't do this
  ALTER DATABASE db1 SET RECOVERY simple
  ```
+ Verwenden Sie den `DEFAULT_DATABASE` Parameter nicht, wenn Sie neue Logins auf Multi-AZ-DB-Instances erstellen, es sei denn, Sie verwenden die Replikation auf Blockebene für hohe Verfügbarkeit, da diese Einstellungen nicht auf den Standby-Spiegel angewendet werden können. Unterlassen Sie beispielsweise Folgendes: 

  ```
  --Don't do this
  CREATE LOGIN [test_dba] WITH PASSWORD=foo, DEFAULT_DATABASE=[db2]
  ```

  Unterlassen Sie zudem Folgendes:

  ```
  --Don't do this
  ALTER LOGIN [test_dba] WITH DEFAULT_DATABASE=[db3]
  ```

# Festlegen des Standorts der sekundären Instance
<a name="USER_SQLServerMultiAZ.Location"></a>

Sie können den Standort des sekundären Replica mithilfe der festlege AWS-Managementkonsole. Sie müssen den Standort der sekundären Instance kennen, wenn Sie Ihre primäre DB-Instance in einer VPC einrichten. 

![\[Sekundäre AZ\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/SQLSvr-MultiAZ.png)


Sie können die Availability Zone der Sekundärseite auch mithilfe des AWS CLI Befehls `describe-db-instances` oder der RDS-API-Operation anzeigen`DescribeDBInstances`. Die Ausgabe zeigt die sekundäre AZ-Instance, in der sich der Standby-Spiegel befindet. 

# Migrieren von der Datenbankspiegelung zu AlwaysOn-Verfügbarkeitsgruppen
<a name="USER_SQLServerMultiAZ.Migration"></a>

In Version 14.00.3049.1 der Microsoft SQL Server Enterprise Edition sind Always-On-Verfügbarkeitsgruppen standardmäßig aktiviert.

Prüfen Sie erst Ihre Version, ehe Sie von der Datenbankspiegelung zu Verfügbarkeitsgruppen migrieren. Wenn Sie eine DB-Instance mit einer Version vor Enterprise Edition 13.00.5216.0 verwenden, patchen Sie die Instance zu Version 13.00.5216.0 oder höher. Wenn Sie eine DB-Instance mit einer Version vor Enterprise Edition 14.00.3049.1 verwenden, patchen Sie die Instance zu Version 14.00.3049.1 oder höher.

Wenn Sie ein Upgrade für eine gespiegelte DB-Instance vornehmen möchten, damit diese Verfügbarkeitsgruppen verwendet, führen Sie zunächst das Upgrade aus, ändern Sie dann die Instance, sodass Multi-AZ entfernt wird und ändern Sie sie dann erneut, um Multi-AZ hinzuzufügen. Dadurch wird Ihre Instance umgewandelt und verwendet AlwaysOn-Verfügbarkeitsgruppen.