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.
# Arbeiten mit Read Replicas für Microsoft SQL Server in Amazon RDS
Sie verwenden Lesereplikate üblicherweise, um die Replikation zwischen Amazon-RDS-DB-Instances zu konfigurieren. Allgemeine Informationen zu Lesereplikaten finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md).
In diesem Abschnitt finden Sie spezifische Informationen zum Arbeiten mit Lesereplikaten unter Amazon RDS für SQL Server.
+ [Synchronisieren von Datenbankbenutzern und -objekten mit einem Lesereplikat von SQL Server](SQLServer.ReadReplicas.ObjectSynchronization.md)
+ [Fehlerbehebung für ein Problem mit einem SQL Server-Read Replica](SQLServer.ReadReplicas.Troubleshooting.md)
## Konfigurieren von Read Replicas für SQL Server
Bevor eine DB-Instance als Quell-Instance für die Replikation eingesetzt werden kann, müssen Sie automatische Sicherungen auf der Quell-DB-Instance aktivieren. Hierzu legen Sie für den Aufbewahrungszeitraum für Sicherungen einen anderen Wert als 0 fest. Durch das Festlegen dieses Bereitstellungstyps wird außerdem erzwungen, dass automatische Sicherungen aktiviert sind.
Das Erstellen eines SQL Server-Lesereplikats erfordert keinen Wartungsausfall für die primäre DB-Instance. Amazon RDS legt die erforderlichen Parameter und Berechtigungen für die Quelldatenbank-Instance und das Lesereplikat ohne Serviceunterbrechung fest. Ein Snapshot von der Quell-DB-Instance wird gemacht und dieser Snapshot wird zum Lesereplikat. Es findet kein Nutzungsausfall statt, wenn Sie ein Lesereplikat löschen.
Sie können bis zu 15 Lesereplikate aus einer Quell-DB-Instance erstellen. Damit die Replikation effektiv durchgeführt werden kann, empfehlen wir Ihnen, jedes Lesereplikat mit derselben Menge an Rechen- und Speicherressourcen wie die Quell-DB-Instance zu konfigurieren. Wenn Sie die Quell-DB-Instance skalieren, skalieren Sie auch die Lesereplikate.
Die SQL-Server-DB-Engine-Version der Quell-DB-Instance und alle Lese-Replikate müssen identisch sein. Amazon RDS aktualisiert die primäre Instance unmittelbar nach dem Upgrade der Lesereplikate, unabhängig vom Wartungsfenster. Weitere Informationen zum Aktualisieren der DB-Engine-Version finden Sie unter [Upgrades der DB-Engine von Microsoft SQL Server](USER_UpgradeDBInstance.SQLServer.md).
Damit ein Lesereplikat Änderungen von der Quelle empfängt und anwendet, sollte es über ausreichende Rechen- und Speicherressourcen verfügen. Wenn ein Lesereplikat die Kapazität von Rechen-, Netzwerk- und Speicherressourcen erreicht hat, stellt das Lesereplikat den Empfang und die Anwendung von Änderungen aus seiner Quelle ein. Sie können die Speicher- und CPU-Ressourcen eines Lesereplikats unabhängig von seiner Quelle und anderen Lesereplikaten ändern.
Informationen zum Erstellen eines Lesereplikats finden Sie unter [Erstellen eines Lesereplikats](USER_ReadRepl.Create.md).
## Read-Replica-Einschränkungen mit SQL Server
Die folgenden Einschränkungen gelten für SQL Server-Lesereplikate in Amazon RDS:
+ Lesereplikate sind nur auf der SQL Server Enterprise Edition (EE)-Engine verfügbar.
+ Lesereplikat sind für SQL-Server-Version 2016–2022 verfügbar.
+ Sie können bis zu 15 Lesereplikate aus einer Quell-DB-Instance erstellen. Die Replikation kann verzögert werden, wenn Ihre Quell-DB-Instance über mehr als 5 Lesereplikate verfügt.
+ Lesereplikate sind nur für DB-Instances verfügbar, die auf DB-Instance-Klassen mit vier oder mehr vCPUs ausgeführt werden.
+ Ein Lesereplikat unterstützt je nach Instance-Klassentyp und Verfügbarkeitsmodus bis zu 100 Datenbanken. Sie müssen Datenbanken auf der Quell-DB-Instance erstellen, um sie automatisch auf die Lesereplikate zu replizieren. Sie können keine einzelnen Datenbanken für die Replikation auswählen. Weitere Informationen finden Sie unter [Einschränkungen für Microsoft SQL Server-DB-Instances](CHAP_SQLServer.md#SQLServer.Concepts.General.FeatureSupport.Limits).
+ Sie können eine Datenbank nicht aus einem Lesereplikat entfernen. Um eine Datenbank zu entfernen, entfernen Sie sie mit der gespeicherten Prozedur `rds_drop_database` aus der Quell-DB-Instance. Weitere Informationen finden Sie unter [Verwerfen einer Datenbank in einer DB-Instance in Amazon RDS für Microsoft SQL Server](Appendix.SQLServer.CommonDBATasks.DropMirrorDB.md).
+ Wenn die Quell-DB-Instance Transparent Data Encryption (TDE) zur Verschlüsselung von Daten verwendet, konfiguriert das Lesereplikat TDE ebenfalls automatisch.
Wenn die Quell-DB-Instance einen KMS-Schlüssel zur Verschlüsselung von Daten verwendet, verwenden Lesereplikate in derselben Region denselben KMS-Schlüssel. Bei regionsübergreifenden Lesereplikaten müssen Sie beim Erstellen des Lesereplikats einen KMS-Schlüssel aus der Region des Lesereplikats angeben. Sie können den KMS-Schlüssel für ein Lesereplikat nicht ändern.
+ Lesereplikate haben dieselbe Zeitzone und Sortierung wie die Quell-DB-Instance, unabhängig von der Availability Zone, in der sie erstellt wurden.
+ Folgendes wird in Amazon RDS für SQL Server nicht unterstützt:
+ Backup-Aufbewahrung von Lesereplikaten
+ Zeitpunktbezogene Wiederherstellung aus Lesereplikaten
+ Manuelle Snapshots von Lesereplikaten
+ Multi-AZ-Lesereplikate
+ Erstellen von Lesereplikaten aus Lesereplikaten
+ Synchronisierung von Benutzeranmeldungen bei Lesereplikaten
+ Amazon RDS für SQL Server greift nicht ein, um eine hohe Replikationsverzögerung zwischen einer Quell-DB-Instance und ihren Lesereplikaten zu minimieren. Stellen Sie sicher, dass die Quell-DB-Instance und ihre Lesereplikate in Bezug auf Rechen- und Speicherkapazität die für ihre Betriebslast angemessene Größe aufweisen.
+ Sie können zwischen den Regionen AWS GovCloud (USA Ost) und AWS GovCloud (USA-West) replizieren, aber nicht in oder aus AWS GovCloud (US) Regions.
## Überlegungen zu Optionen für Replikate von RDS für SQL Server
Bevor Sie ein Replikat von RDS für SQL Server erstellen, sollten Sie die folgenden Anforderungen, Einschränkungen und Empfehlungen berücksichtigen:
+ Wenn sich Ihr SQL-Server-Replikat in derselben Region befindet wie die Quell-DB-Instance, stellen Sie sicher, dass es zur gleichen Optionsgruppe gehört wie die Quell-DB-Instance. Änderungen an der Quell-Optionsgruppe oder der Quell-Optionsgruppenmitgliedschaft werden von den Replikaten übernommen. Diese Änderungen werden unmittelbar, nachdem sie auf die Quell-DB-Instance angewandt wurden, auf die Replikate angewandt, ungeachtet des Wartungsfensters des Replikats.
Weitere Informationen über Optionsgruppen finden Sie unter [Arbeiten mit Optionsgruppen](USER_WorkingWithOptionGroups.md).
+ Wenn Sie ein regionsübergreifendes SQL-Server-Replikat erstellen, erstellt Amazon RDS dafür eine dedizierte Optionsgruppe.
Ein regionsübergreifendes SQL-Server-Replikat kann nicht aus seiner dedizierten Optionsgruppe entfernt werden. Die dedizierte Optionsgruppe eines regionsübergreifenden SQL-Server-Replikats kann nicht von anderen DB-Instances verwendet werden.
Bei den folgenden Optionen handelt es sich um replizierte Optionen. Wenn Sie einem regionsübergreifenden SQL-Server-Replikat replizierte Optionen hinzufügen möchten, fügen Sie es der Optionsgruppe der Quell-DB-Instance hinzu. Die Option wird auch auf allen Replikaten der Quell-DB-Instance installiert.
+ `TDE`
Bei den folgenden Optionen handelt es sich nicht um replizierte Optionen. Sie können nicht replizierte Optionen einer dedizierten Optionsgruppe hinzufügen oder daraus entfernen.
+ `MSDTC`
+ `SQLSERVER_AUDIT`
+ Wenn Sie die `SQLSERVER_AUDIT`-Option für ein regionsübergreifendes Replikat aktivieren möchten, fügen Sie die `SQLSERVER_AUDIT`-Option der dedizierten Optionsgruppe für das regionsübergreifende Lesereplikat und die Optionsgruppe der Quell-Instance hinzu. Indem Sie die `SQLSERVER_AUDIT`-Option für die Quell-Instance des regionsübergreifenden Lesereplikats von SQL Server hinzufügen, können Sie für jedes der regionsübergreifenden Lesereplikate der Quell-Instance ein Prüfobjekt auf Serverebene und Prüfspezifikationen auf Serverebene erstellen. Wenn Sie den regionsübergreifenden Lesereplikaten Zugriffberechtigungen für das Hochladen der abgeschlossenen Prüfprotokolle in einen Amazon-S3-Bucket gewähren möchten, fügen Sie der dedizierten Optionsgruppe die `SQLSERVER_AUDIT`-Option hinzu und konfigurieren Sie die Optionseinstellungen. Der als Ziel für die Überwachungsdateien verwendete Amazon-S3-Bucket muss sich in derselben Region befinden wie das regionsübergreifende Lesereplikat. Sie können die Optionseinstellung der `SQLSERVER_AUDIT`-Option für jedes regionsübergreifende Lesereplikat unabhängig ändern, sodass jedes Replikat in seiner jeweiligen Region auf einen Amazon-S3-Bucket zugreifen kann.
Die folgenden Optionen werden für Lesereplikate nicht unterstützt.
+ `SSRS`
+ `SSAS`
+ `SSIS`
Die folgenden Optionen werden für regionsübergreifende Lesereplikate teilweise unterstützt.
+ `SQLSERVER_BACKUP_RESTORE`
+ Die Quell-DB-Instance eines regionsübergreifenden SQL-Server-Replikats kann über die `SQLSERVER_BACKUP_RESTORE`-Option verfügen, Sie können jedoch erst systemeigene Wiederherstellungen für die Quell-DB-Instance durchführen, wenn Sie alle ihre regionsübergreifenden Replikate gelöscht haben. Alle vorhandenen systemeigenen Wiederherstellungsaufgaben werden bei der Erstellung eines regionsübergreifenden Replikats abgebrochen. Sie können die `SQLSERVER_BACKUP_RESTORE`-Option nicht einer dedizierten Optionsgruppe hinzufügen.
Weitere Informationen zu systemeigenen Backups und Wiederherstellungen finden Sie unter [Importieren und Exportieren von SQL-Server-Datenbanken mithilfe nativer Sicherung und Wiederherstellung](SQLServer.Procedural.Importing.md).
Wenn Sie ein regionsübergreifendes SQL-Server-Lesereplikat hochstufen, verhält sich das hochgestufte Lesereplikat genau so wie andere DB-Instances von SQL Server, einschließlich der Verwaltung seiner Optionen. Weitere Informationen über Optionsgruppen finden Sie unter [Arbeiten mit Optionsgruppen](USER_WorkingWithOptionGroups.md).
# Synchronisieren von Datenbankbenutzern und -objekten mit einem Lesereplikat von SQL Server
Es wird erwartet, dass alle Anmeldungen, benutzerdefinierten Serverrollen, SQL-Agent-Jobs oder andere Objekte auf Serverebene, die zum Zeitpunkt der Erstellung eines Lesereplikats in der primären DB-Instance existieren, im neu erstellten Lesereplikat vorhanden sind. Objekte auf Serverebene, die nach der Erstellung des Lesereplikats in der primären DB-Instance erstellt wurden, werden jedoch nicht automatisch repliziert. Sie müssen sie manuell im Lesereplikat erstellen.
Die Datenbankbenutzer werden automatisch von der primären DB-Instance in das Lesereplikat repliziert. Da sich die Lesereplikat-Datenbank im schreibgeschützten Modus befindet, kann die Sicherheits-ID (SID) des Datenbankbenutzers in der Datenbank nicht aktualisiert werden. Daher muss beim Erstellen von SQL-Anmeldungen im Lesereplikat unbedingt sichergestellt werden, dass die SID dieser Anmeldung mit der SID der entsprechenden SQL-Anmeldung in der primären DB-Instance übereinstimmt. Wenn Sie die SIDs SQL-Logins nicht synchronisieren, können sie nicht auf die Datenbank in der Read Replica zugreifen. Bei authentifizierten Windows Active Directory (AD)-Anmeldungen tritt dieses Problem nicht auf, da der SQL Server die SID von Active Directory bezieht.
**So synchronisieren Sie eine SQL-Anmeldung der primären DB-Instance mit dem Lesereplikat**
1. Stellen Sie eine Verbindung mit der primären DB-Instance her.
1. Erstellen Sie in der primären DB-Instance eine neue SQL-Anmeldung.
```
USE [master]
GO
CREATE LOGIN TestLogin1
WITH PASSWORD = 'REPLACE WITH PASSWORD';
```
**Anmerkung**
Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.
1. Erstellen Sie einen neuen Datenbankbenutzer für die SQL-Anmeldung in der Datenbank.
```
USE [REPLACE WITH YOUR DB NAME]
GO
CREATE USER TestLogin1 FOR LOGIN TestLogin1;
GO
```
1. Überprüfen Sie die SID der neu erstellten SQL-Anmeldung in der primären DB-Instance.
```
SELECT name, sid FROM sys.server_principals WHERE name = 'TestLogin1';
```
1. Stellen Sie eine Verbindung mit dem Lesereplikat her. Erstellen Sie die neue SQL-Anmeldung.
```
CREATE LOGIN TestLogin1 WITH PASSWORD = 'REPLACE WITH PASSWORD', SID=REPLACE WITH sid FROM STEP #4;
```
**Wenn Sie Zugriff auf die Lesereplikat-Datenbank haben, können Sie den verwaisten Benutzer alternativ wie folgt korrigieren:**
1. Stellen Sie eine Verbindung mit dem Lesereplikat her.
1. Identifizieren Sie die verwaisten Benutzer in der Datenbank.
```
USE [REPLACE WITH YOUR DB NAME]
GO
EXEC sp_change_users_login 'Report';
GO
```
1. Erstellen Sie eine neue SQL-Anmeldung für den verwaisten Datenbankbenutzer.
```
CREATE LOGIN TestLogin1 WITH PASSWORD = 'REPLACE WITH PASSWORD', SID=REPLACE WITH sid FROM STEP #2;
```
Beispiel:
```
CREATE LOGIN TestLogin1 WITH PASSWORD = 'TestPa$$word#1', SID=0x1A2B3C4D5E6F7G8H9I0J1K2L3M4N5O6P;
```
**Anmerkung**
Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.
# Fehlerbehebung für ein Problem mit einem SQL Server-Read Replica
Sie können die Replikationsverzögerung in Amazon CloudWatch überwachen, indem Sie die Amazon-RDS-Metrik `ReplicaLag` anzeigen. Weitere Informationen zur zeitlichen Verzögerung bei der Replikation finden Sie unter [Überwachen der Lesereplikation](USER_ReadRepl.Monitoring.md).
Wenn Replikationsverzögerung zu groß ist, können Sie die folgende Abfrage verwenden, um Informationen über die Verzögerung abzurufen.
```
SELECT AR.replica_server_name
, DB_NAME (ARS.database_id) 'database_name'
, AR.availability_mode_desc
, ARS.synchronization_health_desc
, ARS.last_hardened_lsn
, ARS.last_redone_lsn
, ARS.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states ARS
INNER JOIN sys.availability_replicas AR ON ARS.replica_id = AR.replica_id
--WHERE DB_NAME(ARS.database_id) = 'database_name'
ORDER BY AR.replica_server_name;
```