Limitazioni relative a SQL Server come origine Autorizzazioni SQL Server Prerequisiti per l'utilizzo della replica continua (CDC)Acquisizione delle modifiche per SQL Server autogestito on-premise o su EC2 Configurazione della replica continua su un'istanza database di SQL Server nel cloud Impostazioni facoltative per RDS per SQL Server come origine Metodi di compressione supportati Utilizzo di gruppi di disponibilità di SQL Server autogestiti AlwaysOn Requisiti in materia di sicurezza Impostazioni degli endpoint Tipi di dati di origine per SQL Server

Utilizzo di un database Microsoft SQL Server come origine per AWS DMS

Esegui la migrazione dei dati da uno o più database di Microsoft SQL Server utilizzando AWS DMS. Con un database SQL Server come origine, è possibile migrare i dati verso un altro database SQL Server o verso uno degli altri database AWS DMS supportati.

Per informazioni sulle versioni di SQL Server AWS DMS supportate come origine, vedereFonti per AWS DMS.

È possibile installare il database SQL Server di origine su qualsiasi computer della rete. Per l'uso con AWS DMS è necessario anche un account di SQL Server con i privilegi di accesso appropriati per il database di origine e per il tipo di attività scelta. L'account deve avere le autorizzazioni view definition e view server state. È possibile aggiungere questa autorizzazione utilizzando il seguente comando:


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

AWS DMS supporta la migrazione di dati da istanze denominate di SQL Server. È possibile usare la seguente notazione nel nome del server al momento della creazione dell'endpoint di origine.


IPAddress\InstanceName

Ad esempio, il seguente è un nome corretto di server di endpoint di origine. Qui la prima parte del nome è l'indirizzo IP del server e la seconda parte è il nome dell'istanza di SQL Server (in questo esempio, SQLTest).


10.0.0.25\SQLTest

Inoltre, ottieni il numero di porta su cui è in ascolto l'istanza denominata di SQL Server e usalo per configurare AWS DMS l'endpoint di origine.

Nota

L'impostazione predefinita per Microsoft SQL Server è la porta 1433. Tuttavia vengono spesso utilizzate porte dinamiche che cambiano ogni volta che viene avviato SQL Server e specifici numeri di porta statici utilizzati per connettersi a SQL Server tramite un firewall. Quindi, vuoi conoscere il numero di porta effettivo dell'istanza denominata di SQL Server quando crei l'endpoint di AWS DMS origine.

Puoi utilizzare il protocollo SSL per crittografare le connessioni tra l'endpoint di SQL Server e l'istanza di replica. Per ulteriori informazioni sull'utilizzo di SSL con un endpoint di SQL Server, consulta Utilizzo di SSL con AWS Database Migration Service.

Per ulteriori dettagli sull'utilizzo dei database di origine di SQL Server e AWS DMS, vedere quanto segue.

Argomenti

Limitazioni all'utilizzo di SQL Server come origine per AWS DMS
Autorizzazioni per attività solo pieno carico
Prerequisiti per l'utilizzo della replica continua (CDC) da un'origine SQL Server
Acquisizione delle modifiche ai dati per SQL Server autogestito on-premise o su Amazon EC2
Configurazione della replica continua su un'istanza database di SQL Server nel cloud
Impostazioni consigliate per l'utilizzo di Amazon RDS for SQL Server come origine per AWS DMS
Metodi di compressione supportati per SQL Server
Utilizzo di gruppi di disponibilità di SQL Server autogestiti AlwaysOn
Requisiti di sicurezza quando si utilizza SQL Server come origine per AWS Database Migration Service
Impostazioni degli endpoint quando si utilizza SQL Server come origine per AWS DMS
Tipi di dati di origine per SQL Server

Limitazioni all'utilizzo di SQL Server come origine per AWS DMS

Quando si utilizza un database SQL Server come origine per AWS DMS, si applicano le seguenti limitazioni:

La proprietà di identità di una colonna non viene migrata a una colonna del database di destinazione.
L'endpoint SQL Server non supporta l'uso di tabelle con colonne sparse.
L'autenticazione Windows non è supportata.
Le modifiche apportate ai campi calcolati in un SQL Server non vengono replicate.
Le tabelle temporali non sono supportate.
Il cambio delle partizioni di SQL Server non è supportato.
Quando si utilizzano le utilità WRITETEXT e UPDATETEXT, AWS DMS non acquisisce gli eventi applicati al database di origine.
Il seguente modello DML (data manipulation language) non è supportato.
```
SELECT * INTO new_table FROM existing_table
```
Quando utilizzi SQL Server come origine, la crittografia a livello di colonna non è supportata.
AWS DMS non supporta gli audit a livello di server su SQL Server 2008 o SQL Server 2008 R2 come sorgenti. Ciò è dovuto a un problema noto con SQL Server 2008 e 2008 R2. Ad esempio, l'esecuzione del comando seguente causa AWS DMS un errore.
```
USE [master]
GO 
ALTER SERVER AUDIT [my_audit_test-20140710] WITH (STATE=on)
GO
```
Le colonne di geometria non sono supportate in modalità LOB completa quando si utilizza SQL Server come origine. Utilizza invece la modalità LOB limitata o definisci le impostazioni dell'attività InlineLobMaxSize per utilizzare la modalità LOB in linea.
Quando si utilizza un database di origine Microsoft SQL Server in un'attività di replica, le definizioni di SQL Server Replication Publisher non vengono rimosse se si rimuove l'attività. Un amministratore di sistema di Microsoft SQL Server deve eliminare tali definizioni da Microsoft SQL Server.
La migrazione dei dati dalle non-schema-bound viste e dagli schemi è supportata solo per le attività a pieno carico.
La ridenominazione delle tabelle utilizzando sp_rename non è supportata (ad esempio, sp_rename 'Sales.SalesRegion', 'SalesReg;)
La ridenominazione delle colonne utilizzando sp_rename non è supportata (ad esempio, sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';)
AWS DMS non supporta l'elaborazione delle modifiche per impostare e annullare i valori predefiniti delle colonne (utilizzando la clausola con le ALTER COLUMN SET DEFAULT istruzioni). ALTER TABLE
AWS DMS non supporta l'elaborazione delle modifiche per impostare l'annullabilità delle colonne (utilizzando la ALTER COLUMN [SET|DROP] NOT NULL clausola con le istruzioni). ALTER TABLE
Con SQL Server 2012 e SQL Server 2014, quando si utilizza la replica DMS con i gruppi di disponibilità, il database di distribuzione non può essere inserito in un gruppo di disponibilità. SQL 2016 supporta l'inserimento del database di distribuzione in un gruppo di disponibilità, ad eccezione dei database di distribuzione utilizzati nelle topologie di unione, bidirezionali o di replica. peer-to-peer
Per le tabelle partizionate, AWS DMS non supporta impostazioni di compressione dei dati diverse per ogni partizione.
Quando si inserisce un valore nei tipi di dati spaziali di SQL Server (GEOGRAPHY e GEOMETRY), è possibile ignorare la proprietà SRID (Spatial Reference System Identifier) o specificare un numero diverso. Quando si replicano tabelle con tipi di dati spaziali, AWS DMS sostituisce lo SRID con lo SRID predefinito (0 per GEOMETRY e 4326 per GEOGRAPHY).
Se il database non è configurato per MS-REPLICATION o MS-CDC, è comunque possibile acquisire tabelle che non dispongono di una chiave primaria, ma vengono acquisiti solo gli eventi INSERT/DELETE DML. Gli eventi UPDATE e TRUNCATE TABLE vengono ignorati.
Gli indici Columnstore non sono supportati.
Le tabelle ottimizzate per la memoria (utilizzando OLTP in memoria) non sono supportate.
Quando si replica una tabella con una chiave primaria costituita da più colonne, l'aggiornamento delle colonne Chiave primaria durante il pieno carico non è supportato.
La durata ritardata non è supportata.
L'impostazione dell'endpoint readBackupOnly=Y (attributo aggiuntivo di connessione) non funziona sulle istanze di origine di RDS per SQL Server a causa del modo in cui RDS esegue i backup.
EXCLUSIVE_AUTOMATIC_TRUNCATION non funziona sulle istanze di origine di Amazon RDS per SQL Server perché gli utenti RDS non hanno accesso all'esecuzione della stored procedure di SQL Server sp_repldone.
AWS DMS non acquisisce i comandi truncate.
AWS DMS non supporta la replica da database con il ripristino accelerato del database (ADR) attivato.
AWS DMS non supporta l'acquisizione di istruzioni DDL (Data Definition Language) e DML (Data Manipulation Language) all'interno di una singola transazione.
AWS DMS non supporta la replica di pacchetti applicativi a livello di dati (DACPAC).
Le istruzioni UPDATE che coinvolgono chiavi primarie o indici univoci e aggiornano più righe di dati possono causare conflitti quando si applicano modifiche al database di destinazione. Ad esempio, quando il database di destinazione applica gli aggiornamenti come istruzioni INSERT e DELETE anziché tramite una singola istruzione UPDATE. Con la modalità di applicazione ottimizzata in batch, la tabella può essere ignorata. Con la modalità di applicazione transazionale, l'operazione UPDATE può comportare violazioni dei vincoli. Per evitare questo problema, ricarica la tabella pertinente. In alternativa, individua i record problematici nella tabella di controllo Applica eccezioni (dmslogs.awsdms_apply_exceptions) e modificali manualmente nel database di destinazione. Per ulteriori informazioni, consulta Impostazioni di ottimizzazione dell'elaborazione delle modifiche.
AWS DMS non supporta la replica di tabelle e schemi, in cui il nome include un carattere speciale del set seguente.

\\ -- \n \" \b \r ' \t ;
Il mascheramento dei dati non è supportato. AWS DMS migra i dati mascherati senza mascheramento.
AWS DMS replica fino a 32.767 tabelle con chiavi primarie e fino a 1.000 colonne per ogni tabella. Questo perché AWS DMS crea un articolo di replica di SQL Server per ogni tabella replicata e gli articoli di replica di SQL Server presentano queste limitazioni.
Quando si utilizza l'acquisizione dei dati di modifica (CDC), è necessario definire tutte le colonne che compongono un indice univoco come NOT NULL. Se questo requisito non viene soddisfatto, viene restituito l'errore di sistema 22838 di SQL Server.

Quando si accede ai log delle transazioni di backup si applicano le seguenti limitazioni:

I backup crittografati non sono supportati.
I backup archiviati in un URL o in Windows Azure non sono supportati.
AWS DMS non supporta l'elaborazione diretta dei backup dei log delle transazioni a livello di file da cartelle condivise alternative.

Autorizzazioni per attività solo pieno carico

Le seguenti autorizzazioni sono necessarie per eseguire le attività solo pieno carico. Tieni presente che AWS DMS non crea l'dms_useraccesso. Per informazioni sulla creazione di un accesso per SQL Server, consulta Creazione di un utente di database con 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;

Prerequisiti per l'utilizzo della replica continua (CDC) da un'origine SQL Server

Puoi utilizzare la replica continua (acquisizione dei dati di modifica o CDC) per un database autogestito di SQL Server on-premise o su Amazon EC2 oppure per un database cloud come Amazon RDS o un'istanza gestita da Microsoft Azure SQL.

I seguenti requisiti si applicano specificamente quando si usa la replica continua con un database SQL Server come origine per AWS DMS:

SQL Server deve essere configurato per i backup completi ed è necessario eseguire un backup prima di iniziare la replica dei dati.
Il modello di ripristino deve essere impostato su Bulk logged o su Full.
Il backup di SQL Server su più dischi non è supportato. Se il backup è definito per scrivere il backup del database su più file su dischi diversi, non è AWS DMS possibile leggere i dati e l' AWS DMS operazione ha esito negativo.
Per le origini SQL Server autogestite, le definizioni di SQL Server Replication Publisher per l'origine utilizzata in un'attività di CDC DMS non vengono rimosse quando si rimuove l'attività. Un amministratore di sistema di SQL Server deve eliminare queste definizioni da SQL Server per le origini gestite dal cliente.
Durante CDC, AWS DMS deve cercare i backup del registro delle transazioni di SQL Server per leggere le modifiche. AWS DMS non supporta i backup dei log delle transazioni di SQL Server creati utilizzando software di backup di terze parti che non sono in formato nativo. Per supportare i backup dei log delle transazioni che sono in formato nativo e creati utilizzando software di backup di terze parti, aggiungi l'attributo di connessione use3rdPartyBackupDevice=Y all'endpoint di origine.
Per le origini SQL Server gestite dal cliente, tenere presente che SQL Server non acquisisce le modifiche su nuove tabelle create finché non vengono pubblicate. Quando le tabelle vengono aggiunte a un'origine SQL Server, AWS DMS gestisce la creazione della pubblicazione. Tuttavia il processo potrebbe richiedere alcuni minuti. Le operazioni effettuate sulle nuove tabelle create durante il ritardo non vengono acquisite o replicate nella destinazione.
AWS DMS l'acquisizione dei dati di modifica richiede l'attivazione della registrazione completa delle transazioni in SQL Server. Per attivare il log completo delle transazioni in SQL Server, abilita la replica MS-REPLICATION o l'acquisizione dei dati di modifica (CDC).
Le voci tlog di SQL Server non vengono contrassegnate per il riutilizzo finché il processo CDC MS non elabora le modifiche.
Le operazioni CDC non sono supportate su tabelle ottimizzate per la memoria. Queste limitazioni si applicano a SQL Server 2014 (quando la funzionalità è stata introdotta per la prima volta) e versioni successive.
AWS DMS l'acquisizione dei dati di modifica richiede per impostazione predefinita un database di distribuzione su Amazon EC2 o su un server SQL On-Prem come origine. Pertanto assicurati di aver attivato il distributore durante la configurazione della replica MS per tabelle con chiavi primarie.

Acquisizione delle modifiche ai dati per SQL Server autogestito on-premise o su Amazon EC2

Per acquisire le modifiche di un database Microsoft SQL Server di origine, assicurati che il database sia configurato per i backup completi. Configura il database in modalità di ripristino completo o in modalità di registrazione in blocco.

Per un'origine SQL Server autogestita, AWS DMS utilizza quanto segue:

Replica MS-REPLICATION: Per acquisire le modifiche di tabelle con chiavi primarie. È possibile configurarlo automaticamente assegnando i privilegi di amministratore di sistema all'utente dell' AWS DMS endpoint sull'istanza di origine di SQL Server. Oppure puoi seguire i passaggi in questa sezione per preparare l'origine e utilizzare un utente che non dispone dei privilegi di amministratore di sistema per l'endpoint. AWS DMS
Acquisizione MS-CDC: Per acquisire le modifiche di tabelle senza chiavi primarie. Abilita l'acquisizione MS-CDC a livello di database e per tutte le tabelle singolarmente.

Quando si configura un database SQL Server per la replica continua (CDC), è possibile eseguire una delle seguenti operazioni:

Configurare la replica continua utilizzando il ruolo sysadmin.
Configurare la replica continua in modo che non utilizzi il ruolo sysadmin.

Configurazione della replica continua su un SQL Server autogestito

Questa sezione contiene informazioni sulla configurazione della replica continua su un SQL Server autogestito con o senza l'utilizzo del ruolo sysadmin.

Argomenti

Configurazione della replica continua su un SQL Server autogestito: utilizzo del ruolo sysadmin
Configurazione della replica continua su un SQL Server autonomo: senza il ruolo sysadmin

Configurazione della replica continua su un SQL Server autogestito: utilizzo del ruolo sysadmin

AWS DMS la replica continua per SQL Server utilizza la replica nativa di SQL Server per le tabelle con chiavi primarie e l'acquisizione dei dati delle modifiche (CDC) per le tabelle senza chiavi primarie.

Prima di configurare la replica continua, consulta Prerequisiti per l'utilizzo della replica continua (CDC) da un'origine SQL Server.

Per le tabelle con chiavi primarie, in genere AWS DMS è possibile configurare gli artefatti richiesti sull'origine. Tuttavia, per le istanze di origine SQL Server autogestite, assicurati di configurare prima manualmente la distribuzione di SQL Server. Dopo averlo fatto, gli utenti di AWS DMS origine con autorizzazione sysadmin possono creare automaticamente la pubblicazione per le tabelle con chiavi primarie.

Per verificare se la distribuzione è già stata configurata, eseguire il comando seguente.


sp_get_distributor

Se il risultato è NULL per la distribuzione delle colonne, la distribuzione non è configurata. Puoi utilizzare la procedura seguente per configurare la distribuzione.

Per configurare la distribuzione

Connettiti al database di origine SQL Server utilizzando lo strumento SQL Server Management Studio (SSMS).
Apri il menu contestuale (pulsante destro del mouse) della cartella Replica, quindi scegli Configura distribuzione. Viene visualizzata la Configurazione guidata della distribuzione.
Segui la procedura guidata per immettere i valori predefiniti e creare la distribuzione.

Per configurare CDC

AWS DMS la versione 3.4.7 e successive possono configurare MS CDC per il database e tutte le tabelle automaticamente se non si utilizza una replica di sola lettura. Per usare questa funzionalità, imposta l'attributo aggiuntivo di connessione SetUpMsCdcForTables su true. Per informazioni sugli attributi aggiuntivi di connessione, consulta Impostazioni degli endpoint.

Per le versioni AWS DMS precedenti alla 3.4.7 o per una replica di sola lettura come origine, procedi nel seguente modo:

Per le tabelle senza chiavi primarie, configura l'acquisizione MS-CDC per il database. Per farlo, utilizza un account a cui è assegnato il ruolo sysadmin ed esegui il comando seguente.
```
use [DBname]
EXEC sys.sp_cdc_enable_db
```
Quindi, configura l'acquisizione MS-CDC per ciascuna delle tabelle di origine. Per ogni tabella con chiavi univoche ma senza una chiave primaria, esegui la seguente query per configurare l'acquisizione MS-CDC.
```
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
```
Per ogni tabella senza una chiave primaria né chiavi univoche, esegui la seguente query per configurare l'acquisizione MS-CDC.
```
exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO
```

Per ulteriori informazioni sulla configurazione di MS-CDC per tabelle specifiche, consulta la documentazione di SQL Server.

Configurazione della replica continua su un SQL Server autonomo: senza il ruolo sysadmin

Per informazioni sulla configurazione della replica continua su un SQL Server autonomo senza il ruolo sysadmin, consulta Configurazione della replica continua su un SQL Server autonomo senza il ruolo sysadmin.

Configurazione della replica continua su un'istanza database di SQL Server nel cloud

In questa sezione viene descritto come configurare CDC su un'istanza database SQL Server ospitata nel cloud. Un'istanza SQL Server ospitata nel cloud è un'istanza in esecuzione su Amazon RDS per SQL Server, un'istanza gestita da Azure SQL o qualsiasi altra istanza gestita da SQL Server nel cloud. Per informazioni sulle limitazioni alla replica continua per ogni tipo di database, consulta Limitazioni all'utilizzo di SQL Server come origine per AWS DMS.

Prima di configurare la replica continua, consulta Prerequisiti per l'utilizzo della replica continua (CDC) da un'origine SQL Server.

Diversamente dalle origini Microsoft SQL Server autogestite, Amazon RDS per SQL Server non supporta MS-Replication. Pertanto, AWS DMS deve utilizzare MS-CDC per le tabelle con o senza chiavi primarie.

Amazon RDS non concede i privilegi di amministratore di sistema per l'impostazione degli artefatti di replica da AWS DMS utilizzare per le modifiche in corso in un'istanza di SQL Server di origine. Assicurati di attivare l'acquisizione MS-CDC per l'istanza Amazon RDS (utilizzando i privilegi di utente master) come indicato nella procedura seguente.

Per attivare l'acquisizione MS-CDC per un'istanza database SQL Server nel cloud

Esegui una delle seguenti query a livello di database.

Utilizza questa query per un'istanza database RDS per SQL Server.
```
exec msdb.dbo.rds_cdc_enable_db 'DB_name'
```
Utilizza questa query per un'istanza database gestita da Azure SQL.
```
USE DB_name 
GO 
EXEC sys.sp_cdc_enable_db 
GO
```

Per ogni tabella con una chiave primaria, esegui la seguente query per attivare l'acquisizione MS-CDC.


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

Per ogni tabella con chiavi univoche ma senza una chiave primaria, esegui la seguente query per attivare l'acquisizione MS-CDC.


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

Per ogni tabella senza una chiave primaria né chiavi univoche, esegui la seguente query per attivare l'acquisizione MS-CDC.


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

Imposta la disponibilità del periodo di conservazione delle modifiche sull'origine utilizzando il seguente comando.
```
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'
```
Il parametro @pollinginterval viene misurato in secondi con un valore consigliato impostato su 86399. Ciò significa che il log delle transazioni mantiene le modifiche per 86.399 secondi (un giorno) quando @pollinginterval = 86399. La procedura exec sp_cdc_start_job 'capture' avvia le impostazioni.

Nota
In alcune versioni di SQL Server, se il valore di pollinginterval è impostato su più di 3599 secondi, viene ripristinato a cinque secondi predefiniti. Quando ciò accade, le voci T-Log vengono eliminate prima di poterle leggere. AWS DMS Per determinare quali versioni di SQL Server sono interessate da questo problema noto, consulta questo articolo della Knowledge Base di Microsoft.

Se utilizzi Amazon RDS con Multi-AZ, assicurati di impostare anche la versione secondaria in modo che abbia i valori corretti in caso di failover.
```
exec rdsadmin..rds_set_configuration 'cdc_capture_pollinginterval' , 86399
```

Se un'attività di AWS DMS replica che acquisisce le modifiche in corso all'origine di SQL Server si interrompe per più di un'ora, utilizzare la procedura seguente.

Per mantenere il periodo di conservazione durante un' AWS DMS attività di replica

Arresta il processo di troncamento dei log delle transazioni utilizzando il comando seguente.
```
exec sp_cdc_stop_job 'capture'
```
Trova l'attività sulla AWS DMS console e riprendila.
Scegli la scheda Monitoraggio e seleziona il parametro CDCLatencySource.
Una volta che il parametro CDCLatencySource è uguale a 0 (zero) e si stabilizza su tale valore, riavvia l'attività che tronca i log delle transazioni utilizzando il seguente comando.
```
exec sp_cdc_start_job 'capture'
```

Ricordati di avviare il processo che tronca i log delle transazioni di SQL Server. In caso contrario, lo spazio di storage dell'istanza SQL Server potrebbe esaurirsi.

Limitazioni per la replica continua su un'istanza database SQL Server nel cloud

AWS DMS supporta la replica in corso (CDC) solo con il registro delle transazioni attivo. Non è possibile utilizzare il log dei backup con CDC.
È possibile perdere gli eventi se si spostano dal log delle transazioni attivo al log dei backup o li tronchi dal log delle transazioni attivo.

Impostazioni consigliate per l'utilizzo di Amazon RDS for SQL Server come origine per AWS DMS

Quando utilizzi Amazon RDS per SQL Server come origine, il processo di acquisizione si basa sui parametri maxscans e maxtrans. Questi parametri determinano il numero massimo di scansioni eseguite dall'acquisizione nel log delle transazioni e il numero di transazioni elaborate per ogni scansione.

Per i database in cui il numero di transazioni è superiore a maxtrans*maxscans, l'aumento del valore di polling_interval può causare un accumulo di record del log delle transazioni attivo. Questo accumulo può, a sua volta, portare a un aumento delle dimensioni del log delle transazioni.

Tieni presente che AWS DMS non si basa sul processo di acquisizione MS-CDC. Il processo di acquisizione MS-CDC contrassegna le voci del log delle transazioni come elaborate. Ciò consente al processo di backup del log delle transazioni di rimuovere le voci dal log delle transazioni.

Si consiglia di monitorare la dimensione del log delle transazioni e l'esito dei processi di acquisizione MS-CDC. Se i job MS-CDC falliscono, il log delle transazioni potrebbe crescere eccessivamente e causare errori di replica. AWS DMS È possibile monitorare gli errori del processo di acquisizione MS-CDC utilizzando la vista di gestione dinamica sys.dm_cdc_errors nel database di origine. È possibile monitorare la dimensione del log delle transazioni utilizzando il comando di gestione DBCC SQLPERF(LOGSPACE).

Per risolvere l'aumento delle dimensioni del log delle transazioni causato dall'acquisizione MS-CDC

Verificate la provenienza Log Space Used % da cui AWS DMS viene eseguita la replica del database e verificate che aumenti continuamente.
```
DBCC SQLPERF(LOGSPACE)
```
Identifica cosa blocca il processo di backup del log delle transazioni.
```
Select log_reuse_wait, log_reuse_wait_desc, name from sys.databases where name = db_name();
```
Se il valore log_reuse_wait_desc è uguale a REPLICATION, la conservazione del backup del log è causata dalla latenza dell'acquisizione MS-CDC.

Aumenta il numero di eventi elaborati dal processo di acquisizione incrementando i valori dei parametri maxtrans e maxscans.


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'

Per risolvere questo problema, imposta i valori di maxscans e maxtrans in modo che maxtrans*maxscans siano uguali al numero medio di eventi generati per le tabelle AWS DMS replicate dal database di origine per ogni giorno.

Se imposti questi parametri su un valore superiore a quello consigliato, i processi di acquisizione elaborano tutti gli eventi nei log delle transazioni. Se si impostano questi parametri su un valore inferiore a quello consigliato, la latenza dell'acquisizione MS-CDC aumenta e il log delle transazioni incrementa le dimensioni.

L'identificazione dei valori appropriati per maxscans e maxtrans può essere difficile perché le modifiche del carico di lavoro producono un numero variabile di eventi. In questo caso, consigliamo di configurare il monitoraggio della latenza dell'acquisizione MS-CDC. Per ulteriori informazioni, consulta Monitorare il processo nella documentazione di SQL Server. Quindi configura maxtrans e maxscans in modo dinamico in base ai risultati del monitoraggio.

Se l' AWS DMS attività non riesce a trovare i numeri di sequenza di registro (LSN) necessari per riprendere o continuare l'attività, l'operazione potrebbe non riuscire e richiedere un ricaricamento completo.

Nota

Quando si utilizza AWS DMS per replicare i dati da un'origine RDS per SQL Server, è possibile che si verifichino errori nel tentativo di riprendere la replica dopo un evento di stop-start dell'istanza Amazon RDS. Ciò è dovuto al fatto che il processo di SQL Server Agent riavvia il processo di acquisizione quando viene riavviato dopo l'evento di arresto e avvio. Questo processo ignora l'intervallo di polling dell'acquisizione MS-CDC.

Per questo motivo, nei database con volumi di transazioni inferiori all'elaborazione del processo di acquisizione MS-CDC, ciò può causare l'elaborazione o la marcatura dei dati come replicati e di backup prima che AWS DMS possano riprendere da dove si era interrotta, con il seguente errore:


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

Per mitigare questo problema, imposta i valori maxtrans e maxscans come consigliato in precedenza.

Metodi di compressione supportati per SQL Server

Tieni presente le seguenti informazioni sul supporto per i metodi di compressione di SQL Server in AWS DMS:

AWS DMS supporta la compressione Row/Page in SQL Server versione 2008 e successive.
AWS DMS non supporta il formato di archiviazione Vardecimal.
AWS DMS non supporta colonne sparse e compressione della struttura colonnare.

Utilizzo di gruppi di disponibilità di SQL Server autogestiti AlwaysOn

I gruppi di disponibilità Always On di SQL Server forniscono disponibilità elevata e ripristino di emergenza come alternativa a livello aziendale al mirroring del database.

In AWS DMS, è possibile migrare le modifiche da una singola replica del gruppo di disponibilità primario o secondario.

Utilizzo della replica del gruppo di disponibilità principale

Per utilizzare il gruppo di disponibilità primario come origine in AWS DMS, procedi come segue:

Attiva l'opzione di distribuzione in tutte le istanze SQL Server nelle repliche di disponibilità. Per ulteriori informazioni, consulta Configurazione della replica continua su un SQL Server autogestito.
Nella AWS DMS console, apri le impostazioni del database di origine di SQL Server. Per Nome server, specifica il nome DNS (Domain Name Service) o l'indirizzo IP configurato per l'ascoltatore del gruppo di disponibilità.

Quando si avvia un' AWS DMS attività per la prima volta, l'avvio potrebbe richiedere più tempo del solito. Ciò avviene perché la creazione degli articoli della tabella viene duplicata dal server dei gruppi di disponibilità.

Utilizzo della replica del gruppo di disponibilità secondario

Per utilizzare un gruppo di disponibilità secondario come fonte in AWS DMS, procedi come segue:

Utilizzate le stesse credenziali utilizzate dall'utente dell'endpoint di AWS DMS origine per la connessione a singole repliche.
Assicurati che l'istanza di AWS DMS replica sia in grado di risolvere i nomi DNS per tutte le repliche esistenti e di connettersi ad esse. È possibile utilizzare la seguente query SQL per ottenere i nomi DNS per tutte le repliche.
```
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>';
```
Quando crei l'endpoint di origine, specifica il nome DNS dell'ascoltatore del gruppo di disponibilità per il nome del server dell'endpoint o per l'indirizzo del server del segreto dell'endpoint. Per ulteriori informazioni sugli ascoltatori del gruppo di disponibilità, consulta Che cos'è un ascoltatore del gruppo di disponibilità? nella documentazione di SQL Server.

È possibile utilizzare un server DNS pubblico o un server DNS on-premise per risolvere l'ascoltatore del gruppo di disponibilità, la replica principale e le repliche secondarie. Per utilizzare un server DNS on-premise, configura il risolutore Amazon Route 53. Per ulteriori informazioni, consulta Utilizzo del server dei nomi in locale.

Aggiungi i seguenti attributi aggiuntivi di connessione all'endpoint di origine.

Attributo aggiuntivo di connessione	Valore	Note
`applicationIntent`	`ReadOnly`	Senza questa impostazione ODBC, l'attività di replica viene indirizzata alla replica del gruppo di disponibilità principale. Per ulteriori informazioni, consulta Supporto client SQL Server nativo per disponibilità elevata e ripristino di emergenza nella documentazione di SQL Server.
`multiSubnetFailover`	`yes`	Per ulteriori informazioni, consulta Supporto client SQL Server nativo per disponibilità elevata e ripristino di emergenza nella documentazione di SQL Server.
`alwaysOnSharedSynchedBackupIsEnabled`	`false`	Per ulteriori informazioni, consulta Impostazioni degli endpoint quando si utilizza SQL Server come origine per AWS DMS.
`activateSafeguard`	`false`	Per ulteriori informazioni, consulta la sezione seguente: Limitazioni.
`setUpMsCdcForTables`	`false`	Per ulteriori informazioni, consulta la sezione seguente: Limitazioni.

Abilita l'opzione di distribuzione in tutte le repliche del gruppo di disponibilità. Aggiungi tutti i nodi all'elenco dei distributori. Per ulteriori informazioni, consulta Per configurare la distribuzione.
Esegui la seguente query sulla replica principale di lettura/scrittura per abilitare la pubblicazione del database. Questa query viene eseguita una sola volta per il database.
```
sp_replicationdboption @dbname = N'<source DB name>', @optname = N'publish', @value = N'true';
```

Limitazioni

Di seguito sono riportate le limitazioni per l'utilizzo di una replica del gruppo di disponibilità secondario:

AWS DMS non supporta Safeguard quando utilizza una replica del gruppo di disponibilità di sola lettura come origine. Per ulteriori informazioni, consulta Impostazioni degli endpoint quando si utilizza SQL Server come origine per AWS DMS.
AWS DMS non supporta l'attributo di connessione setUpMsCdcForTables extra quando utilizza una replica del gruppo di disponibilità di sola lettura come origine. Per ulteriori informazioni, consulta Impostazioni degli endpoint quando si utilizza SQL Server come origine per AWS DMS.
AWS DMS può utilizzare una replica del gruppo di disponibilità secondario autogestita come database di origine per la replica continua (change data capture o CDC) a partire dalla versione 3.4.7. Le repliche di lettura multi-AZ di SQL Server nel cloud non sono supportate. Se utilizzi versioni precedenti di AWS DMS, assicurati di utilizzare la replica del gruppo di disponibilità principale come database di origine per CDC.

Failover su altri nodi

Se imposti l'attributo di connessione ApplicationIntent aggiuntivo per l'endpoint suReadOnly, l' AWS DMS attività si connette al nodo di sola lettura con la priorità di routing di sola lettura più alta. Quindi esegue il failover su altri nodi di sola lettura del gruppo di disponibilità quando il nodo di sola lettura con la priorità più alta non è disponibile. Se non lo impostiApplicationIntent, l' AWS DMS attività si connette solo al nodo primario (lettura/scrittura) del gruppo di disponibilità.

Requisiti di sicurezza quando si utilizza SQL Server come origine per AWS Database Migration Service

L'account AWS DMS utente deve avere almeno il ruolo db_owner utente nel database di origine di SQL Server a cui ci si sta connettendo.

Impostazioni degli endpoint quando si utilizza SQL Server come origine per AWS DMS

È possibile utilizzare le impostazioni degli endpoint per configurare il database di origine SQL Server in modo simile a come si usano gli attributi aggiuntivi di connessione. Le impostazioni vengono specificate quando si crea l'endpoint di origine utilizzando la AWS DMS console o utilizzando il create-endpoint comando in AWS CLI, con la sintassi --microsoft-sql-server-settings '{"EndpointSetting": "value", ...}' JSON.

Nella tabella seguente vengono elencate le impostazioni degli endpoint che è possibile utilizzare con SQL Server come origine.

Nome	Descrizione
`ActivateSafeguard`	Questo attributo attiva o disattiva la protezione. Per informazioni sulla protezione, consulta `SafeguardPolicy`. Valore predefinito: `true` Valori validi: {`false`, `true`} Esempio: `'{"ActivateSafeguard": true}'`
`AlwaysOnSharedSynchedBackupIsEnabled`	Questo attributo regola il comportamento AWS DMS durante la migrazione da un database di origine di SQL Server ospitato come parte di un cluster di gruppi di disponibilità Always On. AWS DMS ha migliorato il supporto per i database di origine di SQL Server configurati per l'esecuzione in un cluster Always On. In questo caso, AWS DMS tenta di verificare se i backup delle transazioni vengono eseguiti da nodi del cluster Always On diversi dal nodo in cui è ospitata l'istanza del database di origine. All'avvio dell'attività di migrazione, AWS DMS tenta di connettersi a ogni nodo del cluster, ma fallisce se non riesce a connettersi a nessuno dei nodi. Se devi AWS DMS eseguire il polling di tutti i nodi del cluster Always On per i backup delle transazioni, imposta questo attributo su. `false` Valore predefinito: `true` Valori validi: `true` o `false` Esempio: `'{"AlwaysOnSharedSynchedBackupIsEnabled": false}'`
`"ApplicationIntent": "readonly"`	Questa impostazione dell'attributo del driver ODBC consente a SQL Server di indirizzare l'attività di replica al nodo di sola lettura con la priorità più alta. Senza questa impostazione, SQL Server indirizza l'attività di replica al nodo di lettura-scrittura principale.
`EnableNonSysadminWrapper`	Utilizza questa impostazione degli endpoint quando configuri la replica continua su un server SQL autonomo senza un utente sysadmin. Questo parametro è supportato nella AWS DMS versione 3.4.7 e successive. Per informazioni sulla configurazione della replica continua su un SQL Server autonomo, consulta Configurazione della replica continua su un SQL Server autonomo: senza il ruolo sysadmin. Valore predefinito: `false` Valori validi: `true`, `false` Esempio: `'{"EnableNonSysadminWrapper": true}'`
`ExecuteTimeout`	Utilizza questo attributo aggiuntivo di connessione per impostare il timeout in secondi dell'istruzione client per l'istanza SQL Server. Il valore predefinito è 60 secondi. Esempio: `'{"ExecuteTimeout": 100}'`
`FatalOnSimpleModel`	Se configurata su `true`, questa impostazione genera un errore irreversibile quando il modello di ripristino del database SQL Server è impostato su `simple`. Valore predefinito: `false` Valori validi: `true` o `false` Esempio: `'{"FatalOnSimpleModel": true}'`
`ForceLobLookup`	Forza la ricerca LOB su un LOB in linea. Valore predefinito: `false` Valori validi: `true`, `false` Esempio: `'{"ForceLobLookup": false}'`
`"MultiSubnetFailover": "Yes"`	Questo attributo del driver ODBC consente a DMS di connettersi al nuovo gruppo principale in caso di failover del gruppo di disponibilità. L'attributo è progettato per situazioni in cui la connessione è interrotta o l'indirizzo IP dell'ascoltatore non è corretto. In queste situazioni, AWS DMS tenta di connettersi a tutti gli indirizzi IP associati al listener del gruppo di disponibilità.
`ReadBackupOnly`	L'uso di questo attributo richiede i privilegi sysadmin. Quando questo attributo è impostato su`Y`, durante la replica in corso AWS DMS legge le modifiche solo dai backup del registro delle transazioni e non legge dal file di registro delle transazioni attivo. L'impostazione di questo parametro su `Y` consente di controllare l'aumento delle dimensioni del file di log delle transazioni attive durante le attività di caricamento completo e di replica continua. Tuttavia, può aggiungere della latenza di origine alla replica in corso. Valori validi: `N` o `Y`. Il valore predefinito è `N`. Esempio: `'{"ReadBackupOnly": Y}'` Nota: questo parametro non funziona sulle istanze di origine Amazon RDS per SQL Server a causa del modo in cui RDS esegue i backup.
`SafeguardPolicy`	Per prestazioni ottimali, AWS DMS tenta di acquisire tutte le modifiche non lette dal registro delle transazioni attivo (TLOG). A volte, tuttavia, a causa dei troncamenti, il TLOG attivo potrebbe non contenere tutte le modifiche non lette. In tal caso, AWS DMS accede al backup del registro per acquisire le modifiche mancanti. Per ridurre al minimo la necessità di accedere al backup del registro, AWS DMS impedisce il troncamento utilizzando uno dei seguenti metodi: `RELY_ON_SQL_SERVER_REPLICATION_AGENT`(Avvia transazioni nel database): Questa è l'impostazione predefinita per. AWS DMS Quando si utilizza questa impostazione, AWS DMS richiede che l'agente di lettura log di SQL Server sia in esecuzione, in modo che AWS DMS possa spostare le transazioni contrassegnate per la replica dal TLOG attivo. Tieni presente che se l'agente di lettura log non è in esecuzione, il TLOG attivo può esaurire lo spazio, facendo sì che il database di origine passi alla modalità di sola lettura fino alla risoluzione del problema. Se è necessario abilitare Microsoft Replication nel database per uno scopo diverso da AWS DMS, è necessario scegliere questa impostazione. Quando si utilizza questa impostazione, AWS DMS riduce al minimo le letture di backup dei log creando una tabella denominata `awsdms_truncation_safeguard` e impedisce il troncamento di TLOG imitando una transazione aperta nel database. In questo modo si evita che il database tronchi gli eventi e li sposti nel log di backup per cinque minuti (per impostazione predefinita). Assicurati che la tabella non sia inclusa in nessun piano di manutenzione, poiché potrebbe causare l'esito negativo del processo di manutenzione. È possibile eliminare la tabella in modo sicuro se non ci sono attività configurate con l'opzione di database `Start Transactions`. `EXCLUSIVE_AUTOMATIC_TRUNCATION`(Utilizzabile esclusivamente `sp_repldone` con una singola attività): quando si utilizza questa impostazione, AWS DMS ha il pieno controllo del processo dell'agente di replica che contrassegna le voci di registro come utilizzate. `ready for truncation` `sp_repldone` Con questa impostazione, AWS DMS non utilizza una transazione fittizia come con l'impostazione `RELY_ON_SQL_SERVER_REPLICATION_AGENT` (predefinita). È possibile utilizzare questa impostazione solo quando MS Replication non viene utilizzato per scopi diversi dal database AWS DMS di origine. Inoltre, quando si utilizza questa impostazione, solo un' AWS DMS attività può accedere al database. Se è necessario eseguire AWS DMS attività parallele sullo stesso database, utilizzare`RELY_ON_SQL_SERVER_REPLICATION_AGENT`. Questa impostazione richiede che l'agente di lettura log sia arrestato nel database. Se il Log Reader Agent è in esecuzione all'avvio dell' AWS DMS attività, quest'ultima ne forzerà l'interruzione. In alternativa, è possibile arrestare l'agente di lettura log manualmente prima di iniziare l'attività. Quando si utilizza questo metodo con l'acquisizione MS-CDC, è necessario arrestare e disabilitare i processi di acquisizione MS-CDC e pulizia dell'acquisizione MS-CDC. Non è possibile utilizzare questa impostazione quando il processo di migrazione di Microsoft SQL Server viene eseguito su un computer Distributor remoto, poiché AWS DMS non ha accesso al computer remoto. `EXCLUSIVE_AUTOMATIC_TRUNCATION` non funziona sulle istanze di origine Amazon RDS per SQL Server perché gli utenti di Amazon RDS non hanno accesso per eseguire la stored procedure `sp_repldone`. Se imposti `SafeguardPolicy` su `EXCLUSIVE_AUTOMATIC_TRUNCATION` senza utilizzare il ruolo sysadmin, devi concedere le autorizzazioni per gli oggetti `dbo.syscategories` e `dbo.sysjobs` all'utente `dmsuser`. Valore predefinito: `RELY_ON_SQL_SERVER_REPLICATION_AGENT` Valori validi: {`EXCLUSIVE_AUTOMATIC_TRUNCATION`, `RELY_ON_SQL_SERVER_REPLICATION_AGENT`} Esempio: `'{"SafeguardPolicy": "EXCLUSIVE_AUTOMATIC_TRUNCATION"}'`
`SetUpMsCdcForTables`	Questo attributo attiva l'acquisizione MS-CDC per il database di origine e per le tabelle nella mappatura delle attività che non hanno la replica MS abilitata. L'impostazione di questo valore su `true` esegue la stored procedure `sp_cdc_enable_db` sul database di origine ed esegue la stored procedure `sp_cdc_enable_table` su ogni tabella dell'attività in cui non è abilitata la replica MS nel database di origine. Per ulteriori informazioni sull'attivazione della distribuzione, consulta Configurazione della replica continua su un SQL Server autogestito. Valori validi: {`true`, `false`} Esempio: `'{"SetUpMsCdcForTables": true}'`
`TlogAccessMode`	Indica la modalità utilizzata per recuperare i dati CDC. Valore predefinito: `PreferTlog` Valori validi: `BackupOnly`, `PreferBackup`, `PreferTlog`, `TlogOnly` Esempio: `'{"TlogAccessMode": "PreferTlog"}'`
`Use3rdPartyBackupDevice`	Quando questo attributo è impostato su `Y`, AWS DMS elabora i backup dei log delle transazioni di terze parti se sono stati creati in formato nativo.

Tipi di dati di origine per SQL Server

La migrazione dei dati che utilizza SQL Server come origine AWS DMS supporta la maggior parte dei tipi di dati di SQL Server. La tabella seguente mostra i tipi di dati di origine di SQL Server supportati durante l'utilizzo AWS DMS e la mappatura predefinita AWS DMS dei tipi di dati.

Per informazioni su come visualizzare il tipo di dati mappato nella destinazione, consulta la sezione relativa all'endpoint di destinazione che stai utilizzando.

Per ulteriori informazioni sui tipi di AWS DMS dati, vedereTipi di dati per AWS Database Migration Service.

Tipi di dati SQL Server	AWS DMS tipi di dati
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 e versioni successive)	DATETIME
SMALLDATETIME	DATETIME
DATE	DATE
TIME	TIME
DATETIMEOFFSET	WSTRING
CHAR	STRING
VARCHAR	STRING
VARCHAR (max)	CLOB TEXT Per utilizzare questo tipo di dati con AWS DMS, è necessario abilitare l'uso dei tipi di dati CLOB per un'attività specifica. Per le tabelle di SQL Server, AWS DMS aggiorna le colonne LOB nella destinazione anche per le istruzioni UPDATE che non modificano il valore della colonna LOB in SQL Server. Durante CDC, AWS DMS supporta i tipi di dati CLOB solo nelle tabelle che includono una chiave primaria.
NCHAR	WSTRING
NVARCHAR (lunghezza)	WSTRING
NVARCHAR (max)	NCLOB NTEXT Per utilizzare questo tipo di dati con AWS DMS, è necessario abilitare l'uso di SupportLobs per un'attività specifica. Per ulteriori informazioni sull'abilitazione del supporto LOB, consulta Impostazione del supporto LOB per i database di origine in un task AWS DMS. Per le tabelle di SQL Server, AWS DMS aggiorna le colonne LOB nella destinazione anche per le istruzioni UPDATE che non modificano il valore della colonna LOB in SQL Server. Durante CDC, AWS DMS supporta i tipi di dati CLOB solo nelle tabelle che includono una chiave primaria.
BINARY	BYTES
VARBINARY	BYTES
VARBINARY (max)	BLOB IMAGE Per le tabelle di SQL Server, AWS DMS aggiorna le colonne LOB nella destinazione anche per le istruzioni UPDATE che non modificano il valore della colonna LOB in SQL Server. Per utilizzare questo tipo di dati con AWS DMS, è necessario abilitare l'uso dei tipi di dati BLOB per un'attività specifica. AWS DMS supporta i tipi di dati BLOB solo nelle tabelle che includono una chiave primaria.
TIMESTAMP	BYTES
UNIQUEIDENTIFIER	STRING
HIERARCHYID	Utilizza HIERARCHYID durante la replica su un endpoint di destinazione SQL Server. Utilizza WSTRING (250) durante la replica su tutti gli altri endpoint di destinazione.
XML	NCLOB Per le tabelle di SQL Server, AWS DMS aggiorna le colonne LOB nella destinazione anche per le istruzioni UPDATE che non modificano il valore della colonna LOB in SQL Server. Per utilizzare questo tipo di dati con AWS DMS, è necessario abilitare l'uso dei tipi di dati NCLOB per un'attività specifica. Durante CDC, AWS DMS supporta i tipi di dati NCLOB solo nelle tabelle che includono una chiave primaria.
GEOMETRY	Utilizza GEOMETRY durante la replica sugli endpoint di destinazione che supportano questo tipo di dati. Utilizza CLOB durante la replica sugli endpoint di destinazione che non supportano questo tipo di dati.
GEOGRAPHY	Utilizza GEOGRAPHY durante la replica sugli endpoint di destinazione che supportano questo tipo di dati. Utilizza CLOB durante la replica sugli endpoint di destinazione che non supportano questo tipo di dati.

AWS DMS non supporta tabelle che includono campi con i seguenti tipi di dati.

CURSOR
SQL_VARIANT
TABLE

Nota

I tipi di dati definiti dall'utente sono supportati secondo il tipo di base. Ad esempio, un tipo di dati definito dall'utente basato su DATETIME viene gestito come tipo di dati DATETIME.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Utilizzo di Oracle come origine

Utilizzo di un database SQL di Azure come origine