View a markdown version of this page

Verwenden einer Microsoft SQL Server-Datenbank als Quelle für AWS DMS - AWS Datenbankmigrationsdienst

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

Hinweise zu Versionen von SQL Server, die als Quelle AWS DMS unterstützt werden, finden Sie unterQuellen 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. Weitere Informationen finden Sie unter Berechtigungen für SQL Server-Aufgaben.

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

Ermitteln Sie außerdem die Portnummer, auf der Ihre benannte Instanz von SQL Server lauscht, 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.

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

Weitere Informationen zur Arbeit mit SQL Server-Quelldatenbanken und AWS DMS finden 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 spärlichen 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.

  • Wenn Sie die Dienstprogramme WRITETEXT und UPDATETEXT verwenden, 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 Prüfungen 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
  • Geometry- und Geography-Spalten 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 und nicht schemagebundenen Ansichten wird für reine 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 Setzen und Aufheben von Spaltenstandardwerten (unter Verwendung der ALTER COLUMN SET DEFAULT Klausel mit ALTER TABLE Anweisungen).

  • AWS DMS unterstützt keine Änderungsverarbeitung, um die Nullwertfähigkeit von Spalten festzulegen (unter 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 die Platzierung der Verteilungsdatenbank in einer Verfügbarkeitsgruppe, mit Ausnahme von Verteilungsdatenbanken, die in Merge-, bidirektionalen oder Peer-to-Peer-Replikationstopologien verwendet werden.

  • Unterstützt für partitionierte 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-REPLICATION oder konfiguriert ist MS-CDC, können Sie trotzdem Tabellen erfassen, die keinen Primärschlüssel haben, aber es werden nur INSERT/DELETE DML-Ereignisse erfasst. Die Ereignisse UPDATE und TRUNCATE TABLE werden ignoriert.

  • Columnstore-Indizes werden nicht unterstützt.

  • Memory-optimized Tabellen (mit 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 zum Abschneiden.

  • AWS DMS unterstützt keine Replikation aus Datenbanken, bei denen die beschleunigte Datenbankwiederherstellung (ADR) aktiviert ist.

  • AWS DMS unterstützt nicht das Erfassen von DDL- (Data Definition Language) - und DML-Anweisungen (Data Manipulation Language) innerhalb einer einzelnen 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 Schemas, deren 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. Dies liegt daran, dass für jede replizierte Tabelle ein SQL Server-Replikationsartikel AWS DMS erstellt wird und SQL Server-Replikationsartikel diese Einschränkungen aufweisen.

  • 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 aus dem aktiven Transaktionsprotokoll in das Sicherungsprotokoll archiviert oder sie aus dem aktiven Transaktionsprotokoll abschneidet.

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 Transaktionsprotokollsicherungen auf Dateiebene aus alternativen gemeinsamen Ordnern.

  • AWS DMS Unterstützt für andere Cloud SQL Server-Quellen als Amazon RDS für Microsoft SQL Server die fortlaufende Replikation (CDC) nur mit dem aktiven Transaktionslog. Sie können nicht das Backup-Protokoll für CDC verwenden. Sie können Ereignisse verlieren, wenn der SQL-Server sie aus dem aktiven Transaktionslog in das Backup-Log archiviert oder sie aus dem aktiven Transaktionslog abschneidet, bevor DMS es lesen kann.

  • Für Amazon RDS für Microsoft SQL Server-Quellen unterstützt AWS DMS 3.5.2 und niedriger die fortlaufende Replikation (CDC) nur mit dem aktiven Transaktionslog, da DMS mit CDC nicht auf das Backup-Log zugreifen kann. Sie können Ereignisse verlieren, wenn RDS für SQL Server sie aus dem aktiven Transaktionslog in das Backup-Log archiviert oder sie aus dem aktiven Transaktionslog abschneidet, bevor DMS es 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 Volllast-Aufgabe nicht verfügbar ist, wird die Aufgabe AWS DMS möglicherweise nach mehreren Wiederverbindungsversuchen als abgeschlossen markiert, obwohl die Datenmigration unvollständig bleibt. In diesem Szenario enthalten die Zieltabellen nur die Datensätze, die vor dem Verbindungsverlust migriert wurden, wodurch möglicherweise Dateninkonsistenzen zwischen Quell- und Zielsystem entstehen. Um die Vollständigkeit der Daten sicherzustellen, müssen Sie entweder die Vollladeaufgabe vollständig neu starten oder die spezifischen Tabellen, die von der Verbindungsunterbrechung betroffen sind, neu laden.

Berechtigungen für SQL Server-Aufgaben

Berechtigungen für reine Volllastaufgaben

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

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

Self-managed SQL Server-Instanzen können für die fortlaufende Replikation mithilfe von DMS mit oder ohne Verwendung der sysadmin Rolle konfiguriert werden. Stellen Sie für SQL Server-Instanzen, denen Sie die sysadmin Rolle nicht zuweisen können, sicher, dass der DMS-Benutzer über die im Folgenden beschriebenen Rechte verfügt.

Richten Sie Berechtigungen für die fortlaufende 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 beschriebenBerechtigungen für reine Volllastaufgaben, beispielsweise unter. self_managed_user

  2. 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;
  3. Zusätzlich zu den oben genannten Berechtigungen benötigt der Benutzer eine der folgenden Berechtigungen:

Richten Sie Berechtigungen für die fortlaufende Replikation aus einer Cloud-SQL Server-Datenbank ein

Eine in der Cloud gehostete SQL-Server-Instanz ist eine Instanz, die auf Amazon RDS für Microsoft SQL Server, eine von Azure SQL verwaltete Instanz oder eine andere verwaltete Cloud-SQL-Server-Instanz, die von DMS unterstützt wird, ausgeführt wird.

Erstellen Sie ein neues SQL Server-Konto mit Kennwortauthentifizierung mithilfe von SQL Server Management Studio (SSMS) oder wie zuvor Berechtigungen für reine Volllastaufgaben beispielsweise unter beschrieben. rds_user

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

GRANT VIEW SERVER STATE TO rds_user;

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

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

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.

  • Bei CDC AWS DMS muss nach den Sicherungskopien des SQL Server-Transaktionsprotokolls gesucht werden, um die Änderungen zu lesen. 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. Wenn Tabellen zu einer SQL Server-Quelle hinzugefügt werden, AWS DMS verwaltet das Erstellen der Publikation. 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, aktivieren MS-REPLICATION oder ÄNDERN Sie DATA CAPTURE (CDC).

  • 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 Change Data Capture ist standardmäßig eine Verteilungsdatenbank auf Amazon EC2 oder On-Prem 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

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 die Komprimierung von Spaltenstrukturen.

Arbeiten mit selbstverwalteten SQL Server-Verfügbarkeitsgruppen AlwaysOn

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

Um die primäre Verfügbarkeitsgruppe als Quelle zu verwenden in AWS DMS wie folgt:
  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 Einstellungen der 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

Um eine sekundäre Verfügbarkeitsgruppe als Quelle zu verwenden in AWS DMS wie folgt:
  1. Verwenden Sie für die Verbindung mit einzelnen Replikaten dieselben Anmeldeinformationen wie die, die der AWS DMS Quellendpunktbenutzer verwendet.

  2. Stellen Sie sicher, dass Ihre AWS DMS Replikationsinstanz die 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 ein selbstverwaltetes sekundäres Verfügbarkeitsgruppenreplikat als Quelldatenbank für die laufende Replikation (Change Data Capture oder CDC) ab Version 3.4.7 verwenden. Cloud SQL Multi-AZ Server-Lesepliken werden nicht unterstützt. Wenn Sie frühere Versionen von verwenden AWS DMS, stellen Sie sicher, dass Sie das primäre Verfügbarkeitsgruppenreplikat 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 Task eine Verbindung zu dem 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 dies nicht festlegenApplicationIntent, stellt Ihre AWS DMS Aufgabe nur eine Verbindung zum primären Knoten (read/write) in Ihrer Verfügbarkeitsgruppe her.

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 erstellen, oder indem Sie den create-endpoint Befehl in der AWS CLI mit der --microsoft-sql-server-settings '{"EndpointSetting": "value", ...}' JSON-Syntax verwenden.

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

Name Description

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 AWS DMS bei der Migration von einer SQL Server-Quelldatenbank an, die als Teil eines Always-On-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. AWS DMS Versucht beim Start der Migrationsaufgabe, 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 Always-On-Cluster AWS DMS nach Transaktionssicherungen abfragen müssen, setzen Sie dieses Attribut auffalse.

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.

ConnectionTimeout

Verwenden Sie dieses zusätzliche Verbindungsattribut (ECA), um das Endpunkt-Verbindungstimeout für die SQL Server-Instanz in Sekunden festzulegen. Der Standardwert liegt bei 10 Sekunden. ECA-Beispiel:ConnectionTimeout=30.

EnableNonSysadminWrapper

Verwenden Sie diese Endpunkteinstellung, wenn Sie die laufende Replikation auf einer eigenständigen SQL-Server-Quelle ohne Sysadmin-Benutzer einrichten. Dieser Parameter wird in 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 Erfassung von Datenänderungen für die laufende Replikation von SQL Server.

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 wird 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 true gesetzt ist, liest AWS DMS während der laufenden Replikation nur Änderungen aus Backups des Transaktionsprotokolls und nicht aus der aktiven Transaktionsprotokolldatei. Wenn Sie diesen Parameter auf true 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: true oder true. Der Standardwert ist false.

Beispiel: '{"ReadBackupOnly": true}'

Anmerkung

Dieser Parameter funktioniert aufgrund der Art und Weise, wie RDS Backups durchführt, nicht auf Amazon RDS SQL Server-Quell-Instances.

SafeguardPolicy

AWS DMS Versucht, alle ungelesenen Änderungen aus dem aktiven Transaktionslog (TLOG) zu erfassen, um eine optimale Leistung zu erzielen. Manchmal enthält das aktive TLOG jedoch aufgrund von Kürzungen nicht alle ungelesenen Änderungen. AWS DMS Greift in diesem Fall auf die Protokollsicherung zu, um die fehlenden Änderungen zu erfassen. Um den Zugriff auf die Protokollsicherung so gering wie möglich zu halten, AWS DMS wird das Kürzen mithilfe einer der folgenden Methoden verhindert:

  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 wählen.

    Wenn Sie diese Einstellung verwenden, wird das Lesen von Log-Backups AWS DMS minimiert, 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 er die volle Kontrolle über den Replikations-Agent-Prozess, der Logeinträge als verwendet markiert. ready for truncation sp_repldone Bei dieser Einstellung wird AWS DMS keine Dummy-Transaktion wie bei der RELY_ON_SQL_SERVER_REPLICATION_AGENT (Standard-) Einstellung verwendet. Sie können diese Einstellung nur verwenden, wenn MS Replication für keinen anderen Zweck als AWS DMS für die Quelldatenbank verwendet wird. Wenn Sie diese Einstellung verwenden, kann außerdem nur eine AWS DMS Aufgabe auf die Datenbank zugreifen. Wenn Sie parallele AWS DMS Aufgaben für dieselbe Datenbank ausführen müssen, verwenden SieRELY_ON_SQL_SERVER_REPLICATION_AGENT.

    • Diese Einstellung erfordert, dass der Log Reader Agent in der Datenbank beendet wird. Wenn der Log Reader Agent läuft, wenn die Aufgabe gestartet wird, erzwingt die AWS DMS Task ihr Beenden. Sie können den Log Reader Agent auch manuell beenden, bevor Sie die Aufgabe starten.

    • Wenn Sie diese Methode mit verwenden MS-CDC, sollten Sie die MS-CDC Aufzeichnungs- und MS-CDC Bereinigungsaufträge beenden und deaktivieren.

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

    • 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 wird MS-CDC für die Quelldatenbank und für Tabellen in der Task-Zuordnung aktiviert, die nicht MS-Replication aktiviert sind. Wenn Sie diesen Wert so einstellen, dass die sp_cdc_enable_db gespeicherte Prozedur in der Quelldatenbank ausgeführt wird, und die sp_cdc_enable_table gespeicherte Prozedur wird für jede Tabelle in der Aufgabe ausgeführt, die in der Quelldatenbank nicht MS-Replication aktiviert ist. true 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

Eine 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 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 unterDatentypen 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

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 AWS DMS aktualisiert die LOB-Spalten im Ziel auch für UPDATE-Anweisungen, die den Wert der LOB-Spalte in SQL Server nicht ändern.

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 verwenden zu können 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 einem AWS DMS Aufgabe.

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

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 AWS DMS aktualisiert die LOB-Spalten im Ziel auch bei 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

Bei SQL Server-Tabellen AWS DMS aktualisiert 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.

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

User-defined Datentypen werden entsprechend ihrem Basistyp unterstützt. Beispielsweise wird ein benutzerdefinierter Datentyp basierend auf DATETIME als Datentyp DATETIME verarbeitet.