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.

# Verwenden einer Microsoft SQL Server-Datenbank als Quelle für AWS DMS
<a name="CHAP_Source.SQLServer"></a>

Migrieren Sie Daten aus einer oder mehreren Microsoft SQL Server-Datenbanken mit AWS DMS. Mit einer SQL Server-Datenbank als Quelle können Sie Daten in eine andere SQL Server-Datenbank oder in eine der anderen AWS DMS unterstützten Datenbanken migrieren. 

Informationen zu Versionen von SQL Server, die als Quelle AWS DMS unterstützt werden, finden Sie unter[Quellen für AWS DMS](CHAP_Introduction.Sources.md).

Die SQL Server-Quelldatenbank kann auf einem beliebigen Computer in Ihrem Netzwerk installiert sein. Ein SQL Server-Konto mit den entsprechenden Zugriffsberechtigungen für die Quelldatenbank für den Typ der ausgewählten Aufgabe ist für die Verwendung mit AWS DMS erforderlich. Weitere Informationen finden Sie unter [Berechtigungen für SQL Server-Aufgaben](#CHAP_Source.SQLServer.Permissions).

AWS DMS unterstützt die Migration von Daten aus benannten Instanzen von SQL Server. Beim Erstellen des Quellendpunkts können Sie folgende Notation für den Servernamen verwenden.

```
IPAddress\InstanceName
```

Im folgenden Beispiel wird ein korrekter Servername für den Quellendpunkt angegeben. Hier ist der erste Teil des Namens die IP-Adresse des Servers und der zweite Teil ist der Name der SQL Server-Instanz (in diesem Beispiel SQLTest).

```
10.0.0.25\SQLTest
```

Ermitteln Sie außerdem die Portnummer, die Ihre benannte Instanz von SQL Server überwacht, und verwenden Sie sie, um Ihren AWS DMS Quellendpunkt zu konfigurieren. 

**Anmerkung**  
Port 1433 ist der Standard für Microsoft SQL Server. Jedoch werden dynamische Ports, die sich bei jedem Start von SQL Server ändern, und spezifische statische Portnummern, die zum Herstellen einer Verbindung mit SQL Server über eine Firewall genutzt werden, ebenfalls häufig verwendet. Sie möchten also die tatsächliche Portnummer Ihrer benannten Instanz von SQL Server wissen, wenn Sie den AWS DMS Quellendpunkt erstellen.

Sie können SSL verwenden, um Verbindungen zwischen Ihrem SQL Server-Endpunkt und der Replikations-Instance zu verschlüsseln. Weitere Informationen zur Verwendung von SSL mit einem SQL Server-Endpunkt finden Sie unter [Verwenden von SSL mit AWS Database Migration Service](CHAP_Security.SSL.md).

Sie können CDC für die laufende Migration aus einer SQL Server-Datenbank verwenden. Hinweise zur Konfiguration Ihrer SQL Server-Quelldatenbank für CDC finden Sie unter. [Erfassung von Datenänderungen für die laufende Replikation von SQL Server](CHAP_Source.SQLServer.CDC.md)

Weitere Informationen zur Arbeit mit SQL Server-Quelldatenbanken und AWS DMS finden Sie im Folgenden.

**Topics**
+ [Einschränkungen bei der Verwendung von SQL Server als Quelle für AWS DMS](#CHAP_Source.SQLServer.Limitations)
+ [Berechtigungen für SQL Server-Aufgaben](#CHAP_Source.SQLServer.Permissions)
+ [Voraussetzungen für die Verwendung der laufenden Replikation (CDC) von einer SQL-Server-Quelle aus](#CHAP_Source.SQLServer.Prerequisites)
+ [Unterstützte Komprimierungsmethoden für SQL Server](#CHAP_Source.SQLServer.Compression)
+ [Arbeiten mit selbstverwalteten SQL Server-Verfügbarkeitsgruppen AlwaysOn](#CHAP_Source.SQLServer.AlwaysOn)
+ [Endpunkteinstellungen bei Verwendung von SQL Server als Quelle für AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib)
+ [Quelldatentypen für SQL Server](#CHAP_Source.SQLServer.DataTypes)
+ [Erfassung von Datenänderungen für die laufende Replikation von SQL Server](CHAP_Source.SQLServer.CDC.md)

## Einschränkungen bei der Verwendung von SQL Server als Quelle für AWS DMS
<a name="CHAP_Source.SQLServer.Limitations"></a>

Die folgenden Einschränkungen gelten, wenn Sie eine SQL Server-Datenbank als Quelle für AWS DMS verwenden:
+ Die Identitätseigenschaft für eine Spalte wird nicht zu einer Spalte in der Zieldatenbank migriert.
+ Der SQL Server-Endpunkt unterstützt die Verwendung von Tabellen mit spärlichen Spalten nicht.
+ Windows-Authentifizierung wird nicht unterstützt.
+ Änderungen an berechneten Feldern in einem SQL Server werden nicht repliziert.
+ Temporäre Tabellen werden nicht unterstützt.
+ SQL Server-Partition-Switching wird nicht unterstützt.
+ Bei Verwendung der Dienstprogramme WRITETEXT und UPDATETEXT werden AWS DMS keine Ereignisse erfasst, die auf die Quelldatenbank angewendet werden.
+ Das folgende Data Manipulation Language (DML)-Muster wird nicht unterstützt. 

  ```
  SELECT * INTO new_table FROM existing_table
  ```
+ Bei der Verwendung von SQL Server als Quelle wird die Verschlüsselung auf Spaltenebene nicht unterstützt.
+ AWS DMS unterstützt keine Audits auf Serverebene für SQL Server 2008 oder SQL Server 2008 R2 als Quellen. Dies liegt an einem bekannten Problem mit SQL Server 2008 und 2008 R2. Wenn Sie beispielsweise den folgenden Befehl ausführen, schlägt dies AWS DMS fehl.

  ```
  USE [master]
  GO 
  ALTER SERVER AUDIT [my_audit_test-20140710] WITH (STATE=on)
  GO
  ```
+ Die Spalten Geometrie und Geografie werden im vollständigen LOB-Modus nicht unterstützt, wenn SQL Server als Quelle verwendet wird. Verwenden Sie stattdessen den limitierten LOB-Modus oder legen Sie die Aufgabeneinstellung `InlineLobMaxSize` so fest, dass der Inline-LOB-Modus verwendet wird.
+ Wenn Sie eine Quelldatenbank in Microsoft SQL Server in einer Replikationsaufgabe verwenden, werden die Definitionen von SQL Server Replication Publisher nicht entfernt, falls Sie die Aufgabe entfernen. Ein Microsoft SQL Server-Systemadministrator muss diese Definitionen von Microsoft SQL Server löschen.
+ Die Migration von Daten aus schemagebundenen Daten und non-schema-bound Ansichten wird nur für Aufgaben mit Volllast unterstützt. 
+ Das Umbenennen von Tabellen mit sp\$1rename wird nicht unterstützt (z. B. `sp_rename 'Sales.SalesRegion', 'SalesReg;)`
+ Das Umbenennen von Spalten mit sp\$1rename wird nicht unterstützt (z. B. `sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';`)
+ AWS DMS unterstützt keine Änderungsverarbeitung zum Setzen und Löschen von Spaltenstandardwerten (unter Verwendung der `ALTER COLUMN SET DEFAULT` Klausel mit Anweisungen). `ALTER TABLE`
+ AWS DMS unterstützt keine Änderungsverarbeitung zum Festlegen der NULL-Zulässigkeit von Spalten (Verwendung der `ALTER COLUMN [SET|DROP] NOT NULL` Klausel mit `ALTER TABLE` Anweisungen).
+ Bei SQL Server 2012 und SQL Server 2014 kann die Verteilungsdatenbank bei Verwendung der DMS-Replikation mit Verfügbarkeitsgruppen nicht in einer Verfügbarkeitsgruppe platziert werden. SQL 2016 unterstützt das Platzieren der Verteilungsdatenbank in einer Verfügbarkeitsgruppe, mit Ausnahme von Verteilungsdatenbanken, die in Merge-, bidirektionalen oder peer-to-peer Replikationstopologien verwendet werden.
+ Unterstützt bei partitionierten Tabellen AWS DMS keine unterschiedlichen Datenkomprimierungseinstellungen für jede Partition.
+ Wenn Sie einen Wert in räumliche SQL-Server-Datentypen (GEOGRAPHY und GEOMETRY) einfügen, können Sie entweder die Eigenschaft Spatial Reference System Identifier (SRID) ignorieren oder eine andere Zahl angeben. AWS DMS Ersetzt beim Replizieren von Tabellen mit räumlichen Datentypen die SRID durch die Standard-SRID (0 für GEOMETRY und 4326 für GEOGRAPHY).
+ Wenn Ihre Datenbank nicht für MS-REPLIKATION oder MS-CDC konfiguriert ist, können Sie trotzdem Tabellen erfassen, die keinen Primärschlüssel haben, es werden jedoch nur DML-Ereignisse erfasst. INSERT/DELETE Die Ereignisse UPDATE und TRUNCATE TABLE werden ignoriert.
+ Columnstore-Indizes werden nicht unterstützt.
+ Speicheroptimierte Tabellen (unter Verwendung von In-Memory OLTP) werden nicht unterstützt.
+ Wenn Sie eine Tabelle mit einem Primärschlüssel replizieren, der aus mehreren Spalten besteht, wird das Aktualisieren der Primärschlüsselspalten während eines Volllastvorgangs nicht unterstützt.
+ Verzögerte Haltbarkeit wird nicht unterstützt.
+ Aufgrund der Art und Weise, wie RDS Backups durchführt, funktioniert die Endpunkteinstellung `readBackupOnly=true` (zusätzliches Verbindungsattribut) auf Quell-Instances in RDS für SQL Server nicht.
+ `EXCLUSIVE_AUTOMATIC_TRUNCATION` funktioniert auf Quell-Instances in Amazon RDS SQL Server nicht, da RDS-Benutzer keinen Zugriff zum Ausführen der gespeicherten SQL-Server-Prozedur `sp_repldone` haben.
+ AWS DMS erfasst keine Befehle, die gekürzt werden.
+ AWS DMS unterstützt keine Replikation von Datenbanken mit aktivierter beschleunigter Datenbankwiederherstellung (ADR).
+ AWS DMS unterstützt nicht die Erfassung von Anweisungen in Data Definition Language (DDL) und Data Manipulation Language (DML) innerhalb einer einzigen Transaktion.
+ AWS DMS unterstützt nicht die Replikation von Data-Tier-Anwendungspaketen (DACPAC).
+ UPDATE-Anweisungen, die Primärschlüssel oder eindeutige Indizes beinhalten und mehrere Datenzeilen aktualisieren, können zu Konflikten führen, wenn Sie Änderungen auf die Zieldatenbank anwenden. Dies kann beispielsweise der Fall sein, wenn die Zieldatenbank Aktualisierungen als INSERT- und DELETE-Anweisungen anstelle einer einzigen UPDATE-Anweisung anwendet. Im stapeloptimierten Anwendungsmodus wird die Tabelle möglicherweise ignoriert. Im transaktionalen Anwendungsmodus kann die UPDATE-Operation zu Verstößen gegen die Einschränkung führen. Laden Sie die entsprechende Tabelle neu, um dieses Problem zu vermeiden. Suchen Sie alternativ die problematischen Datensätze in der Kontrolltabelle „Ausnahmen anwenden“ (`dmslogs.awsdms_apply_exceptions`) und bearbeiten Sie sie manuell in der Zieldatenbank. Weitere Informationen finden Sie unter [Einstellungen für die Optimierung der Verarbeitung von Änderungen](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
+ AWS DMS unterstützt nicht die Replikation von Tabellen und Schemas, bei denen der Name ein Sonderzeichen aus dem folgenden Satz enthält.

  `\\ -- \n \" \b \r ' \t ;` 
+ Datenmaskierung wird nicht unterstützt. AWS DMS migriert maskierte Daten ohne Maskierung.
+ AWS DMS repliziert bis zu 32.767 Tabellen mit Primärschlüsseln und bis zu 1.000 Spalten für jede Tabelle. Das liegt daran, dass für jede replizierte Tabelle ein Artikel zur SQL Server-Replikation AWS DMS erstellt wird und dass für Artikel zur SQL Server-Replikation diese Einschränkungen gelten.
+ Wenn Sie die Erfassung von Datenänderungen (Change Data Capture, CDC) verwenden, müssen Sie alle Spalten, die einen eindeutigen Index bilden, als `NOT NULL` definieren. Wenn diese Anforderung nicht erfüllt ist, führt dies zum SQL-Server-Systemfehler 22838. 
+ Sie können Ereignisse verlieren, wenn SQL Server vom aktiven Transaktionsprotokoll in das Sicherungsprotokoll archiviert oder sie aus dem aktiven Transaktionsprotokoll kürzt.

Beim Zugriff auf die Sicherungstransaktionsprotokolle gelten die folgenden Einschränkungen:
+ Verschlüsselte Sicherungen werden nicht unterstützt.
+ Sicherungen, die unter einer URL oder unter Windows Azure gespeichert sind, werden nicht unterstützt.
+ AWS DMS unterstützt nicht die direkte Verarbeitung von Transaktionsprotokollsicherungen auf Dateiebene aus alternativen freigegebenen Ordnern.
+  AWS DMS Unterstützt für andere Cloud SQL Server-Quellen als Amazon RDS for Microsoft SQL Server die fortlaufende Replikation (CDC) nur mit dem aktiven Transaktionsprotokoll. Sie können nicht das Backup-Protokoll für CDC verwenden. Sie können Ereignisse verlieren, wenn der SQL-Server sie vom aktiven Transaktionsprotokoll in das Backup-Protokoll archiviert oder sie aus dem aktiven Transaktionsprotokoll kürzt, bevor DMS sie lesen kann. 
+ Für Amazon RDS for Microsoft SQL Server Server-Quellen unterstützen AWS DMS 3.5.2 und niedriger die fortlaufende Replikation (CDC) nur mit dem aktiven Transaktionsprotokoll, da DMS mit CDC nicht auf das Backup-Protokoll zugreifen kann. Sie können Ereignisse verlieren, wenn RDS for SQL Server sie aus dem aktiven Transaktionsprotokoll in das Backup-Protokoll archiviert oder sie aus dem aktiven Transaktionslog kürzt, bevor DMS sie lesen kann. Diese Einschränkung gilt nicht für AWS DMS Version 3.5.3 und höher.
+ AWS DMS unterstützt CDC für Amazon RDS Proxy for SQL Server nicht als Quelle.
+ Wenn die SQL Server-Quelle während einer Aufgabe mit vollständigem Laden nicht verfügbar ist, wird die Aufgabe nach mehreren Verbindungsversuchen AWS DMS möglicherweise als abgeschlossen markiert, obwohl die Datenmigration noch unvollständig ist. In diesem Szenario enthalten die Zieltabellen nur die Datensätze, die vor dem Verbindungsverlust migriert wurden, was möglicherweise zu Dateninkonsistenzen zwischen Quell- und Zielsystem führen kann. Um die Vollständigkeit der Daten sicherzustellen, müssen Sie entweder die Aufgabe zum vollständigen Laden vollständig neu starten oder die spezifischen Tabellen, die von der Verbindungsunterbrechung betroffen sind, neu laden.

## Berechtigungen für SQL Server-Aufgaben
<a name="CHAP_Source.SQLServer.Permissions"></a>

**Topics**
+ [Berechtigungen für reine Volllastaufgaben](#CHAP_Source.SQLServer.Permissions.FullLoad)
+ [Berechtigungen für Aufgaben mit laufender Replikation](#CHAP_Source.SQLServer.Permissions.Ongoing)

### Berechtigungen für reine Volllastaufgaben
<a name="CHAP_Source.SQLServer.Permissions.FullLoad"></a>

Die folgenden Berechtigungen sind zum Ausführen reiner Volllastaufgaben erforderlich. Beachten Sie, dass AWS DMS das Login `dms_user` nicht erstellt. Informationen zum Erstellen eines Anmeldenamens für SQL Server finden Sie unter [Erstellen eines Datenbankbenutzers](https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-database-user?view=sql-server-ver16) *in der Dokumentation von Microsoft*.

```
USE db_name;
                
                CREATE USER dms_user FOR LOGIN dms_user; 
                ALTER ROLE [db_datareader] ADD MEMBER dms_user; 
                GRANT VIEW DATABASE STATE to dms_user;
                GRANT VIEW DEFINITION to dms_user;
                
                USE master;
                
                GRANT VIEW SERVER STATE TO dms_user;
```

### Berechtigungen für Aufgaben mit laufender Replikation
<a name="CHAP_Source.SQLServer.Permissions.Ongoing"></a>

Selbstverwaltete SQL Server-Instanzen können für die laufende Replikation mithilfe von DMS mit oder ohne Verwendung der `sysadmin` Rolle konfiguriert werden. Stellen Sie bei SQL Server-Instanzen, bei denen Sie die `sysadmin` Rolle nicht gewähren können, sicher, dass der DMS-Benutzer über die im Folgenden beschriebenen Rechte verfügt.

**Richten Sie Berechtigungen für die laufende Replikation aus einer selbstverwalteten SQL Server-Datenbank ein**

1. Erstellen Sie ein neues SQL Server-Konto mit Kennwortauthentifizierung mithilfe von SQL Server Management Studio (SSMS) oder wie zuvor beschrieben[Berechtigungen für reine Volllastaufgaben](#CHAP_Source.SQLServer.Permissions.FullLoad), beispielsweise. `self_managed_user`

1. Führen Sie die folgenden `GRANT` Befehle aus: 

   ```
   GRANT VIEW SERVER STATE TO self_managed_user;
   
   USE msdb;
       GRANT SELECT ON msdb.dbo.backupset TO self_managed_user;
       GRANT SELECT ON msdb.dbo.backupmediafamily TO self_managed_user;
       GRANT SELECT ON msdb.dbo.backupfile TO self_managed_user;
       
   USE db_name;
       CREATE USER self_managed_user FOR LOGIN self_managed_user;
       ALTER ROLE [db_owner] ADD MEMBER self_managed_user;
       GRANT VIEW DEFINITION to self_managed_user;
   ```

1. Zusätzlich zu den oben genannten Berechtigungen benötigt der Benutzer eine der folgenden Berechtigungen:
   + Der Benutzer muss Mitglied der `sysadmin` festen Serverrolle sein
   + Konfigurationen und Berechtigungen wie unter [Einrichtung einer laufenden Replikation auf einem SQL-Server in einer Availability-Group-Umgebung: Ohne Sysadmin-Rolle](CHAP_Source.SQLServer.CDC.md#CHAP_SupportScripts.SQLServer.ag) oder beschrieben[Einrichten der laufenden Replikation auf einer eigenständigen SQL-Server-Quelle: Ohne Sysadmin-Rolle](CHAP_Source.SQLServer.CDC.md#CHAP_SupportScripts.SQLServer.standalone), abhängig von Ihrer Quellkonfiguration.

#### Richten Sie Berechtigungen für die laufende Replikation aus einer Cloud-SQL Server-Datenbank ein
<a name="CHAP_Source.SQLServer.Permissions.Cloud"></a>

Eine in der Cloud gehostete SQL Server-Instance ist eine Instance, die auf Amazon RDS for Microsoft SQL Server, einer verwalteten Azure SQL Instance oder einer anderen verwalteten Cloud-SQL Server-Instanz läuft, die von DMS unterstützt wird.

Erstellen Sie ein neues SQL Server-Konto mit Kennwortauthentifizierung mithilfe von SQL Server Management Studio (SSMS) oder wie zuvor beschrieben[Berechtigungen für reine Volllastaufgaben](#CHAP_Source.SQLServer.Permissions.FullLoad), z. B. `rds_user`

Führen Sie die folgenden Befehle zum Erteilen der Berechtigungen aus.

```
GRANT VIEW SERVER STATE TO rds_user;
```

Für Amazon RDS for Microsoft SQL Server Server-Quellen unterstützt DMS-Version 3.5.3 und höher das Lesen aus Transaktionsprotokoll-Backups. Um sicherzustellen, dass DMS auf die Protokollsicherungen zugreifen kann, müssen Sie zusätzlich zu den oben genannten Rechten entweder `master` Benutzerrechte oder die folgenden Rechte für eine RDS-SQL-Server-Quelle gewähren:

```
USE msdb;
    GRANT EXEC ON msdb.dbo.rds_dms_tlog_download TO rds_user;
    GRANT EXEC ON msdb.dbo.rds_dms_tlog_read TO rds_user;
    GRANT EXEC ON msdb.dbo.rds_dms_tlog_list_current_lsn TO rds_user;
    GRANT EXEC ON msdb.dbo.rds_task_status TO rds_user;
    
USE db_name;
    CREATE USER rds_user FOR LOGIN rds_user;
    ALTER ROLE [db_owner] ADD MEMBER rds_user;
    GRANT VIEW DEFINITION to rds_user;
```

Gewähren Sie für Amazon Azure SQL Managed Instances die folgenden Rechte:

```
GRANT SELECT ON msdb.dbo.backupset TO rds_user;
GRANT SELECT ON msdb.dbo.backupmediafamily TO rds_user;
GRANT SELECT ON msdb.dbo.backupfile TO rds_user;
```

## Voraussetzungen für die Verwendung der laufenden Replikation (CDC) von einer SQL-Server-Quelle aus
<a name="CHAP_Source.SQLServer.Prerequisites"></a>

Sie können die laufende Replikation (Erfassung von Datenänderungen (Change Data Capture, CDC)) für eine selbstverwaltete SQL-Server-Datenbank On-Premises oder in Amazon EC2 oder für eine Cloud-Datenbank wie Amazon RDS oder eine von Microsoft Azure SQL verwaltete Instance verwenden.

Die folgenden Anforderungen gelten speziell für die Verwendung der fortlaufenden Replikation mit einer SQL Server-Datenbank als Quelle für AWS DMS:
+ SQL Server muss für vollständige Sicherungen konfiguriert werden und vor Beginn der Datenreplikation muss eine Sicherung ausgeführt werden.
+ Das Wiederherstellungsmodell muss auf **Bulk logged** (Massenprotokollierung) oder **Full** (Vollständig) eingestellt sein.
+ Die SQL Server-Sicherung auf mehrere Datenträger wird nicht unterstützt. Wenn das Backup so definiert ist, dass das Datenbank-Backup in mehrere Dateien auf verschiedenen Festplatten geschrieben wird, AWS DMS können die Daten nicht gelesen werden und die AWS DMS Aufgabe schlägt fehl.
+ Bei selbstverwalteten SQL-Server-Quellen werden Definitionen von SQL Server Replication Publisher für die in einer DMS-CDC-Aufgabe verwendete Quelle nicht entfernt, wenn die Aufgabe entfernt wird. Bei selbstverwalteten Quellen muss ein SQL Server-Systemadministrator diese Definitionen aus SQL Server löschen.
+ Während des CDC AWS DMS muss nach Sicherungen des SQL Server-Transaktionsprotokolls gesucht werden, um Änderungen lesen zu können. AWS DMS unterstützt keine SQL Server-Transaktionsprotokollsicherungen, die mit Sicherungssoftware von Drittanbietern erstellt wurden und *nicht* im systemeigenen Format vorliegen. Um Backups des Transaktionsprotokolls zu unterstützen, die *im nativen Format vorliegen* und mit Backup-Software von Drittanbietern erstellt wurden, fügen Sie dem Quellendpunkt das Verbindungsattribut `use3rdPartyBackupDevice=Y` hinzu.
+ Beachten Sie bei selbstverwalteten SQL Server-Quellen, dass SQL Server Änderungen an neu erstellten Tabellen erst erfasst, nachdem diese veröffentlicht wurden. AWS DMS Verwaltet die Erstellung der Publikation, wenn Tabellen zu einer SQL Server-Quelle hinzugefügt werden. Dieser Vorgang kann allerdings einige Minuten dauern. Während dieser Verzögerung vorgenommene Operationen in neu erstellten Tabellen werden nicht erfasst oder in der Zieldatenbank repliziert. 
+ AWS DMS Für die Erfassung von Änderungsdaten muss die vollständige Transaktionsprotokollierung in SQL Server aktiviert sein. Um die vollständige Transaktionsprotokollierung in SQL Server zu aktivieren, müssen Sie entweder MS-REPLICATION oder CHANGE DATA CAPTURE (CDC) aktivieren.
+ SQL-Server-*tlog*-Einträge werden erst für die Wiederverwendung markiert, wenn der MS-CDC-Erfassungsauftrag diese Änderungen verarbeitet.
+ CDC-Vorgänge werden auf speicheroptimierten Tabellen nicht unterstützt. Diese Einschränkung gilt für SQL Server 2014 (erstmalige Einführung des Features) und höher.
+ AWS DMS Für die Erfassung von Änderungsdaten ist standardmäßig eine Verteilungsdatenbank auf Amazon EC2 oder einem lokalen SQL-Server als Quelle erforderlich. Stellen Sie daher sicher, dass Sie den Verteiler aktiviert haben, während Sie MS Replication für Tabellen mit Primärschlüsseln konfigurieren.

## Unterstützte Komprimierungsmethoden für SQL Server
<a name="CHAP_Source.SQLServer.Compression"></a>

Beachten Sie in Bezug auf die Unterstützung von SQL-Server-Komprimierungsmethoden in AWS DMS Folgendes:
+ AWS DMS unterstützt die Row/Page Komprimierung in SQL Server Version 2008 und höher.
+ AWS DMS unterstützt das Vardecimal-Speicherformat nicht.
+ AWS DMS unterstützt keine spärlichen Spalten und keine Komprimierung von Spaltenstrukturen.

## Arbeiten mit selbstverwalteten SQL Server-Verfügbarkeitsgruppen AlwaysOn
<a name="CHAP_Source.SQLServer.AlwaysOn"></a>

SQL-Server-AlwaysOn-Verfügbarkeitsgruppen bieten Hochverfügbarkeit und Notfallwiederherstellung als Alternative zur Datenbankspiegelung auf Unternehmensebene. 

In AWS DMS können Sie Änderungen von einem einzelnen primären oder sekundären Verfügbarkeitsgruppenreplikat migrieren.

### Arbeiten mit dem Replikat der primären Verfügbarkeitsgruppe
<a name="CHAP_Source.SQLServer.AlwaysOn.Primary"></a>

 

**Gehen Sie wie folgt vor, um die primäre Verfügbarkeitsgruppe als Quelle in AWS DMS zu verwenden:**

1. Aktivieren Sie die Verteilungsoption für alle SQL-Server-Instances in Ihren Replikaten der Verfügbarkeitsgruppe. Weitere Informationen finden Sie unter [Einrichten der laufenden Replikation auf einer selbstverwalteten SQL-Server-Quelle](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.CDC.MSCDC).

1. Öffnen Sie in der AWS DMS Konsole die Einstellungen für die SQL Server-Quelldatenbank. Geben Sie für **Servername** den Domain Name Service (DNS)-Namen oder die IP-Adresse ein, der/die für den Verfügbarkeitsgruppen-Listener konfiguriert wurde. 

Wenn Sie eine AWS DMS Aufgabe zum ersten Mal starten, kann es länger als gewöhnlich dauern, bis sie gestartet wird. Das liegt daran, dass die Erstellung der Tabellenartikel durch den Verfügbarkeitsgruppenserver dupliziert wird. 

### Arbeiten mit dem Replikat einer sekundären Verfügbarkeitsgruppe
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary"></a>

**Gehen Sie wie folgt vor, um eine sekundäre Verfügbarkeitsgruppe als Quelle für zu verwenden: AWS DMS**

1. Verwenden Sie für die Verbindung zu einzelnen Replikaten dieselben Anmeldeinformationen wie für den Benutzer des AWS DMS Quellendpunkts.

1. Stellen Sie sicher, dass Ihre AWS DMS Replikationsinstanz DNS-Namen für alle vorhandenen Replikate auflösen und eine Verbindung zu ihnen herstellen kann. Sie können die folgende SQL-Abfrage verwenden, um DNS-Namen für alle Ihre Replikate abzurufen.

   ```
   select ar.replica_server_name, ar.endpoint_url from sys.availability_replicas ar
   JOIN sys.availability_databases_cluster adc
   ON adc.group_id = ar.group_id AND adc.database_name = '<source_database_name>';
   ```

1. Wenn Sie den Quellendpunkt erstellen, geben Sie den DNS-Namen des Verfügbarkeitsgruppen-Listeners als **Servername** des Endpunkts oder als **Serveradresse** des Endpunkt-Secrets an. Weitere Informationen zu Verfügbarkeitsgruppen-Listenern finden Sie unter [What is an availability group listener?](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-group-listener-overview?view=sql-server-ver15) in der Dokumentation zu SQL Server.

   Sie können entweder einen öffentlichen DNS-Server oder einen On-Premises-DNS-Server verwenden, um den Verfügbarkeitsgruppen-Listener, das primäre Replikat und die sekundären Replikate aufzulösen. Wenn Sie einen On-Premises-DNS-Server verwenden möchten, konfigurieren Sie den Amazon Route 53 Resolver. Weitere Informationen finden Sie unter [Verwenden Ihres eigenen Vor-Ort-Nameservers](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver).

1. Fügen Sie Ihrem Quellendpunkt die folgenden zusätzlichen Verbindungsattribute hinzu.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_Source.SQLServer.html)

1. Aktivieren Sie die Verteilungsoption für alle Replikate in Ihrer Verfügbarkeitsgruppe. Fügen Sie der Verteilerliste alle Knoten hinzu. Weitere Informationen finden Sie unter [So richten Sie die Verteilung ein](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.CDC.MSCDC.Setup).

1. Führen Sie die folgende Abfrage für das primäre Lese-/Schreibreplikat aus, um die Veröffentlichung Ihrer Datenbank zu ermöglichen. Sie führen diese Abfrage nur einmal für Ihre Datenbank aus. 

   ```
   sp_replicationdboption @dbname = N'<source DB name>', @optname = N'publish', @value = N'true';
   ```



#### Einschränkungen
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary.limitations"></a>

Im Folgenden werden Einschränkungen für die Arbeit mit einem Replikat einer sekundären Verfügbarkeitsgruppe aufgeführt:
+ AWS DMS unterstützt Safeguard nicht, wenn Sie ein schreibgeschütztes Verfügbarkeitsgruppenreplikat als Quelle verwenden. Weitere Informationen finden Sie unter [Endpunkteinstellungen bei Verwendung von SQL Server als Quelle für AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib).
+ AWS DMS unterstützt das `setUpMsCdcForTables` zusätzliche Verbindungsattribut nicht, wenn ein schreibgeschütztes Verfügbarkeitsgruppenreplikat als Quelle verwendet wird. Weitere Informationen finden Sie unter [Endpunkteinstellungen bei Verwendung von SQL Server als Quelle für AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib).
+ AWS DMS kann ab Version 3.4.7 ein selbstverwaltetes sekundäres Verfügbarkeitsgruppenreplikat als Quelldatenbank für die laufende Replikation (Change Data Capture, CDC) verwenden. Multi-AZ-Lesereplikate in Cloud SQL Server werden nicht unterstützt. Wenn Sie frühere Versionen von verwenden, stellen Sie sicher AWS DMS, dass Sie das Replikat der primären Verfügbarkeitsgruppe als Quelldatenbank für CDC verwenden.

#### Failover auf andere Knoten
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary.failover"></a>

Wenn Sie das `ApplicationIntent` zusätzliche Verbindungsattribut für Ihren Endpunkt auf festlegen`ReadOnly`, stellt Ihre AWS DMS Aufgabe eine Verbindung mit dem schreibgeschützten Knoten mit der höchsten Nur-Lese-Routing-Priorität her. Anschließend erfolgt ein Failover zu anderen schreibgeschützten Knoten in Ihrer Verfügbarkeitsgruppe, wenn der schreibgeschützte Knoten mit der höchsten Priorität nicht verfügbar ist. Wenn Sie dies nicht festlegen`ApplicationIntent`, stellt Ihre AWS DMS Aufgabe nur eine Verbindung zum primären Knoten (Lese-/Schreibknoten) in Ihrer Verfügbarkeitsgruppe her.

## Endpunkteinstellungen bei Verwendung von SQL Server als Quelle für AWS DMS
<a name="CHAP_Source.SQLServer.ConnectionAttrib"></a>

Sie können Endpunkteinstellungen, ähnlich wie zusätzliche Verbindungsattribute, zum Konfigurieren Ihrer SQL-Server-Quelldatenbank verwenden. Sie geben die Einstellungen an, wenn Sie den Quellendpunkt mithilfe der AWS DMS Konsole oder mithilfe des `create-endpoint` Befehls in [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), mit der `--microsoft-sql-server-settings '{"EndpointSetting": "value", ...}'` JSON-Syntax erstellen.

Die folgende Tabelle zeigt die Endpunkteinstellungen, die Sie mit SQL Server als Quelle verwenden können.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_Source.SQLServer.html)

## Quelldatentypen für SQL Server
<a name="CHAP_Source.SQLServer.DataTypes"></a>

Die Datenmigration, die SQL Server als Quelle verwendet, AWS DMS unterstützt die meisten SQL Server-Datentypen. Die folgende Tabelle zeigt die SQL Server-Quelldatentypen, die bei der Verwendung unterstützt werden, AWS DMS sowie die Standardzuweisung von AWS DMS Datentypen.

Weitere Informationen zum Anzeigen des Datentyps, der im Ziel zugewiesen ist, finden Sie im Abschnitt für den Zielendpunkt, den Sie verwenden.

Weitere Informationen zu AWS DMS Datentypen finden Sie unter[Datentypen für den AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  SQL Server-Datentypen  |  AWS DMS Datentypen  | 
| --- | --- | 
|  BIGINT  |  INT8  | 
|  BIT  |  BOOLEAN  | 
|  DECIMAL  |  NUMERIC  | 
|  INT  |  INT4  | 
|  MONEY  |  NUMERIC  | 
|  NUMERIC (p,s)  |  NUMERIC   | 
|  SMALLINT  |  INT2  | 
|  SMALLMONEY  |  NUMERIC  | 
|  TINYINT  |  UINT1  | 
|  REAL  |  REAL4  | 
|  FLOAT  |  REAL8  | 
|  DATETIME  |  DATETIME  | 
|  DATETIME2 (SQL Server 2008 und höher)  |  DATETIME  | 
|  SMALLDATETIME  |  DATETIME  | 
|  DATE  |  DATE  | 
|  TIME  |  TIME  | 
|  DATETIMEOFFSET  |  WSTRING  | 
|  CHAR  |  STRING  | 
|  VARCHAR  |  STRING  | 
|  VARCHAR (max)  |  CLOB TEXT Um diesen Datentyp mit zu verwenden AWS DMS, müssen Sie die Verwendung von CLOB-Datentypen für eine bestimmte Aufgabe aktivieren. Bei SQL Server-Tabellen werden die LOB-Spalten im Ziel auch für UPDATE-Anweisungen aktualisiert, die den Wert der LOB-Spalte in SQL Server nicht ändern. AWS DMS   AWS DMS Unterstützt während CDC CLOB-Datentypen nur in Tabellen, die einen Primärschlüssel enthalten.  | 
|  NCHAR  |  WSTRING  | 
|  NVARCHAR (Länge)  |  WSTRING  | 
|  NVARCHAR (max)  |  NCLOB NTEXT Um diesen Datentyp mit zu verwenden AWS DMS, müssen Sie die Verwendung von SupportLobs für eine bestimmte Aufgabe aktivieren. Weitere Informationen zum Aktivieren von Lob-Unterstützung finden Sie unter [Einstellung der LOB-Unterstützung für Quelldatenbanken in einer Aufgabe AWS DMS](CHAP_Tasks.LOBSupport.md).  Bei SQL Server-Tabellen werden die LOB-Spalten im Ziel auch für UPDATE-Anweisungen aktualisiert, die den Wert der LOB-Spalte in SQL Server nicht ändern. AWS DMS   AWS DMS Unterstützt während CDC CLOB-Datentypen nur in Tabellen, die einen Primärschlüssel enthalten.  | 
|  BINARY  |  BYTES  | 
|  VARBINARY  |  BYTES  | 
|  VARBINARY (max)  |  BLOB IMAGE Bei SQL Server-Tabellen werden die LOB-Spalten im Ziel auch für UPDATE-Anweisungen aktualisiert, die den Wert der LOB-Spalte in SQL Server nicht ändern. AWS DMS  Um diesen Datentyp mit zu verwenden AWS DMS, müssen Sie die Verwendung von BLOB-Datentypen für eine bestimmte Aufgabe aktivieren. AWS DMS unterstützt BLOB-Datentypen nur in Tabellen, die einen Primärschlüssel enthalten.  | 
|  TIMESTAMP (ZEITSTEMPEL)  |  BYTES  | 
|  UNIQUEIDENTIFIER  |  STRING  | 
|  HIERARCHYID   |  Verwenden Sie HIERARCHYID bei der Replikation von Daten auf einem SQL Server-Zielendpunkt. Verwenden Sie WSTRING (250) bei der Replikation auf allen anderen Zielendpunkten.  | 
|  XML  |  NCLOB  AWS DMS Aktualisiert bei SQL Server-Tabellen die LOB-Spalten im Ziel auch für UPDATE-Anweisungen, die den Wert der LOB-Spalte in SQL Server nicht ändern. Um diesen Datentyp mit zu verwenden AWS DMS, müssen Sie die Verwendung von NCLOB-Datentypen für eine bestimmte Aufgabe aktivieren.  AWS DMS Unterstützt während CDC NCLOB-Datentypen nur in Tabellen, die einen Primärschlüssel enthalten.  | 
|  GEOMETRY  |  Verwenden Sie GEOMETRY bei der Replikation auf Zielendpunkte, die diesen Datentyp unterstützen. Verwenden Sie CLOB bei der Replikation auf Zielendpunkte, die diesen Datentyp nicht unterstützen.  | 
|  GEOGRAPHY  |  Verwenden Sie GEOGRAPHY bei der Replikation auf Zielendpunkte, die diesen Datentyp unterstützen. Verwenden Sie CLOB bei der Replikation auf Zielendpunkte, die diesen Datentyp nicht unterstützen.  | 

AWS DMS unterstützt keine Tabellen, die Felder mit den folgenden Datentypen enthalten. 
+ CURSOR
+ SQL\$1VARIANT
+ TABLE

**Anmerkung**  
Benutzerdefinierte Datentypen werden abhängig von dem Typ, auf dem sie basieren, unterstützt. Beispielsweise wird ein benutzerdefinierter Datentyp basierend auf DATETIME als Datentyp DATETIME verarbeitet.

# Erfassung von Datenänderungen für die laufende Replikation von SQL Server
<a name="CHAP_Source.SQLServer.CDC"></a>

In diesem Thema wird beschrieben, wie Sie die CDC-Replikation auf einer SQL Server-Quelle einrichten.

**Topics**
+ [Erfassen von Datenänderungen für selbstverwaltete SQL-Server-Quellen (On-Premises oder in Amazon EC2)](#CHAP_Source.SQLServer.CDC.Selfmanaged)
+ [Einrichten der laufenden Replikation auf einer SQL-Server-DB-Instance in der Cloud](#CHAP_Source.SQLServer.Configuration)

## Erfassen von Datenänderungen für selbstverwaltete SQL-Server-Quellen (On-Premises oder in Amazon EC2)
<a name="CHAP_Source.SQLServer.CDC.Selfmanaged"></a>

Damit Änderungen aus einer Quelldatenbank in Microsoft SQL Server erfasst werden, stellen Sie sicher, dass die Datenbank für vollständige Backups konfiguriert ist. Konfigurieren Sie die Datenbank entweder im vollständigen Wiederherstellungsmodus oder im massenprotokollierten Modus.

 AWS DMS Verwendet für eine selbstverwaltete SQL Server-Quelle Folgendes:

**MS-Replication**  
Zum Erfassen von Änderungen für Tabellen mit Primärschlüsseln. Sie können dies automatisch konfigurieren, indem Sie dem AWS DMS Endpunktbenutzer auf der SQL Server-Quellinstanz Sysadmin-Rechte gewähren. Oder Sie können die Schritte in diesem Abschnitt befolgen, um die Quelle vorzubereiten und einen Benutzer zu verwenden, der keine Sysadmin-Rechte für den Endpunkt hat. AWS DMS 

**MS-CDC**  
Zum Erfassen von Änderungen für Tabellen ohne Primärschlüssel. Aktivieren Sie MS-CDC auf Datenbankebene und für alle Tabellen einzeln.

Beim Einrichten einer SQL-Server-Datenbank für die laufende Replikation (CDC) können Sie einen der folgenden Schritte ausführen:
+ Einrichten der fortlaufenden Replikation mit der Sysadmin-Rolle.
+ Einrichten der fortlaufenden Replikation ohne Verwendung der Sysadmin-Rolle.

**Anmerkung**  
Sie können das folgende Skript verwenden, um alle Tabellen ohne Primärschlüssel oder eindeutigen Schlüssel zu finden:  

```
USE [DBname]
SELECT SCHEMA_NAME(schema_id) AS schema_name, name AS table_name
FROM sys.tables
WHERE OBJECTPROPERTY(object_id, 'TableHasPrimaryKey') = 0
        AND  OBJECTPROPERTY(object_id, 'TableHasUniqueCnst') = 0
ORDER BY schema_name, table_name;
```

### Einrichten der laufenden Replikation auf einer selbstverwalteten SQL-Server-Quelle
<a name="CHAP_Source.SQLServer.CDC.MSCDC"></a>

Dieser Abschnitt enthält Informationen zum Einrichten der laufenden Replikation auf einer selbstverwalteten SQL-Server-Quelle mit oder ohne die Sysadmin-Rolle.

**Topics**
+ [Einrichten der laufenden Replikation auf einer selbstverwalteten SQL-Server-Quelle: Verwenden der Sysadmin-Rolle](#CHAP_Source.SQLServer.CDC.MSCDC.Sysadmin)
+ [Einrichten der laufenden Replikation auf einer eigenständigen SQL-Server-Quelle: Ohne Sysadmin-Rolle](#CHAP_SupportScripts.SQLServer.standalone)
+ [Einrichtung einer laufenden Replikation auf einem SQL-Server in einer Availability-Group-Umgebung: Ohne Sysadmin-Rolle](#CHAP_SupportScripts.SQLServer.ag)

#### Einrichten der laufenden Replikation auf einer selbstverwalteten SQL-Server-Quelle: Verwenden der Sysadmin-Rolle
<a name="CHAP_Source.SQLServer.CDC.MSCDC.Sysadmin"></a>

AWS DMS Bei der laufenden Replikation für SQL Server wird die systemeigene SQL Server-Replikation für Tabellen mit Primärschlüsseln und die Change Data Capture (CDC) für Tabellen ohne Primärschlüssel verwendet.

Bevor Sie die laufende Replikation einrichten, informieren Sie sich unter [Voraussetzungen für die Verwendung der laufenden Replikation (CDC) von einer SQL-Server-Quelle aus](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Prerequisites). 

Bei Tabellen mit Primärschlüsseln AWS DMS kann im Allgemeinen die erforderlichen Artefakte auf der Quelle konfiguriert werden. Bei selbstverwalteten SQL-Server-Quell-Instances müssen Sie die SQL-Server-Verteilung jedoch zunächst manuell konfigurieren. Danach können AWS DMS Quellbenutzer mit Sysadmin-Rechten automatisch die Publikation für Tabellen mit Primärschlüsseln erstellen.

Um zu überprüfen, ob die Verteilung bereits konfiguriert wurde, führen Sie den folgenden Befehl aus.

```
sp_get_distributor
```

Ist das Ergebnis für die Spaltenverteilung `NULL`, ist die Verteilung nicht konfiguriert. Sie können die Verteilung anhand des folgenden Verfahrens einrichten.<a name="CHAP_Source.SQLServer.CDC.MSCDC.Setup"></a>

**So richten Sie die Verteilung ein**

1. Stellen Sie mithilfe des Tools SQL Server Management Studio (SSMS) eine Verbindung mit der SQL-Server-Quelldatenbank her.

1. Öffnen Sie das Kontextmenü (rechte Maustaste) für den Ordner **Replikation** und wählen Sie die Option **Verteilung konfigurieren**. Der Assistent zum Konfigurieren der Verteilung wird angezeigt. 

1. Befolgen Sie die Anweisungen im Assistenten, um die Standardwerte einzugeben und die Verteilung zu erstellen.<a name="CHAP_Source.SQLServer.CDC.MSCDC.Setup.CDC"></a>

**So richten Sie CDC ein**

AWS DMS Version 3.4.7 und höher kann MS CDC für Ihre Datenbank und alle Ihre Tabellen automatisch einrichten, wenn Sie kein schreibgeschütztes Replikat verwenden. Setzen Sie das ECA `SetUpMsCdcForTables` auf true, um dieses Feature zu verwenden. Hinweise zu finden Sie unter. ECAs [Endpunkteinstellungen](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.ConnectionAttrib)

Gehen Sie für AWS DMS Versionen vor 3.4.7 oder für ein schreibgeschütztes Replikat als Quelle wie folgt vor:

1. Richten Sie bei Tabellen ohne Primärschlüssel MS-CDC für die Datenbank ein. Verwenden Sie dazu ein Konto, dem die Sysadmin-Rolle zugewiesen ist, und führen Sie den folgenden Befehl aus.

   ```
   use [DBname]
   EXEC sys.sp_cdc_enable_db
   ```

1. Richten Sie anschließend MS-CDC für jede der Quelltabellen ein. Führen Sie die folgende Abfrage für jede Tabelle mit eindeutigen Schlüsseln, aber ohne Primärschlüssel aus, um MS-CDC einzurichten.

   ```
   exec sys.sp_cdc_enable_table
   @source_schema = N'schema_name',
   @source_name = N'table_name',
   @index_name = N'unique_index_name',
   @role_name = NULL,
   @supports_net_changes = 1
   GO
   ```

1. Führen Sie die folgende Abfrage für jede Tabelle ohne Primärschlüssel oder eindeutige Schlüssel aus, um MS-CDC einzurichten.

   ```
   exec sys.sp_cdc_enable_table
   @source_schema = N'schema_name',
   @source_name = N'table_name',
   @role_name = NULL
   GO
   ```

Weitere Informationen zum Einrichten von MS-CDC für bestimmte Tabellen finden Sie in der [ SQL Server-Dokumentation](https://msdn.microsoft.com/en-us/library/cc627369.aspx). 

#### Einrichten der laufenden Replikation auf einer eigenständigen SQL-Server-Quelle: Ohne Sysadmin-Rolle
<a name="CHAP_SupportScripts.SQLServer.standalone"></a>

Dieser Abschnitt beschreibt die Einrichtung der fortlaufenden Replikation für eine eigenständige SQL-Server-Datenbankquelle, für die das Benutzerkonto keine Sysadmin-Berechtigungen benötigt.

**Anmerkung**  
Nachdem Sie die Schritte in diesem Abschnitt ausgeführt haben, hat der DMS-Benutzer, der kein Systemadministrator ist, die Berechtigung, um Folgendes zu tun:  
Lesen der Änderungen aus der Protokolldatei für Online-Transaktionen
Festplattenzugriff zum Lesen von Änderungen aus Transaktionsprotokoll-Backup-Dateien
Hinzufügen oder Ändern der von DMS verwendeten Publikation
Hinzufügen von Artikeln zu der Publikation

1. Richten Sie Microsoft SQL Server für die Replikation ein, wie unter [Erfassung von Datenänderungen für die laufende Replikation von SQL Server](#CHAP_Source.SQLServer.CDC) beschrieben.

1. Aktivieren Sie MS-REPLICATION in der Quelldatenbank. Dies kann entweder manuell oder durch einmaliges Ausführen der Aufgabe als Sysadmin-Benutzer erfolgen.

1. Erstellen Sie das `awsdms`-Schema in der Quelldatenbank mit dem folgenden Skript:

   ```
   use master
   go
   create schema awsdms
   go
   
   
   -- Create the table valued function [awsdms].[split_partition_list] on the Master database, as follows:
   USE [master]
   GO
   
   set ansi_nulls on
   go
   
   set quoted_identifier on
   go
   
   if (object_id('[awsdms].[split_partition_list]','TF')) is not null
   
   drop function [awsdms].[split_partition_list];
   
   go
   
   create function [awsdms].[split_partition_list]
   
   (
   
   @plist varchar(8000), --A delimited list of partitions
   
   @dlm nvarchar(1) --Delimiting character
   
   )
   
   returns @partitionsTable table --Table holding the BIGINT values of the string fragments
   
   (
   
   pid bigint primary key
   
   )   
   
   as
   
   begin
   
   declare @partition_id bigint;
   
   declare @dlm_pos integer;
   
   declare @dlm_len integer;
   
   set @dlm_len = len(@dlm);
   
   while (charindex(@dlm,@plist)>0)
   
   begin
   
   set @dlm_pos = charindex(@dlm,@plist);
   
   set @partition_id = cast( ltrim(rtrim(substring(@plist,1,@dlm_pos-1))) as bigint);
   
   insert into @partitionsTable (pid) values (@partition_id)
   
   set @plist = substring(@plist,@dlm_pos+@dlm_len,len(@plist));
   
   end
   
   set @partition_id = cast (ltrim(rtrim(@plist)) as bigint);
   
   insert into @partitionsTable (pid) values ( @partition_id );
   
   return
   
   end
   
   GO
   ```

1. Erstellen Sie die `[awsdms].[rtm_dump_dblog]`-Prozedur in der Master-Datenbank mit dem folgenden Skript:

   ```
   use [MASTER]
   
   go
   
   if (object_id('[awsdms].[rtm_dump_dblog]','P')) is not null drop procedure [awsdms].[rtm_dump_dblog];
   go
   
   
   set ansi_nulls on
   go
   
   set quoted_identifier on
   GO
   
   
   
   CREATE procedure [awsdms].[rtm_dump_dblog]
   
   (
   
   @start_lsn varchar(32),
   
   @seqno integer,
   
   @filename varchar(260),
   
   @partition_list varchar(8000), -- A comma delimited list: P1,P2,... Pn
   
   @programmed_filtering integer,
   
   @minPartition bigint,
   
   @maxPartition bigint
   
   )
   
   as begin
   
   declare @start_lsn_cmp varchar(32); -- Stands against the GT comparator
   
   SET NOCOUNT ON -- – Disable "rows affected display"
   
   set @start_lsn_cmp = @start_lsn;
   
   if (@start_lsn_cmp) is null
   
   set @start_lsn_cmp = '00000000:00000000:0000';
   
   if (@partition_list is null)
   
   begin
   
   RAISERROR ('Null partition list waspassed',16,1);
   
   return
   
   end
   
   if (@start_lsn) is not null
   
   set @start_lsn = '0x'+@start_lsn;
   
   if (@programmed_filtering=0)
   
   
   
   SELECT
   
   [Current LSN],
   
   [operation],
   
   [Context],
   
   [Transaction ID],
   
   [Transaction Name],
   
   [Begin Time],
   
   [End Time],
   
   [Flag Bits],
   
   [PartitionID],
   
   [Page ID],
   
   [Slot ID],
   
   [RowLog Contents 0],
   
   [Log Record],
   
   [RowLog Contents 1]
   
   FROM
   
   fn_dump_dblog (
   
   @start_lsn, NULL, N'DISK', @seqno, @filename,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default)
   
   where [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS
   
   and
   
   (
   
   ( [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
   
   or
   
   ( [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
   
   and
   
   ( ( [context] in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX' and (datalength([RowLog Contents 0]) in (0,1))))
   
   and [PartitionID] in ( select * from master.awsdms.split_partition_list (@partition_list,','))
   
   )
   
   or
   
   ([operation] = 'LOP_HOBT_DDL')
   
   )
   
   
   else
   
   
   SELECT
   
   [Current LSN],
   
   [operation],
   
   [Context],
   
   [Transaction ID],
   
   [Transaction Name],
   
   [Begin Time],
   
   [End Time],
   
   [Flag Bits],
   
   [PartitionID],
   
   [Page ID],
   
   [Slot ID],
   
   [RowLog Contents 0],
   
   [Log Record],
   
   [RowLog Contents 1] -- After Image
   
   FROM
   
   fn_dump_dblog (
   
   @start_lsn, NULL, N'DISK', @seqno, @filename,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default)
   
   where [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS
   
   and
   
   (
   
   ( [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
   
   or
   
   ( [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
   
   and
   
   ( ( [context] in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX' and (datalength([RowLog Contents 0]) in (0,1))))
   
   and ([PartitionID] is not null) and ([PartitionID] >= @minPartition and [PartitionID]<=@maxPartition)
   
   )
   
   or
   
   ([operation] = 'LOP_HOBT_DDL')
   
   )
   
   
   
   SET NOCOUNT OFF -- Re-enable "rows affected display"
   
   end
   
   GO
   ```

1. Erstellen Sie das Zertifikat in der Master-Datenbank mit dem folgenden Skript:

   ```
   Use [master]
   Go
   
   CREATE CERTIFICATE [awsdms_rtm_dump_dblog_cert] ENCRYPTION BY PASSWORD = N'@5trongpassword'
   
   WITH SUBJECT = N'Certificate for FN_DUMP_DBLOG Permissions';
   ```

1. Erstellen Sie die Anmeldung von dem Zertifikat mit dem folgenden Skript: 

   ```
   Use [master]
   Go
   
   CREATE LOGIN awsdms_rtm_dump_dblog_login FROM CERTIFICATE [awsdms_rtm_dump_dblog_cert];
   ```

1. Fügen Sie die Anmeldung mithilfe des folgenden Skripts zur Sysadmin-Serverrolle hinzu:

   ```
   ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_dump_dblog_login];
   ```

1. Fügen Sie die Signatur zu [Master]. [awsdms]. [rtm\$1dump\$1dblog] unter Verwendung des Zertifikats mit dem folgenden Skript hinzu: 

   ```
   Use [master]
   GO
   ADD SIGNATURE
   TO [master].[awsdms].[rtm_dump_dblog] BY CERTIFICATE [awsdms_rtm_dump_dblog_cert] WITH PASSWORD = '@5trongpassword';
   ```
**Anmerkung**  
Wenn Sie die gespeicherte Prozedur neu erstellen, müssen Sie die Signatur erneut hinzufügen.

1. Erstellen Sie [awsdms].[rtm\$1position\$11st\$1timestamp] in der Master-Datenbank mithilfe des folgenden Skripts:

   ```
   use [master]
       if object_id('[awsdms].[rtm_position_1st_timestamp]','P') is not null
       DROP PROCEDURE [awsdms].[rtm_position_1st_timestamp];
       go
       create procedure [awsdms].[rtm_position_1st_timestamp]
       (
       @dbname                sysname,      -- Database name
       @seqno                 integer,      -- Backup set sequence/position number within file
       @filename              varchar(260), -- The backup filename
       @1stTimeStamp          varchar(40)   -- The timestamp to position by
       ) 
       as begin
   
       SET NOCOUNT ON       -- Disable "rows affected display"
   
       declare @firstMatching table
       (
       cLsn varchar(32),
       bTim datetime
       )
   
       declare @sql nvarchar(4000)
       declare @nl                       char(2)
       declare @tb                       char(2)
       declare @fnameVar                 nvarchar(254) = 'NULL'
   
       set @nl  = char(10); -- New line
       set @tb  = char(9)   -- Tab separator
   
       if (@filename is not null)
       set @fnameVar = ''''+@filename +''''
   
       set @sql='use ['+@dbname+'];'+@nl+
       'select top 1 [Current LSN],[Begin Time]'+@nl+
       'FROM fn_dump_dblog (NULL, NULL, NULL, '+ cast(@seqno as varchar(10))+','+ @fnameVar+','+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default)'+@nl+
       'where operation=''LOP_BEGIN_XACT''' +@nl+
       'and [Begin Time]>= cast('+''''+@1stTimeStamp+''''+' as datetime)'+@nl
   
       --print @sql
       delete from  @firstMatching 
       insert into @firstMatching  exec sp_executesql @sql    -- Get them all
   
       select top 1 cLsn as [matching LSN],convert(varchar,bTim,121) as [matching Timestamp] from @firstMatching;
   
       SET NOCOUNT OFF      -- Re-enable "rows affected display"
   
       end
       GO
   ```

1. Erstellen Sie das Zertifikat in der Master-Datenbank mit dem folgenden Skript:

   ```
   Use [master]
   Go
   CREATE CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
   ENCRYPTION BY PASSWORD = '@5trongpassword'
   WITH SUBJECT = N'Certificate for FN_POSITION_1st_TIMESTAMP Permissions';
   ```

1. Erstellen Sie die Anmeldung von dem Zertifikat mit dem folgenden Skript:

   ```
   Use [master]
   Go
   CREATE LOGIN awsdms_rtm_position_1st_timestamp_login FROM CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert];
   ```

1. Fügen Sie die Anmeldedaten mithilfe des folgenden Skripts zur sysadmin-Rolle hinzu:

   ```
   ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_position_1st_timestamp_login];
   ```

1. Fügen Sie die Signatur zu [master].[awsdms].[rtm\$1position\$11st\$1timestamp] unter Verwendung des Zertifikats mit dem folgenden Skript hinzu:

   ```
   Use [master]
       GO
       ADD SIGNATURE
       TO [master].[awsdms].[rtm_position_1st_timestamp]
       BY CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
       WITH PASSWORD = '@5trongpassword';
   ```

1. Gewähren Sie dem DMS-Benutzer mithilfe des folgenden Skripts Ausführungszugriff auf die neue gespeicherte Prozedur:

   ```
   use master
   go
   GRANT execute on [awsdms].[rtm_position_1st_timestamp] to dms_user;
   ```

1. Erstellen Sie in jeder der folgenden Datenbanken einen Benutzer mit den folgenden Berechtigungen und Rollen:
**Anmerkung**  
Sie sollten das Benutzerkonto dmsnosysadmin mit derselben SID für jedes Replikat erstellen. Die folgende SQL-Abfrage kann dabei helfen, den SID-Wert des dmsnosysadmin-Kontos auf jedem Replikat zu überprüfen. Weitere Informationen zum Erstellen eines Benutzers finden Sie unter [BENUTZER ERSTELLEN (Transact-SQL)](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql) in der [Microsoft-SQL-Server-Dokumentation](https://learn.microsoft.com/en-us/sql/). Weitere Informationen zum Erstellen von SQL-Benutzerkonten für die Azure-SQL-Datenbank finden Sie unter [Aktive Georeplikation](https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview).

   ```
   use master
   go
   grant select on sys.fn_dblog to [DMS_user]
   grant view any definition to [DMS_user]
   grant view server state to [DMS_user]--(should be granted to the login).
   grant execute on sp_repldone to [DMS_user]
   grant execute on sp_replincrementlsn to [DMS_user]
   grant execute on sp_addpublication to [DMS_user]
   grant execute on sp_addarticle to [DMS_user]
   grant execute on sp_articlefilter to [DMS_user]
   grant select on [awsdms].[split_partition_list] to [DMS_user]
   grant execute on [awsdms].[rtm_dump_dblog] to [DMS_user]
   ```

   ```
   use msdb
   go
   grant select on msdb.dbo.backupset to self_managed_user
   grant select on msdb.dbo.backupmediafamily to self_managed_user
   grant select on msdb.dbo.backupfile to self_managed_user
   ```

   Führen Sie den folgenden Befehl für die Quelldatenbank aus:

   ```
   use Source_DB
       Go
       EXEC sp_addrolemember N'db_owner', N'DMS_user'
   ```

1. Fügen Sie abschließend dem SQL-Server-Endpunkt ein zusätzliches Verbindungsattribut (ECA) hinzu:

   ```
   enableNonSysadminWrapper=true;
   ```

#### Einrichtung einer laufenden Replikation auf einem SQL-Server in einer Availability-Group-Umgebung: Ohne Sysadmin-Rolle
<a name="CHAP_SupportScripts.SQLServer.ag"></a>

Dieser Abschnitt beschreibt die Einrichtung der fortlaufenden Replikation für eine eigenständige SQL-Server-Datenbankquelle, für die das Benutzerkonto keine sysadmin-Berechtigungen benötigt.

**Anmerkung**  
Nachdem Sie die Schritte in diesem Abschnitt ausgeführt haben, hat der DMS-Benutzer, der kein Systemadministrator ist, die Berechtigung, um Folgendes zu tun:  
Lesen der Änderungen aus der Protokolldatei für Online-Transaktionen
Festplattenzugriff zum Lesen von Änderungen aus Transaktionsprotokoll-Backup-Dateien
Hinzufügen oder Ändern der von DMS verwendeten Publikation
Hinzufügen von Artikeln zu der Publikation

**So richten Sie die fortlaufende Replikation in einer Availability-Group-Umgebung ein, ohne den Sysadmin-Benutzer zu verwenden**

1. Richten Sie Microsoft SQL Server für die Replikation ein, wie unter [Erfassung von Datenänderungen für die laufende Replikation von SQL Server](#CHAP_Source.SQLServer.CDC) beschrieben.

1. Aktivieren Sie MS-REPLICATION in der Quelldatenbank. Dies kann entweder manuell oder durch einmaliges Ausführen der Aufgabe als Sysadmin-Benutzer erfolgen.
**Anmerkung**  
Sie sollten den MS-REPLICATION-Verteiler entweder lokal oder so konfigurieren, dass Benutzer, die keine Systemadministratoren sind, über den zugehörigen Verbindungsserver darauf zugreifen können.

1. Wenn die Option **Nur sp\$1repldone innerhalb eines einzelnen Aufgaben-Endpunkts verwenden** aktiviert ist, beenden Sie den MS-REPLICATION-Protokollleseauftrag.

1. Führen Sie auf jedem Replikat die folgenden Schritte aus:

   1. Erstellen Sie das `[awsdms]`[awsdms]-Schema in der Master-Datenbank:

      ```
      CREATE SCHEMA [awsdms]
      ```

   1. Erstellen Sie die `[awsdms].[split_partition_list]`-Tabellenwertfunktion in der Master-Datenbank:

      ```
      USE [master]
      GO
      
      SET ansi_nulls on
      GO
        
      SET quoted_identifier on
      GO
      
      IF (object_id('[awsdms].[split_partition_list]','TF')) is not null
        DROP FUNCTION [awsdms].[split_partition_list];
      GO
      
      CREATE FUNCTION [awsdms].[split_partition_list] 
      ( 
        @plist varchar(8000),    --A delimited list of partitions    
        @dlm nvarchar(1)    --Delimiting character
      ) 
      RETURNS @partitionsTable table --Table holding the BIGINT values of the string fragments
      (
        pid bigint primary key
      ) 
      AS 
      BEGIN
        DECLARE @partition_id bigint;
        DECLARE @dlm_pos integer;
        DECLARE @dlm_len integer;  
        SET @dlm_len = len(@dlm);
        WHILE (charindex(@dlm,@plist)>0)
        BEGIN 
          SET @dlm_pos = charindex(@dlm,@plist);
          SET @partition_id = cast( ltrim(rtrim(substring(@plist,1,@dlm_pos-1))) as bigint);
          INSERT into @partitionsTable (pid) values (@partition_id)
          SET @plist = substring(@plist,@dlm_pos+@dlm_len,len(@plist));
        END 
        SET @partition_id = cast (ltrim(rtrim(@plist)) as bigint);
        INSERT into @partitionsTable (pid) values (  @partition_id  );
        RETURN
      END
      GO
      ```

   1. Erstellen Sie die `[awsdms].[rtm_dump_dblog]`-Prozedur in der Master-Datenbank:

      ```
      USE [MASTER] 
      GO
      
      IF (object_id('[awsdms].[rtm_dump_dblog]','P')) is not null
        DROP PROCEDURE [awsdms].[rtm_dump_dblog]; 
      GO
      
      SET ansi_nulls on
      GO 
      
      SET quoted_identifier on 
      GO
                                          
      CREATE PROCEDURE [awsdms].[rtm_dump_dblog]
      (
        @start_lsn            varchar(32),
        @seqno                integer,
        @filename             varchar(260),
        @partition_list       varchar(8000), -- A comma delimited list: P1,P2,... Pn
        @programmed_filtering integer,
        @minPartition         bigint,
        @maxPartition         bigint
      ) 
      AS 
      BEGIN
      
        DECLARE @start_lsn_cmp varchar(32); -- Stands against the GT comparator
      
        SET NOCOUNT ON  -- Disable "rows affected display"
      
        SET @start_lsn_cmp = @start_lsn;
        IF (@start_lsn_cmp) is null
          SET @start_lsn_cmp = '00000000:00000000:0000';
      
        IF (@partition_list is null)
          BEGIN
            RAISERROR ('Null partition list was passed',16,1);
            return
            --set @partition_list = '0,';    -- A dummy which is never matched
          END
      
        IF (@start_lsn) is not null
          SET @start_lsn = '0x'+@start_lsn;
      
        IF (@programmed_filtering=0)
          SELECT
            [Current LSN],
            [operation],
            [Context],
            [Transaction ID],
            [Transaction Name],
            [Begin Time],
            [End Time],
            [Flag Bits],
            [PartitionID],
            [Page ID],
            [Slot ID],
            [RowLog Contents 0],
            [Log Record],
            [RowLog Contents 1] -- After Image
          FROM
            fn_dump_dblog (
              @start_lsn, NULL, N'DISK', @seqno, @filename,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default)
          WHERE 
            [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS -- This aims for implementing FN_DBLOG based on GT comparator.
            AND
            (
              (  [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
              OR
              (  [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
                AND
                ( ( [context]   in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX') )
                AND       
                [PartitionID] in ( select * from master.awsdms.split_partition_list (@partition_list,','))
              )
            OR
            ([operation] = 'LOP_HOBT_DDL')
          )
          ELSE
            SELECT
              [Current LSN],
              [operation],
              [Context],
              [Transaction ID],
              [Transaction Name],
              [Begin Time],
              [End Time],
              [Flag Bits],
              [PartitionID],
              [Page ID],
              [Slot ID],
              [RowLog Contents 0],
              [Log Record],
              [RowLog Contents 1] -- After Image
            FROM
              fn_dump_dblog (
                @start_lsn, NULL, N'DISK', @seqno, @filename,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default)
            WHERE [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS -- This aims for implementing FN_DBLOG based on GT comparator.
            AND
            (
              (  [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
              OR
              (  [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
                AND
                ( ( [context]   in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX') )
                AND ([PartitionID] is not null) and ([PartitionID] >= @minPartition and [PartitionID]<=@maxPartition)
              )
              OR
              ([operation] = 'LOP_HOBT_DDL')
            )
            SET NOCOUNT OFF -- Re-enable "rows affected display"
      END
      GO
      ```

   1. Erstellen Sie ein Zertifikat in der Master-Datenbank:

      ```
      USE [master]
      GO
      CREATE CERTIFICATE [awsdms_rtm_dump_dblog_cert]
        ENCRYPTION BY PASSWORD = N'@hardpassword1'
        WITH SUBJECT = N'Certificate for FN_DUMP_DBLOG Permissions'
      ```

   1. Erstellen Sie eine Anmeldung aus dem Zertifikat:

      ```
      USE [master]
      GO
      CREATE LOGIN awsdms_rtm_dump_dblog_login FROM CERTIFICATE
        [awsdms_rtm_dump_dblog_cert];
      ```

   1. Fügen Sie den Anmeldenamen zur Sysadmin-Serverrolle hinzu:

      ```
      ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_dump_dblog_login];
      ```

   1. Fügen Sie die Signatur zur Prozedur [master].[awsdms].[rtm\$1dump\$1dblog] unter Verwendung des Zertifikats hinzu:

      ```
      USE [master]
      GO
      
      ADD SIGNATURE
        TO [master].[awsdms].[rtm_dump_dblog]
        BY CERTIFICATE [awsdms_rtm_dump_dblog_cert]
        WITH PASSWORD = '@hardpassword1';
      ```
**Anmerkung**  
Wenn Sie die gespeicherte Prozedur neu erstellen, müssen Sie die Signatur erneut hinzufügen.

   1. Erstellen Sie die `[awsdms].[rtm_position_1st_timestamp]`-Prozedur in der Master-Datenbank:

      ```
      USE [master]
      IF object_id('[awsdms].[rtm_position_1st_timestamp]','P') is not null
        DROP PROCEDURE [awsdms].[rtm_position_1st_timestamp];
      GO
      CREATE PROCEDURE [awsdms].[rtm_position_1st_timestamp]
      (
        @dbname                sysname,      -- Database name
        @seqno                 integer,      -- Backup set sequence/position number within file
        @filename              varchar(260), -- The backup filename
        @1stTimeStamp          varchar(40)   -- The timestamp to position by
      ) 
      AS 
      BEGIN
        SET NOCOUNT ON       -- Disable "rows affected display"
      
        DECLARE @firstMatching table
        (
          cLsn varchar(32),
          bTim datetime
        )
        DECLARE @sql nvarchar(4000)
        DECLARE @nl                       char(2)
        DECLARE @tb                       char(2)
        DECLARE @fnameVar                 sysname = 'NULL'
      
        SET @nl  = char(10); -- New line
        SET @tb  = char(9)   -- Tab separator
      
        IF (@filename is not null)
          SET @fnameVar = ''''+@filename +''''
        SET @filename = ''''+@filename +''''
        SET @sql='use ['+@dbname+'];'+@nl+
          'SELECT TOP 1 [Current LSN],[Begin Time]'+@nl+
          'FROM fn_dump_dblog (NULL, NULL, NULL, '+ cast(@seqno as varchar(10))+','+ @filename +','+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default)'+@nl+
          'WHERE operation=''LOP_BEGIN_XACT''' +@nl+
          'AND [Begin Time]>= cast('+''''+@1stTimeStamp+''''+' as datetime)'+@nl
      
          --print @sql
          DELETE FROM @firstMatching 
          INSERT INTO @firstMatching  exec sp_executesql @sql    -- Get them all
          SELECT TOP 1 cLsn as [matching LSN],convert(varchar,bTim,121) AS[matching Timestamp] FROM @firstMatching;
      
          SET NOCOUNT OFF      -- Re-enable "rows affected display"
      
      END
      GO
      ```

   1. Erstellen Sie ein Zertifikat in der Master-Datenbank:

      ```
      USE [master]
      GO
      CREATE CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
        ENCRYPTION BY PASSWORD = N'@hardpassword1'
        WITH SUBJECT = N'Certificate for FN_POSITION_1st_TIMESTAMP Permissions';
      ```

   1. Erstellen Sie eine Anmeldung aus dem Zertifikat:

      ```
      USE [master]
      GO
      CREATE LOGIN awsdms_rtm_position_1st_timestamp_login FROM CERTIFICATE
        [awsdms_rtm_position_1st_timestamp_cert];
      ```

   1. Fügen Sie den Anmeldenamen zur Sysadmin-Serverrolle hinzu:

      ```
      ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_position_1st_timestamp_login];
      ```

   1. Fügen Sie der `[master].[awsdms].[rtm_position_1st_timestamp]`-Prozedur mithilfe des Zertifikats die Signatur hinzu:

      ```
      USE [master]
      GO
      ADD SIGNATURE
        TO [master].[awsdms].[rtm_position_1st_timestamp]
        BY CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
        WITH PASSWORD = '@hardpassword1';
      ```
**Anmerkung**  
Wenn Sie die gespeicherte Prozedur neu erstellen, müssen Sie die Signatur erneut hinzufügen.

   1. Erstellen Sie permissions/roles in jeder der folgenden Datenbanken einen Benutzer mit den folgenden Angaben:
**Anmerkung**  
Sie sollten das Benutzerkonto dmsnosysadmin mit derselben SID für jedes Replikat erstellen. Die folgende SQL-Abfrage kann dabei helfen, den SID-Wert des dmsnosysadmin-Kontos auf jedem Replikat zu überprüfen. Weitere Informationen zum Erstellen eines Benutzers finden Sie unter [BENUTZER ERSTELLEN (Transact-SQL)](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql) in der [Microsoft-SQL-Server-Dokumentation](https://learn.microsoft.com/en-us/sql/). Weitere Informationen zum Erstellen von SQL-Benutzerkonten für die Azure-SQL-Datenbank finden Sie unter [Aktive Georeplikation](https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview).

      ```
      SELECT @@servername servername, name, sid, create_date, modify_date
        FROM sys.server_principals
        WHERE name = 'dmsnosysadmin';
      ```

   1. Erteilen Sie für jedes Replikat Berechtigungen für die Master-Datenbank:

      ```
      USE master
      GO 
      
      GRANT select on sys.fn_dblog to dmsnosysadmin;
      GRANT view any definition to dmsnosysadmin;
      GRANT view server state to dmsnosysadmin -- (should be granted to the login).
      GRANT execute on sp_repldone to dmsnosysadmin;
      GRANT execute on sp_replincrementlsn to dmsnosysadmin;
      GRANT execute on sp_addpublication to dmsnosysadmin;
      GRANT execute on sp_addarticle to dmsnosysadmin;
      GRANT execute on sp_articlefilter to dmsnosysadmin;
      GRANT select on [awsdms].[split_partition_list] to dmsnosysadmin;
      GRANT execute on [awsdms].[rtm_dump_dblog] to dmsnosysadmin;
      GRANT execute on [awsdms].[rtm_position_1st_timestamp] to dmsnosysadmin;
      ```

   1. Erteilen Sie für jedes Replikat Berechtigungen für die msdb-Datenbank:

      ```
      USE msdb
      GO
      GRANT select on msdb.dbo.backupset TO self_managed_user
      GRANT select on msdb.dbo.backupmediafamily TO self_managed_user
      GRANT select on msdb.dbo.backupfile TO self_managed_user
      ```

   1. Fügen Sie die `db_owner`-Rolle zu `dmsnosysadmin` in der Quelldatenbank hinzu. Da die Datenbank synchronisiert ist, können Sie die Rolle nur dem primären Replikat hinzufügen.

      ```
      use <source DB>
      GO 
      EXEC sp_addrolemember N'db_owner', N'dmsnosysadmin'
      ```

## Einrichten der laufenden Replikation auf einer SQL-Server-DB-Instance in der Cloud
<a name="CHAP_Source.SQLServer.Configuration"></a>

In diesem Abschnitt wird die Einrichtung von CDC für eine in der Cloud gehostete SQL-Server-Datenbank-Instance beschrieben. Eine in der Cloud gehostete SQL-Server-Instance ist eine Instance, die in Amazon RDS für SQL Server, einer von Azure SQL verwalteten Instance oder einer anderen verwalteten Cloud-SQL-Server-Instance ausgeführt wird. Informationen zu den Einschränkungen der laufenden Replikation für jeden Datenbanktyp finden Sie unter [Einschränkungen bei der Verwendung von SQL Server als Quelle für AWS DMS](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Limitations). 

Bevor Sie die laufende Replikation einrichten, informieren Sie sich unter [Voraussetzungen für die Verwendung der laufenden Replikation (CDC) von einer SQL-Server-Quelle aus](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Prerequisites). 

Im Gegensatz zu selbstverwalteten Microsoft-SQL-Server-Quellen unterstützt Amazon RDS für SQL Server MS-Replication nicht. Daher AWS DMS muss MS-CDC für Tabellen mit oder ohne Primärschlüssel verwendet werden.

Amazon RDS gewährt keine Sysadmin-Rechte für die Einrichtung von Replikationsartefakten, die für laufende Änderungen in einer SQL Server-Quellinstanz AWS DMS verwendet werden. Aktivieren Sie MS-CDC für die Amazon-RDS-Instance (unter Verwendung von Hauptbenutzer-Berechtigungen) wie im folgenden Verfahren gezeigt.

**So aktivieren Sie MS-CDC für eine SQL-Server-DB-Instance in der Cloud**

1. Führen Sie eine der folgenden Abfragen auf Datenbankebene aus.

   Verwenden Sie diese Abfrage für eine DB-Instance von RDS für SQL Server.

   ```
   exec msdb.dbo.rds_cdc_enable_db 'DB_name'
   ```

   Verwenden Sie diese Abfrage für eine von Azure SQL verwaltete DB-Instance.

   ```
   USE DB_name 
   GO 
   EXEC sys.sp_cdc_enable_db 
   GO
   ```

1. Führen Sie die folgende Abfrage für jede Tabelle mit einem Primärschlüssel aus, um MS-CDC zu aktivieren.

   ```
   exec sys.sp_cdc_enable_table
   @source_schema = N'schema_name',
   @source_name = N'table_name',
   @role_name = NULL,
   @supports_net_changes = 1
   GO
   ```

   Führen Sie die folgende Abfrage für jede Tabelle mit eindeutigen Schlüsseln, aber ohne Primärschlüssel aus, um MS-CDC zu aktivieren.

   ```
   exec sys.sp_cdc_enable_table
   @source_schema = N'schema_name',
   @source_name = N'table_name',
   @index_name = N'unique_index_name',
   @role_name = NULL,
   @supports_net_changes = 1
   GO
   ```

    Führen Sie die folgende Abfrage für jede Tabelle ohne Primärschlüssel oder eindeutige Schlüssel aus, um MS-CDC zu aktivieren.

   ```
   exec sys.sp_cdc_enable_table
   @source_schema = N'schema_name',
   @source_name = N'table_name',
   @role_name = NULL
   GO
   ```

1. Legen Sie den Aufbewahrungszeitraum fest:
   + Stellen Sie bei RDS for SQL Server-Instanzen, die mit DMS-Version 3.5.3 und höher replizieren, sicher, dass der Aufbewahrungszeitraum auf den Standardwert von 5 Sekunden festgelegt ist. Wenn Sie ein Upgrade durchführen oder von DMS 3.5.2 und niedriger auf DMS 3.5.3 und höher wechseln, ändern Sie den Wert für das Abfrageintervall, nachdem die Aufgaben auf der neuen oder aktualisierten Instanz ausgeführt wurden. Das folgende Skript legt die Aufbewahrungsdauer auf 5 Sekunden fest:

     ```
     use dbname
     EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 5
     exec sp_cdc_stop_job 'capture'
     exec sp_cdc_start_job 'capture'
     ```
   + Der Parameter `@pollinginterval` wird in Sekunden gemessen, wobei der empfohlene Wert auf 86 399 festgelegt ist. Dies bedeutet, dass das Transaktionsprotokoll Änderungen 86 399 Sekunden (einen Tag) lang speichert, wenn `@pollinginterval = 86399`. Die Prozedur `exec sp_cdc_start_job 'capture'` initiiert die Einstellungen.
**Anmerkung**  
Bei einigen Versionen von SQL Server wird der Wert von `pollinginterval` auf den Standardwert von fünf Sekunden zurückgesetzt, wenn er auf mehr als 3 599 Sekunden festgelegt wurde. In diesem Fall werden T-Log-Einträge gelöscht, bevor sie gelesen werden AWS DMS können. Informationen dazu, welche SQL-Server-Versionen von diesem bekannten Problem betroffen sind, finden Sie in [diesem Microsoft-KB-Artikel](https://support.microsoft.com/en-us/topic/kb4459220-fix-incorrect-results-occur-when-you-convert-pollinginterval-parameter-from-seconds-to-hours-in-sys-sp-cdc-scan-in-sql-server-dac8aefe-b60b-7745-f987-582dda2cfa78).

     Wenn Sie Amazon RDS mit Multi-AZ verwenden, stellen Sie sicher, dass Sie auch Ihre sekundäre Availability Zone so einstellen, dass sie im Falle eines Failovers die richtigen Werte hat.

     ```
     exec rdsadmin..rds_set_configuration 'cdc_capture_pollinginterval' , <5 or preferred value>
     ```

**Um die Aufbewahrungsfrist beizubehalten, wenn eine AWS DMS Replikationsaufgabe für mehr als eine Stunde angehalten wird**
**Anmerkung**  
Die folgenden Schritte sind für eine RDS for SQL Server-Quellreplikation mit DMS 3.5.3 und höher nicht erforderlich.

1. Halten Sie den Auftrag, der die Transaktionsprotokolle kürzt, mit dem folgenden Befehl an. 

   ```
   exec sp_cdc_stop_job 'capture'
   ```

1. Suchen Sie Ihre Aufgabe auf der AWS DMS Konsole und setzen Sie sie fort.

1. Wählen Sie die Registerkarte **Überwachung** und überprüfen Sie die Metrik `CDCLatencySource`. 

1. Wenn die Metrik `CDCLatencySource` gleich 0 (Null) ist und diesen Wert beibehält, starten Sie den Auftrag, der die Transaktionsprotokolle kürzt, mit dem folgenden Befehl neu.

   ```
   exec sp_cdc_start_job 'capture'
   ```

Denken Sie daran, den Auftrag zu starten, der die SQL-Server-Transaktionsprotokolle kürzt. Andernfalls könnte der Speicher auf Ihrer SQL-Server-Instance voll werden.

### Empfohlene Einstellungen bei der Verwendung von RDS für SQL Server als Quelle für AWS DMS
<a name="CHAP_Source.SQLServer.Configuration.Settings"></a>

#### Für AWS DMS 3.5.3 und höher
<a name="CHAP_Source.SQLServer.Configuration.Settings.353"></a>

**Anmerkung**  
Die erste Version der Protokollsicherungsfunktion von RDS für SQL Server ist standardmäßig für Endpoints aktiviert, die Sie nach der Veröffentlichung von DMS-Version 3.5.3 erstellt oder geändert haben. Um diese Funktion für bestehende Endpunkte zu verwenden, ändern Sie den Endpunkt, ohne Änderungen vorzunehmen.

AWS DMS Version 3.5.3 bietet Unterstützung für das Lesen aus Protokollsicherungen. DMS stützt sich hauptsächlich auf das Lesen aus den aktiven Transaktionsprotokollen, um Ereignisse zu replizieren. Wenn eine Transaktion gesichert wird, bevor DMS sie aus dem aktiven Protokoll lesen kann, greift die Task bei Bedarf auf die RDS-Backups zu und liest aus den nachfolgenden Backup-Logs, bis sie das aktive Transaktionslog erreicht. Um sicherzustellen, dass DMS Zugriff auf Protokollsicherungen hat, legen Sie die Aufbewahrungsfrist für automatisierte RDS-Backups auf mindestens einen Tag fest. Informationen zur Einstellung der Aufbewahrungsdauer für automatische [Backup finden Sie unter Aufbewahrungszeitraum](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingAutomatedBackups.html#USER_WorkingWithAutomatedBackups.BackupRetention) für Backups im *Amazon RDS-Benutzerhandbuch*.

Eine DMS-Aufgabe, die auf Protokollsicherungen zugreift, nutzt Speicherplatz auf der RDS-Instance. Beachten Sie, dass die Aufgabe nur auf die für die Replikation benötigten Protokollsicherungen zugreift. Amazon RDS entfernt diese heruntergeladenen Backups innerhalb weniger Stunden. Diese Entfernung hat keine Auswirkungen auf die in Amazon S3 gespeicherten Amazon RDS-Backups oder die Amazon `RESTORE DATABASE` RDS-Funktionalität. Es ist ratsam, zusätzlichen Speicherplatz auf Ihrer RDS-Quelle für SQL Server zuzuweisen, wenn Sie beabsichtigen, mithilfe von DMS zu replizieren. Eine Möglichkeit, den Speicherbedarf abzuschätzen, besteht darin, das Backup zu ermitteln, von dem aus DMS die Replikation beginnen oder fortsetzen wird, und die Dateigrößen aller nachfolgenden Backups mithilfe der RDS-Metadatenfunktion zu addieren. `tlog backup` Weitere Informationen zu dieser `tlog backup` Funktion finden Sie unter [Verfügbare Transaktionsprotokoll-Backups auflisten](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER.SQLServer.AddlFeat.TransactionLogAccess.html#USER.SQLServer.AddlFeat.TransactionLogAccess.Listing) im *Amazon RDS-Benutzerhandbuch*. 

Alternativ können Sie die automatische Speicherskalierung aktivieren und/oder die Speicherskalierung basierend auf der CloudWatch `FreeStorageSpace` Metrik für Ihre Amazon RDS-Instance auslösen.

Wir empfehlen dringend, nicht an einem Punkt zu weit hinten in den Transaktionsprotokoll-Backups zu beginnen oder fortzufahren, da dies dazu führen könnte, dass der Speicherplatz auf Ihrer SQL Server-Instance voll wird. In solchen Fällen ist es ratsam, einen Vollladevorgang zu starten. Das Replizieren aus dem Transaktionslog-Backup ist langsamer als das Lesen aus den aktiven Transaktionslogs. Weitere Informationen finden Sie unter [Verarbeitung von Transaktionsprotokoll-Backups für RDS für SQL Server](CHAP_Troubleshooting_Latency_Source_SQLServer.md#CHAP_Troubleshooting_Latency_Source_SQLServer_backup).

Beachten Sie, dass für den Zugriff auf die Protokollsicherungen zusätzliche Rechte erforderlich sind. Weitere Informationen finden Sie unter [Richten Sie Berechtigungen für die laufende Replikation aus einer Cloud-SQL Server-Datenbank ein](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Permissions.Cloud) Stellen Sie sicher, dass Sie diese Rechte gewähren, bevor die Aufgabe mit der Replikation beginnt.

#### Für AWS DMS 3.5.2 und niedriger
<a name="CHAP_Source.SQLServer.Configuration.Settings.352"></a>

Wenn Sie mit Amazon RDS for SQL Server als Quelle arbeiten, stützt sich der MS-CDC-Erfassungsauftrag auf die Parameter `maxscans` und. `maxtrans` Diese Parameter bestimmen die maximale Anzahl von Scans, die die MS-CDC-Erfassung im Transaktionsprotokoll durchführt, und die Anzahl der Transaktionen, die für jeden Scan verarbeitet werden.

Bei Datenbanken, bei denen die Anzahl der Transaktionen größer als `maxtrans*maxscans` ist, kann eine Erhöhung des Werts `polling_interval` zu einer Anhäufung von aktiven Transaktionsprotokoll-Datensätzen führen. Diese Anhäufung kann wiederum zu einer Vergrößerung des Transaktionsprotokolls führen.

Beachten Sie, dass AWS DMS dies nicht auf den MS-CDC-Erfassungsauftrag angewiesen ist. Der MS-CDC-Erfassungsauftrag kennzeichnet die Transaktionsprotokolleinträge als verarbeitet. Dadurch kann der Backup-Auftrag für das Transaktionsprotokoll die Einträge aus dem Transaktionsprotokoll entfernen.

Es wird empfohlen, die Größe des Transaktionsprotokolls und den Erfolg der MS-CDC-Auftrags zu überwachen. Wenn die MS-CDC-Jobs fehlschlagen, kann das Transaktionsprotokoll übermäßig anwachsen und zu Replikationsfehlern führen. AWS DMS Sie können Fehler bei MS-CDC-Erfassungsaufträgen mithilfe der dynamischen Verwaltungsansicht `sys.dm_cdc_errors` in der Quelldatenbank überwachen. Sie können die Größe des Transaktionsprotokolls mithilfe des Verwaltungsbefehls `DBCC SQLPERF(LOGSPACE)` überwachen.

**So beheben Sie die von MS-CDC verursachte Vergrößerung des Transaktionsprotokolls**

1. Prüfen Sie, aus `Log Space Used %` welcher Datenbank repliziert AWS DMS wird, und stellen Sie sicher, dass sie kontinuierlich wächst.

   ```
   DBCC SQLPERF(LOGSPACE)
   ```

1. Ermitteln Sie, wodurch der Backup-Vorgang des Transaktionsprotokolls blockiert wird.

   ```
   Select log_reuse_wait, log_reuse_wait_desc, name from sys.databases where name = db_name();
   ```

   Wenn der Wert `log_reuse_wait_desc` gleich `REPLICATION` ist, wird die Blockierung des Protokoll-Backups durch die Latenz in MS-CDC verursacht.

1. Erhöhen Sie die Anzahl der vom Erfassungsauftrag verarbeiteten Ereignisse, indem Sie die Parameterwerte `maxtrans` und `maxscans` erhöhen.

   ```
   EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@maxtrans = 5000, @maxscans = 20 
   exec sp_cdc_stop_job 'capture'
   exec sp_cdc_start_job 'capture'
   ```

Um dieses Problem zu beheben, legen Sie die Werte von `maxscans` und `maxtrans` so fest, dass `maxtrans*maxscans` sie der durchschnittlichen Anzahl von Ereignissen entsprechen, die für Tabellen generiert werden, die für jeden Tag aus der Quelldatenbank AWS DMS repliziert werden.

Wenn Sie für diese Parameter einen höheren als den empfohlenen Wert festlegen, verarbeiten die Erfassungsaufträge alle Ereignisse in den Transaktionsprotokollen. Wenn Sie für diese Parameter einen niedrigeren als den empfohlenen Wert festlegen, erhöht sich die MS-CDC-Latenz und das Transaktionsprotokoll wird vergrößert.

Die Ermittlung geeigneter Werte für `maxscans` und `maxtrans` kann schwierig sein, da Änderungen des Workloads zu einer unterschiedlichen Anzahl von Ereignissen führen. In diesem Fall empfehlen wir, Überwachung für die MS-CDC-Latenz einzurichten. Weitere Informationen finden Sie unter [Monitor the process](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/administer-and-monitor-change-data-capture-sql-server?view=sql-server-ver15#Monitor) in der Dokumentation zu SQL Server. Konfigurieren Sie dann `maxtrans` und `maxscans` dynamisch auf Grundlage der Überwachungsergebnisse.

Wenn die AWS DMS Aufgabe nicht in der Lage ist, die für die Fortsetzung oder Fortsetzung der Aufgabe erforderlichen Protokollsequenznummern (LSNs) zu finden, schlägt die Aufgabe möglicherweise fehl und erfordert ein vollständiges Neuladen.

**Anmerkung**  
Wenn Sie Daten aus einer RDS for SQL Server-Quelle replizieren, können Fehler auftreten, wenn Sie versuchen, die Replikation nach einem Stop-Start-Ereignis der Amazon RDS-Instance fortzusetzen. AWS DMS Dies liegt daran, dass der SQL-Server-Agent-Prozess den Erfassungsauftrag neu startet, wenn er nach dem Stopp-Start-Ereignis neu gestartet wird. Dadurch wird das MS-CDC-Abfrageintervall umgangen.  
Aus diesem Grund kann es bei Datenbanken mit einem Transaktionsvolumen, das unter der Verarbeitung des MS-CDC-Erfassungsauftrags liegt, dazu führen, dass Daten verarbeitet oder als repliziert und gesichert markiert werden, bevor sie an der Stelle fortgesetzt werden AWS DMS können, an der sie gestoppt wurden. Dies führt zu dem folgenden Fehler:  

```
[SOURCE_CAPTURE ]E: Failed to access LSN '0000dbd9:0006f9ad:0003' in the backup log sets since BACKUP/LOG-s are not available. [1020465] (sqlserver_endpoint_capture.c:764)
```
Legen Sie die Werte `maxtrans` und `maxscans` wie zuvor empfohlen fest, um dieses Problem zu beheben.