Verwenden einer Microsoft SQL Server-Datenbank als Quelle für AWS DMS - AWS Database Migration Service
Einschränkungen für SQL Server als QuelleSQL-Server-BerechtigungenVoraussetzungen für die Verwendung von laufender CDCErfassen von Änderungen für selbstverwaltete SQL-Server-Quellen (On-Premises oder in Amazon EC2)Einrichten der laufenden Replikation auf einer SQL-Server-DB-Instance in der CloudOptionale Einstellungen für RDS für SQL Server als QuelleUnterstützte KompressionsmethodenArbeiten mit selbstverwalteten SQL Server AlwaysOn-VerfügbarkeitsgruppenAnforderungen an SicherheitEndpunkteinstellungenQuelldatentypen für SQL Server

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

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

Informationen zu Versionen von SQL Server, die als Quelle AWS DMS unterstützt, finden Sie unter Quellen für AWS DMS.

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. Dieses Konto muss über die Berechtigungen view definition und view server state verfügen. Sie fügen diese Berechtigung mit dem folgenden Befehl hinzu:

grant view definition to [user]
grant view server state to [user]

AWS DMS unterstützt die Migration von Daten von benannten Instances 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. Der erste Teil des Namens ist die IP-Adresse des Servers und der zweite Teil ist der Name der SQL Server-Instance (hier "SQLTest").

10.0.0.25\SQLTest

Rufen Sie außerdem die Portnummer ab, die Ihre benannte Instance 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 Instance von SQL Server kennen, 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.

Weitere Informationen zum Arbeiten mit SQL Server-Quelldatenbanken und AWS DMSfinden Sie im Folgenden.

Einschränkungen bei der Verwendung von SQL Server als Quelle für AWS DMS

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 nicht die Verwendung von Tabellen mit Sparse-Spalten.

  • 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 erfasst AWS DMS keine Ereignisse, 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 auf 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 AWS DMS fehl.

    USE [master]
GO 
ALTER SERVER AUDIT [my_audit_test-20140710] WITH (STATE=on)
GO

  • Bei Verwendung von SQL Server als Quelle werden Geometriespalten im vollständigen LOB-Modus nicht unterstützt. 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 non-schema-bound Ansichten und wird nur für Volllastaufgaben unterstützt.

  • Das Umbenennen von Tabellen mit sp_rename wird nicht unterstützt (z. B. sp_rename 'Sales.SalesRegion', 'SalesReg;)

  • Das Umbenennen von Spalten mit sp_rename wird nicht unterstützt (z. B. sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';)

  • AWS DMS unterstützt keine Änderungsverarbeitung zum Festlegen und Aufheben von Spaltenstandardwerten (mit der -ALTER COLUMN SET DEFAULTKlausel mit -ALTER TABLEAnweisungen).

  • AWS DMS unterstützt keine Änderungsverarbeitung zum Festlegen der Spaltenlöschbarkeit (mit der -ALTER COLUMN [SET|DROP] NOT NULLKlausel mit -ALTER TABLEAnweisungen).

  • 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 Zusammenführungs-, bidirektionalen oder peer-to-peer Replikationstopologien verwendet werden.

  • Für partitionierte Tabellen unterstützt keine AWS DMS 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. Beim Replizieren von Tabellen mit räumlichen Datentypen ersetzt die SRID AWS DMS durch die Standard-SRID (0 für GEOMETRY und 4326 für GEOGRAPHY).

  • Wenn Ihre Datenbank nicht für MS-REPLICATION oder MS-CDC konfiguriert ist, können Sie dennoch Tabellen erfassen, die keinen Primärschlüssel haben, es werden aber nur INSERT/DELETE DML-Ereignisse erfasst. 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=Y (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 Kürzungsbefehle.

  • AWS DMS unterstützt keine Replikation aus Datenbanken mit aktivierter beschleunigter Datenbankwiederherstellung (ADR).

  • AWS DMS unterstützt nicht die Erfassung von Data Definition Language (DDL)- und Data Manipulation Language (DML)-Anweisungen innerhalb einer einzigen Transaktion.

  • AWS DMS unterstützt nicht die Replikation von Anwendungspaketen auf Datenebene (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.

  • AWS DMS unterstützt nicht die Replikation von Tabellen und Schemata, wobei der Name ein Sonderzeichen aus dem folgenden Satz enthält.

    \\ -- \n \" \b \r ' \t ;

  • Die 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 pro Tabelle. Dies liegt daran, dass einen SQL Server-Replikationsartikel für jede replizierte Tabelle AWS DMS erstellt und SQL Server-Replikationsartikel diese Einschränkungen haben.

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

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 keine direkte Verarbeitung von Transaktionsprotokoll-Backups auf Dateiebene aus alternativen freigegebenen Ordnern.

Berechtigungen für reine Volllastaufgaben

Die folgenden Berechtigungen sind zum Ausführen reiner Volllastaufgaben erforderlich. Beachten Sie, dass die dms_user Anmeldung AWS DMS nicht erstellt. Informationen zum Erstellen eines Login für SQL Server finden Sie unter Erstellen eines Datenbankbenutzers mit Microsoft SQL Server.

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 ; 
                
                USE master;
                
                GRANT VIEW SERVER STATE TO dms_user;

Voraussetzungen für die Verwendung der laufenden Replikation (CDC) von einer SQL-Server-Quelle aus

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 auf mehrere Dateien über verschiedene Datenträger geschrieben wird, AWS DMS kann die Daten nicht lesen 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 CDC AWS DMS muss SQL Server-Transaktionsprotokoll-Backups nachschlagen, um Änderungen zu lesen. unterstützt AWS DMS keine SQL Server-Transaktionsprotokoll-Backups, die mit Backup-Software von Drittanbietern erstellt wurden, die nicht im nativen 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. Wenn Tabellen zu einer SQL Server-Quelle hinzugefügt werden, AWS DMS verwaltet die Erstellung der Veröffentlichung. 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 Die Erfassung von Änderungsdaten erfordert, dass die vollständige Transaktionsprotokollierung in SQL Server aktiviert ist. 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 Datenänderungen ist standardmäßig eine Verteilungsdatenbank auf Amazon EC2- oder On-Premises-SQL-Servern 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.

Erfassen von Datenänderungen für selbstverwaltete SQL-Server-Quellen (On-Premises oder in Amazon EC2)

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.

Für eine selbstverwaltete SQL Server-Quelle AWS DMS verwendet 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-Quell-Instance Sysadmin-Berechtigungen erteilen. Oder Sie können die Schritte in diesem Abschnitt ausführen, um die Quelle vorzubereiten und einen Benutzer zu verwenden, der keine Sysadmin-Berechtigungen für den AWS DMS Endpunkt hat.

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.

Einrichten der laufenden Replikation auf einer selbstverwalteten SQL-Server-Quelle

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

Einrichten der laufenden Replikation auf einer selbstverwalteten SQL-Server-Quelle: Verwenden der Sysadmin-Rolle

AWS DMS Die laufende Replikation für SQL Server verwendet die native SQL Server-Replikation für Tabellen mit Primärschlüsseln und die Erfassung von Datenänderungen (Change Data Capture, CDC) für Tabellen ohne Primärschlüssel.

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.

Für Tabellen mit Primärschlüsseln AWS DMS kann im Allgemeinen die erforderlichen Artefakte für die Quelle konfigurieren. 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-Berechtigung die Veröffentlichung für Tabellen mit Primärschlüsseln automatisch 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.

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.

  2. Ö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.

  3. Befolgen Sie die Anweisungen im Assistenten, um die Standardwerte einzugeben und die Verteilung zu erstellen.

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. Weitere Informationen zu ECAs finden Sie unter Endpunkteinstellungen.

Führen Sie für Versionen AWS DMS vor 3.4.7 oder für ein schreibgeschütztes Replikat als Quelle die folgenden Schritte aus:

  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

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

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

Einrichten der laufenden Replikation auf einer eigenständigen SQL-Server-Quelle: Ohne Sysadmin-Rolle

Informationen zum Einrichten der laufenden Replikation auf einer eigenständigen SQL-Server-Quelle ohne die Sysadmin-Rolle finden Sie unter Einrichtung der fortlaufenden Replikation auf einem eigenständigen SQL Server: Ohne Sysadmin-Rolle.

Einrichten der laufenden Replikation auf einer SQL-Server-DB-Instance in der Cloud

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.

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.

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

Amazon RDS gewährt keine Sysadmin-Berechtigungen zum Festlegen von Replikationsartefakten, die für laufende Änderungen in einer Quell-SQL-Server-Instance AWS DMS verwendet. 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

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

  3. Stellen Sie mit dem folgenden Befehl den Aufbewahrungszeitraum für Änderungen ein, die in der Quelle verfügbar sein sollen.

    use dbname
EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 86399
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-Protokolleinträge gelöscht, bevor sie lesen AWS DMS kann. Informationen dazu, welche SQL-Server-Versionen von diesem bekannten Problem betroffen sind, finden Sie in diesem Microsoft-KB-Artikel.

    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' , 86399

Wenn eine AWS DMS Replikationsaufgabe, die laufende Änderungen an Ihrer SQL Server-Quelle erfasst, länger als eine Stunde anhält, gehen Sie wie folgt vor.

So behalten Sie den Aufbewahrungszeitraum während einer AWS DMS Replikationsaufgabe bei

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

    exec sp_cdc_stop_job 'capture'

  2. Suchen Sie Ihre Aufgabe in der AWS DMS Konsole und setzen Sie die Aufgabe fort.

  3. Wählen Sie die Registerkarte Überwachung und überprüfen Sie die Metrik CDCLatencySource.

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

Einschränkungen bei der laufenden Replikation auf einer SQL-Server-DB-Instance in der Cloud

  • AWS DMS unterstützt die fortlaufende Replikation (CDC) nur mit dem aktiven Transaktionsprotokoll. Sie können nicht das Backup-Protokoll für CDC verwenden.

  • Ereignisse gehen möglicherweise verloren, wenn Sie sie aus dem aktiven Transaktionsprotokoll in das Backup-Protokoll verschieben oder sie im aktiven Transaktionsprotokoll kürzen.

Empfohlene Einstellungen bei Verwendung von Amazon RDS für SQL Server als Quelle für AWS DMS

Wenn Sie mit Amazon RDS für SQL Server als Quelle arbeiten, stützt sich der Erfassungsauftrag auf die Parameter maxscans und maxtrans. Diese Parameter bestimmen die maximale Anzahl von Scans, die bei der Erfassung im Transaktionsprotokoll durchgeführt werden, 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 nicht auf dem MS-CDC-Erfassungsauftrag basiert. 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-Aufträge fehlschlagen, könnte das Transaktionsprotokoll übermäßig wachsen und AWS DMS zu Replikationsfehlern führen. 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. Überprüfen Sie die Log Space Used % für die Datenbank, die aus repliziert AWS DMS wird, und überprüfen Sie, ob sie kontinuierlich zunimmt.

    DBCC SQLPERF(LOGSPACE)

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

  3. 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 der durchschnittlichen Anzahl von Ereignissen maxtrans*maxscans entspricht, 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 in der Dokumentation zu SQL Server. Konfigurieren Sie dann maxtrans und maxscans dynamisch auf Grundlage der Überwachungsergebnisse.

Wenn die AWS DMS Aufgabe die Protokollsequenznummern (LSNs ) nicht finden kann, die zum Fortsetzen oder Fortsetzen der Aufgabe erforderlich sind, schlägt die Aufgabe möglicherweise fehl und erfordert einen vollständigen erneuten Ladevorgang.

Anmerkung

Wenn Sie verwenden, AWS DMS um Daten aus einer RDS-für-SQL-Server-Quelle zu replizieren, können Fehler auftreten, wenn Sie versuchen, die Replikation nach einem Stopp-Start-Ereignis der Amazon-RDS-Instance fortzusetzen. 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 dies bei Datenbanken mit Transaktionsvolumen, die niedriger als die MS-CDC-Erfassungsauftragsverarbeitung sind, dazu führen, dass Daten verarbeitet oder als repliziert markiert und gesichert werden, bevor von dort aus fortgesetzt werden AWS DMS kann, wo es gestoppt wurde, was zu folgendem Fehler führt:

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

Unterstützte Komprimierungsmethoden für SQL Server

Beachten Sie in Bezug auf die Unterstützung von SQL-Server-Komprimierungsmethoden in AWS DMS Folgendes:

  • AWS DMS unterstützt die Zeilen-/Seitenkomprimierung in SQL Server Version 2008 und höher.

  • AWS DMS unterstützt das Vardecimal-Speicherformat nicht.

  • AWS DMS unterstützt keine Sparse-Spalten und spaltenweise Strukturkomprimierung.

Arbeiten mit selbstverwalteten SQL Server AlwaysOn-Verfügbarkeitsgruppen

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

In können AWS DMSSie Änderungen von einem einzelnen Replikat einer primären oder sekundären Verfügbarkeitsgruppe migrieren.

Arbeiten mit dem Replikat der primären Verfügbarkeitsgruppe

Gehen Sie wie folgt vor AWS DMS, um die primäre Verfügbarkeitsgruppe als Quelle in 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.

  2. Öffnen Sie in der - AWS DMS Konsole die SQL Server-Quelldatenbankeinstellungen. 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

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

  1. Verwenden Sie dieselben Anmeldeinformationen für die Verbindung mit einzelnen Replikaten wie die des AWS DMS Quellendpunktbenutzers.

  2. Stellen Sie sicher, dass Ihre AWS DMS Replikations-Instance DNS-Namen für alle vorhandenen Replikate auflösen kann, und stellen Sie eine Verbindung zu ihnen her. 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>';

  3. 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? 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.

  4. Fügen Sie Ihrem Quellendpunkt die folgenden zusätzlichen Verbindungsattribute hinzu.

    Zusätzliches Verbindungsattribut Wert Hinweise
    applicationIntent ReadOnly Ohne diese ODBC-Einstellung wird die Replikationsaufgabe an das Replikat der primären Verfügbarkeitsgruppe weitergeleitet. Weitere Informationen finden Sie unter SQL Server Native Client Support for High Availability, Disaster Recovery in der Dokumentation zu SQL Server.
    multiSubnetFailover yes Weitere Informationen finden Sie unter SQL Server Native Client Support for High Availability, Disaster Recovery in der Dokumentation zu SQL Server.
    alwaysOnSharedSynchedBackupIsEnabled false Weitere Informationen finden Sie unter Endpunkteinstellungen bei Verwendung von SQL Server als Quelle für AWS DMS.
    activateSafeguard false Weitere Informationen finden Sie unter Einschränkungen.
    setUpMsCdcForTables false Weitere Informationen finden Sie unter Einschränkungen.

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

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

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

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

  • AWS DMS kann ab Version 3.4.7 ein selbstverwaltetes sekundäres Verfügbarkeitsgruppenreplikat als Quelldatenbank für die fortlaufende Replikation (Erfassung von Datenänderungen oder CDC) verwenden. Multi-AZ-Lesereplikate in Cloud SQL Server werden nicht unterstützt. Wenn Sie frühere Versionen von verwenden AWS DMS, stellen Sie sicher, dass Sie das Replikat der primären Verfügbarkeitsgruppe als Quelldatenbank für CDC verwenden.

Failover auf andere Knoten

Wenn Sie das ApplicationIntent zusätzliche Verbindungsattribut für Ihren Endpunkt auf festlegenReadOnly, stellt Ihre AWS DMS Aufgabe eine Verbindung zum schreibgeschützten Knoten mit der höchsten schreibgeschützten 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 nicht festlegenApplicationIntent, stellt Ihre AWS DMS Aufgabe nur eine Verbindung zum primären (Lese-/Schreib-)Knoten in Ihrer Verfügbarkeitsgruppe her.

Sicherheitsanforderungen bei Verwendung von SQL Server als Quelle für AWS Database Migration Service

Das AWS DMS Benutzerkonto muss mindestens über die db_owner Benutzerrolle in der SQL Server-Quelldatenbank verfügen, mit der Sie eine Verbindung herstellen.

Endpunkteinstellungen bei Verwendung von SQL Server als Quelle für AWS DMS

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-endpointBefehls in der AWS CLImit 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.

Name Beschreibung

ActivateSafeguard

Dieses Attribut aktiviert oder deaktiviert Safeguard. Weitere Informationen zu Safeguard finden Sie im Folgenden unter SafeguardPolicy.

Standardwert: true

Zulässige Werte: {false, true}

Beispiel: '{"ActivateSafeguard": true}'
AlwaysOnSharedSynchedBackupIsEnabled

Dieses Attribut passt das Verhalten von AWS DMS bei der Migration von einer SQL Server-Quelldatenbank an, die als Teil eines AlwaysOn-Verfügbarkeitsgruppen-Clusters gehostet wird.

AWS DMS bietet erweiterte Unterstützung für SQL Server-Quelldatenbanken, die für die Ausführung in einem AlwaysOn-Cluster konfiguriert sind. In diesem Fall versucht AWS DMS nachzuverfolgen, ob Transaktions-Backups von anderen Knoten im AlwaysOn-Cluster als dem Knoten, auf dem die Quelldatenbank-Instance gehostet wird, ausgeführt werden. Beim Start der Migrationsaufgabe AWS DMS versucht , eine Verbindung zu jedem Knoten im Cluster herzustellen, schlägt jedoch fehl, wenn keine Verbindung zu einem der Knoten hergestellt werden kann.

Wenn Sie alle Knoten im AlwaysOn-Cluster nach Transaktionssicherungen AWS DMS abfragen müssen, setzen Sie dieses Attribut auf false.

Standardwert: true

Gültige Werte: true oder false.

Beispiel: '{"AlwaysOnSharedSynchedBackupIsEnabled": false}'

"ApplicationIntent": "readonly"

Diese Einstellung des ODBC-Treiberattributs veranlasst SQL Server, Ihre Replikationsaufgabe an den schreibgeschützten Knoten mit der höchsten Priorität weiterzuleiten. Ohne diese Einstellung leitet SQL Server Ihre Replikationsaufgabe an den primären Lese-/Schreibknoten weiter.

EnableNonSysadminWrapper

Verwenden Sie diese Endpunkteinstellung, wenn Sie die laufende Replikation auf einer eigenständigen SQL-Server-Quelle ohne Sysadmin-Benutzer einrichten. Dieser Parameter wird auf AWS DMS Version 3.4.7 und höher unterstützt. Informationen zum Einrichten der laufenden Replikation auf einer eigenständigen SQL-Server-Quelle finden Sie unter Einrichten der laufenden Replikation auf einer eigenständigen SQL-Server-Quelle: Ohne Sysadmin-Rolle.

Standardwert: false

Zulässige Werte: true, false

Beispiel: '{"EnableNonSysadminWrapper": true}'

ExecuteTimeout

Verwenden Sie dieses zusätzliche Verbindungsattribut (Extra Connection Attribute, ECA), um das Timeout für die Client-Anweisung für die SQL-Server-Instance in Sekunden festzulegen. Der Standardwert liegt bei 60 Sekunden.

Beispiel: '{"ExecuteTimeout": 100}'

FatalOnSimpleModel

Ist diese Einstellung auf true gesetzt, wird ein schwerwiegenden Fehler generiert, wenn das Wiederherstellungsmodell für SQL-Server-Datenbanken auf simple festgelegt wird.

Standardwert: false

Gültige Werte: true oder false.

Beispiel: '{"FatalOnSimpleModel": true}'

ForceLobLookup

Erzwingt LOB-Lookup bei Inline-LOB.

Standardwert: false

Zulässige Werte: true, false

Beispiel: '{"ForceLobLookup": false}'

"MultiSubnetFailover": "Yes"

Durch dieses ODBC-Treiberattribut kann DMS im Falle eines Failovers der Verfügbarkeitsgruppen eine Verbindung zur neuen primären Verfügbarkeitsgruppe herstellen. Dieses Attribut ist für Situationen konzipiert, in denen die Verbindung unterbrochen wird oder die Listener-IP-Adresse falsch ist. In diesen Situationen AWS DMS versucht , eine Verbindung zu allen IP-Adressen herzustellen, die dem Availability Group Listener zugeordnet sind.

ReadBackupOnly

Für die Verwendung dieses Attributs sind Sysadmin-Berechtigungen erforderlich. Wenn dieses Attribut auf gesetzt istY, AWS DMS werden während der laufenden Replikation nur Änderungen aus Transaktionsprotokoll-Backups gelesen und nicht aus der aktiven Transaktionsprotokolldatei gelesen. Wenn Sie diesen Parameter auf Y festlegen, können Sie steuern, wie stark die aktive Transaktionsprotokolldatei beim vollständigen Laden und fortlaufenden Replikationsaufgaben wächst. Dies kann bei fortlaufender Replikation jedoch zu einer gewissen Quelllatenz führen.

Gültige Werte: N oder Y. Der Standardwert ist N.

Beispiel: '{"ReadBackupOnly": Y}'

Hinweis: Aufgrund der Art und Weise, wie RDS Backups durchführt, funktioniert dieser Parameter nicht auf Quell-Instances von Amazon RDS SQL Server.

SafeguardPolicy

Für eine optimale Leistung AWS DMS versucht , alle ungelesenen Änderungen aus dem aktiven Transaktionsprotokoll (TLOG) zu erfassen. Manchmal enthält das aktive TLOG jedoch aufgrund von Kürzungen nicht alle ungelesenen Änderungen. In diesem Fall greift AWS DMS auf das Protokoll-Backup zu, um die fehlenden Änderungen zu erfassen. Um die Notwendigkeit für den Zugriff auf das Protokoll-Backup zu minimieren, AWS DMS vermeidet das Kürzen mit einer der folgenden Methoden:

  1. RELY_ON_SQL_SERVER_REPLICATION_AGENT (Transaktionen in der Datenbank starten): Dies ist die Standardeinstellung für AWS DMS.

    Wenn Sie diese Einstellung verwenden, erfordert AWS DMS die Ausführung des SQL Server Log Reader Agent, damit AWS DMS für die Replikation markierte Transaktionen aus dem aktiven TLOG verschieben kann. Beachten Sie, dass das aktive TLOG voll werden kann, wenn der Log Reader Agent nicht ausgeführt wird. In diesem Fall wechselt die Quelldatenbank in den schreibgeschützten Modus, bis das Problem behoben wurde. Wenn Sie Microsoft Replication in Ihrer Datenbank für einen anderen Zweck als aktivieren müssen AWS DMS, müssen Sie diese Einstellung auswählen.

    Wenn Sie diese Einstellung verwenden, AWS DMS minimiert Protokoll-Backup-Lesevorgänge, indem eine Tabelle mit dem Namen erstellt wird, awsdms_truncation_safeguard und verhindert die TLOG-Kürzung, indem eine offene Transaktion in der Datenbank nachgeahmt wird. Dadurch wird verhindert, dass die Datenbank Ereignisse kürzt und sie fünf Minuten lang in das Backup-Protokoll verschiebt (standardmäßig). Stellen Sie sicher, dass die Tabelle in keinem Wartungsplan enthalten ist, da der Wartungsauftrag andernfalls möglicherweise fehlschlägt. Sie können die Tabelle problemlos löschen, wenn keine Aufgaben mit der Datenbankoption Start Transactions konfiguriert sind.

  2. EXCLUSIVE_AUTOMATIC_TRUNCATION (Ausschließlich sp_repldone mit einer einzelnen Aufgabe verwenden): Wenn Sie diese Einstellung verwenden, AWS DMS hat die volle Kontrolle über den Replikationsagentenprozess, der Protokolleinträge als ready for truncation verwendend markiertsp_repldone. Bei dieser Einstellung verwendet keine Dummy AWS DMS -Transaktion wie bei der RELY_ON_SQL_SERVER_REPLICATION_AGENT (Standard)-Einstellung. Sie können diese Einstellung nur verwenden, wenn MS Replication nur für AWS DMS die Quelldatenbank verwendet wird. Wenn Sie diese Einstellung verwenden, kann nur eine AWS DMS Aufgabe auf die Datenbank zugreifen. Wenn Sie parallele AWS DMS Aufgaben für dieselbe Datenbank ausführen müssen, verwenden Sie RELY_ON_SQL_SERVER_REPLICATION_AGENT.

    • Diese Einstellung erfordert, dass der Log Reader Agent in der Datenbank beendet wird. Wenn der Log Reader Agent ausgeführt wird, wenn die Aufgabe gestartet wird, erzwingt die AWS DMS Aufgabe das Beenden. Sie können den Log Reader Agent auch manuell beenden, bevor Sie die Aufgabe starten.

    • Wenn Sie diese Methode mit MS-CDC verwenden, sollten Sie die Aufträge zur MS-CDC-Erfassung und MS-CDC-Bereinigung beenden und deaktivieren.

    • Sie können diese Einstellung nicht verwenden, wenn der Microsoft SQL Server-Migrationsauftrag auf einem Remote-Distributor-Computer ausgeführt AWS DMS wird, da keinen Zugriff auf den Remote-Computer hat.

    • EXCLUSIVE_AUTOMATIC_TRUNCATION funktioniert auf Quell-Instances in Amazon RDS für SQL Server nicht, da Amazon-RDS-Benutzer keinen Zugriff zum Ausführen des gespeicherten Verfahrens sp_repldone haben.

    • Wenn Sie SafeguardPolicy auf EXCLUSIVE_AUTOMATIC_TRUNCATION setzen, ohne die Sysadmin-Rolle zu verwenden, müssen Sie dem Benutzer dmsuser Berechtigungen für die Objekte dbo.syscategories und dbo.sysjobs erteilen.

Standardwert: RELY_ON_SQL_SERVER_REPLICATION_AGENT

Zulässige Werte: {EXCLUSIVE_AUTOMATIC_TRUNCATION, RELY_ON_SQL_SERVER_REPLICATION_AGENT}

Beispiel: '{"SafeguardPolicy": "EXCLUSIVE_AUTOMATIC_TRUNCATION"}'

SetUpMsCdcForTables

Dieses Attribut aktiviert MS-CDC für die Quelldatenbank und für Tabellen in der Aufgabenzuordnung, für die MS-Replication nicht aktiviert ist. Wenn Sie diesen Wert auf true setzen, wird die gespeicherte Prozedur sp_cdc_enable_db in der Quelldatenbank und die gespeicherte Prozedur sp_cdc_enable_table für jede Tabelle in der Aufgabe ausgeführt, für die MS-Replication in der Quelldatenbank nicht aktiviert ist. Weitere Informationen zum Aktivieren der Verteilung finden Sie unter Einrichten der laufenden Replikation auf einer selbstverwalteten SQL-Server-Quelle.

Zulässige Werte: {true, false}

Beispiel: '{"SetUpMsCdcForTables": true}'

TlogAccessMode

Gibt den Modus an, der zum Abrufen von CDC-Daten verwendet wird.

Standardwert: PreferTlog

Zulässige Werte: BackupOnly, PreferBackup, PreferTlog, TlogOnly

Beispiel: '{"TlogAccessMode": "PreferTlog"}'

Use3rdPartyBackupDevice

Wenn dieses Attribut auf Y gesetzt ist, verarbeitet AWS DMS Transaktionsprotokoll-Backups von Drittanbietern, falls sie im nativen Format erstellt wurden.

Quelldatentypen für SQL Server

Datenmigration, die SQL Server als Quelle für verwendet, AWS DMS unterstützt die meisten SQL Server-Datentypen. Die folgende Tabelle zeigt die SQL Server-Quelldatentypen, die bei der Verwendung von unterstützt werden, AWS DMS und die Standardzuordnung 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.

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

DATUM

DATUM

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.

AWS DMS Aktualisiert für SQL-Server-Tabellen LOB-Spalten im Ziel auch für UPDATE-Anweisungen, die den Wert der LOB-Spalte in SQL Server nicht ändern.

Während CDC AWS DMS unterstützt 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.

AWS DMS Aktualisiert für SQL-Server-Tabellen LOB-Spalten im Ziel auch für UPDATE-Anweisungen, die den Wert der LOB-Spalte in SQL Server nicht ändern.

Während CDC AWS DMS unterstützt CLOB-Datentypen nur in Tabellen, die einen Primärschlüssel enthalten.

BINARY

BYTES

VARBINARY

BYTES

VARBINARY (max)

BLOB

IMAGE

AWS DMS Aktualisiert für SQL-Server-Tabellen 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 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 für SQL-Server-Tabellen 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.

Während CDC AWS DMS unterstützt 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_VARIANT

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