Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Utilizzo di un database Microsoft SQL Server come origine per AWS DMS
<a name="CHAP_Source.SQLServer"></a>

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, vedere[Fonti per AWS DMS](CHAP_Introduction.Sources.md).

È 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. Per ulteriori informazioni, consulta [Autorizzazioni per le attività di SQL Server](#CHAP_Source.SQLServer.Permissions).

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 l'endpoint di AWS DMS 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](CHAP_Security.SSL.md).

È possibile utilizzare CDC per la migrazione continua da un database SQL Server. Per informazioni sulla configurazione del database SQL Server di origine per CDC, vedere. [Acquisizione delle modifiche ai dati per la replica continua da SQL Server](CHAP_Source.SQLServer.CDC.md)

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

**Topics**
+ [Limitazioni all'utilizzo di SQL Server come origine per AWS DMS](#CHAP_Source.SQLServer.Limitations)
+ [Autorizzazioni per le attività di SQL Server](#CHAP_Source.SQLServer.Permissions)
+ [Prerequisiti per l'utilizzo della replica continua (CDC) da un'origine SQL Server](#CHAP_Source.SQLServer.Prerequisites)
+ [Metodi di compressione supportati per SQL Server](#CHAP_Source.SQLServer.Compression)
+ [Utilizzo di gruppi di disponibilità di SQL Server autogestiti AlwaysOn](#CHAP_Source.SQLServer.AlwaysOn)
+ [Impostazioni degli endpoint quando si utilizza SQL Server come origine per AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib)
+ [Tipi di dati di origine per SQL Server](#CHAP_Source.SQLServer.DataTypes)
+ [Acquisizione delle modifiche ai dati per la replica continua da SQL Server](CHAP_Source.SQLServer.CDC.md)

## Limitazioni all'utilizzo di SQL Server come origine per AWS DMS
<a name="CHAP_Source.SQLServer.Limitations"></a>

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 Geometry e Geography non sono supportate in modalità full lob 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 associate allo schema è supportata solo per le attività a pieno carico. 
+ La ridenominazione delle tabelle utilizzando sp\$1rename non è supportata (ad esempio, `sp_rename 'Sales.SalesRegion', 'SalesReg;)`
+ La ridenominazione delle colonne utilizzando sp\$1rename 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 eventi DML. INSERT/DELETE 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=true` (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](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
+ 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. 
+ È possibile perdere gli eventi se SQL Server archivia dal log delle transazioni attivo al log di backup o li tronca dal log delle transazioni attivo.

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 doe snot supporta l'elaborazione diretta dei backup del registro delle transazioni a livello di file da cartelle condivise alternative.
+ Per le sorgenti Cloud SQL Server diverse da Amazon RDS for Microsoft SQL Server AWS DMS , supporta la replica continua (CDC) solo con il registro delle transazioni attivo. Non è possibile utilizzare il log dei backup con CDC. È possibile perdere gli eventi se SQL Server li archivia dal log delle transazioni attivo al log di backup o li tronca dal log delle transazioni attivo prima che DMS possa leggerli. 
+ Per le sorgenti Amazon RDS for Microsoft SQL Server AWS DMS , la versione 3.5.2 e le versioni precedenti supportano la replica continua (CDC) solo con il registro delle transazioni attivo, poiché DMS non può accedere al registro di backup con CDC. Potresti perdere gli eventi se RDS per SQL Server li archivia dal log delle transazioni attivo al log di backup o li tronca dal log delle transazioni attivo prima che DMS possa leggerlo. Questa limitazione non si applica alla AWS DMS versione 3.5.3 e successive.
+ AWS DMS non supporta CDC per Amazon RDS Proxy for SQL Server come sorgente.
+ Se l'origine di SQL Server non è disponibile durante un'attività di caricamento completo, AWS DMS potrebbe contrassegnare l'attività come completata dopo più tentativi di riconnessione, anche se la migrazione dei dati rimane incompleta. In questo scenario, le tabelle di destinazione contengono solo i record migrati prima della perdita della connessione, il che potrebbe creare incoerenze di dati tra i sistemi di origine e di destinazione. Per garantire la completezza dei dati, è necessario riavviare completamente l'attività di caricamento completo o ricaricare le tabelle specifiche interessate dall'interruzione della connessione.

## Autorizzazioni per le attività di SQL Server
<a name="CHAP_Source.SQLServer.Permissions"></a>

**Topics**
+ [Autorizzazioni per attività solo pieno carico](#CHAP_Source.SQLServer.Permissions.FullLoad)
+ [Autorizzazioni per attività con replica continua](#CHAP_Source.SQLServer.Permissions.Ongoing)

### Autorizzazioni per attività solo pieno carico
<a name="CHAP_Source.SQLServer.Permissions.FullLoad"></a>

Le seguenti autorizzazioni sono necessarie per eseguire le attività solo pieno carico. Tieni presente che AWS DMS non crea l'accesso `dms_user`. Per informazioni sulla creazione di un accesso per SQL Server, consulta [l'argomento Creazione di un utente del database](https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-database-user?view=sql-server-ver16) nella documentazione *di Microsoft*.

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

### Autorizzazioni per attività con replica continua
<a name="CHAP_Source.SQLServer.Permissions.Ongoing"></a>

Le istanze di SQL Server autogestite possono essere configurate per la replica continua utilizzando DMS con o senza l'utilizzo del ruolo. `sysadmin` Per le istanze di SQL Server, in cui non è possibile concedere il `sysadmin` ruolo, assicurati che l'utente DMS disponga dei privilegi descritti di seguito.

**Imposta le autorizzazioni per la replica continua da un database SQL Server autogestito**

1. Creare un nuovo account SQL Server con autenticazione tramite password utilizzando SQL Server Management Studio (SSMS) o come descritto in precedenza, ad esempio[Autorizzazioni per attività solo pieno carico](#CHAP_Source.SQLServer.Permissions.FullLoad),. `self_managed_user`

1. Esegui i seguenti `GRANT` comandi: 

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

1. Oltre alle autorizzazioni precedenti, l'utente deve disporre di una delle seguenti autorizzazioni:
   + L'utente deve essere un membro del ruolo `sysadmin` fisso del server
   + Configurazioni e autorizzazioni come descritto in [Configurazione della replica continua su SQL Server in un ambiente di gruppo di disponibilità senza il ruolo sysadmin](CHAP_Source.SQLServer.CDC.md#CHAP_SupportScripts.SQLServer.ag) o[Configurazione della replica continua su un SQL Server autonomo: senza il ruolo sysadmin](CHAP_Source.SQLServer.CDC.md#CHAP_SupportScripts.SQLServer.standalone), a seconda della configurazione di origine.

#### Configura le autorizzazioni per la replica continua da un database SQL Server cloud
<a name="CHAP_Source.SQLServer.Permissions.Cloud"></a>

Un'istanza di SQL Server ospitata nel cloud è un'istanza in esecuzione su Amazon RDS per Microsoft SQL Server, un'istanza gestita di Azure SQL o qualsiasi altra istanza SQL Server cloud gestita supportata da DMS.

Crea un nuovo account SQL Server con autenticazione tramite password utilizzando SQL Server Management Studio (SSMS) o come descritto in precedenza, ad esempio,. [Autorizzazioni per attività solo pieno carico](#CHAP_Source.SQLServer.Permissions.FullLoad) `rds_user`

Esegui i seguenti comandi per la concessione.

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

Per i sorgenti Amazon RDS for Microsoft SQL Server, la versione DMS 3.5.3 e successive supportano la lettura dai backup dei log delle transazioni. Per garantire che DMS sia in grado di accedere ai backup dei log, oltre a quanto sopra, concedi i privilegi `master` utente o i seguenti privilegi su una fonte RDS SQL Server:

```
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;
```

Per le istanze gestite di Amazon Azure SQL, concedi i seguenti privilegi:

```
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;
```

## Prerequisiti per l'utilizzo della replica continua (CDC) da un'origine SQL Server
<a name="CHAP_Source.SQLServer.Prerequisites"></a>

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'attività ha esito negativo. AWS DMS 
+ 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.

## Metodi di compressione supportati per SQL Server
<a name="CHAP_Source.SQLServer.Compression"></a>

Tieni presente le seguenti informazioni sul supporto per i metodi di compressione di SQL Server in AWS DMS:
+ AWS DMS supporta Row/Page la compressione 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
<a name="CHAP_Source.SQLServer.AlwaysOn"></a>

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
<a name="CHAP_Source.SQLServer.AlwaysOn.Primary"></a>

 

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

1. 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](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.CDC.MSCDC).

1. 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
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary"></a>

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

1. Utilizzate le stesse credenziali utilizzate dall'utente dell'endpoint di AWS DMS origine per la connessione a singole repliche.

1. 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>';
   ```

1. 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à?](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-group-listener-overview?view=sql-server-ver15) 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](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver).

1. Aggiungi i seguenti attributi aggiuntivi di connessione all'endpoint di origine.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.SQLServer.html)

1. 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](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.CDC.MSCDC.Setup).

1. 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
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary.limitations"></a>

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](#CHAP_Source.SQLServer.ConnectionAttrib).
+ 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](#CHAP_Source.SQLServer.ConnectionAttrib).
+ 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
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary.failover"></a>

Se imposti l'attributo di connessione `ApplicationIntent` aggiuntivo per l'endpoint su`ReadOnly`, 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 imposti`ApplicationIntent`, l' AWS DMS attività si connette solo al nodo primario (lettura/scrittura) del gruppo di disponibilità.

## Impostazioni degli endpoint quando si utilizza SQL Server come origine per AWS DMS
<a name="CHAP_Source.SQLServer.ConnectionAttrib"></a>

È 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](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), 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.

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

## Tipi di dati di origine per SQL Server
<a name="CHAP_Source.SQLServer.DataTypes"></a>

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, vedere[Tipi di dati per AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  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](CHAP_Tasks.LOBSupport.md).  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\$1VARIANT
+ 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.

# Acquisizione delle modifiche ai dati per la replica continua da SQL Server
<a name="CHAP_Source.SQLServer.CDC"></a>

Questo argomento descrive come configurare la replica CDC su un'origine SQL Server.

**Topics**
+ [Acquisizione delle modifiche ai dati per SQL Server autogestito on-premise o su Amazon EC2](#CHAP_Source.SQLServer.CDC.Selfmanaged)
+ [Configurazione della replica continua su un'istanza database di SQL Server nel cloud](#CHAP_Source.SQLServer.Configuration)

## Acquisizione delle modifiche ai dati per SQL Server autogestito on-premise o su Amazon EC2
<a name="CHAP_Source.SQLServer.CDC.Selfmanaged"></a>

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.

**Nota**  
Puoi usare lo script seguente per trovare tutte le tabelle senza una chiave primaria o unica:  

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

### Configurazione della replica continua su un SQL Server autogestito
<a name="CHAP_Source.SQLServer.CDC.MSCDC"></a>

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

**Topics**
+ [Configurazione della replica continua su un SQL Server autogestito: utilizzo del ruolo sysadmin](#CHAP_Source.SQLServer.CDC.MSCDC.Sysadmin)
+ [Configurazione della replica continua su un SQL Server autonomo: senza il ruolo sysadmin](#CHAP_SupportScripts.SQLServer.standalone)
+ [Configurazione della replica continua su SQL Server in un ambiente di gruppo di disponibilità senza il ruolo sysadmin](#CHAP_SupportScripts.SQLServer.ag)

#### Configurazione della replica continua su un SQL Server autogestito: utilizzo del ruolo sysadmin
<a name="CHAP_Source.SQLServer.CDC.MSCDC.Sysadmin"></a>

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](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Prerequisites). 

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.<a name="CHAP_Source.SQLServer.CDC.MSCDC.Setup"></a>

**Per configurare la distribuzione**

1. Connettiti al database di origine SQL Server utilizzando lo strumento SQL Server Management Studio (SSMS).

1. Apri il menu contestuale (pulsante destro del mouse) della cartella **Replica**, quindi scegli **Configura distribuzione**. Viene visualizzata la Configurazione guidata della distribuzione. 

1. Segui la procedura guidata per immettere i valori predefiniti e creare la distribuzione.<a name="CHAP_Source.SQLServer.CDC.MSCDC.Setup.CDC"></a>

**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 su, vedere. ECAs [Impostazioni degli endpoint](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.ConnectionAttrib)

Per le versioni AWS DMS precedenti alla 3.4.7 o per una replica di sola lettura come sorgente, effettuate le seguenti operazioni:

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

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

1. 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](https://msdn.microsoft.com/en-us/library/cc627369.aspx). 

#### Configurazione della replica continua su un SQL Server autonomo: senza il ruolo sysadmin
<a name="CHAP_SupportScripts.SQLServer.standalone"></a>

In questa sezione viene descritto come configurare la replica continua per un'origine database SQL Server indipendente che non richieda all'account utente di disporre di privilegi sysadmin.

**Nota**  
Dopo aver eseguito i passaggi indicati in questa sezione, l'utente DMS non sysadmin disporrà delle autorizzazioni necessarie per:  
Leggere le modifiche dal file di log delle transazioni online
Accedere al disco per leggere le modifiche dai file di backup del log delle transazioni
Aggiungere o modificare la pubblicazione utilizzata da DMS
Aggiungere articoli alla pubblicazione

1. Configura Microsoft SQL Server per la replica come descritto in [Acquisizione delle modifiche ai dati per la replica continua da SQL Server](#CHAP_Source.SQLServer.CDC).

1. Abilita la replica MS-REPLICATION sul database di origine. È possibile abilitare la replica manualmente oppure eseguendo l'attività una sola volta come utente sysadmin.

1. Crea lo schema `awsdms` nel database di origine utilizzando lo script seguente:

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

1. Crea la procedura `[awsdms].[rtm_dump_dblog]` nel database master utilizzando lo script seguente:

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

1. Crea il certificato nel database master utilizzando lo script seguente:

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

1. Crea l'accesso del certificato utilizzando lo script seguente: 

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

1. Aggiungi l'accesso al ruolo del server sysadmin utilizzando lo script seguente:

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

1. Aggiungi la firma a [master].[awsdms].[rtm\$1dump\$1dblog] con il certificato utilizzando lo script seguente: 

   ```
   Use [master]
   GO
   ADD SIGNATURE
   TO [master].[awsdms].[rtm_dump_dblog] BY CERTIFICATE [awsdms_rtm_dump_dblog_cert] WITH PASSWORD = '@5trongpassword';
   ```
**Nota**  
Se la stored procedure viene ricreata, è necessario aggiungere nuovamente la firma.

1. Crea [awsdms].[rtm\$1position\$11st\$1timestamp] sul database master utilizzando lo script seguente:

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

1. Crea il certificato nel database master utilizzando lo script seguente:

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

1. Crea l'accesso del certificato utilizzando lo script seguente:

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

1. Aggiungi l'accesso al ruolo sysadmin utilizzando lo script seguente:

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

1. Aggiungi la firma a [master].[awsdms].[rtm\$1position\$11st\$1timestamp] con il certificato utilizzando lo script seguente:

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

1. Fornisci all'utente DMS l'accesso in esecuzione alla nuova stored procedure utilizzando lo script seguente:

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

1. Crea un utente con le autorizzazioni e i ruoli descritti di seguito in ciascuno dei seguenti database:
**Nota**  
È necessario creare l'account utente dmsnosysadmin con lo stesso SID per ogni replica. La seguente query SQL può verificare il valore SID dell'account dmsnosysadmin per ogni replica. Per ulteriori informazioni sulla creazione di un utente, consulta [CREATE USER (Transact-SQL)](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql) nella [documentazione di Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/). Per ulteriori informazioni sulla creazione di account utente SQL per il database Azure SQL, consulta [Active geo-replication](https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview).

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

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

   Nel database di origine esegui lo script seguente:

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

1. Infine, aggiungi un attributo aggiuntivo di connessione all'endpoint SQL Server di origine:

   ```
   enableNonSysadminWrapper=true;
   ```

#### Configurazione della replica continua su SQL Server in un ambiente di gruppo di disponibilità senza il ruolo sysadmin
<a name="CHAP_SupportScripts.SQLServer.ag"></a>

In questa sezione viene descritto come configurare la replica continua per un'origine database SQL Server in un ambiente del gruppo di disponibilità che non richieda all'account utente di disporre di privilegi sysadmin.

**Nota**  
Dopo aver eseguito i passaggi indicati in questa sezione, l'utente DMS non sysadmin disporrà delle autorizzazioni necessarie per:  
Leggere le modifiche dal file di log delle transazioni online
Accedere al disco per leggere le modifiche dai file di backup del log delle transazioni
Aggiungere o modificare la pubblicazione utilizzata da DMS
Aggiungere articoli alla pubblicazione

**Per configurare la replica continua senza utilizzare l'utente sysadmin in un ambiente di gruppo di disponibilità**

1. Configura Microsoft SQL Server per la replica come descritto in [Acquisizione delle modifiche ai dati per la replica continua da SQL Server](#CHAP_Source.SQLServer.CDC).

1. Abilita la replica MS-REPLICATION sul database di origine. È possibile abilitare la replica manualmente oppure eseguendo l'attività una sola volta come utente sysadmin.
**Nota**  
È necessario configurare il distributore della replica MS-REPLICATION come locale o in modo da consentire l'accesso a utenti non sysadmin tramite il server collegato e associato.

1. Se l'opzione di endpoint **Usa esclusivamente sp\$1repldone in un singola attività** è abilitata, interrompi il processo di lettura dei log della replica MS-REPLICATION.

1. Per ogni replica completa le seguenti operazioni:

   1. Crea lo schema `[awsdms]`[awsdms] nel database master:

      ```
      CREATE SCHEMA [awsdms]
      ```

   1. Crea la funzione dei valori di tabella `[awsdms].[split_partition_list]` nel database master:

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

   1. Crea la procedura `[awsdms].[rtm_dump_dblog]` nel database master:

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

   1. Crea un certificato nel database master:

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

   1. Crea un accesso del certificato:

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

   1. Aggiungi l'accesso al ruolo del server sysadmin:

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

   1. Aggiungi la firma alla procedura [master].[awsdms].[rtm\$1dump\$1dblog] con il certificato:

      ```
      USE [master]
      GO
      
      ADD SIGNATURE
        TO [master].[awsdms].[rtm_dump_dblog]
        BY CERTIFICATE [awsdms_rtm_dump_dblog_cert]
        WITH PASSWORD = '@hardpassword1';
      ```
**Nota**  
Se la stored procedure viene ricreata, è necessario aggiungere nuovamente la firma.

   1. Crea la procedura `[awsdms].[rtm_position_1st_timestamp]` nel database master:

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

   1. Crea un certificato nel database master:

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

   1. Crea un accesso del certificato:

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

   1. Aggiungi l'accesso al ruolo del server sysadmin:

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

   1. Aggiungi la firma alla procedura `[master].[awsdms].[rtm_position_1st_timestamp]` con il certificato:

      ```
      USE [master]
      GO
      ADD SIGNATURE
        TO [master].[awsdms].[rtm_position_1st_timestamp]
        BY CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
        WITH PASSWORD = '@hardpassword1';
      ```
**Nota**  
Se la stored procedure viene ricreata, è necessario aggiungere nuovamente la firma.

   1. Crea un utente con quanto segue permissions/roles in ciascuno dei seguenti database:
**Nota**  
È necessario creare l'account utente dmsnosysadmin con lo stesso SID per ogni replica. La seguente query SQL può verificare il valore SID dell'account dmsnosysadmin per ogni replica. Per ulteriori informazioni sulla creazione di un utente, consulta [CREATE USER (Transact-SQL)](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql) nella [documentazione di Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/). Per ulteriori informazioni sulla creazione di account utente SQL per il database Azure SQL, consulta [Active geo-replication](https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview).

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

   1. Fornisci le autorizzazioni del database master per ogni replica:

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

   1. Fornisci le autorizzazioni del database msdb per ogni replica:

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

   1. Aggiungi il ruolo `db_owner` a `dmsnosysadmin` nel database di origine. Dal momento che il database è sincronizzato, è possibile aggiungere il ruolo solo nella replica primaria.

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

## Configurazione della replica continua su un'istanza database di SQL Server nel cloud
<a name="CHAP_Source.SQLServer.Configuration"></a>

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](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Limitations). 

Prima di configurare la replica continua, consulta [Prerequisiti per l'utilizzo della replica continua (CDC) da un'origine SQL Server](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Prerequisites). 

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

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

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

1. Imposta il periodo di conservazione:
   + Per le istanze di RDS per SQL Server che vengono replicate utilizzando la versione DMS 3.5.3 e successive, assicurati che il periodo di conservazione sia impostato sul valore predefinito di 5 secondi. Se stai effettuando l'aggiornamento o il passaggio da DMS 3.5.2 e versioni precedenti a DMS 3.5.3 e versioni successive, modifica il valore dell'intervallo di polling dopo l'esecuzione delle attività sull'istanza nuova o aggiornata. Lo script seguente imposta il periodo di conservazione su 5 secondi:

     ```
     use dbname
     EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 5
     exec sp_cdc_stop_job 'capture'
     exec sp_cdc_start_job 'capture'
     ```
   + 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 AWS DMS poterle leggere. Per determinare quali versioni di SQL Server sono interessate da questo problema noto, consulta [questo articolo della Knowledge Base di Microsoft](https://support.microsoft.com/en-us/topic/kb4459220-fix-incorrect-results-occur-when-you-convert-pollinginterval-parameter-from-seconds-to-hours-in-sys-sp-cdc-scan-in-sql-server-dac8aefe-b60b-7745-f987-582dda2cfa78).

     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' , <5 or preferred value>
     ```

**Per mantenere il periodo di conservazione quando un'attività di AWS DMS replica viene interrotta per più di un'ora**
**Nota**  
I passaggi seguenti non sono necessari per la replica di un codice sorgente RDS per SQL Server utilizzando DMS 3.5.3 e versioni successive.

1. Arresta il processo di troncamento dei log delle transazioni utilizzando il comando seguente. 

   ```
   exec sp_cdc_stop_job 'capture'
   ```

1. Trova l'attività sulla AWS DMS console e riprendila.

1. Scegli la scheda **Monitoraggio** e seleziona il parametro `CDCLatencySource`. 

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

### Impostazioni consigliate quando si utilizza RDS per SQL Server come origine per AWS DMS
<a name="CHAP_Source.SQLServer.Configuration.Settings"></a>

#### Per AWS DMS 3.5.3 e versioni successive
<a name="CHAP_Source.SQLServer.Configuration.Settings.353"></a>

**Nota**  
La versione iniziale della funzionalità di backup dei log di RDS per SQL Server è abilitata per impostazione predefinita per gli endpoint creati o modificati dopo il rilascio della versione DMS 3.5.3. Per utilizzare questa funzionalità per gli endpoint esistenti, modifica l'endpoint senza apportare modifiche.

AWS DMS la versione 3.5.3 introduce il supporto per la lettura dai backup dei log. DMS si basa principalmente sulla lettura dei log delle transazioni attivi per replicare gli eventi. Se viene eseguito il backup di una transazione prima che DMS possa leggerla dal registro attivo, l'attività accede ai backup RDS su richiesta e legge i registri di backup successivi fino a quando non raggiunge il log delle transazioni attivo. Per garantire che DMS abbia accesso ai backup dei log, imposta il periodo di conservazione dei backup automatizzati RDS su almeno un giorno. Per informazioni sull'impostazione del periodo di conservazione dei backup automatizzati, consulta [Periodo di conservazione dei backup](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingAutomatedBackups.html#USER_WorkingWithAutomatedBackups.BackupRetention) nella *Amazon RDS User Guide*.

Un'attività DMS che accede ai backup dei log utilizza lo storage sull'istanza RDS. Tieni presente che l'attività accede solo ai backup dei log necessari per la replica. Amazon RDS rimuove questi backup scaricati in un paio d'ore. Questa rimozione non influisce sui backup di Amazon RDS conservati in Amazon S3 o sulla funzionalità di Amazon RDS. `RESTORE DATABASE` È consigliabile allocare spazio di archiviazione aggiuntivo sulla sorgente RDS for SQL Server se si intende effettuare la replica utilizzando DMS. Un modo per stimare la quantità di storage necessaria consiste nell'identificare il backup da cui DMS inizierà o riprenderà la replica e sommare le dimensioni dei file di tutti i backup successivi utilizzando la funzione di metadati RDS. `tlog backup` Per ulteriori informazioni sulla `tlog backup` funzione, consulta [Elenco dei backup dei log delle transazioni disponibili](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER.SQLServer.AddlFeat.TransactionLogAccess.html#USER.SQLServer.AddlFeat.TransactionLogAccess.Listing) nella *Amazon RDS User* Guide. 

In alternativa, puoi scegliere di abilitare la scalabilità automatica dello storage e/o attivare la scalabilità dello storage in base al parametro CloudWatch `FreeStorageSpace` per la tua istanza Amazon RDS.

Ti consigliamo vivamente di non avviare o riprendere i backup del registro delle transazioni da un punto troppo indietro nel tempo, poiché ciò potrebbe comportare il riempimento dello storage sull'istanza di SQL Server. In questi casi, è consigliabile avviare un caricamento completo. La replica dal backup del registro delle transazioni è più lenta della lettura dai log delle transazioni attivi. Per ulteriori informazioni, consulta [Elaborazione del backup del registro delle transazioni per RDS per SQL Server](CHAP_Troubleshooting_Latency_Source_SQLServer.md#CHAP_Troubleshooting_Latency_Source_SQLServer_backup).

Si noti che l'accesso ai backup dei log richiede privilegi aggiuntivi. Per ulteriori informazioni, vedere quanto descritto in dettaglio in [Configura le autorizzazioni per la replica continua da un database SQL Server cloud](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Permissions.Cloud) Assicurarsi di concedere questi privilegi prima che l'attività inizi a replicarsi.

#### Per la versione AWS DMS 3.5.2 e versioni precedenti
<a name="CHAP_Source.SQLServer.Configuration.Settings.352"></a>

Quando utilizzi Amazon RDS for SQL Server come sorgente, il processo di acquisizione MS-CDC si basa sui parametri e. `maxscans` `maxtrans` Questi parametri determinano il numero massimo di scansioni eseguite dall'acquisizione MS-CDC nel registro 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.

Si noti 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**

1. Verificate la provenienza `Log Space Used %` da cui AWS DMS viene eseguita la replica del database e verificate che aumenti continuamente.

   ```
   DBCC SQLPERF(LOGSPACE)
   ```

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

1. 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](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/administer-and-monitor-change-data-capture-sql-server?view=sql-server-ver15#Monitor) 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 (LSNs) 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.