

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

# Origini per la migrazione dei dati
<a name="CHAP_Source"></a>

AWS Database Migration Service (AWS DMS) può utilizzare molti dei motori di dati più diffusi come fonte per la replica dei dati. L'origine del database può essere un motore autogestito in esecuzione su un'istanza Amazon EC2 o un database on-premise. Oppure può essere una fonte di dati su un AWS servizio come Amazon RDS o Amazon S3.

Per l'elenco completo di origini valide, consulta [Origini per AWS DMS](CHAP_Introduction.Sources.md#CHAP_Introduction.Sources.title).

**Topics**
+ [Utilizzo di un database Oracle come fonte per AWS DMS](CHAP_Source.Oracle.md)
+ [Utilizzo di un database Microsoft SQL Server come origine per AWS DMS](CHAP_Source.SQLServer.md)
+ [Utilizzo del database SQL di Microsoft Azure come origine per AWS DMS](CHAP_Source.AzureSQL.md)
+ [Utilizzo di Microsoft Azure SQL Managed Instance come origine per AWS DMS](CHAP_Source.AzureMgd.md)
+ [Utilizzo del server flessibile Microsoft Azure Database per PostgreSQL come origine per AWS DMS](CHAP_Source.AzureDBPostgreSQL.md)
+ [Utilizzo del server flessibile Microsoft Azure Database per MySQL come origine per AWS DMS](CHAP_Source.AzureDBMySQL.md)
+ [Utilizzo di OCI MySQL Heatwave come fonte per AWS DMS](CHAP_Source.heatwave.md)
+ [Utilizzo di Google Cloud for MySQL come fonte per AWS DMS](CHAP_Source.GC.md)
+ [Utilizzo di Google Cloud per PostgreSQL come sorgente per AWS DMS](CHAP_Source.GCPostgres.md)
+ [Utilizzo di un database PostgreSQL come sorgente AWS DMS](CHAP_Source.PostgreSQL.md)
+ [Utilizzo di un database compatibile con MySQL come fonte per AWS DMS](CHAP_Source.MySQL.md)
+ [Utilizzo di un database SAP ASE come fonte per AWS DMS](CHAP_Source.SAP.md)
+ [Usare MongoDB come fonte per AWS DMS](CHAP_Source.MongoDB.md)
+ [Utilizzo di Amazon DocumentDB (con compatibilità con MongoDB) come fonte per AWS DMS](CHAP_Source.DocumentDB.md)
+ [Utilizzo di Amazon S3 come sorgente per AWS DMS](CHAP_Source.S3.md)
+ [Utilizzo di IBM Db2 per Linux, Unix, Windows e database Amazon RDS (Db2 LUW) come origine per AWS DMS](CHAP_Source.DB2.md)
+ [Utilizzo di IBM Db2 per i z/OS database come fonte per AWS DMS](CHAP_Source.DB2zOS.md)

# Utilizzo di un database Oracle come fonte per AWS DMS
<a name="CHAP_Source.Oracle"></a>

È possibile migrare i dati da uno o più database Oracle utilizzando AWS DMS. Con un database Oracle come origine, puoi eseguire la migrazione dei dati a una delle destinazioni supportate da AWS DMS.

AWS DMS supporta le seguenti edizioni del database Oracle:
+ Oracle Enterprise Edition
+ Oracle Standard Edition
+ Oracle Express Edition
+ Oracle Personal Edition

Per informazioni sulle versioni dei database Oracle AWS DMS supportate come origine, vedere[Fonti per AWS DMS](CHAP_Introduction.Sources.md).

Puoi utilizzare il protocollo Secure Sockets Layer (SSL) per crittografare le connessioni tra l'endpoint Oracle e l'istanza di replica. Per ulteriori informazioni sull'utilizzo di SSL con un endpoint Oracle, consulta [Supporto SSL per un endpoint Oracle](#CHAP_Security.SSL.Oracle).

AWS DMS supporta l'uso di Oracle Transparent Data Encryption (TDE) per crittografare i dati inattivi nel database di origine. Per ulteriori informazioni sull'utilizzo di Oracle TDE con un endpoint di origine Oracle, consulta [Metodi di crittografia supportati per l'utilizzo di Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.Encryption).

AWS supporta l'uso di TLS versione 1.2 e successive con gli endpoint Oracle (e tutti gli altri tipi di endpoint) e consiglia l'utilizzo di TLS versione 1.3 o successiva.

Segui questi passaggi per configurare un database Oracle come endpoint di origine: AWS DMS 

1. Crea un utente Oracle con le autorizzazioni appropriate per accedere AWS DMS al tuo database di origine Oracle.

1. Crea un endpoint di origine Oracle conforme alla configurazione del database Oracle scelta. Per creare un full-load-only task, non sono necessarie ulteriori configurazioni.

1. Per creare un'attività che gestisca l'acquisizione dei dati di modifica (un'attività solo CDC o a pieno carico e CDC), scegli Oracle LogMiner o AWS DMS Binary Reader per acquisire le modifiche ai dati. La scelta LogMiner di Binary Reader determina alcune delle autorizzazioni e delle opzioni di configurazione successive. Per un confronto tra Binary Reader, consultate la sezione seguente. LogMiner 

**Nota**  
Per ulteriori informazioni sulle attività di pieno carico, sola CDC e di pieno carico e CDC, consulta [Creazione di un'attività](CHAP_Tasks.Creating.md)

Per ulteriori dettagli sull'utilizzo dei database di origine Oracle e AWS DMS, vedere le seguenti sezioni. 

**Topics**
+ [Utilizzo di Oracle LogMiner o AWS DMS Binary Reader for CDC](#CHAP_Source.Oracle.CDC)
+ [Flussi di lavoro per la configurazione di un database di origine Oracle autogestito o gestito per AWS AWS DMSConfigurazione di un database di origine Oracle](#CHAP_Source.Oracle.Workflows)
+ [Utilizzo di un database Oracle autogestito come fonte per AWS DMS](#CHAP_Source.Oracle.Self-Managed)
+ [Utilizzo di un database Oracle AWS gestito come fonte per AWS DMS](#CHAP_Source.Oracle.Amazon-Managed)
+ [Limitazioni all'uso di Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.Limitations)
+ [Supporto SSL per un endpoint Oracle](#CHAP_Security.SSL.Oracle)
+ [Metodi di crittografia supportati per l'utilizzo di Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.Encryption)
+ [Metodi di compressione supportati per l'utilizzo di Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.Compression)
+ [Replica di tabelle annidate utilizzando Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.NestedTables)
+ [Memorizzazione di REDO su Oracle ASM quando si utilizza Oracle come origine per AWS DMS](#CHAP_Source.Oracle.REDOonASM)
+ [Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib)
+ [Tipi di dati di origine per Oracle](#CHAP_Source.Oracle.DataTypes)

## Utilizzo di Oracle LogMiner o AWS DMS Binary Reader for CDC
<a name="CHAP_Source.Oracle.CDC"></a>

In AWS DMS, esistono due metodi per leggere i redo log quando si esegue l'acquisizione dei dati di modifica (CDC) per Oracle come fonte: Oracle LogMiner e AWS DMS Binary Reader. LogMiner è un'API Oracle per leggere i redo log online e i redo log file archiviati. Binary Reader è un AWS DMS metodo che legge e analizza direttamente i redo log file non elaborati. Questi metodi hanno le seguenti funzionalità.


| Funzionalità | LogMiner | Binary Reader | 
| --- | --- | --- | 
| Facilità di configurazione | Sì | No | 
| Minore impatto sul sistema di origine e sulla CPU I/O  | No | Sì | 
| Prestazioni CDC migliorate | No | Sì | 
| Supporto per i cluster di tabelle Oracle | Sì | No | 
| Supporto per tutti i tipi di Oracle Hybrid Columnar Compression (HCC) | Sì |  Parzialmente Binary Reader non supporta QUERY LOW per le attività con CDC. Tutti gli altri tipi di HCC sono completamente supportati.  | 
| Supporto per colonne LOB solo in Oracle 12c | No (il supporto LOB non è disponibile con LogMiner Oracle 12c). | Sì | 
| Supporto per le istruzioni UPDATE che riguardano solo le colonne LOB | No | Sì | 
| Supporto per Oracle Transparent Data Encryption (TDE) |  Parzialmente Quando si utilizza Oracle LogMiner, AWS DMS non supporta la crittografia TDE a livello di colonna per Amazon RDS for Oracle.  |  Parzialmente Binary Reader supporta la crittografia TDE solo per i database Oracle autogestiti.  | 
| Supporto per tutti i metodi di compressione Oracle | Sì | No | 
| Supporto per transazioni XA | No | Sì | 
| RAC |  Sì Non consigliato, per motivi di prestazioni e per alcune limitazioni interne del DMS.  |  Sì Altamente consigliato  | 

**Nota**  
Per impostazione predefinita, AWS DMS utilizza Oracle LogMiner for (CDC).   
AWS DMS supporta i metodi di crittografia trasparente dei dati (TDE) quando si lavora con un database di origine Oracle. Se le credenziali TDE specificate non sono corrette, l'attività di AWS DMS migrazione non ha esito negativo, il che può influire sulla replica continua delle tabelle crittografate. Per ulteriori informazioni sulla specifica delle credenziali TDE, consulta [Metodi di crittografia supportati per l'utilizzo di Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.Encryption).

I principali vantaggi dell'utilizzo di LogMiner with AWS DMS includono quanto segue:
+ LogMiner supporta la maggior parte delle opzioni Oracle, come le opzioni di crittografia e le opzioni di compressione. Binary Reader non supporta tutte le opzioni Oracle, in particolare la compressione e la maggior parte delle opzioni di crittografia.
+ LogMiner offre una configurazione più semplice, soprattutto rispetto alla configurazione ad accesso diretto di Binary Reader o quando i redo log vengono gestiti utilizzando Oracle Automatic Storage Management (ASM).
+ LogMiner supporta i cluster di tabelle utilizzabili da. AWS DMS Binary Reader no.

I principali vantaggi dell'utilizzo di Binary Reader con AWS DMS includono:
+ Per le migrazioni con un elevato volume di modifiche, LogMiner potrebbero avere un impatto parziale I/O o sulla CPU sul computer che ospita il database di origine Oracle. Binary Reader ha meno probabilità di avere I/O un impatto sulla CPU perché i log vengono estratti direttamente anziché effettuare più query sul database.
+ Per le migrazioni con un elevato volume di modifiche, le prestazioni del CDC sono generalmente molto migliori quando si utilizza Binary Reader rispetto a Oracle. LogMiner
+ Binary Reader supporta CDC LOBs nella versione Oracle 12c. LogMiner non lo fa.

In generale, utilizza Oracle LogMiner per la migrazione del database Oracle a meno che non si verifichi una delle seguenti situazioni:
+ È necessario eseguire molte attività di migrazione sul database di origine Oracle.
+ Il volume delle modifiche o dei log redo nel database Oracle di origine è elevato oppure si dispone delle modifiche e si utilizza anche Oracle ASM.

**Nota**  
Se passi dall'utilizzo di LogMiner Oracle a quello di AWS DMS Binary Reader, assicurati di riavviare l'attività CDC. 

### Configurazione dell'attività di CDC su un database di origine Oracle
<a name="CHAP_Source.Oracle.CDC.Configuration"></a>

Per consentire a un endpoint di origine Oracle di connettersi al database per un'attività di acquisizione dei dati di modifica (CDC), potrebbe essere necessario specificare gli attributi aggiuntivi di connessione. Questo è valido per un'attività di pieno carico e CDC o per un'attività di sola CDC. Gli attributi di connessione aggiuntivi specificati dipendono dal metodo utilizzato per accedere ai redo log: Oracle LogMiner o AWS DMS Binary Reader. 

Gli attributi aggiuntivi di connessione si specificano al momento della creazione di un endpoint di origine. Se sono presenti più impostazioni di attributi di connessione, separale tra loro mediante punti e virgola senza inserire spazi vuoti (ad esempio `oneSetting;thenAnother`).

AWS DMS utilizza per impostazione LogMiner predefinita. Non è necessario specificare gli attributi aggiuntivi di connessione per utilizzarlo. 

Per usare Binary Reader per accedere ai log redo, aggiungi i seguenti attributi aggiuntivi di connessione.

```
useLogMinerReader=N;useBfile=Y;
```

Usa il seguente formato per gli attributi di connessione aggiuntivi per accedere a un server che usa ASM con Binary Reader.

```
useLogMinerReader=N;useBfile=Y;asm_user=asm_username;asm_server=RAC_server_ip_address:port_number/+ASM;
```

Imposta il parametro di richiesta `Password` dell’endpoint sorgente sia per la password dell’utente Oracle sia per la password ASM, separate da una virgola come segue.

```
oracle_user_password,asm_user_password
```

Se l'origine Oracle utilizza ASM, è possibile utilizzare opzioni ad alte prestazioni in Binary Reader per l'elaborazione delle transazioni su larga scala. Queste opzioni includono attributi di connessione aggiuntivi per specificare il numero di thread paralleli (`parallelASMReadThreads`) e il numero di buffer read-ahead (`readAheadBlocks`). L'impostazione congiunta di questi attributi è in grado di migliorare sensibilmente le prestazioni dell'attività di CDC. Le seguenti impostazioni forniscono buoni risultati per la maggior parte delle configurazioni ASM.

```
useLogMinerReader=N;useBfile=Y;asm_user=asm_username;asm_server=RAC_server_ip_address:port_number/+ASM;
    parallelASMReadThreads=6;readAheadBlocks=150000;
```

Per ulteriori informazioni sui valori supportati dagli attributi di connessione aggiuntivi, consulta [Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib).

Inoltre, le prestazioni di un'attività di CDC con un'origine Oracle che utilizza ASM dipende da altre impostazioni scelte. Queste impostazioni includono gli attributi di connessione AWS DMS aggiuntivi e le impostazioni di configurazione di SQL dell'origine Oracle. Per ulteriori informazioni sugli attributi aggiuntivi di connessione per un'origine Oracle che utilizza ASM, consulta [Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib).

È inoltre necessario scegliere un punto di partenza appropriato per l'attività di CDC. In genere, quando si esegue questa operazione, si desidera identificare il punto di elaborazione della transazione che acquisisce la prima transazione aperta da cui iniziare l'attività di CDC. In caso contrario, l'attività di CDC può perdere le transazioni aperte in precedenza. Per un database di origine Oracle, puoi scegliere per l'attività di CDC un punto di partenza nativo basato sul numero di modifica del sistema (SCN) di Oracle per identificare la prima transazione aperta. Per ulteriori informazioni, consulta [Esecuzione della replica a partire da un punto di inizio CDC](CHAP_Task.CDC.md#CHAP_Task.CDC.StartPoint).

Per ulteriori informazioni sulla configurazione dell'attività di CDC per un database Oracle autogestito come origine, consulta [I privilegi dell'account sono richiesti quando si utilizza Oracle LogMiner per accedere ai redo log](#CHAP_Source.Oracle.Self-Managed.LogMinerPrivileges), [I privilegi dell'account sono necessari quando si utilizza AWS DMS Binary Reader per accedere ai redo log](#CHAP_Source.Oracle.Self-Managed.BinaryReaderPrivileges) e [Privilegi dell'account aggiuntivi necessari quando si utilizza Binary Reader con Oracle ASM](#CHAP_Source.Oracle.Self-Managed.ASMBinaryPrivileges).

Per ulteriori informazioni sulla configurazione di CDC per un database Oracle AWS gestito come origine, consulta e. [Configurazione di un'attività CDC per l'utilizzo di Binary Reader con un codice sorgente RDS for Oracle per AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC) [Utilizzo di un Amazon RDS Oracle Standby (leggi replica) come sorgente con Binary Reader for CDC in AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.StandBy)

## Flussi di lavoro per la configurazione di un database di origine Oracle autogestito o gestito per AWS AWS DMS


## Configurazione di un database di origine Oracle
<a name="CHAP_Source.Oracle.Workflows"></a>

Per configurare un'istanza database di origine autogestito, utilizza le seguenti fasi del flusso di lavoro, a seconda di come esegui l'attività di CDC. 


| Per questa fase del flusso di lavoro | Se esegui CDC utilizzando CDC, esegui questa operazione LogMiner | Se esegui l'attività di CDC usando Binary Reader | 
| --- | --- | --- | 
| Concedi i privilegi dell'account Oracle. | Consulta [Privilegi dell'account utente richiesti su una fonte Oracle autogestita per AWS DMS](#CHAP_Source.Oracle.Self-Managed.Privileges). | Per informazioni, consulta [Privilegi dell'account utente richiesti su una fonte Oracle autogestita per AWS DMS](#CHAP_Source.Oracle.Self-Managed.Privileges). | 
| Prepara il database di origine per la replica utilizzando l'attività di CDC. | Per informazioni, consulta [Preparazione di un database di origine Oracle autogestito per CDC utilizzando AWS DMS](#CHAP_Source.Oracle.Self-Managed.Configuration). | Per informazioni, consulta [Preparazione di un database di origine Oracle autogestito per CDC utilizzando AWS DMS](#CHAP_Source.Oracle.Self-Managed.Configuration). | 
| Fornisci i privilegi dell'utente Oracle aggiuntivi necessari per l'attività di CDC. | Per informazioni, consulta [I privilegi dell'account sono richiesti quando si utilizza Oracle LogMiner per accedere ai redo log](#CHAP_Source.Oracle.Self-Managed.LogMinerPrivileges). | Per informazioni, consulta [I privilegi dell'account sono necessari quando si utilizza AWS DMS Binary Reader per accedere ai redo log](#CHAP_Source.Oracle.Self-Managed.BinaryReaderPrivileges). | 
| Per un'istanza Oracle con ASM, fornisci i privilegi dell'account utente aggiuntivi, necessari per accedere ad ASM per l'attività di CDC. | Nessuna azione aggiuntiva. AWS DMS supporta Oracle ASM senza privilegi di account aggiuntivi. | Per informazioni, consulta [Privilegi dell'account aggiuntivi necessari quando si utilizza Binary Reader con Oracle ASM](#CHAP_Source.Oracle.Self-Managed.ASMBinaryPrivileges). | 
| Se non l'hai già fatto, configura l'attività per utilizzare LogMiner o Binary Reader for CDC. | Per informazioni, consulta [Utilizzo di Oracle LogMiner o AWS DMS Binary Reader for CDC](#CHAP_Source.Oracle.CDC). | Per informazioni, consulta [Utilizzo di Oracle LogMiner o AWS DMS Binary Reader for CDC](#CHAP_Source.Oracle.CDC). | 
| Configura Oracle Standby come origine per l'attività di CDC. | AWS DMS non supporta Oracle Standby come fonte. | Per informazioni, consulta [Utilizzo di un Oracle Standby autogestito come sorgente con Binary Reader for CDC in AWS DMS](#CHAP_Source.Oracle.Self-Managed.BinaryStandby). | 

Utilizzare i seguenti passaggi del flusso di lavoro per configurare un'istanza del database AWS di origine Oracle gestita.


| Per questa fase del flusso di lavoro | Se esegui CDC utilizzando LogMiner, procedi come segue | Se esegui l'attività di CDC usando Binary Reader | 
| --- | --- | --- | 
| Concedi i privilegi dell'account Oracle. | Per ulteriori informazioni, consulta [Privilegi di account utente richiesti su una fonte Oracle gestita per AWS AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Privileges). | Per ulteriori informazioni, consulta [Privilegi di account utente richiesti su una fonte Oracle gestita per AWS AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Privileges). | 
| Prepara il database di origine per la replica utilizzando l'attività di CDC. | Per ulteriori informazioni, consulta [Configurazione di una fonte Oracle gestita per AWS AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Configuration). | Per ulteriori informazioni, consulta [Configurazione di una fonte Oracle gestita per AWS AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Configuration). | 
| Fornisci i privilegi dell'utente Oracle aggiuntivi necessari per l'attività di CDC. | Non sono necessari altri privilegi dell'account. | Per ulteriori informazioni, consulta [Configurazione di un'attività CDC per l'utilizzo di Binary Reader con un codice sorgente RDS for Oracle per AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). | 
| Se non l'hai già fatto, configura l'attività in modo che utilizzi LogMiner o Binary Reader for CDC. | Per ulteriori informazioni, consulta [Utilizzo di Oracle LogMiner o AWS DMS Binary Reader for CDC](#CHAP_Source.Oracle.CDC). | Per ulteriori informazioni, consulta [Utilizzo di Oracle LogMiner o AWS DMS Binary Reader for CDC](#CHAP_Source.Oracle.CDC). | 
| Configura Oracle Standby come origine per l'attività di CDC. | AWS DMS non supporta Oracle Standby come fonte. | Per ulteriori informazioni, consulta [Utilizzo di un Amazon RDS Oracle Standby (leggi replica) come sorgente con Binary Reader for CDC in AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.StandBy). | 

## Utilizzo di un database Oracle autogestito come fonte per AWS DMS
<a name="CHAP_Source.Oracle.Self-Managed"></a>

Il *database autogestito* è quello puoi configurare e controllare e può trattarsi sia di un'istanza database on-premise che di un database in esecuzione su Amazon EC2. Di seguito, puoi scoprire i privilegi e le configurazioni necessari quando utilizzi un database Oracle autogestito con. AWS DMS

### Privilegi dell'account utente richiesti su una fonte Oracle autogestita per AWS DMS
<a name="CHAP_Source.Oracle.Self-Managed.Privileges"></a>

Per utilizzare un database Oracle come origine in AWS DMS, concedi i seguenti privilegi all'utente Oracle specificato nelle impostazioni di connessione dell'endpoint Oracle.

**Nota**  
Durante la concessione dei privilegi, utilizza il nome effettivo degli oggetti e non i relativi sinonimi. Ad esempio, utilizza `V_$OBJECT` includendo il carattere di sottolineatura, non `V$OBJECT` senza il carattere di sottolineatura.

```
GRANT CREATE SESSION TO dms_user;
GRANT SELECT ANY TRANSACTION TO dms_user;
GRANT SELECT ON V_$ARCHIVED_LOG TO dms_user;
GRANT SELECT ON V_$LOG TO dms_user;
GRANT SELECT ON V_$LOGFILE TO dms_user;
GRANT SELECT ON V_$LOGMNR_LOGS TO dms_user;
GRANT SELECT ON V_$LOGMNR_CONTENTS TO dms_user;
GRANT SELECT ON V_$DATABASE TO dms_user;
GRANT SELECT ON V_$THREAD TO dms_user;
GRANT SELECT ON V_$PARAMETER TO dms_user;
GRANT SELECT ON V_$NLS_PARAMETERS TO dms_user;
GRANT SELECT ON V_$TIMEZONE_NAMES TO dms_user;
GRANT SELECT ON V_$TRANSACTION TO dms_user;
GRANT SELECT ON V_$CONTAINERS TO dms_user;                   
GRANT SELECT ON ALL_INDEXES TO dms_user;
GRANT SELECT ON ALL_OBJECTS TO dms_user;
GRANT SELECT ON ALL_TABLES TO dms_user;
GRANT SELECT ON ALL_USERS TO dms_user;
GRANT SELECT ON ALL_CATALOG TO dms_user;
GRANT SELECT ON ALL_CONSTRAINTS TO dms_user;
GRANT SELECT ON ALL_CONS_COLUMNS TO dms_user;
GRANT SELECT ON ALL_TAB_COLS TO dms_user;
GRANT SELECT ON ALL_IND_COLUMNS TO dms_user;
GRANT SELECT ON ALL_ENCRYPTED_COLUMNS TO dms_user;
GRANT SELECT ON ALL_LOG_GROUPS TO dms_user;
GRANT SELECT ON ALL_TAB_PARTITIONS TO dms_user;
GRANT SELECT ON SYS.DBA_REGISTRY TO dms_user;
GRANT SELECT ON SYS.OBJ$ TO dms_user;
GRANT SELECT ON DBA_TABLESPACES TO dms_user;
GRANT SELECT ON DBA_OBJECTS TO dms_user; -– Required if the Oracle version is earlier than 11.2.0.3.
GRANT SELECT ON SYS.ENC$ TO dms_user; -– Required if transparent data encryption (TDE) is enabled. For more information on using Oracle TDE with AWS DMS, see Metodi di crittografia supportati per l'utilizzo di Oracle come fonte per AWS DMS.
GRANT SELECT ON GV_$TRANSACTION TO dms_user; -– Required if the source database is Oracle RAC in AWS DMS versions 3.4.6 and higher.
GRANT SELECT ON V_$DATAGUARD_STATS TO dms_user; -- Required if the source database is Oracle Data Guard and Oracle Standby is used in the latest release of DMS version 3.4.6, version 3.4.7, and higher.
GRANT SELECT ON V_$DATABASE_INCARNATION TO dms_user;
```

Concedi il seguente privilegio aggiuntivo per ogni tabella replicata quando utilizzi un elenco di tabelle specifico.

```
GRANT SELECT on any-replicated-table to dms_user;
```

Concedi il seguente privilegio aggiuntivo per utilizzare la funzione di convalida.

```
GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_user;
```

Concedi il seguente privilegio aggiuntivo se utilizzi il lettore binario anziché. LogMiner

```
GRANT SELECT ON SYS.DBA_DIRECTORIES TO dms_user;
```

Concedi il seguente privilegio aggiuntivo per esporre le viste.

```
GRANT SELECT on ALL_VIEWS to dms_user;
```

Per esporre le viste, devi anche aggiungere l'attributo aggiuntivo di connessione `exposeViews=true` all'endpoint di origine.

Concedi il seguente privilegio aggiuntivo quando utilizzi le repliche serverless.

```
GRANT SELECT on dba_segments to dms_user;
GRANT SELECT on v_$tablespace to dms_user;
GRANT SELECT on dba_tab_subpartitions to dms_user;
GRANT SELECT on dba_extents to dms_user;
```

Per informazioni sulle repliche serverless, consulta [Lavorare con AWS DMS Serverless](CHAP_Serverless.md).

Concedi i seguenti privilegi aggiuntivi quando utilizzi le valutazioni di premigrazione specifiche di Oracle.

```
GRANT SELECT on gv_$parameter  to dms_user;
GRANT SELECT on v_$instance to dms_user;
GRANT SELECT on v_$version to dms_user;
GRANT SELECT on gv_$ASM_DISKGROUP to dms_user;
GRANT SELECT on gv_$database to dms_user;
GRANT SELECT on dba_db_links to dms_user;
GRANT SELECT on gv_$log_History to dms_user;
GRANT SELECT on gv_$log to dms_user;
GRANT SELECT ON DBA_TYPES TO dms_user;
GRANT SELECT ON DBA_USERS to dms_user;
GRANT SELECT ON DBA_DIRECTORIES to dms_user;
GRANT EXECUTE ON SYS.DBMS_XMLGEN TO dms_user;
```

Per informazioni sulle valutazioni di premigrazione specifiche di Oracle, consulta [Valutazioni Oracle](CHAP_Tasks.AssessmentReport.Oracle.md).

#### Prerequisiti per la gestione delle transazioni aperte per Oracle Standby
<a name="CHAP_Source.Oracle.Self-Managed.Privileges.Standby"></a>

Quando si utilizzano AWS DMS le versioni 3.4.6 e successive, effettuare le seguenti operazioni per gestire le transazioni aperte per Oracle Standby. 

1. Crea un collegamento di database denominato `AWSDMS_DBLINK` nel database primario. `DMS_USER` utilizzerà il collegamento per connettersi al database primario. Tieni presente che il collegamento di database viene eseguito dall'istanza di standby per eseguire query sulle transazioni aperte in esecuzione nel database primario. Guarda l'esempio seguente. 

   ```
   CREATE PUBLIC DATABASE LINK AWSDMS_DBLINK 
      CONNECT TO DMS_USER IDENTIFIED BY DMS_USER_PASSWORD
      USING '(DESCRIPTION=
               (ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_HOST_NAME_OR_IP)(PORT=PORT))
               (CONNECT_DATA=(SERVICE_NAME=SID))
             )';
   ```

1. Verifica che sia stata stabilita la connessione al collegamento di database usando `DMS_USER`, come illustrato nell'esempio seguente.

   ```
   select 1 from dual@AWSDMS_DBLINK
   ```

### Preparazione di un database di origine Oracle autogestito per CDC utilizzando AWS DMS
<a name="CHAP_Source.Oracle.Self-Managed.Configuration"></a>

Prepara il database Oracle autogestito come origine per eseguire un'attività di CDC effettuando le seguenti operazioni: 
+ [Verifica che AWS DMS supporti la versione del database di origine](#CHAP_Source.Oracle.Self-Managed.Configuration.DbVersion).
+ [Verifica che la modalità ARCHIVELOG sia attiva](#CHAP_Source.Oracle.Self-Managed.Configuration.ArchiveLogMode).
+ [Impostazione del log supplementare](#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging).

#### Verifica che AWS DMS supporti la versione del database di origine
<a name="CHAP_Source.Oracle.Self-Managed.Configuration.DbVersion"></a>

Esegui una query come la seguente per verificare che la versione corrente del database di origine Oracle sia supportata da AWS DMS.

```
SELECT name, value, description FROM v$parameter WHERE name = 'compatible';
```

Qui, `name`, `value` e `description` sono colonne presenti da qualche parte nel database che vengono interrogate in base al valore di `name`. Se questa query viene eseguita senza errori, AWS DMS supporta la versione corrente del database ed è possibile continuare con la migrazione. Se la query genera un errore, AWS DMS significa che non supporta la versione corrente del database. Per procedere con la migrazione, converti innanzitutto il database Oracle in una versione supportata da AWS DMS.

#### Verifica che la modalità ARCHIVELOG sia attiva
<a name="CHAP_Source.Oracle.Self-Managed.Configuration.ArchiveLogMode"></a>

Puoi eseguire Oracle in due diverse modalità: la modalità `ARCHIVELOG` e la modalità `NOARCHIVELOG`. Per eseguire un'attività di CDC, esegui il database in modalità `ARCHIVELOG`. Per sapere se il database è in modalità `ARCHIVELOG`, esegui la seguente query.

```
SQL> SELECT log_mode FROM v$database;
```

Se viene restituita la modalità `NOARCHIVELOG`, imposta il database su `ARCHIVELOG` in base alle istruzioni di Oracle. 

#### Impostazione del log supplementare
<a name="CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging"></a>

Per acquisire le modifiche in corso, è AWS DMS necessario abilitare una registrazione supplementare minima sul database di origine Oracle. Inoltre, è necessario abilitare il log supplementare per ogni tabella replicata nel database.

Per impostazione predefinita, AWS DMS aggiunge una registrazione `PRIMARY KEY` supplementare su tutte le tabelle replicate. AWS DMS Per consentire l'aggiunta di log `PRIMARY KEY` supplementari, concedi il seguente privilegio per ogni tabella replicata.

```
ALTER on any-replicated-table;
```

È possibile disabilitare la registrazione `PRIMARY KEY` supplementare predefinita aggiunta utilizzando AWS DMS l'attributo extra connection. `addSupplementalLogging` Per ulteriori informazioni, consulta [Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib).

Assicuratevi di attivare la registrazione supplementare se l'attività di replica aggiorna una tabella utilizzando una `WHERE` clausola che non fa riferimento a una colonna chiave primaria.

**Per impostare manualmente il log supplementare**

1. Esegui la seguente query per verificare che il log supplementare sia abilitato sul database.

   ```
   SELECT supplemental_log_data_min FROM v$database;
   ```

   Se il risultato restituito è `YES` o `IMPLICIT`, il log supplementare è abilitato sul database.

   In caso contrario, abilita il log supplementare sul database eseguendo il seguente comando.

   ```
   ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
   ```

1. Assicurati che venga aggiunto il log supplementare richiesto per ogni tabella replicata.

   Considera i seguenti aspetti:
   + Se alla tabella viene aggiunto il log supplementare `ALL COLUMNS`, non è necessario aggiungere altri log.
   + Se esiste una chiave primaria, aggiungi il log supplementare per la chiave primaria. Puoi eseguire questa operazione utilizzando il formato per aggiungere il log supplementare sulla chiave primaria oppure aggiungendo il log supplementare sulle colonne della chiave primaria nel database.

     ```
     ALTER TABLE Tablename ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
     ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
     ```
   + Se non esiste una chiave primaria e la tabella dispone di un unico indice univoco, aggiungi tutte le colonne dell'indice univoco ai log supplementari.

     ```
     ALTER TABLE TableName ADD SUPPLEMENTAL LOG GROUP LogGroupName (UniqueIndexColumn1[, UniqueIndexColumn2] ...) ALWAYS;
     ```

     Using `SUPPLEMENTAL LOG DATA (UNIQUE INDEX) COLUMNS` non aggiunge le colonne di indice univoche al registro.
   + Se non esiste una chiave primaria e la tabella ha più indici univoci, AWS DMS seleziona il primo indice univoco in un elenco crescente in ordine alfabetico. È necessario aggiungere un log supplementare sulle colonne dell'indice selezionato come nell'elemento precedente.

     Using `SUPPLEMENTAL LOG DATA (UNIQUE INDEX) COLUMNS` non aggiunge le colonne dell'indice univoco al registro.
   + Se non esiste una chiave primaria e non esiste un indice univoco, aggiungere il log supplementare su tutte le colonne.

     ```
     ALTER TABLE TableName ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
     ```

     In alcuni casi, la chiave primaria o l'indice univoco della tabella di destinazione sono diversi da quelli della tabella di origine. In questi casi, aggiungi il log supplementare sulle colonne della tabella di origine che compongono la chiave primaria o l'indice univoco.

     Se modifichi la chiave primaria della tabella di destinazione, è necessario aggiungere il log supplementare sulle colonne dell'indice selezionato invece che sulle colonne della chiave primaria o dell'indice univoco originali.

Se per una tabella sono definiti un filtro o una trasformazione, potrebbe essere necessario abilitare un logging aggiuntivo.

Considera i seguenti aspetti:
+ Se alla tabella viene aggiunto il log supplementare `ALL COLUMNS`, non è necessario aggiungere altri log.
+ Se una tabella dispone di un indice univoco o una chiave primaria, aggiungi un log supplementare a ciascuna colonna interessata da un filtro o da una trasformazione. Esegui questa operazione solo se le colonne sono diverse dalle colonne della chiave primaria o dell'indice univoco.
+ Se una trasformazione include solo una colonna, non aggiungere questa colonna a un gruppo di log supplementare. Ad esempio, per una trasformazione `A+B`, aggiungi il log supplementare su entrambe le colonne `A` e `B`. Tuttavia, per una trasformazione `substring(A,10)` non aggiungere il log supplementare alla colonna `A`.
+ Per impostare il log supplementare sulle colonne della chiave primaria o dell'indice univoco e su altre colonne che vengono filtrate o trasformate, puoi impostare il log supplementare `USER_LOG_GROUP`. Aggiungi questo log sulle colonne della chiave primaria o dell'indice univoco e su altre colonne specifiche che vengono filtrate o trasformate.

  Ad esempio, per replicare una tabella denominata `TEST.LOGGING` con chiave primaria `ID` e un filtro in base alla colonna `NAME`, puoi eseguire un comando simile a quello seguente per creare il log supplementare del gruppo di log.

  ```
  ALTER TABLE TEST.LOGGING ADD SUPPLEMENTAL LOG GROUP TEST_LOG_GROUP (ID, NAME) ALWAYS;
  ```

### I privilegi dell'account sono richiesti quando si utilizza Oracle LogMiner per accedere ai redo log
<a name="CHAP_Source.Oracle.Self-Managed.LogMinerPrivileges"></a>

Per accedere ai redo log utilizzando Oracle LogMiner, concedi i seguenti privilegi all'utente Oracle specificato nelle impostazioni di connessione dell'endpoint Oracle.

```
GRANT EXECUTE on DBMS_LOGMNR to dms_user;
GRANT SELECT on V_$LOGMNR_LOGS to dms_user;
GRANT SELECT on V_$LOGMNR_CONTENTS to dms_user;
GRANT LOGMINING to dms_user; -– Required only if the Oracle version is 12c or higher.
```

### I privilegi dell'account sono necessari quando si utilizza AWS DMS Binary Reader per accedere ai redo log
<a name="CHAP_Source.Oracle.Self-Managed.BinaryReaderPrivileges"></a>

Per accedere ai redo log utilizzando AWS DMS Binary Reader, concedi i seguenti privilegi all'utente Oracle specificato nelle impostazioni di connessione dell'endpoint Oracle.

```
GRANT SELECT on v_$transportable_platform to dms_user;   -– Grant this privilege if the redo logs are stored in Oracle Automatic Storage Management (ASM) and AWS DMS accesses them from ASM.
GRANT CREATE ANY DIRECTORY to dms_user;                  -– Grant this privilege to allow AWS DMS to use Oracle BFILE read file access in certain cases. This access is required when the replication instance does not have file-level access to the redo logs and the redo logs are on non-ASM storage.
GRANT EXECUTE on DBMS_FILE_TRANSFER to dms_user;         -– Grant this privilege to copy the redo log files to a temporary folder using the CopyToTempFolder method.
GRANT EXECUTE on DBMS_FILE_GROUP to dms_user;
```

Binary Reader utilizza le funzionalità di gestione file di Oracle che includono le directory Oracle. Ogni oggetto directory Oracle include il nome della cartella contenente i redo log da elaborare. Queste directory Oracle non sono rappresentate a livello di file system. Sono invece directory logiche che vengono create a livello di database Oracle. È possibile visualizzarle nella vista Oracle `ALL_DIRECTORIES`.

Se desideri AWS DMS creare queste directory Oracle, concedi il `CREATE ANY DIRECTORY` privilegio specificato in precedenza. AWS DMS crea i nomi delle directory con il prefisso. `DMS_` Se non concedi il privilegio `CREATE ANY DIRECTORY`, crea manualmente le directory corrispondenti. In alcuni casi, quando si creano manualmente le directory Oracle, l'utente Oracle specificato nell'endpoint di origine Oracle non è l'utente che ha creato tali directory. In questi casi, concedi anche il privilegio `READ on DIRECTORY`.

**Nota**  
AWS DMS CDC non supporta Active Dataguard Standby che non è configurato per utilizzare il servizio di trasporto di ripristino automatico.

In alcuni casi i log potrebbero essere stati archiviati con Oracle Managed Files (OMF). In alternativa l'endpoint di origine è in modalità ADG e il privilegio CREATE ANY DIRECTORY non può essere concesso. In questi casi, crea manualmente le directory con tutte le possibili posizioni di registro prima di iniziare l'attività di replica. AWS DMS Se AWS DMS non trova una directory precreata come previsto, l'operazione si interrompe. Inoltre, AWS DMS non elimina le voci che ha creato nella `ALL_DIRECTORIES` vista, quindi le elimina manualmente.

### Privilegi dell'account aggiuntivi necessari quando si utilizza Binary Reader con Oracle ASM
<a name="CHAP_Source.Oracle.Self-Managed.ASMBinaryPrivileges"></a>

Per accedere ai log redo in Automatic Storage Management (ASM) utilizzando Binary Reader, concedi i seguenti privilegi all'utente Oracle specificato nelle impostazioni di connessione dell'endpoint Oracle.

```
SELECT ON v_$transportable_platform
SYSASM -– To access the ASM account with Oracle 11g Release 2 (version 11.2.0.2) and higher, grant the Oracle endpoint user the SYSASM privilege. For older supported Oracle versions, it's typically sufficient to grant the Oracle endpoint user the SYSDBA privilege.
```

È possibile verificare l'accesso all'account ASM aprendo un prompt dei comandi e richiamando una delle istruzioni seguenti, a seconda della versione di Oracle come specificato in precedenza.

Se è necessario il privilegio `SYSDBA`, utilizza quanto segue.

```
sqlplus asmuser/asmpassword@+asmserver as sysdba
```

Se è necessario il privilegio `SYSASM`, utilizza quanto segue. 

```
sqlplus asmuser/asmpassword@+asmserver as sysasm
```

### Utilizzo di un Oracle Standby autogestito come sorgente con Binary Reader for CDC in AWS DMS
<a name="CHAP_Source.Oracle.Self-Managed.BinaryStandby"></a>

Per configurare un'istanza Oracle Standby come origine quando si utilizza Binary Reader per l'attività di CDC, è necessario soddisfare i seguenti prerequisiti iniziali:
+ AWS DMS attualmente supporta solo Oracle Active Data Guard Standby.
+ Assicurati che la configurazione di Oracle Data Guard utilizzi:
  + Servizi di trasporto per la riesecuzione per trasferimenti automatici di dati di redo.
  + Servizi per applicare automaticamente la riesecuzione al database in standby.

Per verificare che tali requisiti siano soddisfatti, esegui la seguente query.

```
SQL> select open_mode, database_role from v$database;
```

Dall'output della query, verifica che il database in standby sia aperto in modalità READ ONLY e che la riesecuzione venga applicata automaticamente. Esempio:

```
OPEN_MODE             DATABASE_ROLE
--------------------  ----------------
READ ONLY WITH APPLY  PHYSICAL STANDBY
```

**Per configurare un'istanza Oracle Standby come origine quando si utilizza Binary Reader per l'attività di CDC**

1. Concedi i privilegi aggiuntivi necessari per accedere ai file di log in standby.

   ```
   GRANT SELECT ON v_$standby_log TO dms_user;
   ```

1. Crea un endpoint di origine per Oracle Standby utilizzando Console di gestione AWS o AWS CLI. Al momento della creazione dell'endpoint, specifica i seguenti attributi aggiuntivi di connessione.

   ```
   useLogminerReader=N;useBfile=Y;
   ```
**Nota**  
In AWS DMS, è possibile utilizzare attributi di connessione aggiuntivi per specificare se si desidera migrare dai log di archivio anziché dai redo log. Per ulteriori informazioni, consulta [Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib).

1. Configura la destinazione dei log archiviati.

   DMS Binary Reader per l'origine Oracle senza ASM utilizza le directory Oracle per accedere ai log redo archiviati. Se il database è configurato per utilizzare la Fast Recovery Area (FRA) come destinazione dei log di archiviazione, la posizione dei file di archivio di riesecuzione non è costante. Ogni giorno in cui vengono generati i log redo archiviati, viene creata una nuova directory nella FRA, utilizzando il formato del nome di directory AAAA\$1MM\$1GG. Esempio: 

   ```
   DB_RECOVERY_FILE_DEST/SID/archivelog/YYYY_MM_DD
   ```

   Quando DMS deve accedere ai redo file archiviati nella directory FRA appena creata e il database primario di lettura/scrittura viene utilizzato come origine, DMS crea una nuova directory Oracle o sostituisce una directory Oracle esistente, come segue. 

   ```
   CREATE OR REPLACE DIRECTORY dmsrep_taskid AS ‘DB_RECOVERY_FILE_DEST/SID/archivelog/YYYY_MM_DD’;
   ```

   Quando il database in standby viene utilizzato come origine, DMS non è in grado di creare o sostituire la directory Oracle perché il database è in modalità di sola lettura. Tuttavia, è possibile scegliere di eseguire una di queste fasi aggiuntive: 

   1. Modifica `log_archive_dest_id_1` per utilizzare un percorso effettivo anziché l'area FRA in una configurazione tale che Oracle non crei giornalmente sottodirectory:

      ```
      ALTER SYSTEM SET log_archive_dest_1=’LOCATION=full directory path’
      ```

      Quindi, crea un oggetto directory Oracle da utilizzare con DMS:

      ```
      CREATE OR REPLACE DIRECTORY dms_archived_logs AS ‘full directory path’;
      ```

   1. Crea una destinazione aggiuntiva per il log di archiviazione e un oggetto directory Oracle che punti a tale destinazione. Esempio:

      ```
      ALTER SYSTEM SET log_archive_dest_3=’LOCATION=full directory path’; 
      CREATE DIRECTORY dms_archived_log AS ‘full directory path’;
      ```

      Quindi aggiungi un attributo aggiuntivo di connessione all'endpoint di origine dell'attività:

      ```
      archivedLogDestId=3
      ```

   1. Crea manualmente in anticipo gli oggetti directory Oracle da utilizzare con DMS.

      ```
      CREATE DIRECTORY dms_archived_log_20210301 AS ‘DB_RECOVERY_FILE_DEST/SID/archivelog/2021_03_01’;
      CREATE DIRECTORY dms_archived_log_20210302 AS ‘DB_RECOVERY_FILE_DEST>/SID>/archivelog/2021_03_02’; 
      ...
      ```

   1. Crea un processo di pianificazione Oracle che venga eseguito quotidianamente e crei la directory richiesta.

1. Configura la destinazione dei log online. 

   Crea una directory Oracle che punti alla directory del sistema operativo con i redo log in standby:

   ```
   CREATE OR REPLACE DIRECTORY STANDBY_REDO_DIR AS '<full directory path>';
   GRANT READ ON DIRECTORY STANDBY_REDO_DIR TO <dms_user>;
   ```

### Utilizzo di un database gestito dall'utente su Oracle Cloud Infrastructure (OCI) come fonte per CDC in AWS DMS
<a name="CHAP_Source.Oracle.Self-Managed.OCI"></a>

Un database gestito dall'utente è quello che puoi configurare e controllare, ad esempio un database Oracle creato su una macchina virtuale (VM), un bare metal o un server Exadata. In alternativa, è il database che puoi configurare e controllare che viene eseguito su un'infrastruttura dedicata, come Oracle Cloud Infrastructure (OCI). Le seguenti informazioni descrivono i privilegi e le configurazioni necessari quando si utilizza un database Oracle gestito dall'utente su OCI come origine per l'acquisizione dei dati di modifica (CDC) in AWS DMS.

**Per configurare un database Oracle gestito dall'utente ospitato da OCI come origine per l'acquisizione dei dati di modifica**

1. Concedi i privilegi dell'account utente necessari per un database di origine Oracle gestito dall'utente su OCI. Per ulteriori informazioni, consulta [Privilegi dell'account per un endpoint di origine Oracle autogestito](#CHAP_Source.Oracle.Self-Managed.Privileges).

1. Concedi i privilegi dell'account necessari quando utilizzi Binary Reader per accedere ai log redo. Per ulteriori informazioni, consulta [Account privileges required when using Binary Reader](#CHAP_Source.Oracle.Self-Managed.BinaryReaderPrivileges).

1. Aggiungi i privilegi dell'account necessari quando utilizzi Binary Reader con Oracle Automatic Storage Management (ASM). Per ulteriori informazioni, consulta [Additional account privileges required when using Binary Reader with Oracle ASM](#CHAP_Source.Oracle.Self-Managed.ASMBinaryPrivileges).

1. Imposta il log supplementare. Per ulteriori informazioni, consulta [Setting up supplemental logging](#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging).

1. Configura la crittografia TDE. Per ulteriori informazioni, consulta [Encryption methods when using an Oracle database as a source endpoint](#CHAP_Source.Oracle.Encryption).

Le seguenti limitazioni si applicano alla replica dei dati di un database di origine Oracle su Oracle Cloud Infrastructure (OCI).

**Limitazioni**
+ DMS non supporta l'utilizzo di Oracle LogMiner per accedere ai redo log.
+ DMS non supporta Autonomous DB.

## Utilizzo di un database Oracle AWS gestito come fonte per AWS DMS
<a name="CHAP_Source.Oracle.Amazon-Managed"></a>

Un database AWS gestito è un database che si trova su un servizio Amazon come Amazon RDS, Amazon Aurora o Amazon S3. Di seguito, puoi trovare i privilegi e le configurazioni che devi configurare quando utilizzi un database Oracle gestito con. AWS AWS DMS

### Privilegi di account utente richiesti su una fonte Oracle gestita per AWS AWS DMS
<a name="CHAP_Source.Oracle.Amazon-Managed.Privileges"></a>

Concedi i seguenti privilegi all'account utente Oracle specificato nella definizione dell'endpoint di origine Oracle.

**Importante**  
Per tutti i valori dei parametri, ad esempio `dms_user` e `any-replicated-table`, Oracle presuppone che il valore sia tutto in maiuscolo a meno che non si specifichi il valore con un identificatore con distinzione tra maiuscole e minuscole. Ad esempio, supponiamo di creare un valore `dms_user` senza utilizzare le virgolette, come in `CREATE USER myuser` o `CREATE USER MYUSER`. In questo caso, Oracle identifica e memorizza il valore come tutto maiuscolo (`MYUSER`). Se si utilizzano le virgolette, come in `CREATE USER "MyUser"` o `CREATE USER 'MyUser'`, Oracle identifica e memorizza il valore con distinzione tra maiuscole e minuscole specificato (`MyUser`).

```
GRANT CREATE SESSION to dms_user;
GRANT SELECT ANY TRANSACTION to dms_user;
GRANT SELECT on DBA_TABLESPACES to dms_user;
GRANT SELECT ON any-replicated-table to dms_user;
GRANT EXECUTE on rdsadmin.rdsadmin_util to dms_user;
 -- For Oracle 12c or higher:
GRANT LOGMINING to dms_user; – Required only if the Oracle version is 12c or higher.
```

Inoltre, concedi le autorizzazioni `SELECT` e `EXECUTE` sugli oggetti `SYS` utilizzando la procedura Amazon RDS `rdsadmin.rdsadmin_util.grant_sys_object`, come illustrato. Per ulteriori informazioni, consulta [Concessione di privilegi SELECT o EXECUTE su oggetti SYS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html#Appendix.Oracle.CommonDBATasks.TransferPrivileges).

```
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_VIEWS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_PARTITIONS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_INDEXES', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_OBJECTS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TABLES', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_USERS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CATALOG', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONSTRAINTS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONS_COLUMNS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_COLS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_IND_COLUMNS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_LOG_GROUPS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOG', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGFILE', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$THREAD', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$NLS_PARAMETERS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TIMEZONE_NAMES', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TRANSACTION', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$CONTAINERS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_REGISTRY', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('OBJ$', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_ENCRYPTED_COLUMNS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_LOGS', 'dms_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_CONTENTS','dms_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_LOGMNR', 'dms_user', 'EXECUTE');

-- (as of Oracle versions 12.1 and higher)
exec rdsadmin.rdsadmin_util.grant_sys_object('REGISTRY$SQLPATCH', 'dms_user', 'SELECT');

-- (for Amazon RDS Active Dataguard Standby (ADG))
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$STANDBY_LOG', 'dms_user', 'SELECT'); 

-- (for transparent data encryption (TDE))

exec rdsadmin.rdsadmin_util.grant_sys_object('ENC$', 'dms_user', 'SELECT'); 
               
-- (for validation with LOB columns)
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_CRYPTO', 'dms_user', 'EXECUTE');
                    
-- (for binary reader)
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_DIRECTORIES','dms_user','SELECT'); 
                    
-- Required when the source database is Oracle Data guard, and Oracle Standby is used in the latest release of DMS version 3.4.6, version 3.4.7, and higher.

exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATAGUARD_STATS', 'dms_user', 'SELECT');
```

Per ulteriori informazioni sull'uso di Amazon RDS Active Dataguard Standby (ADG) con AWS DMS , consulta [Utilizzo di un Amazon RDS Oracle Standby (leggi replica) come sorgente con Binary Reader for CDC in AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.StandBy).

Per ulteriori informazioni sull'utilizzo di Oracle TDE con AWS DMS, vedere. [Metodi di crittografia supportati per l'utilizzo di Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.Encryption)

#### Prerequisiti per la gestione delle transazioni aperte per Oracle Standby
<a name="CHAP_Source.Oracle.Amazon-Managed.Privileges.Standby"></a>

Se si utilizzano AWS DMS le versioni 3.4.6 e successive, effettuare le seguenti operazioni per gestire le transazioni aperte per Oracle Standby. 

1. Crea un collegamento di database denominato `AWSDMS_DBLINK` nel database primario. `DMS_USER` utilizzerà il collegamento per connettersi al database primario. Tieni presente che il collegamento di database viene eseguito dall'istanza di standby per eseguire query sulle transazioni aperte in esecuzione nel database primario. Guarda l'esempio seguente. 

   ```
   CREATE PUBLIC DATABASE LINK AWSDMS_DBLINK 
      CONNECT TO DMS_USER IDENTIFIED BY DMS_USER_PASSWORD
      USING '(DESCRIPTION=
               (ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_HOST_NAME_OR_IP)(PORT=PORT))
               (CONNECT_DATA=(SERVICE_NAME=SID))
             )';
   ```

1. Verifica che sia stata stabilita la connessione al collegamento di database usando `DMS_USER`, come illustrato nell'esempio seguente.

   ```
   select 1 from dual@AWSDMS_DBLINK
   ```

### Configurazione di una fonte Oracle gestita per AWS AWS DMS
<a name="CHAP_Source.Oracle.Amazon-Managed.Configuration"></a>

Prima di utilizzare un database Oracle AWS gestito come origine per AWS DMS, esegui le seguenti attività per il database Oracle:
+ Abilita backup automatici. Per ulteriori informazioni sull'abilitazione dei backup automatici, consulta [Abilitazione dei backup automatici](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html#USER_WorkingWithAutomatedBackups.Enabling) nella *Guida per l'utente di Amazon RDS*.
+ Imposta il log supplementare.
+ Imposta l'archiviazione. L'archiviazione dei redo log per l'istanza DB di Amazon RDS for Oracle AWS DMS consente di recuperare le informazioni di registro utilizzando Oracle o Binary Reader. LogMiner 

**Per impostare l'archiviazione**

1. Per impostare l'archiviazione eseguire il comando `rdsadmin.rdsadmin_util.set_configuration`.

   Ad esempio, per mantenere i log redo archiviati per 24 ore, esegui il seguente comando.

   ```
   exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);
   commit;
   ```
**Nota**  
Il commit è necessario per rendere effettiva la modifica.

1. Assicurati che lo spazio di storage sia sufficiente per i log redo archiviati durante il periodo di conservazione specificato. Ad esempio, se il periodo di conservazione è 24 ore, calcola la dimensione totale dei log redo archiviati accumulati in un'ora di elaborazione tipica delle transazioni e moltiplica il totale per 24. Confronta il totale calcolato su 24 ore con lo spazio di storage disponibile e decidi se disponi di spazio di storage sufficiente per gestire un'intera elaborazione delle transazioni di 24 ore.

**Per impostare il log supplementare**

1. Per abilitare il log supplementare a livello di database, esegui il comando riportato di seguito.

   ```
   exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');
   ```

1. Esegui il comando riportato di seguito per abilitare il log supplementare della chiave primaria.

   ```
   exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');
   ```

1. (Facoltativo) Abilita il log supplementare della chiave a livello di tabella.

   Nel database di origine si verificherà un leggero sovraccarico quando il log supplementare della chiave è abilitato. Pertanto, se esegui solo la migrazione di un sottoinsieme di tabelle, puoi abilitare il log supplementare della chiave a livello di tabella. Per abilitare il log supplementare della chiave a livello di tabella, esegui il comando riportato di seguito.

   ```
   alter table table_name add supplemental log data (PRIMARY KEY) columns;
   ```

### Configurazione di un'attività CDC per l'utilizzo di Binary Reader con un codice sorgente RDS for Oracle per AWS DMS
<a name="CHAP_Source.Oracle.Amazon-Managed.CDC"></a>

Puoi configurare l'accesso AWS DMS ai redo log di origine delle istanze Amazon RDS for Oracle utilizzando Binary Reader for CDC. 

**Nota**  
Per utilizzare Oracle LogMiner, sono sufficienti i privilegi minimi richiesti per l'account utente. Per ulteriori informazioni, consulta [Privilegi di account utente richiesti su una fonte Oracle gestita per AWS AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Privileges).

Per utilizzare AWS DMS Binary Reader, specifica impostazioni aggiuntive e attributi di connessione aggiuntivi per l'endpoint di origine Oracle, a seconda della versione in uso. AWS DMS 

Il supporto Binary Reader è disponibile nelle seguenti versioni di Amazon RDS per Oracle:
+ Oracle 11.2, versione 11.2.0.4V11 e successive
+ Oracle 12.1, versione 12.1.0.2.V7 e successive
+ Oracle 12.2, tutte le versioni
+ Oracle 18.0, tutte le versioni
+ Oracle 19.0, tutte le versioni

**Per configurare CDC utilizzando Binary Reader**

1. Accedi al database di origine Amazon RDS per Oracle come utente master ed esegui le seguenti stored procedure per creare le directory a livello di server.

   ```
   exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;
   exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;
   ```

1. Concedi i seguenti privilegi all'account utente Oracle che viene utilizzato per accedere all'endpoint di origine Oracle.

   ```
   GRANT READ ON DIRECTORY ONLINELOG_DIR TO dms_user;
   GRANT READ ON DIRECTORY ARCHIVELOG_DIR TO dms_user;
   ```

1. Imposta i seguenti attributi aggiuntivi di connessione sull'endpoint di origine Amazon RDS per Oracle.
   + Per RDS per Oracle versioni 11.2 e 12.1, imposta quanto segue.

     ```
     useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false;useAlternateFolderForOnline=true;
     oraclePathPrefix=/rdsdbdata/db/{$DATABASE_NAME}_A/;usePathPrefix=/rdsdbdata/log/;replacePathPrefix=true;
     ```
   + Per RDS per Oracle versioni 12.2, 18.0 e 19.0, imposta quanto segue.

     ```
     useLogminerReader=N;useBfile=Y;
     ```

**Nota**  
Assicurati che non ci siano spazi bianchi dopo il separatore punto e virgola (;) per più impostazioni di attributi, ad esempio `oneSetting;thenAnother`.

Per ulteriori informazioni sulla configurazione di un'attività di CDC, consulta [Configurazione dell'attività di CDC su un database di origine Oracle](#CHAP_Source.Oracle.CDC.Configuration).

### Utilizzo di un Amazon RDS Oracle Standby (leggi replica) come sorgente con Binary Reader for CDC in AWS DMS
<a name="CHAP_Source.Oracle.Amazon-Managed.StandBy"></a>

Verifica i seguenti prerequisiti per l'utilizzo di Amazon RDS per Oracle Standby come origine quando usi Binary Reader per l'attività di CDC in AWS DMS:
+ Utilizza l'utente master Oracle per configurare Binary Reader.
+ Assicurati che AWS DMS attualmente supporti solo l'utilizzo di Oracle Active Data Guard Standby.

Una volta fatto, usa la procedura seguente per utilizzare RDS per Oracle Standby come origine con Binary Reader per l'attività di CDC.

**Per configurare un'istanza RDS per Oracle Standby come origine quando si utilizza Binary Reader per l'attività di CDC**

1. Accedi all'istanza primaria RDS per Oracle come utente master.

1. Esegui le seguenti stored procedure come documentato nella Guida per l'utente di Amazon RDS per creare le directory a livello di server.

   ```
   exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;
   exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;
   ```

1. Identifica le directory create nella fase 2.

   ```
   SELECT directory_name, directory_path FROM all_directories
   WHERE directory_name LIKE ( 'ARCHIVELOG_DIR_%' )
           OR directory_name LIKE ( 'ONLINELOG_DIR_%' )
   ```

   Ad esempio, il codice precedente visualizza un elenco di directory come il seguente.  
![\[Table showing directory names and their corresponding paths for archive and online logs.\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-rds-server-level-directories.png)

1. Concedi il privilegio `Read` sulle directory precedenti all'account utente Oracle utilizzato per accedere a Oracle Standby.

   ```
   GRANT READ ON DIRECTORY ARCHIVELOG_DIR_A TO dms_user;
   GRANT READ ON DIRECTORY ARCHIVELOG_DIR_B TO dms_user;
   GRANT READ ON DIRECTORY ONLINELOG_DIR_A TO dms_user;
   GRANT READ ON DIRECTORY ONLINELOG_DIR_B TO dms_user;
   ```

1. Applica un'opzione del log di archiviazione all'istanza principale. In questo modo le modifiche a `ALL_DIRECTORIES` vengano trasferite anche in Oracle Standby.

1. Esegui una query `ALL_DIRECTORIES` su Oracle Standby per verificare che le modifiche siano state applicate.

1. Crea un endpoint di origine per Oracle Standby utilizzando la AWS DMS Management Console o AWS Command Line Interface ().AWS CLI Al momento della creazione dell'endpoint, specifica i seguenti attributi aggiuntivi di connessione.

   ```
   useLogminerReader=N;useBfile=Y;archivedLogDestId=1;additionalArchivedLogDestId=2
   ```

1. Dopo aver creato l'endpoint, utilizzare **Test endpoint connection** nella pagina **Crea endpoint** della console o il AWS CLI `test-connection` comando per verificare che la connettività sia stabilita.

## Limitazioni all'uso di Oracle come fonte per AWS DMS
<a name="CHAP_Source.Oracle.Limitations"></a>

Quando si utilizza un database Oracle come origine per AWS DMS, si applicano le seguenti limitazioni:
+ AWS DMS supporta i tipi di dati Oracle Extended nella AWS DMS versione 3.5.0 e successive.
+ AWS DMS non supporta nomi di oggetti lunghi (oltre 30 byte).
+ AWS DMS non supporta indici basati su funzioni.
+ Se gestisci il log supplementare ed esegui trasformazioni su una qualsiasi delle colonne, assicurati che il log supplementare sia attivato per tutti i campi e le colonne. Per ulteriori informazioni sull'impostazione del log supplementare, consulta i seguenti argomenti:
  + Per un database di origine Oracle autogestito, consulta [Impostazione del log supplementare](#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging).
  + Per un database di origine Oracle AWS gestito, vedere. [Configurazione di una fonte Oracle gestita per AWS AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Configuration)
+ AWS DMS non supporta il database radice dei contenitori multi-tenant (CDB\$1ROOT). Supporta un PDB utilizzando Binary Reader.
+ AWS DMS non supporta vincoli differiti.
+ AWS DMS la versione 3.5.3 e successive supporta completamente secure. LOBs
+ AWS DMS supporta la `rename table table-name to new-table-name` sintassi per tutte le versioni Oracle 11 e successive supportate. Questa sintassi non è supportata per i database di origine Oracle versione 10.
+ AWS DMS non replica i risultati dell'istruzione DDL. `ALTER TABLE ADD column data_type DEFAULT default_value` Invece di replicare `default_value` sulla destinazione, imposta la nuova colonna su `NULL`.
+ Quando si utilizza AWS DMS la versione 3.4.7 o successiva, per replicare le modifiche derivanti da operazioni di partizione o partizione secondaria, effettuate le seguenti operazioni prima di avviare un'attività DMS.
  + Crea manualmente la struttura della tabella partizionata (DDL). 
  + Assicurati che il DDL sia lo stesso per l'origine e la destinazione Oracle. 
  + Imposta l'attributo aggiuntivo di connessione `enableHomogenousPartitionOps=true`.

  Per ulteriori informazioni su `enableHomogenousPartitionOps`, consultare [Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib). Inoltre, tenete presente che nelle attività FULL\$1CDC, DMS non replica le modifiche ai dati acquisite come parte delle modifiche memorizzate nella cache. In questo caso d'uso, ricrea la struttura della tabella sulla destinazione Oracle e ricarica le tabelle in questione.

  Prima della versione 3.4.7: AWS DMS 

  DMS non replica le modifiche ai dati risultanti da operazioni di partizione o sottopartizione (,, e). `ADD` `DROP` `EXCHANGE` `TRUNCATE` Tali aggiornamenti possono causare i seguenti errori durante la replica:
  + Nel caso di operazioni `ADD`, aggiornamenti ed eliminazioni sui dati aggiunti potrebbero generare un avviso "0 righe interessate".
  + Nel caso di operazioni `DROP` e `TRUNCATE`, nuovi inserimenti potrebbero generare errori di "duplicazione".
  + Operazioni `EXCHANGE` potrebbero generare sia un avviso "0 righe interessate" che errori di "duplicazione".

  Per replicare le modifiche derivanti da operazioni di partizione o di sottopartizione, ricaricare le tabelle in questione. Dopo aver aggiunto una nuova partizione vuota, le operazioni sulla partizione appena aggiunta vengono replicate nella destinazione come al solito.
+ AWS DMS le versioni precedenti alla 3.4 non supportano le modifiche ai dati sulla destinazione derivanti dall'esecuzione dell'istruzione sull'`CREATE TABLE AS`origine. Tuttavia, nella destinazione viene creata la nuova tabella.
+ AWS DMS non acquisisce le modifiche apportate dal `DBMS_REDEFINITION` pacchetto Oracle, ad esempio i metadati della tabella e il `OBJECT_ID` campo.
+ Quando è abilitata la modalità LOB a dimensione limitata, le BLOB/CLOB colonne vuote nell'origine Oracle vengono replicate come valori NULL. Quando la modalità Full LOB è abilitata, vengono replicate come stringa vuota ('').
+ Quando si acquisiscono le modifiche con Oracle 11 LogMiner, un aggiornamento su una colonna CLOB con una lunghezza di stringa superiore al 1982 viene perso e la destinazione non viene aggiornata.
+ Durante l'acquisizione dei dati delle modifiche (CDC), non AWS DMS supporta gli aggiornamenti in batch alle colonne numeriche definite come chiave primaria.
+ AWS DMS non supporta determinati `UPDATE` comandi. L'esempio seguente è un comando `UPDATE` non supportato.

  ```
  UPDATE TEST_TABLE SET KEY=KEY+1;
  ```

  Qui, `TEST_TABLE` è il nome della tabella e `KEY` è una colonna numerica definita come chiave primaria.
+ AWS DMS non supporta la modalità LOB completa per il caricamento delle colonne LONG e LONG RAW. È invece possibile utilizzare la modalità LOB limitata per migrare questi tipi di dati in una destinazione Oracle. In modalità LOB limitata, AWS DMS tronca tutti i dati a 64 KB impostati su colonne LONG o LONG RAW più lunghe di 64 KB.
+ AWS DMS non supporta la modalità LOB completa per il caricamento delle colonne XMLTYPE. È invece possibile utilizzare la modalità LOB limitata per migrare le colonne XMLTYPE in una destinazione Oracle. In modalità LOB limitata, DMS tronca tutti i dati più lunghi della variabile "Dimensione massima dei LOB" definita dall'utente. Il valore massimo consigliato per "Dimensione massima dei LOB" è 100 MB.
+ AWS DMS non replica tabelle i cui nomi contengono apostrofi.
+ AWS DMS supporta CDC da viste materializzate. Ma DMS non supporta CDC da nessun altro punto di vista.
+ AWS DMS non supporta CDC per le tabelle organizzate a indice con un segmento di overflow.
+ AWS DMS non supporta l'`Drop Partition`operazione per le tabelle partizionate per riferimento con set to. `enableHomogenousPartitionOps` `true`
+ Quando si utilizza Oracle LogMiner per accedere ai redo log, AWS DMS presenta le seguenti limitazioni:
  + Solo per Oracle 12, AWS DMS non replica alcuna modifica alle colonne LOB.
  + AWS DMS non supporta transazioni XA in fase di replica durante l'utilizzo di Oracle. LogMiner
  + Oracle LogMiner non supporta connessioni a un database collegabile (PDB). Per connettersi a un PDB, accedere ai redo log utilizzando Binary Reader.
  + Le operazioni SHRINK SPACE non sono supportate.
+ Quando si utilizza Binary Reader, AWS DMS presenta le seguenti limitazioni:
  + Non supporta i cluster di tabelle.
  + Supporta solo le operazioni `SHRINK SPACE` a livello di tabella. Questo livello include la tabella completa, le partizioni e le sottopartizioni.
  + Non supporta le modifiche alle tabelle organizzate a indice con compressione dei tasti.
  + Non supporta l'implementazione dei redo log online su dispositivi raw.
  + Binary Reader supporta TDE solo per i database Oracle autogestiti, poiché RDS per Oracle non supporta il recupero delle password dei wallet per le chiavi di crittografia TDE.
+ AWS DMS non supporta connessioni a una sorgente Oracle Amazon RDS che utilizza un proxy Oracle Automatic Storage Management (ASM).
+ AWS DMS non supporta colonne virtuali. 
+ AWS DMS non supporta il tipo di `ROWID` dati o le viste materializzate basate su una colonna ROWID.

  AWS DMS supporta parzialmente Oracle Materialized Views. Per i caricamenti completi, DMS può eseguire la copia del pieno carico di una vista materializzata Oracle. DMS copia la vista materializzata come tabella di base nel sistema di destinazione e ignora tutte le colonne ROWID nella vista materializzata. Per la replica continua (CDC), DMS tenta di replicare le modifiche ai dati nella vista materializzata, ma i risultati potrebbero non essere ideali. In particolare, se la vista materializzata viene completamente aggiornata, DMS replica le singole eliminazioni per tutte le righe, seguite dai singoli inserimenti per tutte le righe. Si tratta di un esercizio che richiede molte risorse e potrebbe avere scarse prestazioni per le viste materializzate con un numero elevato di righe. Per una replica continua in cui le viste materializzate eseguono un aggiornamento rapido, DMS cerca di elaborare e replicare le modifiche ai dati con aggiornamento rapido. In entrambi i casi, DMS ignora qualsiasi colonna ROWID nella vista materializzata.
+ AWS DMS non carica o acquisisce tabelle temporanee globali.
+ Per le destinazioni S3 che utilizzano la replica, abilita il log supplementare su ogni colonna in modo che gli aggiornamenti delle righe di origine possano acquisire ogni valore di colonna. Di seguito è riportato un esempio: `alter table yourtablename add supplemental log data (all) columns;`.
+ Un aggiornamento per una riga con una chiave univoca composita che contiene `null` non può essere replicato sulla destinazione.
+ AWS DMS non supporta l'uso di più chiavi di crittografia Oracle TDE sullo stesso endpoint di origine. Ogni endpoint può avere un solo attributo per il nome della chiave di crittografia TDE "`securityDbEncryptionName`" e una password TDE per questa chiave.
+ Durante la replica da Amazon RDS for Oracle, TDE è supportato solo con tablespace crittografato e utilizzando Oracle. LogMiner
+ AWS DMS non supporta più operazioni di ridenominazione di tabelle in rapida successione.
+ Quando si utilizza Oracle 19.0 come sorgente, AWS DMS non supporta le seguenti funzionalità:
  + Reindirizzamento DML con protezione dei dati
  + Tabelle ibride partizionate
  + Account Oracle solo schema
+ AWS DMS non supporta la migrazione di tabelle o viste di tipo `BIN$` o`DR$`.
+ A partire da Oracle 18.x, AWS DMS non supporta l'acquisizione dei dati di modifica (CDC) di Oracle Express Edition (Oracle Database XE).
+ Al momento della migrazione dei dati da una colonna CHAR, DMS tronca gli spazi finali. 
+ AWS DMS non supporta la replica dai contenitori di applicazioni.
+ AWS DMS non supporta l'esecuzione di Oracle Flashback Database e dei punti di ripristino, poiché queste operazioni influiscono sulla coerenza dei file Oracle Redo Log.
+ Prima della AWS DMS versione 3.5.3, la procedura di caricamento diretto `INSERT` con l'opzione di esecuzione parallela non è supportata nei seguenti casi:
  + Tabelle non compresse con più di 255 colonne
  + Dimensione delle righe superiore a 8K
  + Tabelle HCC Exadata
  + Database in esecuzione sulla piattaforma Big Endian
+ Una tabella di origine senza chiave primaria né univoca richiede l'abilitazione del log supplementare ALL COLUMN. Crea più attività di log redo e può aumentare la latenza dell'attività di CDC di DMS.
+ AWS DMS non migra i dati dalle colonne invisibili del database di origine. Per includere queste colonne nell'ambito della migrazione, utilizza l'istruzione `ALTER TABLE` per renderle visibili.
+ Per tutte le versioni di Oracle, AWS DMS non replica il risultato delle `UPDATE` operazioni sulle colonne LOB `XMLTYPE` e B.
+ AWS DMS non supporta la replica da tabelle con vincoli di validità temporale.
+ Se l'origine Oracle 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.

## Supporto SSL per un endpoint Oracle
<a name="CHAP_Security.SSL.Oracle"></a>

AWS DMS Gli endpoint Oracle supportano SSL V3 per le modalità e SSL. `none` `verify-ca` Per utilizzare SSL con un endpoint Oracle, carica il wallet Oracle per l'endpoint anziché i file di certificato .pem. 

**Topics**
+ [Utilizzo di un certificato esistente per SSL Oracle](#CHAP_Security.SSL.Oracle.Existing)
+ [Utilizzo di un certificato autofirmato per SSL Oracle](#CHAP_Security.SSL.Oracle.SelfSigned)

### Utilizzo di un certificato esistente per SSL Oracle
<a name="CHAP_Security.SSL.Oracle.Existing"></a>

Per utilizzare un'istallazione client Oracle esistente per creare il file wallet Oracle dal file di certificato CA, procedi come segue.

**Per utilizzare un'installazione client Oracle esistente per Oracle SSL con AWS DMS**

1. Impostare la variabile di sistema `ORACLE_HOME` sulla posizione della directory `dbhome_1` eseguendo il comando seguente.

   ```
   prompt>export ORACLE_HOME=/home/user/app/user/product/12.1.0/dbhome_1                        
   ```

1. Aggiungere `$ORACLE_HOME/lib` alla variabile di sistema `LD_LIBRARY_PATH`.

   ```
   prompt>export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib                        
   ```

1. Crea una directory per il wallet Oracle nel percorso `$ORACLE_HOME/ssl_wallet`.

   ```
   prompt>mkdir $ORACLE_HOME/ssl_wallet
   ```

1. Inserire il file `.pem` del certificato CA nella directory `ssl_wallet`. Se si utilizza Amazon RDS, è possibile scaricare il file del certificato CA root `rds-ca-2015-root.pem` ospitato da Amazon RDS. Per ulteriori informazioni sul download di questo file, consulta [Using SSL/TLS to encrypt a connection to a DB nella Amazon](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) *RDS User* Guide.

1. Se il tuo certificato CA contiene più di un file PEM (come il pacchetto globale o regionale di Amazon RDS), devi dividerlo in file separati e aggiungerli al portafoglio Oracle utilizzando il seguente script bash. Questo script richiede due input di parametri: il percorso del certificato CA e il percorso della cartella del portafoglio Oracle creato in precedenza.

   ```
   #!/usr/bin/env bash
   
   certnum=$(grep -c BEGIN <(cat $1))
   
   cnt=0
   temp_cert=""
   while read line
   do
   if [ -n "$temp_cert" -a "$line" == "-----BEGIN CERTIFICATE-----" ]
   then
   cnt=$(expr $cnt + 1)
   printf "\rImporting certificate # $cnt of $certnum"
   orapki wallet add -wallet "$2" -trusted_cert -cert <(echo -n "${temp_cert}") -auto_login_only 1>/dev/null 2>/dev/null
   temp_cert=""
   fi
   temp_cert+="$line"$'\n'
   done < <(cat $1)
   
   cnt=$(expr $cnt + 1)
   printf "\rImporting certificate # $cnt of $certnum"
   orapki wallet add -wallet "$2" -trusted_cert -cert <(echo -n "${temp_cert}") -auto_login_only 1>/dev/null 2>/dev/null
   echo ""
   ```

Una volta completate le fasi precedenti, è possibile importare il file wallet con la chiamata API `ImportCertificate` specificando il parametro certificate-wallet. È quindi possibile utilizzare il certificato wallet importato quando si seleziona `verify-ca` come modalità SSL durante la creazione o la modifica dell'endpoint Oracle.

**Nota**  
 I portafogli Oracle sono file binari. AWS DMS accetta questi file così come sono. 

### Utilizzo di un certificato autofirmato per SSL Oracle
<a name="CHAP_Security.SSL.Oracle.SelfSigned"></a>

Per utilizzare un certificato autofirmato per Oracle SSL, procedi nel seguente modo, presupponendo che la password del wallet Oracle sia `oracle123`.

**Utilizzare un certificato autofirmato per Oracle SSL con AWS DMS**

1. Creare una directory da utilizzare con il certificato autofirmato.

   ```
   mkdir -p /u01/app/oracle/self_signed_cert
   ```

1. Passare alla directory creata nella fase precedente.

   ```
   cd /u01/app/oracle/self_signed_cert
   ```

1. Creare una chiave root.

   ```
   openssl genrsa -out self-rootCA.key 2048
   ```

1. Autofirmare un certificato root utilizzando la chiave root creata nel passaggio precedente.

   ```
   openssl req -x509 -new -nodes -key self-rootCA.key 
           -sha256 -days 3650 -out self-rootCA.pem
   ```

   Utilizza i parametri di input, come i seguenti.
   + `Country Name (2 letter code) [XX]`, ad esempio: `AU`
   + `State or Province Name (full name) []`, ad esempio: `NSW`
   + `Locality Name (e.g., city) [Default City]`, ad esempio: `Sydney`
   + `Organization Name (e.g., company) [Default Company Ltd]`, ad esempio: `AmazonWebService`
   + `Organizational Unit Name (e.g., section) []`, ad esempio: `DBeng`
   + `Common Name (e.g., your name or your server's hostname) []`, ad esempio: `aws`
   + `Email Address []`, ad esempio: abcd.efgh@amazonwebservice.com

1. Creare una directory per il wallet Oracle per il database Oracle.

   ```
   mkdir -p /u01/app/oracle/wallet
   ```

1. Creare un nuovo wallet Oracle.

   ```
   orapki wallet create -wallet "/u01/app/oracle/wallet" -pwd oracle123 -auto_login_local
   ```

1. Aggiungere il certificato root al wallet Oracle.

   ```
   orapki wallet add -wallet "/u01/app/oracle/wallet" -pwd oracle123 -trusted_cert 
   -cert /u01/app/oracle/self_signed_cert/self-rootCA.pem
   ```

1. Elencare i contenuti del wallet Oracle. L'elenco deve includere il certificato root. 

   ```
   orapki wallet display -wallet /u01/app/oracle/wallet -pwd oracle123
   ```

   Ad esempio, potrebbe essere visualizzato in modo simile a quanto segue.

   ```
   Requested Certificates:
   User Certificates:
   Trusted Certificates:
   Subject:        CN=aws,OU=DBeng,O= AmazonWebService,L=Sydney,ST=NSW,C=AU
   ```

1. Generare la richiesta di firma del certificato (CSR) utilizzando l'utility ORAPKI.

   ```
   orapki wallet add -wallet "/u01/app/oracle/wallet" -pwd oracle123 
   -dn "CN=aws" -keysize 2048 -sign_alg sha256
   ```

1. Eseguire il seguente comando seguente.

   ```
   openssl pkcs12 -in /u01/app/oracle/wallet/ewallet.p12 -nodes -out /u01/app/oracle/wallet/nonoracle_wallet.pem
   ```

   Ciò produce un output simile al seguente.

   ```
   Enter Import Password:
   MAC verified OK
   Warning unsupported bag type: secretBag
   ```

1. Utilizzare "dms" come nome comune.

   ```
   openssl req -new -key /u01/app/oracle/wallet/nonoracle_wallet.pem -out certdms.csr
   ```

   Utilizza i parametri di input, come i seguenti.
   + `Country Name (2 letter code) [XX]`, ad esempio: `AU`
   + `State or Province Name (full name) []`, ad esempio: `NSW`
   + `Locality Name (e.g., city) [Default City]`, ad esempio: `Sydney`
   + `Organization Name (e.g., company) [Default Company Ltd]`, ad esempio: `AmazonWebService`
   + `Organizational Unit Name (e.g., section) []`, ad esempio: `aws`
   + `Common Name (e.g., your name or your server's hostname) []`, ad esempio: `aws`
   + `Email Address []`, ad esempio: abcd.efgh@amazonwebservice.com

   Assicurati che non siano uguali a quelli della fase 4. Puoi, ad esempio, modificare il nome dell'unità organizzativa usando un nome diverso, come illustrato.

   Inserisci gli attributi aggiuntivi seguenti da inviare con la richiesta di certificato.
   + `A challenge password []`, ad esempio: `oracle123`
   + `An optional company name []`, ad esempio: `aws`

1. Ottenere la firma del certificato.

   ```
   openssl req -noout -text -in certdms.csr | grep -i signature
   ```

   La chiave di firma per questo post è `sha256WithRSAEncryption`.

1. Utilizza il comando seguente per generare il file di certificato (`.crt`).

   ```
   openssl x509 -req -in certdms.csr -CA self-rootCA.pem -CAkey self-rootCA.key 
   -CAcreateserial -out certdms.crt -days 365 -sha256
   ```

   Ciò produce un output simile al seguente.

   ```
   Signature ok
   subject=/C=AU/ST=NSW/L=Sydney/O=awsweb/OU=DBeng/CN=aws
   Getting CA Private Key
   ```

1. Aggiungere il certificato al wallet.

   ```
   orapki wallet add -wallet /u01/app/oracle/wallet -pwd oracle123 -user_cert -cert certdms.crt
   ```

1. Visualizza il wallet. È composto da due voci. Consulta il seguente codice.

   ```
   orapki wallet display -wallet /u01/app/oracle/wallet -pwd oracle123
   ```

1. Configurare il file `sqlnet.ora` (`$ORACLE_HOME/network/admin/sqlnet.ora`).

   ```
   WALLET_LOCATION =
      (SOURCE =
        (METHOD = FILE)
        (METHOD_DATA =
          (DIRECTORY = /u01/app/oracle/wallet/)
        )
      ) 
   
   SQLNET.AUTHENTICATION_SERVICES = (NONE)
   SSL_VERSION = 1.0
   SSL_CLIENT_AUTHENTICATION = FALSE
   SSL_CIPHER_SUITES = (SSL_RSA_WITH_AES_256_CBC_SHA)
   ```

1. Interrompere il listener Oracle.

   ```
   lsnrctl stop
   ```

1. Aggiungere voci per SSL nel file `listener.ora` (`$ORACLE_HOME/network/admin/listener.ora`).

   ```
   SSL_CLIENT_AUTHENTICATION = FALSE
   WALLET_LOCATION =
     (SOURCE =
       (METHOD = FILE)
       (METHOD_DATA =
         (DIRECTORY = /u01/app/oracle/wallet/)
       )
     )
   
   SID_LIST_LISTENER =
    (SID_LIST =
     (SID_DESC =
      (GLOBAL_DBNAME = SID)
      (ORACLE_HOME = ORACLE_HOME)
      (SID_NAME = SID)
     )
    )
   
   LISTENER =
     (DESCRIPTION_LIST =
       (DESCRIPTION =
         (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
         (ADDRESS = (PROTOCOL = TCPS)(HOST = localhost.localdomain)(PORT = 1522))
         (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
       )
     )
   ```

1. Configurare il file `tnsnames.ora` (`$ORACLE_HOME/network/admin/tnsnames.ora`).

   ```
   <SID>=
   (DESCRIPTION=
           (ADDRESS_LIST = 
                   (ADDRESS=(PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
           )
           (CONNECT_DATA =
                   (SERVER = DEDICATED)
                   (SERVICE_NAME = <SID>)
           )
   )
   
   <SID>_ssl=
   (DESCRIPTION=
           (ADDRESS_LIST = 
                   (ADDRESS=(PROTOCOL = TCPS)(HOST = localhost.localdomain)(PORT = 1522))
           )
           (CONNECT_DATA =
                   (SERVER = DEDICATED)
                   (SERVICE_NAME = <SID>)
           )
   )
   ```

1. Riavviare il listener Oracle.

   ```
   lsnrctl start
   ```

1. Mostrare lo stato del listener Oracle.

   ```
   lsnrctl status
   ```

1. Verificare la connessione SSL al database da localhost utilizzando sqlplus e la voce SSL tnsnames.

   ```
   sqlplus -L ORACLE_USER@SID_ssl
   ```

1. Verificare che la connessione sia stabilita utilizzando SSL.

   ```
   SELECT SYS_CONTEXT('USERENV', 'network_protocol') FROM DUAL;
   
   SYS_CONTEXT('USERENV','NETWORK_PROTOCOL')
   --------------------------------------------------------------------------------
   tcps
   ```

1. Modificare la directory nella directory con il certificato autofirmato.

   ```
   cd /u01/app/oracle/self_signed_cert
   ```

1. Crea un nuovo portafoglio client Oracle AWS DMS da utilizzare.

   ```
   orapki wallet create -wallet ./ -auto_login_only
   ```

1. Aggiungere il certificato root autofirmato al wallet Oracle.

   ```
   orapki wallet add -wallet ./ -trusted_cert -cert self-rootCA.pem -auto_login_only
   ```

1. Elenca il contenuto del portafoglio Oracle AWS DMS da utilizzare. L'elenco deve includere il certificato root autofirmato.

   ```
   orapki wallet display -wallet ./
   ```

   Ciò produce un output simile al seguente.

   ```
   Trusted Certificates:
   Subject:        CN=aws,OU=DBeng,O=AmazonWebService,L=Sydney,ST=NSW,C=AU
   ```

1. Carica il portafoglio Oracle su cui hai appena creato AWS DMS.

## Metodi di crittografia supportati per l'utilizzo di Oracle come fonte per AWS DMS
<a name="CHAP_Source.Oracle.Encryption"></a>

Nella tabella seguente sono riportati i metodi TDE (Transparent Data Encryption) AWS DMS supportati quando si lavora con un database di origine Oracle. 


| Metodo di accesso ai redo log | Tablespace TDE | Colonna TDE | 
| --- | --- | --- | 
| Oracle LogMiner | Sì  | Sì | 
| Binary Reader | Sì  | Sì | 

AWS DMS supporta Oracle TDE quando si utilizza Binary Reader, sia a livello di colonna che a livello di tablespace. Per utilizzare la crittografia TDE con AWS DMS, è necessario innanzitutto identificare la posizione del wallet Oracle in cui sono archiviate la chiave di crittografia TDE e la password TDE. Identifica quindi la chiave di crittografia TDE e la password corrette per l'endpoint di origine Oracle.

**Per identificare e specificare la chiave di crittografia e la password per la crittografia TDE**

1. Esegui la seguente query per trovare il wallet di crittografia Oracle nell'host di database Oracle.

   ```
   SQL> SELECT WRL_PARAMETER FROM V$ENCRYPTION_WALLET;
   
   WRL_PARAMETER
   --------------------------------------------------------------------------------
   /u01/oracle/product/12.2.0/dbhome_1/data/wallet/
   ```

   Qui, `/u01/oracle/product/12.2.0/dbhome_1/data/wallet/` è la posizione del wallet.

1. Ottieni l'ID della chiave principale per una fonte non CDB o CDB come segue:

   1. Per una fonte non CDB, esegui la seguente query per recuperare l'ID della chiave di crittografia principale:

      ```
      SQL>  select rownum, key_id, activation_time from v$encryption_keys;
      
      ROWNUM KEY_ID                                                 ACTIVATION_TIME
      ------ ------------------------------------------------------ ---------------
           1 AeKask0XZU+NvysflCYBEVwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA   04-SEP-24 10.20.56.605200 PM +00:00
           2 AV7WU9uhoU8rv8daE/HNnSwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA   10-AUG-21 07.52.03.966362 PM +00:00
           3 AckpoJ/f+k8xvzJ+gSuoVH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA   14-SEP-20 09.26.29.048870 PM +00:00
      ```

      Il tempo di attivazione è utile se prevedi di avviare CDC da un momento all'altro. Ad esempio, utilizzando i risultati precedenti, è possibile avviare CDC da un punto compreso tra il 10 agosto e le 19.52.03 e il 14 settembre alle 21.26.29 utilizzando l'ID della chiave principale in ROWNUM 2. Quando l'operazione raggiunge il ripristino generato il 14-set-20 09.26.29 PM o dopo tale data fallisce, è necessario modificare l'endpoint di origine, fornire l'ID della chiave principale in ROWNUM 3 e quindi riprendere l'attività.

   1. Per CDB source DMS richiede la chiave di crittografia CDB\$1ROOT Master. Connect a CDB\$1ROOT ed esegui la seguente query:

      ```
      SQL> select rownum, key_id, activation_time from v$encryption_keys where con_id = 1;
      
      ROWNUM KEY_ID                                               ACTIVATION_TIME
      ------ ---------------------------------------------------- -----------------------------------
           1 Aa2E/Vwb5U+zv5hCncS5ErMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 29-AUG-24 12.51.19.699060 AM +00:00
      ```

1. Dalla riga di comando, elenca le voci del wallet di crittografia sull'host di database Oracle di origine.

   ```
   $ mkstore -wrl /u01/oracle/product/12.2.0/dbhome_1/data/wallet/ -list
   Oracle Secret Store entries:
   ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   ORACLE.SECURITY.DB.ENCRYPTION.AY1mRA8OXU9Qvzo3idU4OH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   ORACLE.SECURITY.DB.ENCRYPTION.MASTERKEY
   ORACLE.SECURITY.ID.ENCRYPTION.
   ORACLE.SECURITY.KB.ENCRYPTION.
   ORACLE.SECURITY.KM.ENCRYPTION.AY1mRA8OXU9Qvzo3idU4OH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   ```

   Trova la voce contenente l'ID della chiave master che hai trovato nella fase 2 (`AWGDC9glSk8Xv+3bVveiVSg`). Questa voce è il nome della chiave di crittografia TDE.

1. Visualizza i dettagli della voce trovata nella fase precedente.

   ```
   $ mkstore -wrl /u01/oracle/product/12.2.0/dbhome_1/data/wallet/ -viewEntry ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   Oracle Secret Store Tool : Version 12.2.0.1.0
   Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved.
   Enter wallet password:
   ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA = AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==
   ```

   Inserisci la password del wallet per vedere il risultato.

   Qui, il valore a destra di `'='` è la password TDE.

1. Specifica il nome della chiave di crittografia TDE per l'endpoint di origine Oracle impostando l'attributo aggiuntivo di connessione `securityDbEncryptionName`.

   ```
   securityDbEncryptionName=ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   ```

1. Fornisci la password TDE associata a questa chiave sulla console come parte del valore **Password** dell'origine Oracle. Utilizza l'ordine seguente per formattare i valori delle password separati da virgole, terminati dal valore della password TDE.

   ```
   Oracle_db_password,ASM_Password,AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==
   ```

   Specificare i valori della password in questo ordine indipendentemente dalla configurazione del database Oracle. Ad esempio, se si utilizza TDE ma il database Oracle non utilizza ASM, specifica i valori delle password nel seguente ordine separato da virgole.

   ```
   Oracle_db_password,,AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==
   ```

Se le credenziali TDE specificate non sono corrette, l'operazione di AWS DMS migrazione non ha esito negativo. Tuttavia, l'attività non legge né applica le modifiche di replica in corso al database di destinazione. Dopo aver avviato l'attività, monitora le **Statistiche della tabella** nella pagina dell'attività di migrazione della console per assicurarti che le modifiche vengano replicate.

Se un amministratore di database modifica i valori delle credenziali TDE per il database Oracle durante l'esecuzione, l'attività ha esito negativo. Il messaggio di errore contiene il nuovo nome della chiave di crittografia TDE. Per specificare nuovi valori e riavviare l'attività, utilizza la procedura precedente.

**Importante**  
Non è possibile manipolare un wallet TDE creato in una posizione Oracle Automatic Storage Management (ASM) perché i comandi a livello di sistema operativo, come `cp`, `mv`, `orapki` e `mkstore`, danneggiano i file del wallet archiviati in una posizione ASM. Questa restrizione è specifica solo per i file del wallet TDE archiviati in una posizione ASM, ma non per i file del wallet TDE archiviati in una directory del sistema operativo locale.  
Per manipolare un wallet TDE archiviato in ASM con comandi a livello di sistema operativo, crea un keystore locale e unisci il keystore ASM nel keystore locale come segue:   
Crea un keystore locale.  

   ```
   ADMINISTER KEY MANAGEMENT create keystore file system wallet location identified by wallet password;
   ```
Unisci il keystore ASM nel keystore locale.  

   ```
   ADMINISTER KEY MANAGEMENT merge keystore ASM wallet location identified by wallet password into existing keystore file system wallet location identified by wallet password with backup;
   ```
Quindi, per elencare le voci del wallet di crittografia e la password TDE, esegui le fasi 3 e 4 sul keystore locale.

## Metodi di compressione supportati per l'utilizzo di Oracle come fonte per AWS DMS
<a name="CHAP_Source.Oracle.Compression"></a>

Nella tabella seguente, puoi trovare i metodi di compressione AWS DMS supportati quando si lavora con un database di origine Oracle. Come illustrato nella tabella, il supporto alla compressione dipende sia dalla versione del database Oracle in uso sia dal fatto che DMS sia configurato per utilizzare Oracle LogMiner per accedere ai redo log.


| Versione | Di base | OLTP |  HCC (da Oracle 11g R2 o versione successiva)  | Altri | 
| --- | --- | --- | --- | --- | 
| Oracle 10 | No | N/D | N/D | No | 
| Oracle 11 o versione successiva: Oracle LogMiner | Sì  | Sì | Sì  | Sì, qualsiasi metodo di compressione supportato da Oracle LogMiner. | 
| Oracle 11 o versione successiva, Binary Reader | Sì  | Sì | Sì. Per ulteriori informazioni, consulta la seguente nota. | Sì | 

**Nota**  
Quando l'endpoint di origine Oracle è configurato per utilizzare Binary Reader, il livello Query Low del metodo di compressione HCC è supportato solo per le attività di caricamento completo.

## Replica di tabelle annidate utilizzando Oracle come fonte per AWS DMS
<a name="CHAP_Source.Oracle.NestedTables"></a>

AWS DMS supporta la replica di tabelle Oracle contenenti colonne che sono tabelle nidificate o tipi definiti. Per abilitare questa funzionalità, aggiungere la seguente impostazione dell'attributo aggiuntivo di connessione all'endpoint di origine Oracle.

```
allowSelectNestedTables=true;
```

AWS DMS crea le tabelle di destinazione dalle tabelle nidificate di Oracle come normali tabelle principali e secondarie sulla destinazione senza un vincolo univoco. Per accedere ai dati corretti sulla destinazione, eseguire il join tra le tabelle padre e figlio. A tale scopo, creare manualmente un indice non univoco sulla colonna `NESTED_TABLE_ID` nella tabella figlio di destinazione. È quindi possibile utilizzare la colonna `NESTED_TABLE_ID` nella clausola di join `ON` insieme alla colonna padre che corrisponde al nome della tabella figlio. Inoltre, la creazione di un indice di questo tipo migliora le prestazioni quando i dati della tabella secondaria di destinazione vengono aggiornati o eliminati da. AWS DMS Per vedere un esempio, consulta [Esempio di join per le tabelle padre e figlio sulla destinazione](#CHAP_Source.Oracle.NestedTables.JoinExample).

Si consiglia di configurare l'arresto dell'attività dopo il completamento di un caricamento completo. Quindi, creare questi indici non univoci per tutte le tabelle figlio replicate nella destinazione e riprendere l'attività.

Se una tabella nidificata acquisita viene aggiunta a una tabella principale esistente (acquisita o non acquisita), la AWS DMS gestisce correttamente. Tuttavia, l'indice non univoco per la tabella di destinazione corrispondente non viene creato. In questo caso, se la tabella figlio di destinazione diventa estremamente grande, le prestazioni potrebbero risentirne. In tal caso, si consiglia di interrompere l'attività, creare l'indice, quindi riprendere l'attività.

Dopo che le tabelle nidificate vengono replicate nella destinazione, fare in modo che il DBA esegua un join sulle tabelle figlio padre e corrispondenti per appiattire i dati.

### Prerequisiti per la replica di tabelle nidificate Oracle come origine
<a name="CHAP_Source.Oracle.NestedTables.Prerequisites"></a>

Assicurarsi di replicare le tabelle padre per tutte le tabelle nidificate replicate. Include sia le tabelle principali (le tabelle contenenti la colonna della tabella nidificata) che le tabelle secondarie (ovvero nidificate) nelle mappature delle AWS DMS tabelle.

### Tipi di tabelle nidificate Oracle supportati come origine
<a name="CHAP_Source.Oracle.NestedTables.Types"></a>

AWS DMS supporta i seguenti tipi di tabelle nidificate Oracle come origine:
+ Tipo di dati
+ Oggetto definito dall'utente

### Limitazioni del AWS DMS supporto per le tabelle nidificate Oracle come fonte
<a name="CHAP_Source.Oracle.NestedTables.Limitations"></a>

AWS DMS presenta le seguenti limitazioni nel supporto delle tabelle nidificate Oracle come origine:
+ AWS DMS supporta solo un livello di nidificazione delle tabelle.
+ AWS DMS la mappatura delle tabelle non verifica che sia la tabella o le tabelle principale che quelle secondarie siano selezionate per la replica. Cioè, è possibile selezionare una tabella padre senza un a tabella figlio o una tabella figlio senza una tabella padre.

### In che modo AWS DMS replica le tabelle annidate di Oracle come fonte
<a name="CHAP_Source.Oracle.NestedTables.HowReplicated"></a>

AWS DMS replica le tabelle principali e nidificate sulla destinazione come segue:
+ AWS DMS crea la tabella principale identica a quella di origine. Definisce quindi la colonna nidificata nella tabella padre come `RAW(16)` e include un riferimento alle tabelle nidificate della tabella padre nella sua colonna `NESTED_TABLE_ID`.
+ AWS DMS crea la tabella figlio identica alla sorgente nidificata, ma con una colonna aggiuntiva denominata`NESTED_TABLE_ID`. Questa colonna ha lo stesso tipo e valore della colonna nidificata nella tabella padre corrispondente e ha lo stesso significato.

### Esempio di join per le tabelle padre e figlio sulla destinazione
<a name="CHAP_Source.Oracle.NestedTables.JoinExample"></a>

Per appiattire la tabella padre, eseguire un join tra le tabelle padre e figlio, come illustrato nell'esempio seguente:

1. Creare la tabella `Type`.

   ```
   CREATE OR REPLACE TYPE NESTED_TEST_T AS TABLE OF VARCHAR(50);
   ```

1. Creare la tabella padre con una colonna di tipo `NESTED_TEST_T` come definita precedentemente.

   ```
   CREATE TABLE NESTED_PARENT_TEST (ID NUMBER(10,0) PRIMARY KEY, NAME NESTED_TEST_T) NESTED TABLE NAME STORE AS NAME_KEY;
   ```

1. Appiattire la tabella `NESTED_PARENT_TEST` utilizzando un join con la tabella figlio `NAME_KEY` in cui `CHILD.NESTED_TABLE_ID` corrisponde a `PARENT.NAME`.

   ```
   SELECT … FROM NESTED_PARENT_TEST PARENT, NAME_KEY CHILD WHERE CHILD.NESTED_
   TABLE_ID = PARENT.NAME;
   ```

## Memorizzazione di REDO su Oracle ASM quando si utilizza Oracle come origine per AWS DMS
<a name="CHAP_Source.Oracle.REDOonASM"></a>

Per le origini Oracle con un'elevata generazione di REDO, l'archiviazione di REDO su Oracle ASM può favorire le prestazioni, specialmente in una configurazione RAC perché è possibile configurare DMS per distribuire le letture REDO di ASM su tutti i nodi ASM.

Per utilizzare questa configurazione, usa l'attributo di connessione `asmServer`. Ad esempio, la seguente stringa di connessione distribuisce le letture REDO di DMS su 3 nodi ASM:

```
asmServer=(DESCRIPTION=(CONNECT_TIMEOUT=8)(ENABLE=BROKEN)(LOAD_BALANCE=ON)(FAILOVER=ON)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node1_ip_address)(PORT=asm_node1_port_number))
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node2_ip_address)(PORT=asm_node2_port_number))
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node3_ip_address)(PORT=asm_node3_port_number)))
(CONNECT_DATA=(SERVICE_NAME=+ASM)))
```

Quando si utilizza NFS per archiviare i REDO Oracle, è importante assicurarsi che vengano applicate le patch del client DNFS (Direct NFS) applicabili, in particolare tutte le patch che risolvono il bug Oracle 25224242. Per ulteriori informazioni, consulta la seguente pubblicazione Oracle sulle patch relative al client Direct NFS, [Recommended Patches for Direct NFS Client](https://support.oracle.com/knowledge/Oracle Cloud/1495104_1.html). 

Inoltre, per migliorare le prestazioni di lettura NFS, si consiglia di aumentare il valore di `rsize` e `wsize` in `fstab` per il volume NFS, come mostrato nell'esempio seguente.

```
NAS_name_here:/ora_DATA1_archive /u09/oradata/DATA1 nfs rw,bg,hard,nointr,tcp,nfsvers=3,_netdev,
timeo=600,rsize=262144,wsize=262144
```

Inoltre, regola il valore `tcp-max-xfer-size` come segue:

```
vserver nfs modify -vserver vserver -tcp-max-xfer-size 262144
```

## Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS
<a name="CHAP_Source.Oracle.ConnectionAttrib"></a>

È possibile utilizzare le impostazioni degli endpoint per configurare il database di origine Oracle 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 contenuto in [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), con la sintassi `--oracle-settings '{"EndpointSetting": "value", ...}'` JSON.

Nella tabella seguente sono riportate le impostazioni degli endpoint che è possibile utilizzare con Oracle come origine.


| Nome | Description | 
| --- | --- | 
| AccessAlternateDirectly |  Imposta questo attributo su false per utilizzare Binary Reader al fine di acquisire i dati di modifica per un Amazon RDS per Oracle come origine. In questo modo l'istanza DMS è configurata per non accedere ai log redo tramite qualsiasi sostituzione del prefisso del percorso specificato utilizzando l'accesso diretto ai file. Per ulteriori informazioni, consulta [Configurazione di un'attività CDC per l'utilizzo di Binary Reader con un codice sorgente RDS for Oracle per AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). Valore predefinito: true  Valori validi: true/false Ad esempio: `--oracle-settings '{"AccessAlternateDirectly": false}'`  | 
|  `AdditionalArchivedLogDestId`  |  Imposta questo attributo con `ArchivedLogDestId` in una configurazione principale/in standby. Questo attributo è utile in caso di switchover quando si utilizza un database Oracle Data Guard come origine. In questo caso, AWS DMS deve sapere da quale destinazione recuperare i redo log dell'archivio per leggere le modifiche. Ciò è necessario perché dopo lo switchover l'istanza primaria precedente è diventata un'istanza di standby. Sebbene AWS DMS supporti l'uso dell'`RESETLOGS`opzione Oracle per aprire il database, non utilizzarla mai a `RESETLOGS` meno che non sia necessario. Per ulteriori informazioni su `RESETLOGS`, consulta [RMAN Data Repair Concepts](https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-data-repair-concepts.html#GUID-1805CCF7-4AF2-482D-B65A-998192F89C2B) nella *Guida per l'utente di Oracle® Database Backup and Recovery*. Valori validi: ID di destinazione dell'archivio Ad esempio: `--oracle-settings '{"AdditionalArchivedLogDestId": 2}'`  | 
|  `AddSupplementalLogging`  |  Imposta questo attributo per configurare il log supplementare a livello di tabella per il database Oracle. Questo attributo abilita uno dei seguenti elementi in tutte le tabelle selezionate per un'attività di migrazione, a seconda dei metadati della tabella: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.Oracle.html) Valore predefinito: false  Valori validi: true/false  Ad esempio: `--oracle-settings '{"AddSupplementalLogging": false}'`  Se utilizzi questa opzione, è comunque necessario abilitare il log supplementare a livello di database come descritto in precedenza.    | 
|  `AllowSelectNestedTables`  |  Imposta questo attributo su true per abilitare la replica delle tabelle Oracle contenenti colonne che sono tabelle nidificate o tipi definiti. Per ulteriori informazioni, consulta [Replica di tabelle annidate utilizzando Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.NestedTables). Valore predefinito: false  Valori validi: true/false Ad esempio: `--oracle-settings '{"AllowSelectNestedTables": true}'`  | 
|  `ArchivedLogDestId`  |  Specifica l'ID di destinazione per i registri di ripristino archiviati. Questo valore deve corrispondere a un numero nella colonna dest\$1id della visualizzazione v\$1archived\$1log. Se utilizzi una destinazione aggiuntiva per i log redo, ti consigliamo di usare l'attributo `AdditionalArchivedLogDestId` per specificare l'ID della destinazione aggiuntiva. In questo modo è possibile migliorare le prestazioni garantendo l'accesso ai log corretti fin dal principio.  Valore predefinito: 1 Valori validi: numero  Ad esempio: `--oracle-settings '{"ArchivedLogDestId": 1}'`  | 
|  `ArchivedLogsOnly`  |  Quando questo campo è impostato su Y, accede AWS DMS solo ai redo log archiviati. Se i redo log archiviati sono memorizzati solo su Oracle ASM, all'account AWS DMS utente devono essere concessi i privilegi ASM.  Valore predefinito: N  Valori validi: Y/N  Ad esempio: `--oracle-settings '{"ArchivedLogsOnly": Y}'`  | 
|  `asmUsePLSQLArray` (solo ECA)  |  Utilizzate questo attributo di connessione aggiuntivo (ECA) quando acquisite le modifiche all'origine con. BinaryReader Questa impostazione consente a DMS di memorizzare nel buffer 50 letture a livello di ASM per singolo thread di lettura controllando al contempo il numero di thread che utilizzano l'attributo `parallelASMReadThreads`. Quando impostate questo attributo, il lettore AWS DMS binario utilizza un PL/SQL blocco anonimo per acquisire i dati di ripristino e inviarli all'istanza di replica come buffer di grandi dimensioni. Ciò riduce il numero di round trip all'origine. Inoltre, può migliorare in modo significativo le prestazioni di acquisizione dell'origine, ma comporta un maggiore consumo di memoria PGA sull'istanza ASM. Potrebbero sorgere problemi di stabilità se la destinazione di memoria non è sufficiente. È possibile utilizzare la formula seguente per stimare l'utilizzo totale della memoria PGA dell'istanza ASM per una singola attività DMS: `number_of_redo_threads * parallelASMReadThreads * 7 MB` Valore predefinito: false Valori validi: true/false Esempio ECA: `asmUsePLSQLArray=true;`  | 
|  `ConvertTimestampWithZoneToUTC`  |  Imposta questo attributo su `true` per convertire in UTC il valore del timestamp delle colonne "TIMESTAMP WITH TIME ZONE" e "TIMESTAMP WITH LOCAL TIME ZONE". Per impostazione predefinita, il valore di questo attributo è "false" e i dati vengono replicati utilizzando il fuso orario del database di origine. Valore predefinito: false Valori validi: true/false Ad esempio: `--oracle-settings '{"ConvertTimestampWithZoneToUTC": true}'`  | 
|  `EnableHomogenousPartitionOps`  |  Imposta questo attributo su `true` per abilitare la replica delle operazioni DDL su partizioni e sottopartizioni Oracle per la migrazione *omogenea* di Oracle. Si noti che questa funzionalità e questo miglioramento sono stati introdotti nella versione 3.4.7. AWS DMS  Valore predefinito: false Valori validi: true/false Ad esempio: `--oracle-settings '{"EnableHomogenousPartitionOps": true}'`  | 
|  `EnableHomogenousTablespace`  |  Imposta questo attributo per consentire la replica omogenea degli spazi tabelle e la creazione di tabelle o indici esistenti negli stessi spazi tabelle sulla destinazione. Valore predefinito: false Valori validi: true/false Ad esempio: `--oracle-settings '{"EnableHomogenousTablespace": true}'`  | 
|  `EscapeCharacter`  |  Imposta questo attributo su un carattere di escape. Il carattere di escape consente che un singolo carattere jolly si comporti come un normale carattere nelle espressioni di mappatura delle tabelle. Per ulteriori informazioni, consulta [Caratteri jolly nella mappatura delle tabelle](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Wildcards.md). Valore predefinito: Null  Valori validi: qualsiasi carattere diverso da un carattere jolly Ad esempio: `--oracle-settings '{"EscapeCharacter": "#"}'` Può essere utilizzato solo `escapeCharacter` per i nomi delle tabelle. Non imposta i caratteri di escape dei nomi degli schemi o dei nomi delle colonne.  | 
|  `ExposeViews`  |  Utilizza questo attributo per estrarre i dati una volta da una vista. Non è possibile utilizzarlo per la replica continua. Quando estrai dati da una vista, quest'ultima viene mostrata come tabella sullo schema di destinazione. Valore predefinito: false Valori validi: true/false Ad esempio: `--oracle-settings '{"ExposeViews": true}'`  | 
|  `ExtraArchivedLogDestIds`  |  Specifica un'altra destinazione per IDs uno o più redo log archiviati. Questi IDs sono i valori della colonna dest\$1id nella vista v\$1archived\$1log. Usa questa impostazione con l'attributo ArchivedLogDestId extra connection in una configurazione o in una configurazione. primary-to-single primary-to-multiple-standby Questa impostazione è utile in caso di switchover quando si utilizza un database Oracle Data Guard come origine. In questo caso, sono AWS DMS necessarie informazioni sulla destinazione da cui recuperare i redo log dell'archivio per leggere le modifiche. AWS DMS ne ha bisogno perché dopo il passaggio l'istanza primaria precedente è un'istanza di standby. Valori validi: ID di destinazione dell'archivio Ad esempio: `--oracle-settings '{"ExtraArchivedLogDestIds": 1}'`  | 
|  `FailTasksOnLobTruncation`  |  Se è impostato su `true`, questo attributo non consentirà la riuscita di un'attività se le dimensioni attuali di una colonna LOB sono maggiori di quelle specificate in `LobMaxSize`. Se un'attività è impostata sulla modalità LOB limitata e questa opzione è impostata su `true`, l'operazione ha esito negativo invece di troncare i dati LOB. Valore predefinito: false  Valori validi: booleani  Ad esempio: `--oracle-settings '{"FailTasksOnLobTruncation": true}'`  | 
|  `filterTransactionsOfUser` (solo ECA)  |  Utilizza questo attributo di connessione aggiuntivo (ECA) per consentire a DMS di ignorare le transazioni di un utente specificato durante la replica dei dati da Oracle durante l'utilizzo. LogMiner È possibile passare i nomi utente separati da virgole, ma devono essere scritti solo in lettere MAIUSCOLE. Esempio ECA: `filterTransactionsOfUser=USERNAME;`  | 
|  `NumberDataTypeScale`  |  Specifica il fattore di dimensionamento. È possibile selezionare un aumento fino a 38 oppure è possibile selezionare -1 per FLOAT o -2 per VARCHAR. Per impostazione predefinita, il tipo di dati NUMBER è convertito alla precisione 38, dimensione 10. Valore predefinito: 10  Valori validi: da -2 a 38 (-2 per VARCHAR, -1 per FLOAT) Ad esempio: `--oracle-settings '{"NumberDataTypeScale": 12}'`  Seleziona una combinazione con scala di precisione, -1 (FLOAT) o -2 (VARCHAR). DMS supporta qualsiasi combinazione con scala di precisione prevista da Oracle. Se la precisione è pari o superiore a 39, seleziona -2 (VARCHAR). L' NumberDataTypeScale impostazione per il database Oracle viene utilizzata solo per il tipo di dati NUMBER (senza la precisione esplicita e la definizione della scala). È necessario notare che può verificarsi una perdita di precisione quando questa impostazione non è configurata correttamente.   | 
|  `OpenTransactionWindow`  |   Fornisce l'intervallo di tempo in minuti per verificare la presenza di eventuali transazioni aperte per l'attività di sola CDC. Quando è impostato su `OpenTransactionWindow` 1 o superiore, DMS converte i `SCN_TO_TIMESTAMP` valori SCN in valori di timestamp. A causa delle limitazioni del database Oracle, se si specifica un SCN troppo vecchio come punto di partenza CDC, SCN\$1TO\$1TIMESTAMP fallirà con un errore e non sarà possibile avviare attività solo CDC. `ORA-08181` Valore predefinito: 0  Valori validi: numero intero da 0 a 240 Ad esempio: `openTransactionWindow=15;`  | 
| OraclePathPrefix | Imposta questo attributo stringa sul valore richiesto per utilizzare Binary Reader al fine di acquisire dati di modifica per un Amazon RDS per Oracle come origine. Questo valore specifica la radice Oracle predefinita utilizzata per accedere ai log redo. Per ulteriori informazioni, consulta [Configurazione di un'attività CDC per l'utilizzo di Binary Reader con un codice sorgente RDS for Oracle per AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).Valore predefinito: nessuno rdsdbdata/db/ORCLValore valido:/\$1A/ Ad esempio: `--oracle-settings '{"OraclePathPrefix": "/rdsdbdata/db/ORCL_A/"}'`  | 
| ParallelASMReadThreads |  Imposta questo attributo per modificare il numero di thread configurati da DMS per eseguire l'acquisizione dei dati di modifica (CDC) utilizzando Oracle Automatic Storage Management (ASM). È possibile specificare un valore intero compreso tra 2 (impostazione predefinita) e 8 (massimo). Utilizzare questo attributo con l'attributo `ReadAheadBlocks`. Per ulteriori informazioni, consulta [Configurazione di un'attività CDC per l'utilizzo di Binary Reader con un codice sorgente RDS for Oracle per AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). Valore predefinito: 2  Valori validi: numero intero da 2 a 8 Ad esempio: `--oracle-settings '{"ParallelASMReadThreads": 6;}'`  | 
| ReadAheadBlocks |  Imposta questo attributo per modificare il numero di thread configurati da DMS per eseguire CDC utilizzando Oracle Automatic Storage Management (ASM) e lo storage NAS non ASM. È possibile specificare un valore intero compreso tra 1000 (impostazione predefinita) e 2.000.000 (massimo). Utilizzare questo attributo con l'attributo `ParallelASMReadThreads`. Per ulteriori informazioni, consulta [Configurazione di un'attività CDC per l'utilizzo di Binary Reader con un codice sorgente RDS for Oracle per AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). Valore predefinito: 1000  Valori validi: un numero intero compreso tra 1000 e 2.000.000 Ad esempio: `--oracle-settings '{"ReadAheadBlocks": 150000}'`  | 
|  `ReadTableSpaceName`  |  Quando è impostato su `true`, questo attributo supporta la replica dello spazio tabella. Valore predefinito: false  Valori validi: booleani  Ad esempio: `--oracle-settings '{"ReadTableSpaceName": true}'`  | 
| ReplacePathPrefix | Imposta questo attributo su true per utilizzare Binary Reader al fine di acquisire i dati di modifica per un Amazon RDS per Oracle come origine. Questa impostazione indica all'istanza DMS di sostituire la radice Oracle predefinita con l'impostazione UsePathPrefix specificata per accedere ai log redo. Per ulteriori informazioni, consulta [Configurazione di un'attività CDC per l'utilizzo di Binary Reader con un codice sorgente RDS for Oracle per AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).Valore predefinito: false Valori validi: true/false Ad esempio: `--oracle-settings '{"ReplacePathPrefix": true}'`  | 
|  `RetryInterval`  |  Specifica il numero di secondi che il sistema attende prima di reinviare una query.  Valore predefinito: 5  Valori validi: numeri a partire da 1  Ad esempio: `--oracle-settings '{"RetryInterval": 6}'`  | 
|  `SecurityDbEncryptionName`  |  Specifica il nome di una chiave utilizzata per la crittografia trasparente dei dati (TDE) delle colonne e dei tablespace nel database di origine Oracle. Per ulteriori informazioni sull'impostazione di questo attributo e della relativa password associata nell'endpoint di origine Oracle, consulta [Metodi di crittografia supportati per l'utilizzo di Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.Encryption). Valore predefinito: ""  Valori validi: stringa  Ad esempio: `--oracle-settings '{"SecurityDbEncryptionName": "ORACLE.SECURITY.DB.ENCRYPTION.Adg8m2dhkU/0v/m5QUaaNJEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"}'`  | 
|  `SpatialSdo2GeoJsonFunctionName`  |  Per le origini Oracle 12.1 o precedenti che migrano verso destinazioni PostgreSQL, utilizzare questo attributo per convertire SDO\$1GEOMETRY in formato GEOJSON. Per impostazione predefinita, AWS DMS chiama la funzione `SDO2GEOJSON` personalizzata che deve essere presente e accessibile all'utente. AWS DMS In alternativa, puoi creare una funzione personalizzata che imita l'operazione di `SDOGEOJSON` e impostare `SpatialSdo2GeoJsonFunctionName` affinché la richiami.  Valore predefinito: SDO2 GEOJSON Valori validi: stringa  Ad esempio: `--oracle-settings '{"SpatialSdo2GeoJsonFunctionName": "myCustomSDO2GEOJSONFunction"}'`  | 
|  `StandbyDelayTime`  |  Utilizza questo attributo per specificare il tempo di ritardo in minuti della sincronizzazione in standby. Se l'origine è un database in standby Active Data Guard, utilizza questo attributo per specificare l'intervallo di tempo tra il database primario e quello in standby. In AWS DMS, puoi creare un'attività Oracle CDC che utilizza un'istanza di standby di Active Data Guard come origine per la replica delle modifiche in corso. Questa operazione elimina la necessità di connettersi a un database attivo che potrebbe essere in produzione. Valore predefinito: 0  Valori validi: numero  Ad esempio: `--oracle-settings '{"StandbyDelayTime": 1}'` **Nota: **quando si utilizza DMS 3.4.6, 3.4.7 e versioni successive, l'uso di questa impostazione di connessione è facoltativo. Nell'ultima versione di DMS 3.4.6 e nella versione 3.4.7, `dms_user` deve avere l'autorizzazione `select` su `V_$DATAGUARD_STATS`, che consente a DMS di calcolare il tempo di ritardo in standby.  | 
| UseAlternateFolderForOnline | Imposta questo attributo su true per utilizzare Binary Reader al fine di acquisire i dati di modifica per un Amazon RDS per Oracle come origine. In questo modo l'istanza DMS utilizza qualsiasi sostituzione prefisso specificata per accedere a tutti i log redo online. Per ulteriori informazioni, consulta [Configurazione di un'attività CDC per l'utilizzo di Binary Reader con un codice sorgente RDS for Oracle per AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).Valore predefinito: false Valori validi: true/false Ad esempio: `--oracle-settings '{"UseAlternateFolderForOnline": true}'`  | 
| UseBfile |  Imposta questo attributo su Y (Sì) per acquisire i dati utilizzando la utility Binary Reader. Imposta `UseLogminerReader` su N (No) per impostare questo attributo su Y (Sì). Per utilizzare Binary Reader con Amazon RDS per Oracle come origine, è necessario impostare attributi aggiuntivi. Per ulteriori informazioni su questa impostazione e sull'utilizzo di Oracle ASM, vedere [Utilizzo di Oracle LogMiner o AWS DMS Binary Reader for CDC](#CHAP_Source.Oracle.CDC). Nota: quando si imposta questo valore come attributo aggiuntivo di connessione, i valori validi sono "Y" e "N". Quando si configura questo valore come impostazione dell'endpoint, i valori validi sono `true` e `false`. Valore predefinito: N  Valori validi: Y/N (quando si imposta questo valore come ECA); true/false (quando si imposta questo valore come impostazione dell'endpoint). Ad esempio: `--oracle-settings '{"UseBfile": Y}'`  | 
|  `UseLogminerReader`  |  Imposta questo attributo su Y per acquisire i dati di modifica utilizzando l' LogMiner utilità (impostazione predefinita). Imposta questa opzione su N se desideri che AWS DMS acceda ai redo log come file binario. Quando imposti questa opzione su N, aggiungi anche l'impostazione usebFile=y. Per ulteriori informazioni su questa impostazione e sull'utilizzo di Oracle Automatic Storage Management (ASM), consulta [Utilizzo di Oracle LogMiner o AWS DMS Binary Reader for CDC](#CHAP_Source.Oracle.CDC). Nota: quando si imposta questo valore come attributo aggiuntivo di connessione, i valori validi sono "Y" e "N". Quando si configura questo valore come impostazione dell'endpoint, i valori validi sono `true` e `false`. Valore predefinito: Y  Valori validi: Y/N (quando si imposta questo valore come ECA); true/false (quando si imposta questo valore come impostazione dell'endpoint). Ad esempio: `--oracle-settings '{"UseLogminerReader": Y}'`  | 
| UsePathPrefix | Imposta questo attributo stringa sul valore richiesto per utilizzare Binary Reader al fine di acquisire dati di modifica per un Amazon RDS per Oracle come origine. Questo valore specifica il prefisso del percorso utilizzato per sostituire la radice Oracle predefinita per accedere ai log redo. Per ulteriori informazioni, consulta [Configurazione di un'attività CDC per l'utilizzo di Binary Reader con un codice sorgente RDS for Oracle per AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).Valore predefinito: nessuno Valore valido: /rdsdbdata/log/ Ad esempio: `--oracle-settings '{"UsePathPrefix": "/rdsdbdata/log/"}'`  | 

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

L'endpoint Oracle for AWS DMS supporta la maggior parte dei tipi di dati Oracle. La tabella seguente mostra i tipi di dati di origine Oracle supportati durante l'utilizzo AWS DMS e la mappatura predefinita ai tipi di AWS DMS dati.

**Nota**  
Ad eccezione dei tipi di dati LONG e LONG RAW, durante la replica da un'origine Oracle a una destinazione Oracle (*replica omogenea*), tutti i tipi di dati di origine e di destinazione saranno identici. Tuttavia, il tipo di dati LONG verrà mappato su CLOB e il tipo di dati LONG RAW verrà mappato su BLOB. 

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


|  Tipo di dati Oracle  |  AWS DMS tipo di dati  | 
| --- | --- | 
|  BINARY\$1FLOAT  |  REAL4  | 
|  BINARY\$1DOUBLE  |  REAL8  | 
|  BINARY  |  BYTES  | 
|  FLOAT (P)  |  Se la precisione è inferiore o uguale a 24, utilizzare REAL4. Se la precisione è maggiore di 24, utilizzare REAL8.  | 
|  NUMBER (P,S)  |  Quando la dimensione è maggiore di 0, utilizza NUMERIC. Quando la dimensione è 0: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.Oracle.html) Quando la scala è inferiore a 0, usa REAL8. | 
|  DATE  |  DATETIME  | 
|  INTERVAL\$1YEAR TO MONTH  |  STRING (con indicazione interval year\$1to\$1month)  | 
|  INTERVAL\$1DAY TO SECOND  |  STRING (con indicazione interval day\$1to\$1second)  | 
|  TIMESTAMP  |  DATETIME  | 
|  TIMESTAMP WITH TIME ZONE  |  STRING (con indicazione timestamp\$1with\$1timezone)  | 
|  TIMESTAMP WITH LOCAL TIME ZONE  |  STRING (con indicazione timestamp\$1with\$1local\$1 timezone)  | 
|  CHAR  |  STRING  | 
|  VARCHAR2  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.Oracle.html)  | 
|  NCHAR  |  WSTRING  | 
|  NVARCHAR2  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.Oracle.html)  | 
|  RAW  |  BYTES  | 
|  REAL  |  REAL8  | 
|  BLOB  |  BLOB 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.  | 
|  CLOB  |  CLOB Per utilizzare questo tipo di dati con AWS DMS, è necessario abilitare l'uso dei tipi di dati CLOB per un'attività specifica. Durante CDC, AWS DMS supporta i tipi di dati CLOB solo nelle tabelle che includono una chiave primaria.  | 
|  NCLOB  |  NCLOB 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.  | 
|  LONG  |  CLOB Il tipo di dati LONG non è supportato nella modalità di applicazione ottimizzata per batch (modalità CDC). TurboStream  Per utilizzare questo tipo di dati con AWS DMS, abilita l'uso di LOBs per un'attività specifica. Durante CDC o a pieno carico, AWS DMS supporta i tipi di dati LOB solo nelle tabelle con una chiave primaria. Inoltre, non AWS DMS supporta la modalità LOB completa per il caricamento di colonne LONG. È invece possibile utilizzare la modalità LOB limitata per migrare le colonne LONG in una destinazione Oracle. In modalità LOB limitata, AWS DMS tronca a 64 KB tutti i dati impostati su colonne LONG più lunghe di 64 KB. Per ulteriori informazioni sul supporto LOB in, vedere AWS DMS[Impostazione del supporto LOB per i database di origine in un task AWS DMS](CHAP_Tasks.LOBSupport.md)  | 
|  LONG RAW  |  BLOB Il tipo di dati LONG RAW non è supportato nella modalità di applicazione ottimizzata per batch (modalità TurboStream CDC). Per utilizzare questo tipo di dati con AWS DMS, abilita l'uso di LOBs per un'attività specifica. Durante CDC o a pieno carico, AWS DMS supporta i tipi di dati LOB solo nelle tabelle con una chiave primaria. Inoltre, non AWS DMS supporta la modalità LOB completa per il caricamento delle colonne LONG RAW. È invece possibile utilizzare la modalità LOB limitata per migrare le colonne LONG RAW in una destinazione Oracle. In modalità LOB limitata, AWS DMS tronca a 64 KB tutti i dati impostati nelle colonne LONG RAW più lunghe di 64 KB. Per ulteriori informazioni sul supporto LOB in AWS DMS, vedere [Impostazione del supporto LOB per i database di origine in un task AWS DMS](CHAP_Tasks.LOBSupport.md)  | 
|  XMLTYPE  |  CLOB  | 
| SDO\$1GEOMETRY | BLOB (in caso di migrazione da Oracle a Oracle)CLOB (in caso di migrazione da Oracle a PostgreSQL) | 

Le tabelle Oracle utilizzate come origine con colonne dei seguenti tipi di dati non sono supportate e non possono essere replicate. La replica di colonne con questi tipi di dati risulta in una colonna null.
+ BFILE
+ ROWID
+ REF
+ UROWID
+ Tipi di dati definiti dall’utente
+ ANYDATA
+ VARRAY

**Nota**  
Le colonne virtuali non sono supportate.

### Migrazione dei tipi di dati spaziali di Oracle
<a name="CHAP_Source.Oracle.DataTypes.Spatial"></a>

I *dati spaziali* identificano le informazioni sulla geometria di un oggetto o di una posizione nello spazio. In un database Oracle, la descrizione geometrica di un oggetto spaziale viene memorizzata in un oggetto di tipo SDO\$1GEOMETRY. All'interno di questo oggetto, la descrizione geometrica viene memorizzata in una singola riga in una singola colonna di una tabella definita dall'utente. 

AWS DMS supporta la migrazione del tipo Oracle SDO\$1GEOMETRY da una fonte Oracle a un target Oracle o PostgreSQL.

Quando esegui la migrazione dei tipi di dati spaziali Oracle utilizzando, tieni presente queste considerazioni: AWS DMS
+ Quando si esegue la migrazione verso una destinazione Oracle, assicurarsi di trasferire manualmente le voci USER\$1SDO\$1GEOM\$1METADATA che includono informazioni sul tipo. 
+ Durante la migrazione da un endpoint di origine Oracle a un endpoint di destinazione PostgreSQL, crea colonne di destinazione. AWS DMS Queste colonne contengono informazioni predefinite sul tipo di geometria e di geografia con una dimensione 2D e un identificatore di riferimento spaziale (SRID) uguale a zero (0). Un esempio è `GEOMETRY, 2, 0`.
+ Per le origini Oracle 12.1 o precedenti che migrano a destinazioni PostgreSQL, convertire gli oggetti `SDO_GEOMETRY` in formato `GEOJSON` utilizzando la funzione `SDO2GEOJSON` o l'attributo di connessione aggiuntivo `spatialSdo2GeoJsonFunctionName`. Per ulteriori informazioni, consulta [Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib).
+ AWS DMS supporta le migrazioni di Oracle Spatial Column solo per la modalità Full LOB. AWS DMS non supporta le modalità LOB limitata o LOB in linea. Per ulteriori informazioni sulla modalità LOB, consulta [Impostazione del supporto LOB per i database di origine in un task AWS DMS](CHAP_Tasks.LOBSupport.md).
+ Poiché supporta AWS DMS solo la modalità Full LOB per la migrazione di Oracle Spatial Columns, la tabella delle colonne richiede una chiave primaria e una chiave univoca. Se la tabella non ha una chiave primaria e una chiave univoca, la tabella viene ignorata dalla migrazione.

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

# Utilizzo del database SQL di Microsoft Azure come origine per AWS DMS
<a name="CHAP_Source.AzureSQL"></a>

Con AWS DMS, puoi usare il database SQL di Microsoft Azure come origine più o meno allo stesso modo di SQL Server. AWS DMS supporta, come origine, lo stesso elenco di versioni di database supportate per SQL Server in esecuzione in locale o su un'istanza Amazon EC2. 

Per ulteriori informazioni, consulta [Utilizzo di un database Microsoft SQL Server come origine per AWS DMS](CHAP_Source.SQLServer.md).

**Nota**  
AWS DMS non supporta le operazioni di acquisizione dei dati di modifica (CDC) con il database SQL di Azure.

# Utilizzo di Microsoft Azure SQL Managed Instance come origine per AWS DMS
<a name="CHAP_Source.AzureMgd"></a>

Con AWS DMS, puoi usare Microsoft Azure SQL Managed Instance come origine più o meno allo stesso modo di SQL Server. AWS DMS supporta, come origine, lo stesso elenco di versioni di database supportate per SQL Server in esecuzione in locale o su un'istanza Amazon EC2. 

Per ulteriori informazioni, consulta [Utilizzo di un database Microsoft SQL Server come origine per AWS DMS](CHAP_Source.SQLServer.md).

# Utilizzo del server flessibile Microsoft Azure Database per PostgreSQL come origine per AWS DMS
<a name="CHAP_Source.AzureDBPostgreSQL"></a>

Con AWS DMS, puoi usare il server flessibile Microsoft Azure Database per PostgreSQL come origine più o meno allo stesso modo in cui usi PostgreSQL.

Per informazioni sulle versioni del server flessibile di Microsoft Azure Database per PostgreSQL AWS DMS che supporta come origine, vedere. [Fonti per AWS DMS](CHAP_Introduction.Sources.md)

## Configurazione del server flessibile Microsoft Azure per PostgreSQL per la replica e la decodifica logica
<a name="CHAP_Source.AzureDBPostgreSQL.setup"></a>

Puoi usare le funzionalità di replica e decodifica logica nel server flessibile Microsoft Azure Database per PostgreSQL durante la migrazione del database.

Per la decodifica logica, DMS utilizza il plug-in `test_decoding` o `pglogical`. Se il plug-in `pglogical` è disponibile su un database PostgreSQL di origine, DMS crea uno slot di replica utilizzando `pglogical`, altrimenti viene utilizzato il plug-in `test_decoding`. 

Per configurare il server flessibile Microsoft Azure per PostgreSQL come endpoint di origine per DMS, procedi nel seguente modo: 

1. Apri la pagina Parametri del server sul portale.

1. Imposta il parametro del server `wal_level` su `LOGICAL`.

1. Se desideri utilizzare l'estensione `pglogical`, imposta i parametri `shared_preload_libraries` e `azure.extensions` su `pglogical`.

1. Imposta il parametro `max_replication_slots` sul numero massimo di attività DMS che intendi eseguire contemporaneamente. In Microsoft Azure, il valore predefinito per questo parametro è 10. Il valore massimo di questo parametro dipende dalla memoria disponibile dell'istanza PostgreSQL, che consente da 2 a 8 slot di replica per GB di memoria.

1. Imposta il parametro `max_wal_senders` su un valore maggiore di 1. Il parametro `max_wal_senders` imposta il numero di attività simultanee che è possibile eseguire. Il valore predefinito è 10.

1. Imposta il valore del parametro `max_worker_processes` almeno su 16. In caso contrario, è possibile che vengano restituiti errori come i seguenti:

   ```
   WARNING: out of background worker slots.
   ```

1. Salvare le modifiche. Riavvia il server per applicare le modifiche.

1. Verifica che l'istanza PostgreSQL consenta il traffico di rete proveniente dalla risorsa di connessione.

1. Fornisci le autorizzazioni di replica a un utente esistente o crea un nuovo utente con le autorizzazioni di replica utilizzando i seguenti comandi. 
   + Fornisci a un utente esistente le autorizzazioni di replica utilizzando il seguente comando:

     ```
     ALTER USER <existing_user> WITH REPLICATION;
     ```
   + Crea un nuovo utente con le autorizzazioni di replica utilizzando il seguente comando: 

     ```
     CREATE USER aws_dms_user PASSWORD 'aws_dms_user_password';
     GRANT azure_pg_admin to aws_dms_user;
     ALTER ROLE aws_dms_user REPLICATION LOGIN;
     ```

Per ulteriori informazioni sulla replica logica con PostgreSQL, consulta i seguenti argomenti:
+ [Abilitazione dell'acquisizione dei dati di modifica (CDC) mediante la replica logica](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security)
+ [Utilizzo dei punti di avvio CDC nativi per impostare un carico CDC di un endpoint di origine PostgreSQL](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.v10)
+ [Logical replication and logical decoding in Azure Database for PostgreSQL - Flexible Server](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-logical) nella [documentazione del database di Azure per PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/).

# Utilizzo del server flessibile Microsoft Azure Database per MySQL come origine per AWS DMS
<a name="CHAP_Source.AzureDBMySQL"></a>

Con AWS DMS, puoi usare il server flessibile Microsoft Azure Database for MySQL come origine più o meno allo stesso modo in cui usi MySQL.

Per informazioni sulle versioni del server flessibile Microsoft Azure Database for MySQL AWS DMS che supporta come origine, vedere. [Fonti per AWS DMS](CHAP_Introduction.Sources.md) 

Per ulteriori informazioni sull'utilizzo di un database compatibile con MySQL gestito dal cliente con, vedere. AWS DMS[Utilizzo di un database autogestito compatibile con MySQL come fonte per AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.CustomerManaged)

## Limitazioni nell'uso di Azure MySQL come origine per AWS Database Migration Service
<a name="CHAP_Source.AzureDBMySQL.limitations"></a>
+ Il valore predefinito per la variabile di sistema del server flessibile Azure MySQL `sql_generate_invisible_primary_key` è`ON`, e il server aggiunge automaticamente una chiave primaria invisibile generata (GIPK) a qualsiasi tabella creata senza una chiave primaria esplicita. AWS DMS non supporta la replica continua per le tabelle MySQL con vincoli GIPK.

# Utilizzo di OCI MySQL Heatwave come fonte per AWS DMS
<a name="CHAP_Source.heatwave"></a>

Con AWS DMS, puoi usare OCI MySQL Heatwave come sorgente più o meno allo stesso modo di MySQL. L'uso di OCI MySQL Heatwave come origine richiede alcune modifiche di configurazione aggiuntive.

Per informazioni sulle versioni di OCI MySQL Heatwave AWS DMS supportate come sorgente, vedere. [Fonti per AWS DMS](CHAP_Introduction.Sources.md)

## Configurazione di OCI MySQL Heatwave per la replica logica
<a name="CHAP_Source.heatwave.setup"></a>

Per configurare l'istanza OCI MySQL Heatwave come endpoint di origine per DMS, procedi come segue:

1. Accedi alla console OCI e apri il menu principale a forma di hamburger (≡) nell'angolo in alto a sinistra.

1. Scegli **Database** e **Sistemi DB**.

1. Apri il menu **Configurazioni**.

1. Scegli **Crea configurazione**.

1. Immetti un nome per la configurazione, ad esempio **dms\$1configuration**.

1. Scegli la forma della tua attuale istanza OCI MySQL Heatwave. Puoi trovare la forma nella scheda delle proprietà di **configurazione del sistema database** dell'istanza nella sezione **Configurazione del sistema database: forma**.

1. Nella sezione **Variabili dell'utente** scegli la variabile di sistema `binlog_row_value_options`. Il valore predefinito è `PARTIAL_JSON`. Cancella il valore.

1. Scegli il pulsante **Crea**.

1. **Apri la tua SQLHeatwave istanza OCI My e scegli il pulsante Modifica.**

1. Nella sezione **Configurazione** seleziona il pulsante **Cambia configurazione** e scegli la configurazione della forma che hai creato nel passaggio 4.

1. Quando le modifiche diventano effettive, l'istanza è pronta per la replica logica.

# Utilizzo di Google Cloud for MySQL come fonte per AWS DMS
<a name="CHAP_Source.GC"></a>

Con AWS DMS, puoi utilizzare Google Cloud for MySQL come sorgente più o meno allo stesso modo in cui usi MySQL. 

Per informazioni sulle versioni di GCP MySQL AWS DMS supportate come sorgente, vedere. [Fonti per AWS DMS](CHAP_Introduction.Sources.md) 

Per ulteriori informazioni, consulta [Utilizzo di un database compatibile con MySQL come fonte per AWS DMS](CHAP_Source.MySQL.md).

**Nota**  
Il supporto per GCP MySQL 8.0 come sorgente è disponibile nella versione 3.4.6. AWS DMS   
AWS DMS non supporta la modalità SSL `verify-full` per GCP per istanze MySQL.  
L'`Allow only SSL connections`impostazione di sicurezza GCP MySQL non è supportata, poiché richiede la verifica del certificato sia del server che del client. AWS DMS supporta solo la verifica dei certificati del server.  
AWS DMS supporta il valore predefinito di GCP CloudSQL for MySQL per il flag del database. `CRC32` `binlog_checksum`

# Utilizzo di Google Cloud per PostgreSQL come sorgente per AWS DMS
<a name="CHAP_Source.GCPostgres"></a>

Con AWS DMS, puoi utilizzare Google Cloud for PostgreSQL come sorgente più o meno allo stesso modo dei database PostgreSQL autogestiti.

Per informazioni sulle versioni di GCP PostgreSQL supportate come sorgente, vedere AWS DMS . [Fonti per AWS DMS](CHAP_Introduction.Sources.md) 

Per ulteriori informazioni, consulta [Utilizzo di un database PostgreSQL come sorgente AWS DMS](CHAP_Source.PostgreSQL.md).

## Configurazione di Google Cloud per PostgreSQL per la replica e la decodifica logica
<a name="CHAP_Source.GCPostgres.setup"></a>

Puoi utilizzare le funzionalità di replica e decodifica logica in Google Cloud SQL per PostgreSQL durante la migrazione del database.

Per la decodifica logica, DMS utilizza uno dei seguenti plug-in:
+ `test_decoding`
+ `pglogical`

Se il plug-in `pglogical` è disponibile su un database PostgreSQL di origine, DMS crea uno slot di replica utilizzando `pglogical`, altrimenti viene utilizzato il plug-in `test_decoding`. 

Tieni presente quanto segue sull'uso della decodifica logica con: AWS DMS

1. Con Google Cloud SQL per PostgreSQL, abilita la decodifica logica impostando il flag `cloudsql.logical_decoding` su `on`.

1. Per abilitare `pglogical`, imposta il flag `cloudsql.enable_pglogical` su `on` e riavvia il database.

1. Per utilizzare le funzionalità di decodifica logica, crea un utente PostgreSQL con l'attributo `REPLICATION`. Quando usi l'estensione `pglogical` l'utente deve avere il ruolo `cloudsqlsuperuser`. Per creare un utente con il ruolo `cloudsqlsuperuser`, procedi come indicato di seguito:

   ```
   CREATE USER new_aws_dms_user WITH REPLICATION
   IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'new_aws_dms_user_password';
   ```

   Per impostare questo attributo su un utente esistente, completa queste operazioni:

   ```
   ALTER USER existing_user WITH REPLICATION;
   ```

1. Imposta il parametro `max_replication_slots` sul numero massimo di attività DMS che intendi eseguire contemporaneamente. In Google Cloud SQL, il valore predefinito per questo parametro è 10. Il valore massimo di questo parametro dipende dalla memoria disponibile dell'istanza PostgreSQL, che consente da 2 a 8 slot di replica per GB di memoria.

Per ulteriori informazioni sulla replica logica con PostgreSQL, consulta i seguenti argomenti:
+ [Abilitazione dell'acquisizione dei dati di modifica (CDC) mediante la replica logica](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security)
+ [Utilizzo dei punti di avvio CDC nativi per impostare un carico CDC di un endpoint di origine PostgreSQL](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.v10)
+ [Configurazione di replica e decodifica logiche](https://cloud.google.com/sql/docs/postgres/replication/configure-logical-replication) nella [documentazione di Cloud SQL per PostgreSQL](https://cloud.google.com/sql/docs/postgres).

# Utilizzo di un database PostgreSQL come sorgente AWS DMS
<a name="CHAP_Source.PostgreSQL"></a>

È possibile migrare i dati da uno o più database PostgreSQL utilizzando. AWS DMS Con un database PostgreSQL come origine, puoi eseguire la migrazione dei dati a un altro database PostgreSQL o a uno degli altri database supportati. 

Per informazioni sulle versioni di PostgreSQL supportate come sorgente, AWS DMS consulta. [Fonti per AWS DMS](CHAP_Introduction.Sources.md) 

AWS DMS supporta PostgreSQL per questi tipi di database: 
+ Database locali
+ Database su un'istanza Amazon EC2
+ Database su un'istanza database Amazon RDS
+ Database su un'istanza database basata su Amazon Aurora edizione compatibile con PostgreSQL
+ Database su un'istanza database basata su Amazon Aurora edizione serverless compatibile con PostgreSQL

**Nota**  
DMS supporta Amazon Aurora PostgreSQL serverless V1 come origine per solo pieno carico. Tuttavia puoi usare Amazon Aurora PostgreSQL serverless V2 come origine per le attività di pieno carico, pieno carico e CDC nonché sola CDC.

Puoi utilizzare il protocollo Secure Sockets Layer (SSL) per crittografare le connessioni tra l'endpoint PostgreSQL e l'istanza di replica. Per ulteriori informazioni sull'utilizzo di SSL con un endpoint PostgreSQL, consulta [Utilizzo di SSL con AWS Database Migration Service](CHAP_Security.SSL.md).

Come requisito di sicurezza aggiuntivo, quando si utilizza PostgreSQL come origine, l'account utente specificato deve essere un utente registrato nel database PostgreSQL.

Per configurare un database PostgreSQL come endpoint di origine, procedi AWS DMS come segue:
+ Crea un utente PostgreSQL con le autorizzazioni appropriate per fornire l' AWS DMS accesso al tuo database di origine PostgreSQL.
**Nota**  
Se il database di origine PostgreSQL è autogestito, consulta [Utilizzo di database PostgreSQL autogestiti come sorgente in AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites) per ulteriori informazioni.
Se il database di origine PostgreSQL è gestito da Amazon RDS, consulta [Utilizzo di database PostgreSQL AWS gestiti come sorgente DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL) per ulteriori informazioni.
+ Crea un endpoint do origine PostgreSQL conforme alla configurazione del database PostgreSQL scelta.
+ Crea un'attività o una serie di attività per migrare le tabelle.

  Per creare un' full-load-onlyattività, non è necessaria alcuna ulteriore configurazione dell'endpoint.

  Prima di creare un'attività per l'acquisizione dei dati di modifica (un'attività di sola CDC o pieno carico e CDC), consulta [Abilitazione del CDC utilizzando un database PostgreSQL autogestito come sorgente AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC) o [Abilitazione del CDC con un' AWS istanza DB PostgreSQL gestita con AWS DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC).

**Topics**
+ [Utilizzo di database PostgreSQL autogestiti come sorgente in AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites)
+ [Utilizzo di database PostgreSQL AWS gestiti come sorgente DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL)
+ [Abilitazione dell'acquisizione dei dati di modifica (CDC) mediante la replica logica](#CHAP_Source.PostgreSQL.Security)
+ [Utilizzo dei punti di avvio CDC nativi per impostare un carico CDC di un endpoint di origine PostgreSQL](#CHAP_Source.PostgreSQL.v10)
+ [Migrazione da PostgreSQL a PostgreSQL utilizzando AWS DMS](#CHAP_Source.PostgreSQL.Homogeneous)
+ [Migrazione da Babelfish per Amazon Aurora PostgreSQL utilizzando AWS DMS](#CHAP_Source.PostgreSQL.Babelfish)
+ [Rimozione di AWS DMS artefatti da un database sorgente PostgreSQL](#CHAP_Source.PostgreSQL.CleanUp)
+ [Impostazioni di configurazione aggiuntive quando si utilizza un database PostgreSQL come origine DMS](#CHAP_Source.PostgreSQL.Advanced)
+ [Leggi la replica come sorgente per PostgreSQL](#CHAP_Source.PostgreSQL.ReadReplica)
+ [Utilizzo dell'impostazione dell'`MapBooleanAsBoolean`endpoint PostgreSQL](#CHAP_Source.PostgreSQL.ConnectionAttrib.Endpointsetting)
+ [Impostazioni degli endpoint e attributi di connessione aggiuntivi (ECAs) quando si utilizza PostgreSQL come sorgente DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib)
+ [Limitazioni all'utilizzo di un database PostgreSQL come origine DMS](#CHAP_Source.PostgreSQL.Limitations)
+ [Tipi di dati di origine per PostgreSQL](#CHAP_Source-PostgreSQL-DataTypes)

## Utilizzo di database PostgreSQL autogestiti come sorgente in AWS DMS
<a name="CHAP_Source.PostgreSQL.Prerequisites"></a>

Con un database PostgreSQL autogestito come origine, puoi migrare i dati su un altro database PostgreSQL o su uno degli altri database di destinazione supportati da. AWS DMS Il database di origine può essere un database on-premise o un motore autogestito in esecuzione su un'istanza Amazon EC2. È possibile utilizzare un'istanza database sia per le attività di pieno carico che per l'acquisizione dei dati di modifica (CDC).

### Prerequisiti per l'utilizzo di un database PostgreSQL autogestito come sorgente AWS DMS
<a name="CHAP_Source.PostgreSQL.Prerequisites.SelfManaged"></a>

Prima di migrare i dati da un database di origine PostgreSQL autogestito, procedi come segue: 
+ Assicurati di utilizzare un database PostgreSQL versione 9.4.x o successiva.
+ Per le attività di pieno carico e CDC o le attività di sola CDC, fornisci le autorizzazioni di superuser per l'account utente specificato per il database di origine PostgreSQL. Le autorizzazioni di superuser sono necessarie all'account utente per accedere alle funzioni specifiche della replica nell'origine. L'account utente DMS necessita delle autorizzazioni SELECT su tutte le colonne per migrare correttamente le tabelle. Nel caso in cui manchino le autorizzazioni sulle colonne, DMS crea la tabella di destinazione utilizzando le normali mappature dei tipi di dati DMS, il che porta a differenze di metadati e errori nelle attività.
+ Aggiungere l'indirizzo IP del server di AWS DMS replica al file di `pg_hba.conf` configurazione e abilitare la replica e le connessioni socket. Di seguito è riportato un esempio.

  ```
              # Replication Instance
              host all all 12.3.4.56/00 md5
              # Allow replication connections from localhost, by a user with the
              # replication privilege.
              host replication dms 12.3.4.56/00 md5
  ```

  Il file di configurazione di PostgreSQL `pg_hba.conf` controlla l'autenticazione client. (HBA sta per autenticazione basata su host) Il file è solitamente memorizzato nella directory dei dati del cluster di database. 
+ Se stai configurando un database come origine per la replica logica usando see AWS DMS [Abilitazione del CDC utilizzando un database PostgreSQL autogestito come sorgente AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC)

**Nota**  
Alcune AWS DMS transazioni rimangono inattive per qualche tempo prima che il motore DMS le utilizzi nuovamente. Il parametro `idle_in_transaction_session_timeout` in PostgreSQL versione 9.6 e successive consente di mandare in timeout e in errore le transazioni inattive. Non terminare le transazioni inattive quando utilizzi AWS DMS. 

### Abilitazione del CDC utilizzando un database PostgreSQL autogestito come sorgente AWS DMS
<a name="CHAP_Source.PostgreSQL.Prerequisites.CDC"></a>

AWS DMS supporta l'acquisizione dei dati di modifica (CDC) mediante la replica logica. Per abilitare la replica logica su un database di origine PostgreSQL autogestito, imposta i seguenti parametri e valori nel file di configurazione `postgresql.conf`:
+ Imposta `wal_level = logical`.
+ Imposta `max_replication_slots` su un valore maggiore di 1.

  Imposta il valore `max_replication_slots` in base al numero di attività che desideri eseguire. Ad esempio, per eseguire cinque attività dovrai impostare un minimo di cinque slot. Gli slot si aprono automaticamente non appena viene avviata un'attività e restano aperti anche quando l'attività non è più in esecuzione. Assicurati di eliminare manualmente gli slot aperti. Tieni presente che DMS rilascia automaticamente gli slot di replica che ha creato quando l'attività viene eliminata.
+ Imposta `max_wal_senders` su un valore maggiore di 1.

  Il parametro `max_wal_senders` imposta il numero di attività simultanee che è possibile eseguire.
+ Il parametro `wal_sender_timeout` termina le connessioni di replica che sono inattive per un tempo maggiore del numero specificato di millisecondi. L'impostazione predefinita per un database PostgreSQL on-premise è di 60.000 millisecondi (60 secondi). L'impostazione del valore su 0 (zero) disabilita il meccanismo di timeout ed è un'opzione valida per DMS.

  Quando si imposta `wal_sender_timeout` su un valore diverso da zero, un'attività DMS con CDC richiede un minimo di 10.000 millisecondi (10 secondi) e non riesce se il valore è inferiore a 10.000. Mantieni il valore inferiore a 5 minuti per evitare ritardi durante un failover multi-AZ di un'istanza di replica DMS.

Alcuni parametri sono statici e possono essere impostati solo all'avvio del server. Qualsiasi modifica alle relative voci nel file di configurazione (per un database autogestito) o nel gruppo di parametri di database (per un database RDS per PostgreSQL) viene ignorata fino al riavvio del server. Per ulteriori informazioni, consultare la [documentazione di PostgreSQL](https://www.postgresql.org/docs/current/intro-whatis.html).

Per ulteriori informazioni sull'abilitazione della CDC, consulta [Abilitazione dell'acquisizione dei dati di modifica (CDC) mediante la replica logica](#CHAP_Source.PostgreSQL.Security).

## Utilizzo di database PostgreSQL AWS gestiti come sorgente DMS
<a name="CHAP_Source.PostgreSQL.RDSPostgreSQL"></a>

È possibile utilizzare un'istanza database PostgreSQL AWS gestita come origine per. AWS DMSÈ possibile eseguire attività di pieno carico e acquisizione dei dati di modifica (CDC) utilizzando un'origine PostgreSQL gestita da AWS. 

### Prerequisiti per l'utilizzo di un AWS database PostgreSQL gestito come sorgente DMS
<a name="CHAP_Source.PostgreSQL.RDSPostgreSQL.Prerequisites"></a>

Prima di migrare i dati da un database AWS sorgente PostgreSQL gestito, procedi come segue:
+ Si consiglia di utilizzare un account AWS utente con le autorizzazioni minime richieste per l'istanza DB PostgreSQL come account utente per l'endpoint di origine PostgreSQL per. AWS DMS L'utilizzo di un account master è sconsigliato. L'account deve avere il ruolo `rds_superuser` e il ruolo `rds_replication`. Il ruolo `rds_replication` fornisce le autorizzazioni per gestire gli slot logici e per eseguire lo streaming dei dati utilizzando gli slot logici.

  Assicurati di creare diversi oggetti dall'account utente master per l'account che utilizzi. Per informazioni sulla creazione di questi oggetti, consulta [Migrazione di un database Amazon RDS per PostgreSQL senza utilizzare l'account utente master](#CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser).
+ Se il database di origine è in un cloud privato virtuale (VPC), seleziona il gruppo di sicurezza VPC che fornisce accesso all'istanza database in cui risiede il database. Ciò è necessario affinché l'istanza di replica DMS si connetta correttamente all'istanza database di origine. Quando il database e l'istanza di replica DMS si trovano nello stesso VPC, aggiungi il gruppo di sicurezza appropriato alle relative regole in entrata.

**Nota**  
Alcune AWS DMS transazioni rimangono inattive per qualche tempo prima che il motore DMS le utilizzi nuovamente. Il parametro `idle_in_transaction_session_timeout` in PostgreSQL versione 9.6 e successive consente di mandare in timeout e in errore le transazioni inattive. Non terminare le transazioni inattive quando utilizzi AWS DMS.

### Abilitazione del CDC con un' AWS istanza DB PostgreSQL gestita con AWS DMS
<a name="CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC"></a>

AWS DMS supporta CDC sui database Amazon RDS PostgreSQL quando l'istanza DB è configurata per utilizzare la replica logica. La tabella seguente riassume la compatibilità della replica logica di ciascuna versione di PostgreSQL AWS gestita. 


|  Versione PostgreSQL  |  AWS DMS supporto a pieno carico   |  AWS DMS supporto CDC  | 
| --- | --- | --- | 
|  Aurora PostgreSQL versione 2.1 compatibile con PostgreSQL 10.5 (o versioni precedenti)  |  Sì  |  No  | 
|  Aurora PostgreSQL versione 2.2 compatibile con PostgreSQL 10.6 (o versioni successive)   |  Sì   |  Sì  | 
|  RDS per PostgreSQL compatibile con PostgreSQL 10.21 (o versioni successive)  |  Sì   |  Sì  | 

**Per abilitare la replica logica per un'istanza database RDS per PostgreSQL**

1. Usa l'account utente AWS principale per l'istanza DB PostgreSQL come account utente per l'endpoint di origine PostgreSQL. L'account utente master dispone dei ruoli necessari che consentono di configurare il CDC. 

   Se utilizzi un account diverso dall'account utente master, è necessario creare diversi oggetti dall'account utente master per l'account che utilizzi. Per ulteriori informazioni, consulta [Migrazione di un database Amazon RDS per PostgreSQL senza utilizzare l'account utente master](#CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser).

1. Imposta il parametro `rds.logical_replication` su 1 nel gruppo di parametri del cluster di database. Questo parametro statico richiede un riavvio dell'istanza database per avere effetto. Come parte dell'applicazione di questo parametro AWS DMS imposta i parametri `wal_level`, `max_wal_senders`, `max_replication_slots` e `max_connections`. Queste modifiche ai parametri possono aumentare la generazione dei WAL (Write Ahead Log), quindi impostare solo `rds.logical_replication` quando si utilizzano slot di replica logica.

1. Il parametro `wal_sender_timeout` termina le connessioni di replica che sono inattive per un tempo maggiore del numero specificato di millisecondi. L'impostazione predefinita per un database PostgreSQL AWS gestito è 30000 millisecondi (30 secondi). L'impostazione del valore su 0 (zero) disabilita il meccanismo di timeout ed è un'opzione valida per DMS.

   Quando si imposta `wal_sender_timeout` su un valore diverso da zero, un'attività DMS con CDC richiede un minimo di 10.000 millisecondi (10 secondi) e non riesce se il valore è compreso tra 0 e 10.000. Mantieni il valore inferiore a 5 minuti per evitare ritardi durante un failover multi-AZ di un'istanza di replica DMS.

1.  Assicurati che il valore del parametro `max_worker_processes` nel gruppo di parametri del cluster di database sia uguale o superiore ai valori totali combinati di `max_logical_replication_workers`, `autovacuum_max_workers` e `max_parallel_workers`. Un numero elevato di processi di lavoro in background potrebbe influire sui carichi di lavoro delle applicazioni su istanze di piccole dimensioni. Quindi, monitora le prestazioni del database se imposti un valore di `max_worker_processes` superiore a quello predefinito.

1.  Quando si utilizza Aurora PostgreSQL come sorgente con CDC, impostare su. `synchronous_commit` `ON`

**Per utilizzare PostgreSQL MultiaZ DB Cluster Read Replica per CDC (replica continua)**

1. Imposta i `sync_replication_slots` parametri `rds.logical_replication` and nel gruppo di parametri DB CLUSTER su 1. Questi parametri statici richiedono il riavvio dell'istanza DB per avere effetto.

1. Eseguite il comando seguente per creare la `awsdms_ddl_audit` tabella su Writer e sostituirla `objects_schema` con il nome dello schema da utilizzare:

   ```
   CREATE TABLE objects_schema.awsdms_ddl_audit
   (
     c_key    bigserial primary key,
     c_time   timestamp,    -- Informational
     c_user   varchar(64),  -- Informational: current_user
     c_txn    varchar(16),  -- Informational: current transaction
     c_tag    varchar(24),  -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE'
     c_oid    integer,      -- For future use - TG_OBJECTID
     c_name   varchar(64),  -- For future use - TG_OBJECTNAME
     c_schema varchar(64),  -- For future use - TG_SCHEMANAME. For now - holds current_schema
     c_ddlqry  text         -- The DDL query associated with the current DDL event
   );
   ```

1. Eseguite il comando seguente per creare la `awsdms_intercept_ddl` funzione e sostituirla `objects_schema` con il nome dello schema da utilizzare:

   ```
   CREATE OR REPLACE FUNCTION objects_schema.awsdms_intercept_ddl()
     RETURNS event_trigger
   LANGUAGE plpgsql
   SECURITY DEFINER
     AS $$
     declare _qry text;
   BEGIN
     if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE' or tg_tag = 'CREATE TABLE AS') then
            SELECT current_query() into _qry;
            insert into objects_schema.awsdms_ddl_audit
            values
            (
            default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry
            );
            delete from objects_schema.awsdms_ddl_audit;
   end if;
   END;
   $$;
   ```

1. Eseguite il comando seguente per creare il trigger `awsdms_intercept_ddl` dell'evento:

   ```
   CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl();
   ```

   Assicurati che tutti gli utenti e i ruoli che accedono a questi eventi dispongano delle autorizzazioni DDL necessarie. Esempio:

   ```
   grant all on public.awsdms_ddl_audit to public;
   grant all on public.awsdms_ddl_audit_c_key_seq to public;
   ```

1. Crea uno slot di replica su Writer:

   ```
   SELECT * FROM pg_create_logical_replication_slot('dms_read_replica_slot', 'test_decoding', false, true);
   ```

1. Assicurati che lo slot di replica sia disponibile su Reader:

   ```
   select * from pg_catalog.pg_replication_slots where slot_name = 'dms_read_replica_slot';
   
   slot_name            |plugin       |slot_type|datoid|database|temporary|active|active_pid|xmin|catalog_xmin|restart_lsn|confirmed_flush_lsn|wal_status|safe_wal_size|two_phase|inactive_since               |conflicting|invalidation_reason|failover|synced|
   ---------------------+-------------+---------+------+--------+---------+------+----------+----+------------+-----------+-------------------+----------+-------------+---------+-----------------------------+-----------+-------------------+--------+------+
   dms_read_replica_slot|test_decoding|logical  |     5|postgres|false    |false |          |    |3559        |0/180011B8 |0/180011F0         |reserved  |             |true     |2025-02-10 15:45:04.083 +0100|false      |                   |false   |false |
   ```

1. Crea un endpoint di origine DMS per Read Replica e imposta il nome dello slot di replica logica tramite l'attributo di connessione aggiuntivo:

   ```
   slotName=dms_read_replica_slot;
   ```

1. Crea e avvia l'attività CDC/FL\$1CDC.
**Nota**  
Per le migrazioni CDC/FL\$1CDC, DMS considera l'ora di inizio dell'attività come posizione iniziale del CDC. Tutte le versioni precedenti dello slot di replica vengono ignorate. LSNs 

### Migrazione di un database Amazon RDS per PostgreSQL senza utilizzare l'account utente master
<a name="CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser"></a>

In alcuni casi, si può decidere di non utilizzare l'account utente master per l'istanza di database Amazon RDS PostgreSQL che si sta utilizzando come origine. In questi casi, è necessario creare diversi oggetti per acquisire gli eventi DDL (Data Definition Language). Puoi creare questi oggetti nell'account diverso dall'account master e quindi creare un trigger nell'account utente master.

**Nota**  
Se configuri l'impostazione dell'endpoint `CaptureDdls` su `false` nell'endpoint di origine, non è necessario creare la tabella e il trigger seguenti nel database di origine.

Per creare questi oggetti, utilizza la procedura seguente.

**Per creare oggetti**

1. Scegli lo schema in cui devono essere creati gli oggetti. Lo schema predefinito è `public`. Verifica che lo schema esista e che l'account `OtherThanMaster` vi possa accedere. 

1. Accedi all'istanza database PostgreSQL utilizzando l'account utente diverso dall'account master, qui l'account `OtherThanMaster`.

1. Crea la tabella `awsdms_ddl_audit` eseguendo il comando seguente, sostituendo `objects_schema` nel codice e il nome dello schema da utilizzare.

   ```
   CREATE TABLE objects_schema.awsdms_ddl_audit
   (
     c_key    bigserial primary key,
     c_time   timestamp,    -- Informational
     c_user   varchar(64),  -- Informational: current_user
     c_txn    varchar(16),  -- Informational: current transaction
     c_tag    varchar(24),  -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE'
     c_oid    integer,      -- For future use - TG_OBJECTID
     c_name   varchar(64),  -- For future use - TG_OBJECTNAME
     c_schema varchar(64),  -- For future use - TG_SCHEMANAME. For now - holds current_schema
     c_ddlqry  text         -- The DDL query associated with the current DDL event
   );
   ```

1. Crea la funzione `awsdms_intercept_ddl` eseguendo il comando seguente, sostituendo `objects_schema` nel codice e il nome dello schema da utilizzare.

   ```
   CREATE OR REPLACE FUNCTION objects_schema.awsdms_intercept_ddl()
     RETURNS event_trigger
   LANGUAGE plpgsql
   SECURITY DEFINER
     AS $$
     declare _qry text;
   BEGIN
     if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE' or tg_tag = 'CREATE TABLE AS') then
            SELECT current_query() into _qry;
            insert into objects_schema.awsdms_ddl_audit
            values
            (
            default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry
            );
            delete from objects_schema.awsdms_ddl_audit;
   end if;
   END;
   $$;
   ```

1. Esci dall'account `OtherThanMaster` e collegati con un account che disponga del ruolo `rds_superuser`.

1. Crea il trigger evento `awsdms_intercept_ddl` utilizzando il seguente comando.

   ```
   CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end 
   EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl();
   ```

1. Assicurati che tutti gli utenti e i ruoli che accedono a questi eventi dispongano delle autorizzazioni DDL necessarie. Esempio:

   ```
   grant all on public.awsdms_ddl_audit to public;
   grant all on public.awsdms_ddl_audit_c_key_seq to public;
   ```

Una volta completata la procedura precedente, puoi creare l'endpoint di origine AWS DMS utilizzando l'account `OtherThanMaster`.

**Nota**  
Questi eventi sono attivati dalle istruzioni `CREATE TABLE`, `ALTER TABLE` e `DROP TABLE`.

## Abilitazione dell'acquisizione dei dati di modifica (CDC) mediante la replica logica
<a name="CHAP_Source.PostgreSQL.Security"></a>

Puoi usare la funzionalità di replica logica nativa di PostgreSQL per abilitare l'acquisizione dei dati di modifica (CDC) durante la migrazione del database per le origini PostgreSQL. Puoi utilizzare questa funzionalità con un'istanza database SQL PostgreSQL autogestita e Amazon RDS per PostgreSQL. Questo approccio riduce i tempi di inattività e aiuta a garantire che il database di destinazione sia sincronizzato con il database PostgreSQL di origine.

AWS DMS supporta CDC per tabelle PostgreSQL con chiavi primarie. Se una tabella non ha una chiave primaria, i log write-ahead (WAL) non includono un'immagine precedente della riga del database. In questo caso, DMS non è in grado di aggiornare la tabella. Puoi utilizzare impostazioni di configurazione aggiuntive e l'identità di replica della tabella come soluzione alternativa. Tuttavia, questo approccio può generare log aggiuntivi. Ti consigliamo di utilizzare l'identità di replica delle tabelle come soluzione alternativa solo dopo attenti test. Per ulteriori informazioni, consulta [Impostazioni di configurazione aggiuntive quando si utilizza un database PostgreSQL come origine DMS](#CHAP_Source.PostgreSQL.Advanced).

**Nota**  
REPLICA IDENTITY FULL è supportato con un plug-in di decodifica logica, ma non è supportato con un plug-in pglogical. Per ulteriori informazioni, consulta [la documentazione di pglogical](https://github.com/2ndQuadrant/pglogical#primary-key-or-replica-identity-required).

Per le attività a pieno carico e solo CDC e CDC, AWS DMS utilizza slot di replica logici per conservare i log WAL per la replica fino alla decodifica dei log. Al riavvio (non alla ripresa) di un'attività di pieno carico e CDC o un'attività di sola CDC, lo slot di replica viene ricreato.

**Nota**  
Per la decodifica logica, DMS utilizza il plug-in test\$1decoding o pglogical. Se il plug-in pglogical è disponibile su un database PostgreSQL di origine, DMS crea uno slot di replica utilizzando pglogical, altrimenti viene utilizzato un plug-in test\$1decoding. Per ulteriori informazioni sul plug-in test-decoding, consulta la [ documentazione di PostgreSQL](https://www.postgresql.org/docs/9.4/test-decoding.html).  
Se il parametro di database `max_slot_wal_keep_size` è impostato su un valore non predefinito e `restart_lsn` dello slot di replica è inferiore al numero LSN corrente di oltre questa dimensione, l'attività DMS ha esito negativo a causa della rimozione dei file WAL richiesti.

### Configurazione del plug-in pglogical
<a name="CHAP_Source.PostgreSQL.Security.Pglogical"></a>

Implementato come estensione PostgreSQL, il plug-in pglogical è un sistema e un modello di replica logica per la replica dei dati selettiva. La tabella seguente identifica le versioni del database PostgreSQL di origine che supportano il plug-in pglogical.


|  Origine PostgreSQL   |  Supporta pglogical  | 
| --- | --- | 
|  PostgreSQL 9.4 autogestito o versioni successive  |  Sì  | 
|  Amazon RDS PostgreSQL 9.5 o versioni precedenti  |  No  | 
|  Amazon RDS PostgreSQL 9.6 o versioni successive  |  Sì  | 
|  Aurora PostgreSQL da 1.x a 2.5.x  |  No  | 
|  Aurora PostgreSQL 2.6.x o versioni successive  |  Sì  | 
|  Aurora PostgreSQL 3.3.x o versioni successive  |  Sì  | 

Prima di configurare pglogical per l'uso con AWS DMS, abilita innanzitutto la replica logica per l'acquisizione dei dati di modifica (CDC) sul tuo database di origine PostgreSQL. 
+ Per informazioni sull'abilitazione della replica logica per CDC su database di origine PostgreSQL *autogestiti*, consulta [Abilitazione del CDC utilizzando un database PostgreSQL autogestito come sorgente AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC).
+ Per informazioni sull'abilitazione della replica logica per CDC su database di origine PostgreSQL *gestiti da AWS*, consulta [Abilitazione del CDC con un' AWS istanza DB PostgreSQL gestita con AWS DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC).

Dopo aver abilitato la replica logica sul database di origine PostgreSQL, segui i passaggi riportati di seguito per configurare pglogical per l'uso con DMS.

**Per utilizzare il plugin pglogical per la replica logica su un database sorgente PostgreSQL con AWS DMS**

1. Crea un'estensione pglogical sul database PostgreSQL di origine:

   1. Imposta il parametro corretto:
      + Per i database PostgreSQL autogestiti, imposta il parametro di database `shared_preload_libraries= 'pglogical'`.
      + Per i database PostgreSQL su Amazon RDS e Amazon Aurora edizione compatibile con PostgreSQL, imposta il parametro `shared_preload_libraries` su `pglogical` nello stesso gruppo di parametri RDS.

   1. Riavvia il database di origine PostgreSQL.

   1. Sul database PostgreSQL, esegui il comando `create extension pglogical;`.

1. Per verificare che pglogical sia stato installato, esegui il comando seguente:

   `select * FROM pg_catalog.pg_extension`

È ora possibile creare un' AWS DMS attività che esegua l'acquisizione dei dati di modifica per l'endpoint del database di origine PostgreSQL.

**Nota**  
Se non abiliti pglogical sul database di origine PostgreSQL, AWS DMS utilizza il plug-in `test_decoding` per impostazione predefinita. Quando pglogical è abilitato per la decodifica logica, utilizza pglogical per impostazione predefinita. AWS DMS Tuttavia, puoi impostare l'attributo aggiuntivo di connessione `PluginName` per utilizzare il plug-in `test_decoding`.

## Utilizzo dei punti di avvio CDC nativi per impostare un carico CDC di un endpoint di origine PostgreSQL
<a name="CHAP_Source.PostgreSQL.v10"></a>

Per abilitare i punti di avvio CDC nativi con PostgreSQL come origine è necessario impostare l'attributo aggiuntivo di connessione `slotName` sul nome di uno slot di replica logica esistente quando si crea l'endpoint. Questo slot di replica logica contiene le modifiche in corso dal momento della creazione dell'endpoint, quindi supporta la replica da un punto precedente nel tempo. 

PostgreSQL scrive le modifiche al database nei file WAL che vengono scartati solo quando AWS DMS legge correttamente le modifiche dallo slot di replica logica. Utilizzando gli slot di replica logica è possibile proteggere le modifiche registrate dall'eliminazione prima che vengano utilizzate dal motore di replica. 

Tuttavia, a seconda della velocità di modifica e utilizzo, le modifiche presenti in uno slot di replica logica possono causare un utilizzo elevato del disco. Ti consigliamo di impostare gli allarmi relativi all'utilizzo dello spazio nell'istanza PostgreSQL di origine quando vengono utilizzati gli slot di replica logica. Per ulteriori informazioni sull'impostazione dell'attributo di connessione aggiuntivo `slotName`, consulta [Impostazioni degli endpoint e attributi di connessione aggiuntivi (ECAs) quando si utilizza PostgreSQL come sorgente DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib).

La seguente procedura percorre questo approccio in modo più dettagliato.

**Per utilizzare un punto di avvio CDC nativo per impostare un caricamento CDC di un endpoint di origine PostgreSQL**

1. Identificare lo slot di replica logica utilizzato da un'attività di replica precedente (un'attività padre) che si desidera utilizzare come punto iniziale. Quindi interroga la `pg_replication_slots` vista sul database di origine per assicurarsi che questo slot non abbia connessioni attive. In tal caso, risolvile e chiudile prima di procedere.

   Per i passaggi seguenti, si supponga che lo slot di replica logica sia `abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef`. 

1. Creare un nuovo endpoint di origine che include la seguente impostazione dell'attributo di connessione aggiuntivo:

   ```
   slotName=abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef;
   ```

1. Crea una nuova attività solo CDC utilizzando la console AWS CLI o AWS DMS l'API. Ad esempio, utilizzando l'interfaccia a riga di comando è possibile eseguire il seguente comando `create-replication-task`. 

   ```
   aws dms create-replication-task --replication-task-identifier postgresql-slot-name-test 
   --source-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ABCD1EFGHIJK2LMNOPQRST3UV4 
   --target-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ZYX9WVUTSRQONM8LKJIHGF7ED6 
   --replication-instance-arn arn:aws:dms:us-west-2:012345678901:rep:AAAAAAAAAAA5BB4CCC3DDDD2EE 
   --migration-type cdc --table-mappings "file://mappings.json" --cdc-start-position "4AF/B00000D0" 
   --replication-task-settings "file://task-pg.json"
   ```

   Nel comando precedente vengono impostate le seguenti opzioni:
   + L'opzione `source-endpoint-arn` è impostata sul nuovo valore creato nella fase 2.
   + L'opzione `replication-instance-arn` è impostata sullo stesso valore dell'attività padre della fase 1.
   + Le opzioni `table-mappings` e `replication-task-settings` sono impostate sugli stessi valori dell'attività padre della fase 1.
   + L'opzione `cdc-start-position` è impostata su un valore di posizione iniziale. Per trovare questa posizione iniziale, interrogare la visualizzazione `pg_replication_slots` nel database di origine o visualizzare i dettagli della console per l'attività padre nel passaggio 1. Per ulteriori informazioni, consulta [Determinazione di un punto di inizio nativo CDC](CHAP_Task.CDC.md#CHAP_Task.CDC.StartPoint.Native).

   Per abilitare la modalità di avvio CDC personalizzata quando si crea una nuova attività solo CDC utilizzando la AWS DMS console, procedi come segue:
   + Nella sezione **Impostazioni delle attività** scegli **Abilita la modalità di avvio CDC personalizzata** per **Modalità di avvio CDC per le transazioni di origine**.
   + Per **Punto di avvio CDC personalizzato per le transazioni di origine** scegli **Specifica un numero di sequenza del log**. Specifica il numero di modifica del sistema o scegli **Specifica un checkpoint di ripristino** e fornisci un checkpoint di ripristino.

   Quando viene eseguita questa attività CDC, AWS DMS genera un errore se lo slot di replica logica specificato non esiste. Genera un errore anche se l'attività non viene creata con un'impostazione valida per `cdc-start-position`.

Quando utilizzi punti di avvio CDC nativi con il plug-in pglogical e desideri utilizzare un nuovo slot di replica, completa i passaggi di configurazione seguenti prima di creare un'attività di CDC. 

**Per utilizzare un nuovo slot di replica non creato in precedenza come parte di un'altra attività DMS**

1. Crea uno slot di replica come illustrato di seguito:

   ```
   SELECT * FROM pg_create_logical_replication_slot('replication_slot_name', 'pglogical');
   ```

1. Dopo che il database ha creato lo slot di replica, recupera e annota i valori **restart\$1lsn** e **confirmed\$1flush\$1lsn** per lo slot:

   ```
   select * from pg_replication_slots where slot_name like 'replication_slot_name';
   ```

   Tieni presente che il punto di avvio CDC nativo per un'attività di CDC creata dopo lo slot di replica non può essere precedente al valore **confirmed\$1flush\$1lsn**.

   Per informazioni sui valori **restart\$1lsn** e **confirmed\$1flush\$1lsn**, consulta [pg\$1replication\$1slots](https://www.postgresql.org/docs/14/view-pg-replication-slots.html). 

1. Crea un nodo pglogical.

   ```
   SELECT pglogical.create_node(node_name := 'node_name', dsn := 'your_dsn_name');
   ```

1. Crea due set di replica utilizzando la funzione `pglogical.create_replication_set`. Il primo set di replica tiene traccia degli aggiornamenti e delle eliminazioni per le tabelle con chiavi primarie. Il secondo set di replica tiene traccia solo degli inserimenti e ha lo stesso nome del primo set di replica, con l'aggiunta del prefisso "i".

   ```
   SELECT pglogical.create_replication_set('replication_slot_name', false, true, true, false);
   SELECT pglogical.create_replication_set('ireplication_slot_name', true, false, false, true);
   ```

1. Aggiungi una tabella al set di repliche.

   ```
   SELECT pglogical.replication_set_add_table('replication_slot_name', 'schemaname.tablename', true);
   SELECT pglogical.replication_set_add_table('ireplication_slot_name', 'schemaname.tablename', true);
   ```

1. Imposta l'attributo aggiuntivo di connessione seguente quando crei l'endpoint di origine.

   ```
   PluginName=PGLOGICAL;slotName=slot_name;
   ```

A questo punto puoi creare un'attività di sola CDC con un punto di avvio nativo PostgreSQL utilizzando il nuovo slot di replica. Per ulteriori informazioni sul plug-in pglogical, consulta la [documentazione di pglogical 3.7](https://www.enterprisedb.com/docs/pgd/3.7/pglogical/)

## Migrazione da PostgreSQL a PostgreSQL utilizzando AWS DMS
<a name="CHAP_Source.PostgreSQL.Homogeneous"></a>

Quando si esegue la migrazione da un motore di database diverso da PostgreSQL a un database PostgreSQL, è quasi sempre lo strumento di migrazione migliore da utilizzare AWS DMS . Tuttavia, per una migrazione da un database PostgreSQL a un database PostgreSQL, gli strumenti PostgreSQL possono essere più efficaci.

### Utilizzo degli strumenti nativi PostgreSQL per migrare i dati
<a name="CHAP_Source.PostgreSQL.Homogeneous.Native"></a>

Ti consigliamo di utilizzare gli strumenti per la migrazione dei database PostgreSQL come `pg_dump` nei seguenti casi: 
+ Hai una migrazione omogenea, dove effettui la migrazione da un database di origine PostgreSQL a un database PostgreSQL di destinazione. 
+ Desideri migrare un intero database.
+ Gli strumenti nativi ti consentono di migrare i dati con tempi di inattività ridotti. 

L'utilità pg\$1dump utilizza il comando COPY per creare uno schema e il dump dei dati di un database PostgreSQL. Lo script del dump generato da pg\$1dump carica i dati in un database con lo stesso nome e ricrea le tabelle, gli indici e le chiavi esterne. Utilizza il comando `pg_restore` e il parametro `-d` per ripristinare i dati in un database con un nome diverso.

Se esegui la migrazione dei dati da un database di origine PostgreSQL in esecuzione su EC2 a una destinazione Amazon RDS per PostgreSQL, puoi utilizzare il plug-in pglogical.

Per ulteriori informazioni sull'importazione di un database PostgreSQL in Amazon RDS per PostgreSQL o Amazon Aurora edizione compatibile con PostgreSQL, consulta [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html).

### Utilizzo di DMS per la migrazione dei dati da PostgreSQL a PostgreSQL
<a name="CHAP_Source.PostgreSQL.Homogeneous.DMS"></a>

 AWS DMS può migrare i dati, ad esempio, da un database PostgreSQL di origine locale a un'istanza Amazon RDS for PostgreSQL o Aurora PostgreSQL di destinazione. Nella maggior parte dei casi, la migrazione di tipi di dati core o di base PostgreSQL avviene correttamente.

**Nota**  
Quando si replicano tabelle partizionate da un'origine PostgreSQL a una destinazione PostgreSQL, non è necessario menzionare la tabella padre come parte dei criteri di selezione nell'attività DMS. La menzione della tabella padre causa la duplicazione dei dati nelle tabelle figlio sulla destinazione, causando probabilmente una violazione delle chiavi primarie. Selezionando solo le tabelle figlio nella tabella che mappa i criteri di selezione, la tabella padre viene compilata automaticamente.

I tipi di dati supportati nel database di origine ma non supportati nella destinazione potrebbero non essere migrati correttamente. AWS DMS trasmette alcuni tipi di dati come stringhe se il tipo di dati è sconosciuto. Alcuni tipi di dati, ad esempio XML e JSON, possono migrare come file di piccole dimensioni, ma potrebbero non migrare correttamente se i documenti sono di grandi dimensioni. 

Quando esegui la migrazione del tipo di dati, tieni presente quanto segue:
+ In alcuni casi, il tipo di dati PostgreSQL NUMERIC (p, s) non specifica alcuna precisione e scala. Per DMS 3.4.2 e versioni precedenti, DMS utilizza una precisione di 28 e una scala di 6 per impostazione predefinita, NUMERIC(28,6). Ad esempio, il valore 0,611111104488373 dell'origine viene convertito in 0,611111 nella destinazione PostgreSQL.
+ Una tabella con un tipo di dati ARRAY deve avere una chiave primaria. Una tabella con un tipo di dati ARRAY priva di una chiave primaria viene sospesa durante il pieno carico.

La tabella seguente mostra i tipi di dati di origine PostgreSQL e indica se possono essere migrati correttamente:


| Tipo di dati | Migrazione corretta | Migrazione parziale | non migra | Commenti | 
| --- | --- | --- | --- | --- | 
| INTEGER | X |  |  |  | 
| SMALLINT | X |  |  |  | 
| BIGINT | X |  |  |  | 
| NUMERIC/DECIMAL(p,s) |  | X |  | Dove 0<p<39 e 0<s | 
| NUMERIC/DECIMAL |  | X |  | Dove p>38 o p=s=0 | 
| REAL | X |  |  |  | 
| DOUBLE | X |  |  |  | 
| SMALLSERIAL | X |  |  |  | 
| SERIAL | X |  |  |  | 
| BIGSERIAL | X |  |  |  | 
| MONEY | X |  |  |  | 
| CHAR |  | X |  | Senza precisione specificata | 
| CHAR(n) | X |  |  |  | 
| VARCHAR |  | X |  | Senza precisione specificata | 
| VARCHAR(n) | X |  |  |  | 
| TEXT | X |  |  |  | 
| BYTEA | X |  |  |  | 
| TIMESTAMP | X |  |  | I valori infiniti positivi e negativi vengono troncati rispettivamente a "9999-12-31 23:59:59" e "4713-01-01 00:00:00 BC". | 
| TIMESTAMP WITH TIME ZONE |  | X |  |  | 
| DATE | X |  |  |  | 
| TIME | X |  |  |  | 
| TIME WITH TIME ZONE | X |  |  |  | 
| INTERVAL |  | X |  |  | 
| BOOLEAN | X |  |  |  | 
| ENUM |  |  | X |  | 
| CIDR | X |  |  |  | 
| INET |  |  | X |  | 
| MACADDR |  |  | X |  | 
| TSVECTOR |  |  | X |  | 
| TSQUERY |  |  | X |  | 
| XML |  | X |  |  | 
| POINT | X |  |  | Tipo di dati spaziali PostGIS | 
| LINE |  |  | X |  | 
| LSEG |  |  | X |  | 
| BOX |  |  | X |  | 
| PATH |  |  | X |  | 
| POLYGON | X |  |  | Tipo di dati spaziali PostGIS | 
| CIRCLE |  |  | X |  | 
| JSON |  | X |  |  | 
| ARRAY | X |  |  | Richiede la chiave primaria | 
| COMPOSITE |  |  | X |  | 
| RANGE |  |  | X |  | 
| LINESTRING | X |  |  | Tipo di dati spaziali PostGIS | 
| MULTIPOINT | X |  |  | Tipo di dati spaziali PostGIS | 
| MULTILINESTRING | X |  |  | Tipo di dati spaziali PostGIS | 
| MULTIPOLYGON | X |  |  | Tipo di dati spaziali PostGIS | 
| GEOMETRYCOLLECTION | X |  |  | Tipo di dati spaziali PostGIS | 

### Migrazione dei tipi di dati spaziali di PostGIS
<a name="CHAP_Source.PostgreSQL.DataTypes.Spatial"></a>

I *dati spaziali* identificano le informazioni sulla geometria di un oggetto o di una posizione nello spazio. I database relazionali a oggetti PostgreSQL supportano i tipi di dati spaziali PostGIS. 

Prima di migrare gli oggetti formati da dati spaziali PostgreSQL, assicurati che il plug-in PostGIS sia abilitato a livello globale. In questo modo si garantisce la AWS DMS creazione delle colonne di dati spaziali di origine esatte per l'istanza DB di destinazione PostgreSQL.

Per le AWS DMS migrazioni omogenee da PostgreSQL a PostgreSQL, supporta la migrazione di tipi e sottotipi di oggetti dati geometrici e geografici (coordinate geodetiche) di PostGIS come i seguenti:
+  POINT 
+  LINESTRING 
+  POLYGON 
+  MULTIPOINT 
+  MULTILINESTRING 
+  MULTIPOLYGON 
+  GEOMETRYCOLLECTION 

## Migrazione da Babelfish per Amazon Aurora PostgreSQL utilizzando AWS DMS
<a name="CHAP_Source.PostgreSQL.Babelfish"></a>

Puoi migrare le tabelle di origine PostgreSQL di Babelfish for Aurora su qualsiasi endpoint di destinazione supportato utilizzando. AWS DMS

Quando crei il tuo endpoint di AWS DMS origine utilizzando la console DMS, l'API o i comandi CLI, imposti l'origine su **Amazon Aurora PostgreSQL** e il nome del database su. **babelfish\$1db** Nella sezione **Endpoint Settings**, assicurati che sia impostato su Babelfish e che **DatabaseMode**sia impostato sul nome del **database Babelfish** T-SQL di **BabelfishDatabaseName**origine. Invece di usare la porta TCP Babelfish**1433**, usa la porta TCP Aurora PostgreSQL. **5432**

È necessario creare le tabelle prima di migrare i dati per assicurarsi che DMS utilizzi i tipi di dati e i metadati delle tabelle corretti. Se non crei le tabelle sulla destinazione prima di eseguire la migrazione, DMS potrebbe creare le tabelle con tipi di dati e autorizzazioni errati.

### Aggiunta delle regole di trasformazione all'attività di migrazione
<a name="CHAP_Source.PostgreSQL.Babelfish.Transform"></a>

Quando crei un'attività di migrazione per una fonte Babelfish, devi includere regole di trasformazione che assicurino che DMS utilizzi le tabelle di destinazione precreate.

Se hai impostato la modalità di migrazione multi-database quando hai definito il tuo cluster Babelfish per PostgreSQL, aggiungi una regola di trasformazione che rinomina il nome dello schema nello schema T-SQL. Ad esempio, se il nome dello schema T-SQL è `dbo` e il nome dello schema Babelfish for PostgreSQL è`mydb_dbo`, rinomina lo schema utilizzando una regola di trasformazione. `dbo` *Per trovare il nome dello schema PostgreSQL, [consulta l'architettura Babelfish](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/babelfish-architecture.html) nella Guida per l'utente di Amazon Aurora.* 

Se utilizzi la modalità a database singolo, non è necessario utilizzare una regola di trasformazione per rinominare gli schemi di database. I nomi degli schemi PostgreSQL hanno one-to-one una mappatura con i nomi degli schemi nel database T-SQL.

Il seguente esempio di regola di trasformazione mostra come rinominare il nome dello schema da back a: `mydb_dbo` `dbo`

```
{
    "rules": [
        {
            "rule-type": "transformation",
            "rule-id": "566251737",
            "rule-name": "566251737",
            "rule-target": "schema",
            "object-locator": {
                "schema-name": "mydb_dbo"
            },
            "rule-action": "rename",
            "value": "dbo",
            "old-value": null
        },
        {
            "rule-type": "selection",
            "rule-id": "566111704",
            "rule-name": "566111704",
            "object-locator": {
                "schema-name": "mydb_dbo",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        }
    ]
}
```

### Limitazioni per l'utilizzo di un endpoint sorgente PostgreSQL con le tabelle Babelfish
<a name="CHAP_Source.PostgreSQL.Babelfish.Limitations"></a>

Le seguenti limitazioni si applicano quando si utilizza un endpoint sorgente PostgreSQL con tabelle Babelfish:
+ DMS supporta solo la migrazione dalla versione 16.2/15.6 di Babelfish e successive e dalla versione DMS 3.5.3 e successive.
+ DMS non replica le modifiche alla definizione della tabella Babelfish sull'endpoint di destinazione. Una soluzione alternativa per questa limitazione consiste nell'applicare prima le modifiche alla definizione della tabella sul target, quindi modificare la definizione della tabella sul sorgente Babelfish.
+ Quando si creano tabelle Babelfish con il tipo di dati BYTEA, DMS le converte nel tipo di `varbinary(max)` dati durante la migrazione a SQL Server come destinazione.
+ DMS non supporta la modalità Full LOB per i tipi di dati binari. Utilizzate invece la modalità LOB limitata per i tipi di dati binari.
+ DMS non supporta la convalida dei dati per Babelfish come fonte.
+ **Per l'impostazione delle attività della **modalità di preparazione della tabella di Target**, utilizza solo le modalità **Non fare nulla o Truncate**.** Non utilizzare la modalità **Rilascia tabelle nella destinazione**. Quando si utilizza **Drop tables on target**, DMS può creare le tabelle con tipi di dati errati.
+ Quando si utilizza la replica continua (CDC o Full load e CDC), imposta l'attributo di connessione `PluginName` aggiuntivo (ECA) su. `TEST_DECODING`
+ DMS non supporta la replica (CDC o Full load e CDC) della tabella partizionata per Babelfish come sorgente.

## Rimozione di AWS DMS artefatti da un database sorgente PostgreSQL
<a name="CHAP_Source.PostgreSQL.CleanUp"></a>

Per acquisire eventi DDL, AWS DMS crea vari artefatti nel database PostgreSQL all'avvio di un'attività di migrazione. Al termine dell'attività è possibile rimuovere gli artefatti.

Per rimuovere gli artefatti, invia le seguenti istruzioni (nell'ordine), dove `{AmazonRDSMigration}` è lo schema in cui sono stati creati gli artefatti. L'eliminazione di uno schema deve essere eseguita con estrema attenzione. Non eliminare mai uno schema operativo, soprattutto uno pubblico.

```
drop event trigger awsdms_intercept_ddl;
```

Il trigger dell'evento non appartiene a uno schema specifico.

```
drop function {AmazonRDSMigration}.awsdms_intercept_ddl()
drop table {AmazonRDSMigration}.awsdms_ddl_audit
drop schema {AmazonRDSMigration}
```

## Impostazioni di configurazione aggiuntive quando si utilizza un database PostgreSQL come origine DMS
<a name="CHAP_Source.PostgreSQL.Advanced"></a>

Puoi aggiungere ulteriori impostazioni di configurazione durante la migrazione dei dati da un database PostgreSQL in due modi:
+ Puoi aggiungere valori all'attributo di connessione aggiuntivo per acquisire eventi DDL e per specificare lo schema in cui vengono creati gli artefatti operativi del database DDL. Per ulteriori informazioni, consulta [Impostazioni degli endpoint e attributi di connessione aggiuntivi (ECAs) quando si utilizza PostgreSQL come sorgente DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib).
+ Puoi sostituire i parametri della stringa di connessione. Scegli questa opzione per eseguire una delle seguenti operazioni:
  + Specificate AWS DMS i parametri interni. Questi parametri sono raramente necessari e non sono quindi visualizzati nell'interfaccia utente.
  + Specificate i valori pass-through (passthru) per il client di database specifico. AWS DMS include i parametri pass-through nella stringa di connessione passata al client del database.
+ Utilizzando il parametro table-level nelle versioni 9.4 e successive di `REPLICA IDENTITY` PostgreSQL, puoi controllare le informazioni scritte nei log write-ahead (). WALs In particolare, lo fa per WALs identificare le righe che vengono aggiornate o eliminate. `REPLICA IDENTITY FULL`registra i vecchi valori di tutte le colonne della riga. `REPLICA IDENTITY FULL`Usalo con attenzione per ogni tabella poiché ne `FULL` genera un numero aggiuntivo WALs che potrebbe non essere necessario. Per ulteriori informazioni, consulta [ALTER TABLE-REPLICA IDENTITY](https://www.postgresql.org/docs/devel/sql-altertable.html). 

## Leggi la replica come sorgente per PostgreSQL
<a name="CHAP_Source.PostgreSQL.ReadReplica"></a>

Usa le repliche di lettura PostgreSQL come sorgenti CDC per ridurre il carico del database primario. AWS DMS Questa funzionalità è disponibile in PostgreSQL 16.x e richiede la versione 3.6.1 o successiva. AWS DMS L'utilizzo di repliche di lettura per l'elaborazione CDC riduce l'impatto operativo sul database principale.

**Nota**  
Amazon RDS PostgreSQL versione 16.x presenta limitazioni per la replica logica delle repliche di lettura nelle configurazioni Three-AZ (TAZ). Per il supporto completo della replica logica della replica di lettura nelle implementazioni TAZ, è necessario utilizzare PostgreSQL versione 17.x o successiva.

### Prerequisiti
<a name="CHAP_Source.PostgreSQL.ReadReplica.prereq"></a>

Prima di utilizzare una replica di lettura come origine CDC per AWS DMS, è necessario abilitare la replica logica sia sull'istanza del database principale che sulla relativa replica di lettura per creare la decodifica logica su una replica di lettura. Esegui le seguenti azioni:
+ Abilita la replica logica sia sull'istanza del database principale che sulla relativa replica di lettura insieme a qualsiasi altro parametro di database richiesto. Per ulteriori informazioni, consulta [Lavorare con database PostgreSQL AWS gestiti come sorgente DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.RDSPostgreSQL).
+ Per le attività riservate esclusivamente a CDC, create uno slot di replica sull'istanza primaria (writer). Per ulteriori informazioni, consulta [Utilizzo dei punti di partenza CDC nativi per configurare un carico CDC di una fonte PostgreSQL](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10). Questa azione è necessaria in quanto le repliche di lettura non supportano la creazione di slot di replica.
+ Per la versione 16 di PostgreSQL, lo slot deve essere creato manualmente nella replica di lettura.
+ Per PostgreSQL versione 17 e successive, lo slot di replica deve essere creato sul primario e viene sincronizzato automaticamente con la replica di lettura.
+ Quando si utilizzano attività Full Load \$1 CDC o solo CDC, è AWS DMS possibile gestire automaticamente gli slot di replica logici sulle istanze primarie ma non sulle repliche di lettura. Per le repliche di lettura di PostgreSQL versione 16, è necessario eliminare e ricreare manualmente gli slot di replica prima di riavviare un'attività (non riprenderla). Saltare questo passaggio può causare errori nelle attività o posizioni iniziali del CDC errate. A partire dalla versione 17 di PostgreSQL, la sincronizzazione degli slot logici dall'istanza principale automatizza questo processo.

Dopo aver completato i prerequisiti, è possibile configurare l'endpoint di origine con la replica della AWS DMS fonte `SlotName` di replica letta nelle impostazioni dell'endpoint e configurare l'attività utilizzando i punti di partenza CDC nativi. AWS DMS Per ulteriori informazioni, consulta [Impostazioni dell'endpoint e Attributi di connessione aggiuntivi (ECAs) quando si utilizza PostgreSQL come sorgente DMS e Utilizzo dei punti di avvio CDC nativi per configurare un](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.ConnectionAttrib) [carico CDC](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10) di una fonte PostgreSQL.

## Utilizzo dell'impostazione dell'`MapBooleanAsBoolean`endpoint PostgreSQL
<a name="CHAP_Source.PostgreSQL.ConnectionAttrib.Endpointsetting"></a>

Puoi utilizzare le impostazioni degli endpoint PostgreSQL per mappare un booleano come tale dall'origine PostgreSQL a una destinazione Amazon Redshift. Per impostazione predefinita, il tipo BOOLEAN viene migrato come varchar(5). È possibile specificare `MapBooleanAsBoolean` per consentire a PostgreSQL di migrare il tipo booleano come tale, come mostrato nell'esempio seguente.

```
--postgre-sql-settings '{"MapBooleanAsBoolean": true}'
```

Tieni presente che questa impostazione, affinché abbia effetto, deve essere configurata sia sull'endpoint di origine che su quello di destinazione.

Poiché MySQL non ha un tipo BOOLEAN, usa una regola di trasformazione anziché questa impostazione per la migrazione dei dati BOOLEAN su MySQL.

## Impostazioni degli endpoint e attributi di connessione aggiuntivi (ECAs) quando si utilizza PostgreSQL come sorgente DMS
<a name="CHAP_Source.PostgreSQL.ConnectionAttrib"></a>

Puoi utilizzare le impostazioni dell'endpoint e gli attributi di connessione aggiuntivi (ECAs) per configurare il tuo database di origine PostgreSQL. Le impostazioni degli endpoint vengono specificate quando si crea l'endpoint di origine utilizzando la AWS DMS console o utilizzando il `create-endpoint` comando in, con la sintassi JSON. [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)`--postgre-sql-settings '{"EndpointSetting": "value", ...}'`

La tabella seguente mostra le impostazioni degli endpoint e le impostazioni ECAs che è possibile utilizzare con PostgreSQL come sorgente.

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

## Limitazioni all'utilizzo di un database PostgreSQL come origine DMS
<a name="CHAP_Source.PostgreSQL.Limitations"></a>

Quando si utilizza un database PostgreSQL come origine per AWS DMS, si applicano le seguenti limitazioni:
+ AWS DMS non funziona con Amazon RDS for PostgreSQL 10.4 o Amazon Aurora PostgreSQL 10.4 come origine o destinazione.
+ Una tabella acquisita deve avere una chiave primaria. Se una tabella non ha una chiave primaria, ignora le operazioni di record DELETE e UPDATE per quella tabella. AWS DMS Come soluzione alternativa, consulta [Abilitazione dell'acquisizione dei dati di modifica (CDC) mediante la replica logica](#CHAP_Source.PostgreSQL.Security). 

  **Nota:** non è consigliabile eseguire la migrazione senza un Key/Unique indice primario, altrimenti si applicano limitazioni aggiuntive come la funzionalità di applicazione Batch «NO», la funzionalità LOB completa, la convalida dei dati e l'impossibilità di replicare in modo efficiente sulla destinazione Redshift.
+ AWS DMS ignora un tentativo di aggiornare un segmento di chiave primaria. In questi casi, la destinazione identifica l'aggiornamento come un'operazione che non ha aggiornato righe. Tuttavia, poiché i risultati di aggiornamento di una chiave primaria in PostgreSQL sono imprevedibili, non vengono scritti record nella tabella delle eccezioni.
+ AWS DMS non supporta l'opzione **Avvia processo di modifica da Timestamp run**.
+ AWS DMS non replica le modifiche risultanti da operazioni di partizione o sottopartizione (, o). `ADD` `DROP` `TRUNCATE`
+ La replica di più tabelle con lo stesso nome, in cui ogni nome presenta una differenza tra maiuscole e minuscole (ad esempio, table1 e Table1) può causare un comportamento TABLE1 imprevedibile. A causa di questo problema, AWS DMS non supporta questo tipo di replica.
+ Nella maggior parte dei casi, AWS DMS supporta l'elaborazione delle modifiche delle istruzioni DDL CREATE, ALTER e DROP per le tabelle. AWS DMS non supporta questa elaborazione delle modifiche se le tabelle sono contenute in un blocco interno del corpo di una funzione o di una procedura o in altri costrutti annidati.

  Ad esempio, la seguente modifica non viene acquisita.

  ```
  CREATE OR REPLACE FUNCTION attu.create_distributors1() RETURNS void
  LANGUAGE plpgsql
  AS $$
  BEGIN
  create table attu.distributors1(did serial PRIMARY KEY,name
  varchar(40) NOT NULL);
  END;
  $$;
  ```
+ Attualmente, i tipi di dati `boolean` in un'origine PostgreSQL vengono migrati a una destinazione SQL Server come tipo di dati `bit` con valori incoerenti. Come soluzione alternativa, precrea la tabella con un tipo di `VARCHAR(1)` dati per la colonna (o fai AWS DMS creare la tabella). Quindi fai in modo che l'elaborazione a valle tratti una «F» come False e una «T» come True.
+ AWS DMS non supporta l'elaborazione delle modifiche delle operazioni TRUNCATE.
+ Il tipo di dati OID LOB non viene migrato nella destinazione.
+ AWS DMS supporta il tipo di dati PostGIS solo per migrazioni omogenee.
+ Se l'origine è un database PostgreSQL on-premise o su un'istanza Amazon EC2, accertati che il plug-in di output test\$1decoding sia installato nell'endpoint di origine. Puoi trovare questo plug-in nel pacchetto contrib PostgreSQL. Per ulteriori informazioni sul plug-in di test-decoding, consulta la [ documentazione di PostgreSQL](https://www.postgresql.org/docs/10/static/test-decoding.html).
+ AWS DMS non supporta l'elaborazione delle modifiche per impostare e annullare l'impostazione dei valori predefiniti delle colonne (utilizzando la clausola ALTER COLUMN SET DEFAULT nelle istruzioni ALTER TABLE).
+ AWS DMS non supporta l'elaborazione delle modifiche per impostare l'annullabilità delle colonne (utilizzando la clausola ALTER COLUMN [SET\$1DROP] NOT NULL nelle istruzioni ALTER TABLE).
+ Quando la replica logica è abilitata, il numero massimo di modifiche conservate in memoria per transazione è 4 MB. Dopodiché, le modifiche vengono riversate su disco. Di conseguenza `ReplicationSlotDiskUsage` aumenta e `restart_lsn` non avanza finché la transazione non viene completata o interrotta e il rollback non termina. Poiché si tratta di una transazione lunga, il rollback può richiedere tempi lunghi. Pertanto, evita transazioni di lunga durata o molte sottotransazioni quando la replica logica è abilitata. Prova invece a suddividere la transazione in diverse transazioni più piccole. 

  Nelle versioni 13 e successive di Aurora PostgreSQL, è possibile ottimizzare il `logical_decoding_work_mem` parametro per controllare quando le fuoriuscite di DMS modificano i dati sul disco. Per ulteriori informazioni, consulta [Versare file in Aurora PostgreSQL](CHAP_Troubleshooting_Latency_Source_PostgreSQL.md#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill).
+ Una tabella con un tipo di dati ARRAY deve avere una chiave primaria. Una tabella con un tipo di dati ARRAY priva di una chiave primaria viene sospesa durante il pieno carico.
+ AWS DMS [non supporta la migrazione dei metadati delle tabelle relativi al partizionamento o all'ereditarietà delle tabelle.](https://www.postgresql.org/docs/15/ddl-inherit.html) Quando AWS DMS incontra una tabella partizionata o una tabella che utilizza l'ereditarietà, si osserva il seguente comportamento:
  + AWS DMS identifica e riporta le tabelle principali e secondarie coinvolte nel partizionamento o nell'ereditarietà nel database di origine.
  + **Creazione di tabelle su Target**: nel database di destinazione, AWS DMS crea la tabella come tabella standard (non partizionata, non ereditata), preservando la struttura e le proprietà delle tabelle selezionate ma non la logica di partizionamento o di ereditarietà.
  + **Differenziazione dei record nelle tabelle ereditate: per le tabelle** che utilizzano l'ereditarietà, non distingue i record appartenenti alle tabelle secondarie quando popola la tabella principale AWS DMS . Di conseguenza, non utilizza query SQL con sintassi come:. `SELECT * FROM ONLY parent_table_name`
+ Per replicare le tabelle partizionate da un'origine PostgreSQL a una destinazione PostgreSQL, crea manualmente le tabelle padre e figlio nella destinazione. Quindi definisci un'attività separata per la replica su tali tabelle. In questo caso, imposta la configurazione dell'attività su **Tronca prima di caricare**.
+ Il tipo di dati PostgreSQL `NUMERIC` non viene fissato nelle dimensioni. Quando si trasferiscono dati di tipo `NUMERIC` ma senza precisione e dimensioni, per impostazione predefinita DMS usa `NUMERIC(28,6)` (una precisione di 28 e dimensione 6). Ad esempio, il valore 0.611111104488373 dell'origine viene convertito in 0.611111 nella destinazione PostgreSQL.
+ AWS DMS supporta Aurora PostgreSQL Serverless V1 come origine solo per attività a pieno carico. AWS DMS supporta Aurora PostgreSQL Serverless V2 come fonte per attività a pieno carico, a pieno carico e solo CDC e CDC.
+ AWS DMS non supporta la replica di una tabella con un indice univoco creato con una funzione di coalescenza.
+ Se la definizione della chiave primaria su origine e destinazione non corrisponde, i risultati della replica potrebbero essere imprevedibili.
+ Quando si utilizza la funzionalità di caricamento parallello, la segmentazione delle tabelle in base a partizioni o sottopartizioni non è supportata. Per ulteriori informazioni sul caricamento parallelo, consulta [Utilizzo del caricamento parallelo per le tabelle, le viste e le raccolte selezionate](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.ParallelLoad). 
+ AWS DMS non supporta i vincoli differiti.
+ AWS DMS la versione 3.4.7 supporta PostgreSQL 14.x come sorgente con queste limitazioni:
  + AWS DMS non supporta l'elaborazione delle modifiche dei commit in due fasi.
  + AWS DMS non supporta la replica logica per lo streaming di lunghe transazioni in corso.
+ AWS DMS non supporta CDC per Amazon RDS Proxy for PostgreSQL come sorgente.
+ Quando si utilizzano [filtri di origine](CHAP_Tasks.CustomizingTasks.Filters.md) che non contengono una colonna di chiave primaria, le operazioni `DELETE` non verranno acquisite.
+ Se il database di origine è anche la destinazione di un altro sistema di replica di terze parti, le modifiche DDL potrebbero non migrare durante CDC in quanto potrebbero impedire l'attivazione del trigger dell'evento `awsdms_intercept_ddl`. Per aggirare la situazione, modifica il trigger nel database di origine come segue:

  ```
  alter event trigger awsdms_intercept_ddl enable always;
  ```
+ AWS DMS non supporta la replica delle modifiche apportate alle definizioni delle chiavi primarie nel database di origine. Se la struttura della chiave primaria viene modificata durante un'attività di replica attiva, le successive modifiche alle tabelle interessate non vengono replicate nella destinazione.
+ Nella replica DDL come parte di uno script, il numero totale massimo di comandi DDL per script è 8192 e il numero totale massimo di righe per script è 8192 righe.
+ AWS DMS non supporta le viste materializzate.
+ Per le attività a pieno carico e CDC che utilizzano una replica di lettura come origine, AWS DMS non è possibile creare slot di replica sulle repliche di lettura.

## Tipi di dati di origine per PostgreSQL
<a name="CHAP_Source-PostgreSQL-DataTypes"></a>

La tabella seguente mostra i tipi di dati sorgente PostgreSQL supportati durante l' AWS DMS utilizzo e la mappatura predefinita ai tipi di dati. AWS DMS 

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 PostgreSQL  |  Tipi di dati DMS  | 
| --- | --- | 
|  INTEGER  |  INT4  | 
|  SMALLINT  |  INT2  | 
|  BIGINT  |  INT8  | 
|  NUMERIC (p,s)  |  Se la precisione è compresa tra 0 e 38, utilizzare NUMERIC. Se la precisione è 39 o maggiore, utilizzare STRING.  | 
|  DECIMAL(P,S)  |  Se la precisione è compresa tra 0 e 38, utilizzare NUMERIC. Se la precisione è 39 o maggiore, utilizzare STRING.  | 
|  REAL  |  REAL4  | 
|  DOUBLE  |  REAL8  | 
|  SMALLSERIAL  |  INT2  | 
|  SERIAL  |  INT4  | 
|  BIGSERIAL  |  INT8  | 
|  MONEY  |  NUMERIC(38,4) Il tipo di dati MONEY è mappato su FLOAT in SQL Server.  | 
|  CHAR  |  WSTRING (1)  | 
|  CHAR(N)  |  WSTRING (n)  | 
|  VARCHAR(N)  |  WSTRING (n)  | 
|  TEXT  |  NCLOB  | 
|  CITEXT  |  NCLOB  | 
|  BYTEA  |  BLOB  | 
|  TIMESTAMP  |  DATETIME  | 
|  TIMESTAMP WITH TIME ZONE  |  DATETIME  | 
|  DATE  |  DATE  | 
|  TIME  |  TIME  | 
|  TIME WITH TIME ZONE  |  TIME  | 
|  INTERVAL  |  STRING (128): 1 YEAR, 2 MONTHS, 3 DAYS, 4 HOURS, 5 MINUTES, 6 SECONDS  | 
|  BOOLEAN  |  CHAR (5) false o true  | 
|  ENUM  |  STRING (64)  | 
|  CIDR  |  STRING (50)  | 
|  INET  |  STRING (50)  | 
|  MACADDR  |  STRING (18)  | 
|  BIT(n)  |  STRING (n)  | 
|  BIT VARYING (n)  |  STRING (n)  | 
|  UUID  |  STRING  | 
|  TSVECTOR  |  CLOB  | 
|  TSQUERY  |  CLOB  | 
|  XML  |  CLOB  | 
|  POINT  |  STRING (255) "(x,y)"  | 
|  LINE  |  STRING (255) "(x,y,z)"  | 
|  LSEG  |  STRING (255) "((x1,y1),(x2,y2))"  | 
|  BOX  |  STRING (255) "((x1,y1),(x2,y2))"  | 
|  PATH  |  CLOB "((x1,y1),(xn,yn))"  | 
|  POLYGON  |  CLOB "((x1,y1),(xn,yn))"  | 
|  CIRCLE  |  STRING (255) "(x,y),r"  | 
|  JSON  |  NCLOB  | 
|  JSONB  |  NCLOB  | 
|  ARRAY  |  NCLOB  | 
|  COMPOSITE  |  NCLOB  | 
|  HSTORE  |  NCLOB  | 
|  INT4INTERVALLO  |  STRING (255)  | 
|  INT8INTERVALLO  |  STRING (255)  | 
|  NUMRANGE  |  STRING (255)  | 
|  STRRANGE  |  STRING (255)  | 

### Utilizzo dei tipi di dati di origine LOB per PostgreSQL
<a name="CHAP_Source-PostgreSQL-DataTypes-LOBs"></a>

Le dimensioni di colonna PostgreSQL influenzano la conversione dei tipi di dati LOB PostgreSQL in tipi di dati AWS DMS . Per utilizzare questa funzione, effettua la procedura riportata di seguito per i seguenti tipi di dati AWS DMS :
+ BLOB: imposta **Limita dimensioni LOB a** sul valore di **Dimensione massima dei LOB (KB)** al momento della creazione dell'attività.
+ CLOB — La replica gestisce ogni personaggio come un UTF8 personaggio. Pertanto, individua il testo con il maggiore numero di caratteri nella colonna `max_num_chars_text`. Utilizza questa lunghezza per specificare il valore di **Limita dimensioni LOB a**. Se i dati includono caratteri a 4 byte, moltiplicare per 2 per specificare il valore di **Limit LOB size to (Limita dimensioni LOB a)**, che è espresso in byte. In questo caso, **Limit LOB size to (Limita dimensioni LOB a)** è uguale a `max_num_chars_text` moltiplicato per 2.
+ NCLOB: la replica gestisce ogni carattere come carattere a due byte. Pertanto, individua il testo con il maggiore numero di caratteri nella colonna (`max_num_chars_text`) e moltiplicarlo per 2. Questa operazione viene eseguita per specificare il valore di **Limita dimensioni LOB a**. In questo caso, **Limit LOB size to (Limita dimensioni LOB a)** è uguale a `max_num_chars_text` moltiplicato per 2. Se i dati includono caratteri a 4 byte, moltiplicare ancora per 2. In questo caso, **Limit LOB size to (Limita dimensioni LOB a)** è uguale a `max_num_chars_text` moltiplicato per 4.

# Utilizzo di un database compatibile con MySQL come fonte per AWS DMS
<a name="CHAP_Source.MySQL"></a>

Puoi migrare i dati da qualsiasi database compatibile con MySQL (MySQL, MariaDB o Amazon Aurora MySQL) utilizzando Database Migration Service. AWS 

Per informazioni sulle versioni di MySQL supportate come AWS DMS sorgente, vedere. [Fonti per AWS DMS](CHAP_Introduction.Sources.md) 

Puoi utilizzare il protocollo SSL per crittografare le connessioni tra l'endpoint compatibile con MySQL e l'istanza di replica. Per ulteriori informazioni sull'utilizzo di SSL con un endpoint compatibile con MySQL, consulta [Utilizzo di SSL con AWS Database Migration Service](CHAP_Security.SSL.md).

Nelle sezioni seguenti, il termine "autogestito" si applica a qualsiasi database installato on-premise o su Amazon EC2. Il termine "gestito da AWS" si applica a qualsiasi database su Amazon RDS, Amazon Aurora o Amazon S3.

Per ulteriori dettagli sull'utilizzo di database compatibili con MySQL AWS DMS, vedere le seguenti sezioni.

**Topics**
+ [Migrazione da MySQL a MySQL utilizzando AWS DMS](#CHAP_Source.MySQL.Homogeneous)
+ [Utilizzo di qualsiasi database compatibile con MySQL come fonte per AWS DMS](#CHAP_Source.MySQL.Prerequisites)
+ [Utilizzo di un database autogestito compatibile con MySQL come fonte per AWS DMS](#CHAP_Source.MySQL.CustomerManaged)
+ [Utilizzo di un AWS database compatibile con MySQL gestito come fonte per AWS DMS](#CHAP_Source.MySQL.AmazonManaged)
+ [Limitazioni all'utilizzo di un database MySQL come fonte per AWS DMS](#CHAP_Source.MySQL.Limitations)
+ [Supporto per transazione XA](#CHAP_Source.MySQL.XA)
+ [Impostazioni degli endpoint quando si utilizza MySQL come sorgente per AWS DMS](#CHAP_Source.MySQL.ConnectionAttrib)
+ [Tipi di dati di origine per MySQL](#CHAP_Source.MySQL.DataTypes)

**Nota**  
Quando si configurano le regole di mappatura AWS Database Migration Service (AWS DMS), è importante evitare l'uso di caratteri jolly (%) per i nomi di database o schemi. È invece necessario specificare in modo esplicito solo i database creati dall'utente che devono essere migrati. L'utilizzo di un carattere jolly include tutti i database nel processo di migrazione, inclusi i database di sistema che non sono necessari nell'istanza di destinazione. Poiché l'utente master MySQL di Amazon RDS non dispone delle autorizzazioni necessarie per importare i dati nei database del sistema di destinazione, il tentativo di migrare questi database di sistema non riesce.

## Migrazione da MySQL a MySQL utilizzando AWS DMS
<a name="CHAP_Source.MySQL.Homogeneous"></a>

Per una migrazione eterogenea, in cui si esegue la migrazione da un motore di database diverso da MySQL a un database MySQL, è quasi sempre lo strumento di migrazione migliore da utilizzare. AWS DMS Ma per una migrazione omogenea, ad esempio da un database MySQL a un database MySQL, ti consigliamo di utilizzare un progetto di migrazione di dati omogeneo. Le migrazioni di dati omogenee utilizzano strumenti di database nativi per fornire prestazioni e precisione di migrazione dei dati migliorate rispetto a AWS DMS.

## Utilizzo di qualsiasi database compatibile con MySQL come fonte per AWS DMS
<a name="CHAP_Source.MySQL.Prerequisites"></a>

Prima di iniziare a utilizzare un database MySQL come sorgente AWS DMS per, assicurati di avere i seguenti prerequisiti. Questi prerequisiti si applicano sia alle fonti autogestite che a quelle gestite. AWS

È necessario disporre di un account con il ruolo di AWS DMS amministratore di replica. Il ruolo richiede i seguenti privilegi:
+ **REPLICATION CLIENT**: questo privilegio è richiesto per le attività di sola CDC. In altre parole, le full-load-only attività non richiedono questo privilegio. 
**Nota**  
Per la versione 10.5.2\$1 di MariadB, puoi usare BINLOG MONITOR, che sostituisce REPLICATION CLIENT.
+ **REPLICATION SLAVE**: questo privilegio è richiesto per le attività di sola CDC. In altre parole, le attività non richiedono questo privilegio full-load-only.
+ **SUPER**: questo privilegio è richiesto solo nelle versioni di MySQL precedenti alla 5.6.6.

L' AWS DMS utente deve inoltre disporre dei privilegi SELECT per le tabelle di origine designate per la replica.

Concedi i seguenti privilegi se utilizzi valutazioni di premigrazione specifiche per MySQL:

```
grant select on mysql.user to <dms_user>;
grant select on mysql.db to <dms_user>;
grant select on mysql.tables_priv to <dms_user>;
grant select on mysql.role_edges to <dms_user>  #only for MySQL version 8.0.11 and higher
grant select on performance_schema.replication_connection_status to <dms_user>;  #Required for primary instance validation - MySQL version 5.7 and higher only
```

Se utilizzi una fonte RDS e intendi eseguire valutazioni di premigrazione specifiche per MySQL, aggiungi la seguente autorizzazione:

```
grant select on mysql.rds_configuration to <dms_user>;  #Required for binary log retention check
```

Se il parametro `BatchEnable` è, è necessario concedere: `true`

```
grant create temporary tables on `<schema>`.* to <dms_user>;
```

## Utilizzo di un database autogestito compatibile con MySQL come fonte per AWS DMS
<a name="CHAP_Source.MySQL.CustomerManaged"></a>

Puoi utilizzare i seguenti database gestiti dal cliente compatibili con MySQL come origini per AWS DMS:
+ MySQL Community Edition
+ MySQL Standard Edition
+ MySQL Enterprise Edition
+ MySQL Cluster Carrier Grade Edition
+ MariaDB Community Edition
+ MariaDB Enterprise Edition
+ MariaDB Column Store

Per utilizzare CDC, assicurati di abilitare la registrazione binaria. Per abilitare la registrazione binaria, devi configurare i seguenti parametri nel file `my.ini` (Windows) o `my.cnf` (UNIX) di MySQL.


| Parametro | Valore | 
| --- | --- | 
| `server_id` | Imposta questo parametro su un valore uguale o maggiore di 1. | 
| `log-bin` | Imposta il percorso del file di log binario, ad esempio `log-bin=E:\MySql_Logs\BinLog`. Non includere l'estensione del file. | 
| `binlog_format` | Imposta questo parametro su `ROW`. Si consiglia questa impostazione per la replica perché, in alcuni casi, quando `binlog_format` è impostato su `STATEMENT`, si possono verificare incoerenze della replica dei dati sulla destinazione. Il motore di database scrive dati incoerenti simili sulla destinazione quando `binlog_format` è impostato su `MIXED` perché passa automaticamente alla registrazione basata su `STATEMENT`, il che può comportare la scrittura di dati non coerenti sul database di destinazione. | 
| `expire_logs_days` | Imposta questo parametro su un valore uguale o maggiore di 1. Per prevenire un utilizzo eccessivo di spazio su disco, si consiglia di non utilizzare il valore predefinito di 0. | 
| `binlog_checksum` | Imposta questo parametro su `NONE` per la versione DMS 3.4.7 o precedente. | 
| `binlog_row_image` | Imposta questo parametro su `FULL`. | 
| `log_slave_updates` | Imposta questo parametro su `TRUE` se stai utilizzando come origine una replica di lettura di MySQL o di MariaDB. | 

Se si utilizza una replica di lettura MySQL o MariaDB come origine per un'**attività di migrazione DMS utilizzando la modalità Migra dati esistenti e replica modifiche in corso, esiste la possibilità di perdita di dati**. DMS non scriverà una transazione durante il pieno carico o durante il CDC nelle seguenti condizioni:
+ La transazione era stata salvata nell'istanza principale prima dell'inizio dell'attività DMS.
+ La transazione era stata salvata nella replica solo dopo l'avvio dell'attività DMS, a causa del ritardo tra l'istanza principale e la replica.

Maggiore è il ritardo tra l'istanza principale e la replica, maggiore è il rischio di perdita di dati.

Se l'origine utilizza il motore di database NDB (cluster), i parametri seguenti devono essere configurati per abilitare il CDC sulle tabelle che utilizzano il motore di storage. Aggiungi queste modifiche nel file `my.ini` (Windows) o `my.cnf` (UNIX) di MySQL.


| Parametro | Valore | 
| --- | --- | 
| `ndb_log_bin` | Imposta questo parametro su `ON`. Questo valore garantisce che le modifiche nelle tabelle cluster vengono registrate nel log binario. | 
| `ndb_log_update_as_write` | Imposta questo parametro su `OFF`. Questo valore impedisce la scrittura nel log binario delle istruzioni UPDATE come istruzioni INSERT. | 
| `ndb_log_updated_only` | Imposta questo parametro su `OFF`. Questo valore garantisce che il log binario contiene l'intera riga e non soltanto le colonne modificate. | 

## Utilizzo di un AWS database compatibile con MySQL gestito come fonte per AWS DMS
<a name="CHAP_Source.MySQL.AmazonManaged"></a>

È possibile utilizzare i seguenti database AWS gestiti compatibili con MySQL come sorgenti per: AWS DMS
+ MySQL Community Edition
+ MariaDB Community Edition
+ Amazon Aurora edizione compatibile con MySQL

Quando utilizzi un database compatibile con MySQL AWS gestito come fonte per AWS DMS, assicurati di avere i seguenti prerequisiti per CDC:
+ Per abilitare i log binari per RDS per MySQL e per RDS per MariaDB, abilita i backup automatici a livello di istanza. Per abilitare i log binari per un cluster Aurora MySQL, modifica la variabile `binlog_format` nel gruppo di parametri.

  Per ulteriori informazioni sull'impostazione dei backup automatici, consulta [Abilitazione dei backup automatici](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) nella *Guida per l'utente di Amazon RDS*.

  Per ulteriori informazioni sulla configurazione della registrazione binaria per un database Amazon RDS per MySQL, consulta [Configurazione del log binario](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) nella *Guida per l'utente di Amazon RDS*. 

  Per ulteriori informazioni sulla configurazione della registrazione binaria per un cluster MySQL Aurora, consulta [Come posso attivare la registrazione binaria per il cluster Amazon Aurora MySQL edizione compatibile?](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/) 
+ Se intendi utilizzare CDC, attiva la registrazione binaria. Per ulteriori informazioni sulla configurazione della registrazione binaria per un database Amazon RDS per MySQL, consulta [Configurazione del log binario](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) nella *Guida per l'utente di Amazon RDS*.
+ Assicuratevi che i log binari siano disponibili per. AWS DMS Poiché i database compatibili con AWS-managed MySQL eliminano i log binari il prima possibile, è necessario aumentare il periodo di tempo in cui i log rimangono disponibili. Ad esempio, per aumentare il periodo di conservazione dei log binari a 24 ore, esegui il comando seguente. 

  ```
   call mysql.rds_set_configuration('binlog retention hours', 24);
  ```
+ Imposta il parametro `binlog_format` su `"ROW"`.
**Nota**  
Su MySQL o MariaDB, `binlog_format` è un parametro dinamico, quindi non è necessario riavviare il computer per rendere effettivo il nuovo valore. Tuttavia, il nuovo valore verrà applicato solo alle nuove sessioni. Se si passa `binlog_format` su `ROW` per scopi di replica, il database può comunque creare log binari successivi utilizzando il formato `MIXED`, se tali sessioni sono iniziate prima della modifica del valore. Ciò potrebbe impedire la corretta acquisizione di tutte le modifiche nel AWS DMS database di origine. Quando modifichi l'impostazione `binlog_format` su un database MariaDB o MySQL, assicurati di riavviare il database per chiudere tutte le sessioni esistenti o riavviare qualsiasi applicazione che esegua operazioni DML (Data Manipulation Language). Forzando il database a riavviare tutte le sessioni dopo aver modificato il `binlog_format` parametro, `ROW` si assicurerà che il database scriva tutte le successive modifiche al database di origine utilizzando il formato corretto, in modo che sia AWS DMS possibile acquisire correttamente tali modifiche.
+ Imposta il parametro `binlog_row_image` su `"Full"`. 
+ Imposta il `binlog_checksum` parametro su `"NONE"` DMS versione 3.4.7 o precedente. Per ulteriori informazioni sull'impostazione dei parametri in Amazon RDS MySQL, consulta [Abilitazione dei backup automatici](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) nella *Guida per l'utente di Amazon RDS*.
+ Se stai utilizzando una replica di lettura Amazon RDS MySQL o Amazon RDS MariaDB come origine, abilita i backup sulla replica di lettura e assicurati che il parametro `log_slave_updates` sia impostato su `TRUE`.

## Limitazioni all'utilizzo di un database MySQL come fonte per AWS DMS
<a name="CHAP_Source.MySQL.Limitations"></a>

Quando si utilizza un database MySQL come origine, considerare quanto segue:
+  L'acquisizione dei dati di modifica (CDC) non è supportata per Amazon RDS MySQL 5.5 o versioni precedenti. Per Amazon RDS MySQL, è necessario utilizzare la versione 5.6, 5.7 o 8.0 per abilitare CDC. CDC è supportata per origini MySQL 5.5 autogestite. 
+ Per CDC, `CREATE TABLE`, `ADD COLUMN` e `DROP COLUMN` che modificano il tipo di dati di colonne e `renaming a column` sono supportati. Tuttavia `DROP TABLE`, `RENAME TABLE` e gli aggiornamenti apportati ad altri attributi, come il valore predefinito della colonna, la nullabilità delle colonne, il set di caratteri e così via, non sono supportati.
+  Per le tabelle partizionate sull'origine, quando si imposta la **modalità di preparazione della tabella di Target** su **Drop tables on target**, AWS DMS crea una tabella semplice senza partizioni sulla destinazione MySQL. Per eseguire la migrazione di tabelle partizionate a una tabella partizionata nella destinazione, crea in anticipo le tabelle partizionate nel database di destinazione MySQL.
+  L'utilizzo di un'`ALTER TABLE table_name ADD COLUMN column_name`istruzione per aggiungere colonne all'inizio (FIRST) o al centro di una tabella (AFTER) non è supportato per gli obiettivi relazionali. Le colonne vengono sempre aggiunte alla fine della tabella. Quando la destinazione è Amazon S3 o Amazon Kinesis Data Streams, è supportata l'aggiunta di colonne utilizzando FIRST o AFTER.
+ Il CDC non è supportato quando un nome di tabella contiene caratteri maiuscoli e minuscoli e il motore di origine è ospitato in un sistema operativo con nomi di file che non fanno distinzione tra lettere maiuscole e minuscole. Un esempio è Microsoft Windows oppure OS X che utilizza HFS \$1.
+ Puoi usare Aurora, compatibile con MySQL, Edition Serverless v1 a pieno carico, ma non puoi usarlo per CDC. perché non è possibile abilitare i prerequisiti per MySQL. Per ulteriori informazioni, consulta [Parameter groups and Aurora Serverless v1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html#aurora-serverless.parameter-groups). 

  L'edizione Serverless v2 compatibile con Aurora MySQL supporta CDC.
+  L'attributo AUTO\$1INCREMENT di una colonna non viene migrato a una colonna del database di destinazione.
+  L'acquisizione delle modifiche quando i log binari non sono archiviati su uno storage a blocchi standard non è supportata. Ad esempio, CDC non funziona quando i log binari sono archiviati su Amazon S3.
+  AWS DMS crea tabelle di destinazione con il motore di archiviazione InnoDB per impostazione predefinita. Se è necessario utilizzare un motore di storage diverso da InnoDB, occorre creare manualmente la tabella ed eseguirvi la migrazione utilizzando la modalità [nessuna azione](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html).
+ **Non è possibile utilizzare le repliche Aurora MySQL come origine, a AWS DMS meno che la modalità attività di migrazione DMS non sia Migra dati esistenti, solo a pieno carico.**
+  Se l'origine compatibile con MySQL viene interrotta durante il caricamento completo, l' AWS DMS attività non si interrompe con un errore. L'attività termina correttamente, ma la destinazione potrebbe non essere sincronizzata con l'origine. In questo caso, riavvia l'attività o ricarica le tabelle interessate.
+  Gli indici creati su una parte di un valore di colonna non vengono migrati. Ad esempio, l'indice CREATE INDEX first\$1ten\$1chars ON customer (name(10)) non viene creato nella destinazione.
+ In alcuni casi, l'attività è configurata per non essere replicata LOBs (SupportLobs«" è false nelle impostazioni dell'attività oppure l'opzione **Non includere le colonne LOB** è stata scelta nella console delle attività). In questi casi, AWS DMS non migra alcuna colonna MEDIUMBLOB, LONGBLOB, MEDIUMTEXT e LONGTEXT verso la destinazione.

  Le colonne BLOB, TINYBLOB, TEXT e TINYTEXT non sono interessate e vengono migrate nella destinazione.
+ Le tabelle di dati temporali o le tabelle con versioni di sistema non sono supportate nei database di origine e di destinazione di MariaDB.
+ Se si esegue la migrazione tra due cluster Amazon RDS Aurora MySQL, l'endpoint di origine MySQL di RDS Aurora deve essere un'istanza, non un'istanza di replica. read/write 
+ AWS DMS attualmente non supporta la migrazione delle visualizzazioni per MariadB.
+ AWS DMS non supporta le modifiche DDL per le tabelle partizionate per MySQL. Per ignorare la sospensione della tabella per le modifiche DDL della partizione durante CDC, imposta `skipTableSuspensionForPartitionDdl` su `true`.
+ AWS DMS supporta solo transazioni XA nella versione 3.5.0 e successive. Le versioni precedenti non supportano le transazioni XA. AWS DMS non supporta le transazioni XA in MariadB versione 10.6 o successiva Per ulteriori informazioni, vedere quanto segue. [Supporto per transazione XA](#CHAP_Source.MySQL.XA)
+ AWS DMS non viene utilizzato GTIDs per la replica, anche se i dati di origine li contengono. 
+ AWS DMS non supporta il log binario avanzato di Aurora MySQL.
+ AWS DMS non supporta la compressione delle transazioni di log binario.
+ AWS DMS non propaga gli eventi ON DELETE CASCADE e ON UPDATE CASCADE per i database MySQL utilizzando il motore di archiviazione InnoDB. Per questi eventi, MySQL non genera eventi binlog per riflettere le operazioni a cascata sulle tabelle secondarie. Di conseguenza, non AWS DMS è possibile replicare le modifiche corrispondenti alle tabelle secondarie. Per ulteriori informazioni, consulta [Indici, chiavi esterne o aggiornamenti o eliminazioni a cascata non migrati](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.FKsAndIndexes).
+ AWS DMS non acquisisce le modifiche alle colonne calcolate (`VIRTUAL`e`GENERATED ALWAYS`). Per ovviare a questa limitazione, esegui queste operazioni:
  + Crea in anticipo la tabella di destinazione nel database di destinazione e crea l'attività AWS DMS con l'impostazione dell'attività di pieno carico `DO_NOTHING` o `TRUNCATE_BEFORE_LOAD`.
  + Aggiungi una regola di trasformazione per rimuovere la colonna calcolata dall'ambito dell'attività. Per informazioni sulle regole di trasformazione, consulta [Operazioni e regole di trasformazione](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
+ A causa della limitazione interna di MySQL AWS DMS , può BINLOGs elaborare dimensioni non superiori a 4 GB. BINLOGs più di 4 GB possono causare errori nelle attività DMS o altri comportamenti imprevedibili. È necessario ridurre le dimensioni delle transazioni per evitare transazioni superiori a 4 GB. BINLOGs 
+ AWS DMS non supporta back-tick (```) o virgolette singole (`'`) nei nomi di schemi, tabelle e colonne.
+ AWS DMS non migra i dati dalle colonne invisibili del database di origine. Per includere queste colonne nell'ambito di migrazione, utilizzate l'istruzione ALTER TABLE per rendere visibili queste colonne.

## Supporto per transazione XA
<a name="CHAP_Source.MySQL.XA"></a>

Una transazione Extended Architecture (XA) è una transazione che può essere utilizzata per raggruppare una serie di operazioni da più risorse transazionali in un'unica transazione globale affidabile. Una transazione XA utilizza un protocollo di commit in due fasi. In generale, l'acquisizione delle modifiche mentre sono presenti transazioni XA aperte potrebbe portare alla perdita di dati. Se il database non utilizza transazioni XA, puoi ignorare questa autorizzazione e la configurazione `IgnoreOpenXaTransactionsCheck` utilizzando il valore predefinito. `TRUE` Per iniziare la replica da un'origine che contiene transazioni XA, effettua le seguenti operazioni:
+ Assicurati che l'utente dell' AWS DMS endpoint disponga delle seguenti autorizzazioni:

  ```
  grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';
  ```
+ Configura l'impostazione dell'endpoint `IgnoreOpenXaTransactionsCheck` su `false`.

**Nota**  
AWS DMS non supporta le transazioni XA su MariaDB Source DB versione 10.6 o successiva.

## Impostazioni degli endpoint quando si utilizza MySQL come sorgente per AWS DMS
<a name="CHAP_Source.MySQL.ConnectionAttrib"></a>

È possibile utilizzare le impostazioni degli endpoint per configurare il database di origine MySQL 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 JSON. `--my-sql-settings '{"EndpointSetting": "value", ...}'`

La tabella riportata di seguito mostra le impostazioni degli endpoint che è possibile utilizzare con MySQL come origine.

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

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

La tabella seguente mostra i tipi di dati di origine del database MySQL supportati durante l' AWS DMS utilizzo e la AWS DMS mappatura predefinita 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 MySQL  |  AWS DMS tipi di dati  | 
| --- | --- | 
|  INT  |  INT4  | 
|  BIGINT  |  INT8  | 
|  MEDIUMINT  |  INT4  | 
|  TINYINT  |  INT1  | 
|  SMALLINT  |  INT2  | 
|  UNSIGNED TINYINT  |  UINT1  | 
|  UNSIGNED SMALLINT  |  UINT2  | 
|  UNSIGNED MEDIUMINT  |  UINT4  | 
|  UNSIGNED INT  |  UINT4  | 
|  UNSIGNED BIGINT  |  UINT8  | 
|  DECIMAL(10)  |  NUMERIC (10,0)  | 
|  BINARY  |  BYTES(1)  | 
|  BIT  |  BOOLEAN  | 
|  BIT(64)  |  BYTES(8)  | 
|  BLOB  |  BYTES(65535)  | 
|  LONGBLOB  |  BLOB  | 
|  MEDIUMBLOB  |  BLOB  | 
|  TINYBLOB  |  BYTES(255)  | 
|  DATE  |  DATE  | 
|  DATETIME  |  DATETIME DATETIME senza un valore tra parentesi viene replicato senza millisecondi. DATETIME con un valore tra parentesi compreso tra 1 e 5 (ad esempio `DATETIME(5)`) viene replicato con i millisecondi. Quando si replica una colonna DATETIME, l'ora rimane la stessa sulla destinazione. Non viene convertita in UTC.  | 
|  TIME  |  STRING  | 
|  TIMESTAMP  |  DATETIME Quando si replica una colonna TIMESTAMP, l'ora viene convertita in UTC sulla destinazione.  | 
|  ANNO  |  INT2  | 
|  DOUBLE  |  REAL8  | 
|  FLOAT  |  REAL(DOUBLE) Se i valori FLOAT non sono compresi nell'intervallo seguente, usa una trasformazione per mappare FLOAT su STRING. Per ulteriori informazioni sulle trasformazioni, consulta [Operazioni e regole di trasformazione](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md). L'intervallo FLOAT supportato è da -1.79E\$1308 a -2.23E-308, 0 e da 2.23E-308 a 1.79E\$1308  | 
|  VARCHAR (45)  |  WSTRING (45)  | 
|  VARCHAR (2000)  |  WSTRING (2000)  | 
|  VARCHAR (4000)  |  WSTRING (4000)  | 
|  VARBINARY (4000)  |  BYTES (4000)  | 
|  VARBINARY (2000)  |  BYTES (2000)  | 
|  CHAR  |  WSTRING  | 
|  TEXT  |  WSTRING  | 
|  LONGTEXT  |  NCLOB  | 
|  MEDIUMTEXT  |  NCLOB  | 
|  TINYTEXT  |  WSTRING(255)  | 
|  GEOMETRY  |  BLOB  | 
|  POINT  |  BLOB  | 
|  LINESTRING  |  BLOB  | 
|  POLYGON  |  BLOB  | 
|  MULTIPOINT  |  BLOB  | 
|  MULTILINESTRING  |  BLOB  | 
|  MULTIPOLYGON  |  BLOB  | 
|  GEOMETRYCOLLECTION  |  BLOB  | 
|  ENUM  |  STRINGA () *length* Qui *length* è la lunghezza del valore più lungo nell'ENUM.  | 
|  SET  |  STRINGA () *length* Qui *length* è la lunghezza totale di tutti i valori nel SET, comprese le virgole.  | 
|  JSON  |  CLOB  | 

**Nota**  
In alcuni casi, è possibile specificare i tipi di dati DATETIME e TIMESTAMP con un valore "zero" (ovvero 0000-00-00). In tal caso, assicurati che il database di destinazione nell'attività di replica supporti valori "zero" per i tipi di dati DATETIME e TIMESTAMP. In caso contrario, tali valori vengono registrati come null nella destinazione.

# Utilizzo di un database SAP ASE come fonte per AWS DMS
<a name="CHAP_Source.SAP"></a>

È possibile migrare i dati da un database SAP Adaptive Server Enterprise (ASE), precedentemente noto come Sybase, utilizzando. AWS DMS Con un database SAP ASE come origine, è possibile migrare i dati verso uno qualsiasi degli altri database di destinazione supportati. AWS DMS 

Per informazioni sulle versioni di SAP ASE AWS DMS supportate come origine, consulta. [Fonti per AWS DMS](CHAP_Introduction.Sources.md)

Per ulteriori dettagli sull'utilizzo dei database SAP ASE e AWS DMS, consulta le seguenti sezioni.

**Topics**
+ [Prerequisiti per l'utilizzo di un database SAP ASE come origine per AWS DMS](#CHAP_Source.SAP.Prerequisites)
+ [Limitazioni all'utilizzo di SAP ASE come fonte per AWS DMS](#CHAP_Source.SAP.Limitations)
+ [Autorizzazioni necessarie per utilizzare SAP ASE come fonte per AWS DMS](#CHAP_Source.SAP.Security)
+ [Rimozione del punto di troncamento](#CHAP_Source.SAP.Truncation)
+ [Impostazioni degli endpoint quando si utilizza SAP ASE come fonte per AWS DMS](#CHAP_Source.SAP.ConnectionAttrib)
+ [Tipi di dati di origine per SAP ASE](#CHAP_Source.SAP.DataTypes)

## Prerequisiti per l'utilizzo di un database SAP ASE come origine per AWS DMS
<a name="CHAP_Source.SAP.Prerequisites"></a>

Per utilizzare un database SAP ASE come fonte AWS DMS, procedi come segue:
+ Abilita la replica SAP ASE per le tabelle utilizzando il comando `sp_setreptable`. Per ulteriori informazioni, consulta [Sybase Infocenter Archive]( http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.dc32410_1501/html/refman/X37830.htm). 
+ Disabilita `RepAgent` sul database SAP ASE. Per ulteriori informazioni, consulta [Arrestare e disabilitare il RepAgent thread nel database primario](http://infocenter-archive.sybase.com/help/index.jsp?topic=/com.sybase.dc20096_1260/html/mra126ag/mra126ag65.htm). 
+ Per eseguire la replica in SAP ASE versione 15.7 su un'istanza Windows EC2 configurata per caratteri non latini (ad esempio, cinese), installa SAP ASE 15.7 sul computer di destinazione. SP121

**Nota**  
Per la replica continua, l'acquisizione dei dati di modifica (CDC), DMS esegue `dbcc logtransfer` e `dbcc log` per leggere i dati del log delle transazioni.

## Limitazioni all'utilizzo di SAP ASE come fonte per AWS DMS
<a name="CHAP_Source.SAP.Limitations"></a>

Quando si utilizza un database SAP ASE come origine per AWS DMS, si applicano le seguenti limitazioni:
+ È possibile eseguire solo un' AWS DMS attività con replica continua o CDC per ogni database SAP ASE. È possibile eseguire più full-load-only attività in parallelo.
+ Non puoi rinominare una tabella. Ad esempio, il seguente comando ha esito negativo.

  ```
  sp_rename 'Sales.SalesRegion', 'SalesReg;
  ```
+ Non puoi rinominare una colonna. Ad esempio, il seguente comando ha esito negativo.

  ```
  sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';
  ```
+ I valori zero situati al termine di stringhe di tipo di dati binari vengono troncati quando vengono replicati nel database di destinazione. Ad esempio, `0x0000000000000000000000000100000100000000` nella tabella di origine diventa `0x00000000000000000000000001000001` nella tabella di destinazione.
+ Se l'impostazione predefinita del database è impostata per non consentire valori NULL, AWS DMS crea la tabella di destinazione con colonne che non consentono valori NULL. Di conseguenza, se un'attività di replica a pieno carico o CDC contiene valori vuoti, AWS DMS genera un errore. È possibile evitare questi errori consentendo valori NULL nel database di origine utilizzando i comandi seguenti.

  ```
  sp_dboption database_name, 'allow nulls by default', 'true'
  go
  use database_name
  CHECKPOINT
  go
  ```
+ Il comando di indicizzazione `reorg rebuild` non è supportato.
+ AWS DMS non supporta i cluster o utilizza MSA (Multi-Site Availability) /Warm Standby come fonte.
+ Quando l'espressione dell'intestazione di trasformazione `AR_H_TIMESTAMP` viene utilizzata nelle regole di mappatura, i millisecondi non vengono acquisiti per una colonna aggiunta.
+ L'esecuzione di operazioni di unione durante una CDC genera un errore irreversibile. Per ripristinare la destinazione sincronizzata, esegui un pieno carico.
+ Gli eventi del trigger di rollback non sono supportati per le tabelle che utilizzano uno schema di blocco delle righe di dati.
+ AWS DMS non può riprendere un'attività di replica dopo aver eliminato una tabella compresa nell'ambito dell'attività da un database SAP di origine. Se l'attività di replica DMS è stata interrotta ed è stata eseguita un'operazione DML (INSERT, UPDATE, DELETE) seguita dall'eliminazione della tabella, è necessario riavviare l'attività di replica.

## Autorizzazioni necessarie per utilizzare SAP ASE come fonte per AWS DMS
<a name="CHAP_Source.SAP.Security"></a>

Per utilizzare un database SAP ASE come origine in un' AWS DMS attività, è necessario concedere le autorizzazioni. Concedi all'account utente specificato nelle definizioni del AWS DMS database le seguenti autorizzazioni nel database SAP ASE: 
+ sa\$1role
+ replication\$1role
+ sybase\$1ts\$1role
+ Per impostazione predefinita, quando è necessario disporre dell'autorizzazione per eseguire la `sp_setreptable` stored procedure, AWS DMS abilita l'opzione di replica SAP ASE. Se si desidera eseguire l'esecuzione `sp_setreptable` su una tabella direttamente dall'endpoint del database e non tramite AWS DMS se stessa, è possibile utilizzare l'attributo di connessione `enableReplication` extra. Per ulteriori informazioni, consulta [Impostazioni degli endpoint quando si utilizza SAP ASE come fonte per AWS DMS](#CHAP_Source.SAP.ConnectionAttrib).

## Rimozione del punto di troncamento
<a name="CHAP_Source.SAP.Truncation"></a>

All'avvio di un'attività, AWS DMS stabilisce una `$replication_truncation_point` voce nella vista del `syslogshold` sistema, che indica che è in corso un processo di replica. Durante AWS DMS il funzionamento, fa avanzare il punto di troncamento della replica a intervalli regolari, in base alla quantità di dati che sono già stati copiati sulla destinazione.

Dopo aver stabilito l'`$replication_truncation_point`immissione, mantieni l' AWS DMS attività in esecuzione per evitare che il registro del database diventi eccessivamente grande. Se desideri interrompere l' AWS DMS attività in modo permanente, rimuovi il punto di troncamento della replica emettendo il seguente comando:

```
dbcc settrunc('ltm','ignore')
```

Dopo la rimozione del punto di troncamento, non è possibile riprendere l'attività. AWS DMS Il log continua a essere automaticamente troncato ai checkpoint (se è impostato il troncamento automatico).

## Impostazioni degli endpoint quando si utilizza SAP ASE come fonte per AWS DMS
<a name="CHAP_Source.SAP.ConnectionAttrib"></a>

È possibile utilizzare le impostazioni di endpoint per configurare il database di origine SAP ASE 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 `--sybase-settings '{"EndpointSetting": "value", ...}'` sintassi JSON.

Nella tabella seguente vengono elencate le impostazioni dell'endpoint che è possibile utilizzare con SAP ASE come origine.

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

## Tipi di dati di origine per SAP ASE
<a name="CHAP_Source.SAP.DataTypes"></a>

Per un elenco dei tipi di dati di origine SAP ASE supportati durante l'utilizzo AWS DMS e la mappatura predefinita dei tipi di AWS DMS dati, vedere la tabella seguente. AWS DMS non supporta le tabelle di origine SAP ASE con colonne del tipo di dati UDT (User-Defined Type). Le colonne replicate con questo tipo di dati sono create come NULL. 

Per informazioni su come visualizzare il tipo di dati mappato nella destinazione, consulta la [Destinazioni per la migrazione dei dati](CHAP_Target.md) sezione relativa all'endpoint di destinazione.

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 SAP ASE  |  AWS DMS tipi di dati  | 
| --- | --- | 
| BIGINT | INT8 | 
| UNSIGNED BIGINT | UINT8 | 
| INT | INT4 | 
| UNSIGNED INT | UINT4 | 
| SMALLINT | INT2 | 
| UNSIGNED SMALLINT | UINT2 | 
| TINYINT | UINT1 | 
| DECIMAL | NUMERIC | 
| NUMERIC | NUMERIC | 
| FLOAT | REAL8 | 
| DOUBLE | REAL8 | 
| REAL | REAL4 | 
| MONEY | NUMERIC | 
| SMALLMONEY | NUMERIC | 
| DATETIME | DATETIME | 
| BIGDATETIME | DATETIME(6) | 
| SMALLDATETIME | DATETIME | 
| DATE | DATE | 
| TIME | TIME | 
| BIGTIME | TIME | 
| CHAR | STRING | 
| UNICHAR | WSTRING | 
| NCHAR | WSTRING | 
| VARCHAR | STRING | 
| UNIVARCHAR | WSTRING | 
| NVARCHAR | WSTRING | 
| BINARY | BYTES | 
| VARBINARY | BYTES | 
| BIT | BOOLEAN | 
| TEXT | CLOB | 
| UNITEXT | NCLOB | 
| IMAGE | BLOB | 

# Usare MongoDB come fonte per AWS DMS
<a name="CHAP_Source.MongoDB"></a>

 Per informazioni sulle versioni di MongoDB AWS DMS supportate come sorgente, consulta. [Fonti per AWS DMS](CHAP_Introduction.Sources.md) 

Tieni presente quanto segue in relazione al supporto delle versioni di MongoDB:
+ Le versioni AWS DMS 3.4.5 e successive supportano le versioni di MongoDB 4.2 e 4.4. 
+ Le versioni AWS DMS 3.4.5 e successive e le versioni di MongoDB 4.2 e successive supportano le transazioni distribuite. Per ulteriori informazioni sulle transazioni distribuite MongoDB, consulta [Transactions](https://docs.mongodb.com/manual/core/transactions/) nella [documentazione di MongoDB.](https://www.mongodb.com/docs/)
+ Le versioni AWS DMS 3.5.0 e successive non supportano le versioni di MongoDB precedenti alla 3.6.
+ Le versioni AWS DMS 3.5.1 e successive supportano la versione 5.0 di MongoDB.
+ Le versioni AWS DMS 3.5.2 e successive supportano la versione 6.0 di MongoDB.
+ Le versioni AWS DMS 3.5.4 e successive supportano le versioni 7.0 e 8.0 di MongoDB.



Se non conosci MongoDB, è necessario avere familiarità con i seguenti importanti concetti del database MongoDB: 
+ Un record in MongoDB è un *documento* che è una struttura di dati costituita da coppie di campi e di valori. Il valore di un campo può includere altri documenti, matrici e matrici di documenti. Un documento è approssimativamente equivalente a una riga di una tabella di database relazionali.
+ Una *raccolta* in MongoDB è un gruppo di documenti ed è approssimativamente equivalente a una tabella di database relazionale.
+ Un *database* in MongoDB è un set di raccolte ed è approssimativamente equivalente a uno schema di database relazionale.
+ Internamente, un documento MongoDB viene memorizzato come un file JSON binario (BSON) in un formato compresso che include un tipo per ogni campo del documento. Ogni documento ha un ID univoco.

AWS DMS *supporta due modalità di migrazione quando si utilizza MongoDB come sorgente*, la modalità Document* o la modalità Table.* È possibile specificare la modalità di migrazione da utilizzare quando si crea l'endpoint MongoDB o impostando il parametro **Modalità metadati** dalla console AWS DMS . Facoltativamente, puoi creare una seconda colonna denominata `_id` che funge da chiave primaria selezionando il pulsante con il segno di spunta per **\$1id come colonna separata** nel pannello di configurazione dell'endpoint. 

La scelta della modalità di migrazione influenza il formato risultante dei dati di destinazione come descritto di seguito. 

**Modalità documento**  
In modalità documento, il documento MongoDB viene migrato così com'è, vale a dire che i dati del documento vengono consolidati in una singola colonna denominata `_doc` in una tabella di destinazione. La modalità documento è l'impostazione predefinita quando si utilizza MongoDB come endpoint di origine.  
Ad esempio, considera i seguenti documenti in una raccolta MongoDB denominata myCollection.  

```
 db.myCollection.find()
{ "_id" : ObjectId("5a94815f40bd44d1b02bdfe0"), "a" : 1, "b" : 2, "c" : 3 }
{ "_id" : ObjectId("5a94815f40bd44d1b02bdfe1"), "a" : 4, "b" : 5, "c" : 6 }
```
Una volta completata la migrazione dei dati a una tabella di database relazionale utilizzando la modalità documento, i dati vengono strutturati come segue. I campi dei dati nel documento MongoDB sono consolidati nella colonna` _doc`.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.MongoDB.html)
Puoi impostare facoltativamente l'attributo di connessione aggiuntivo `extractDocID` su *true* per creare una seconda colonna denominata `"_id"` che agisca come chiave primaria. Se prevedi di utilizzare CDC, imposta questo parametro su *true*.  
*Quando si utilizza CDC con fonti che producono [transazioni con più documenti](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), il `ExtractDocId` parametro **deve essere** impostato su true.* Se questo parametro non è abilitato, l' AWS DMS operazione avrà esito negativo quando rileva una transazione con più documenti.  
In modalità documento, AWS DMS gestisce la creazione e la ridenominazione di raccolte in questo modo:  
+ Se aggiungi una nuova raccolta al database di origine, AWS DMS crea una nuova tabella di destinazione per la raccolta e replica tutti i documenti. 
+ Se rinomini una raccolta esistente nel database di origine, AWS DMS non rinomina la tabella di destinazione. 
Se l'endpoint di destinazione è Amazon DocumentDB, esegui la migrazione in **modalità documento**.

**Modalità tabella**  
In modalità tabella, AWS DMS trasforma ogni campo di primo livello in un documento MongoDB in una colonna nella tabella di destinazione. Se un campo è nidificato, AWS DMS appiattisce i valori nidificati in una singola colonna. AWS DMS quindi aggiunge un campo chiave e i tipi di dati al set di colonne della tabella di destinazione.   
Per ogni documento MongoDB AWS DMS , aggiunge ogni chiave e tipo al set di colonne della tabella di destinazione. Ad esempio, utilizzando la modalità tabella, AWS DMS migra l'esempio precedente nella tabella seguente.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.MongoDB.html)
I valori nidificati sono appiattiti in una colonna contenente nomi di chiavi separati da punti. La colonna è denominata dalla concatenazione dei nomi di campo appiattiti separati da punti. Ad esempio, AWS DMS migra un documento JSON con un campo di valori annidati, ad esempio in una colonna `{"a" : {"b" : {"c": 1}}}` denominata `a.b.c.`  
Per creare le colonne di destinazione, AWS DMS analizza un numero specificato di documenti MongoDB e crea un set di tutti i campi e i relativi tipi. AWS DMS quindi utilizza questo set per creare le colonne della tabella di destinazione. Se crei o modifichi l'endpoint di origine di MongoDB utilizzando la console, è possibile specificare il numero di documenti per la scansione. Il valore predefinito è 1000 documenti. Se si utilizza il AWS CLI, è possibile utilizzare l'attributo di connessione extra`docsToInvestigate`.  
In modalità tabella, AWS DMS gestisce documenti e raccolte in questo modo:  
+ Quando aggiungi un documento in una raccolta esistente, il documento viene replicato. Se ci sono campi che non esistono nella destinazione, tali campi non vengono replicati.
+ Quando aggiorni un documento, il documento aggiornato viene replicato. Se ci sono campi che non esistono nella destinazione, tali campi non vengono replicati.
+ L'eliminazione di un documento è supportata integralmente.
+ L'aggiunta di una nuova raccolta non ha come risultato una nuova tabella nella destinazione durante un'attività CDC.
+ Nella fase Change Data Capture (CDC), AWS DMS non supporta la ridenominazione di una raccolta.

**Topics**
+ [Autorizzazioni necessarie quando si utilizza MongoDB come fonte per AWS DMS](#CHAP_Source.MongoDB.PrerequisitesCDC)
+ [Configurazione di un set di repliche MongoDB per CDC](#CHAP_Source.MongoDB.PrerequisitesCDC.ReplicaSet)
+ [Requisiti di sicurezza per l'utilizzo di MongoDB come fonte per AWS DMS](#CHAP_Source.MongoDB.Security)
+ [Segmentazione delle raccolte MongoDB e migrazione in parallelo](#CHAP_Source.MongoDB.ParallelLoad)
+ [Migrazione di più database quando si utilizza MongoDB come fonte per AWS DMS](#CHAP_Source.MongoDB.Multidatabase)
+ [Limitazioni nell'utilizzo di MongoDB come fonte per AWS DMS](#CHAP_Source.MongoDB.Limitations)
+ [Impostazioni di configurazione degli endpoint quando si utilizza MongoDB come fonte per AWS DMS](#CHAP_Source.MongoDB.Configuration)
+ [Tipi di dati di origine per MongoDB](#CHAP_Source.MongoDB.DataTypes)

## Autorizzazioni necessarie quando si utilizza MongoDB come fonte per AWS DMS
<a name="CHAP_Source.MongoDB.PrerequisitesCDC"></a>

Per una AWS DMS migrazione con una fonte MongoDB, puoi creare un account utente con privilegi di root o un utente con autorizzazioni solo sul database da migrare. 

Il codice seguente crea un utente come account root.

```
use admin
db.createUser(
  {
    user: "root",
    pwd: "password",
    roles: [ { role: "root", db: "admin" } ]
  }
)
```

Per un'origine MongoDB 3.x, il codice seguente crea un utente con privilegi minimi sul database da migrare.

```
use database_to_migrate
db.createUser( 
{ 
    user: "dms-user",
    pwd: "password",
    roles: [ { role: "read", db: "local" }, "read"] 
})
```

Per un'origine MongoDB 4.x, il codice seguente crea un utente con privilegi minimi.

```
{ resource: { db: "", collection: "" }, actions: [ "find", "changeStream" ] }
```

Ad esempio, crea il seguente ruolo nel database "admin".

```
use admin
db.createRole(
{
role: "changestreamrole",
privileges: [
{ resource: { db: "", collection: "" }, actions: [ "find","changeStream" ] }
],
roles: []
}
)
```

Una volta creato il ruolo, crea un utente nel database da migrare.

```
 use test
> db.createUser( 
{ 
user: "dms-user12345",
pwd: "password",
roles: [ { role: "changestreamrole", db: "admin" }, "read"] 
})
```

## Configurazione di un set di repliche MongoDB per CDC
<a name="CHAP_Source.MongoDB.PrerequisitesCDC.ReplicaSet"></a>

Per utilizzare la replica continua o CDC con MongoDB, è necessario l' AWS DMS accesso al registro delle operazioni di MongoDB (oplog). Per creare l'oplog, devi distribuire un set di repliche se non esiste già. Per ulteriori informazioni, consulta la [ documentazione di MongoDB](https://docs.mongodb.com/manual/tutorial/deploy-replica-set/).

Puoi utilizzare il CDC con il nodo primario o secondario di un set di repliche MongoDB come endpoint di origine.

**Per convertire un'istanza autonoma in un set di repliche**

1. Utilizzando la riga di comando, collegati a `mongo`.

   ```
   mongo localhost
   ```

1. Arresta il servizio `mongod`.

   ```
   service mongod stop
   ```

1. Riavvia `mongod` utilizzando il seguente comando:

   ```
   mongod --replSet "rs0" --auth -port port_number
   ```

1. Verifica la connessione al set di repliche utilizzando i comandi seguenti:

   ```
   mongo -u root -p password --host rs0/localhost:port_number 
     --authenticationDatabase "admin"
   ```

Se prevedi di eseguire una migrazione in modalità documento, seleziona l'opzione `_id as a separate column` quando crei l'endpoint di MongoDB. Se selezioni questa opzione, viene creata una seconda colonna denominata `_id` che agisce come chiave primaria. Questa seconda colonna è necessaria per supportare le operazioni DML (Data Manipulation AWS DMS Language).

**Nota**  
AWS DMS utilizza il registro delle operazioni (oplog) per acquisire le modifiche durante la replica in corso. Se MongoDB elimina i record dall'oplog AWS DMS prima di leggerli, le tue attività falliranno. Ti consigliamo di dimensionare l'oplog in modo da mantenere le modifiche per almeno 24 ore. 

## Requisiti di sicurezza per l'utilizzo di MongoDB come fonte per AWS DMS
<a name="CHAP_Source.MongoDB.Security"></a>

AWS DMS supporta due metodi di autenticazione per MongoDB. I due metodi di autenticazione vengono utilizzati per crittografare la password, in modo che vengano utilizzati solo quando il parametro `authType` è impostato su *PASSWORD*.

I metodi autenticazione di MongoDB sono i seguenti:
+ **MONGODB-CR**: per la compatibilità con le versioni precedenti
+ **SCRAM-SHA-1**: l'impostazione predefinita quando si utilizza MongoDB versione 3.x e 4.0

Se non viene specificato un metodo di autenticazione, AWS DMS utilizza il metodo predefinito per la versione del sorgente MongoDB.

## Segmentazione delle raccolte MongoDB e migrazione in parallelo
<a name="CHAP_Source.MongoDB.ParallelLoad"></a>

Per migliorare le prestazioni di un'attività di migrazione, gli endpoint di origine MongoDB supportano due opzioni per il pieno carico parallelo nella mappatura delle tabelle. 

In altre parole, è possibile migrare una raccolta in parallelo utilizzando la segmentazione automatica o la segmentazione degli intervalli con la mappatura delle tabelle per il pieno carico parallelo nelle impostazioni JSON. Con la segmentazione automatica, puoi specificare i criteri per AWS DMS segmentare automaticamente la fonte per la migrazione in ogni thread. Con la segmentazione degli intervalli, puoi indicare AWS DMS l'intervallo specifico di ogni segmento che DMS deve migrare in ogni thread. Per ulteriori informazioni su queste impostazioni, consulta [Regole e operazioni delle impostazioni di tabella e raccolta](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md).

### Migrazione di un database MongoDB in parallelo utilizzando gli intervalli di segmentazione automatica
<a name="CHAP_Source.MongoDB.ParallelLoad.AutoPartitioned"></a>

Puoi migrare i tuoi documenti in parallelo specificando i criteri che AWS DMS utilizza per partizionare (segmentare) automaticamente i dati per ogni thread. In particolare, si specifica il numero di documenti da migrare per thread. Utilizzando questo approccio, AWS DMS tenta di ottimizzare i confini dei segmenti per ottenere le massime prestazioni per thread.

È possibile specificare i criteri di segmentazione utilizzando le opzioni di impostazione della tabella riportate di seguito nella mappatura delle tabelle.


|  Opzione delle impostazioni della tabella  |  Description  | 
| --- | --- | 
|  `"type"`  |  (Obbligatoria) Impostata su `"partitions-auto"` per MongoDB come origine.  | 
|  `"number-of-partitions"`  |  (Facoltativa) Numero totale di partizioni (segmenti) utilizzate per la migrazione. Il valore predefinito è 16.  | 
|  `"collection-count-from-metadata"`  |  (Facoltativa) Se questa opzione è impostata su `true`, AWS DMS utilizza un conteggio di raccolte stimato per determinare il numero di partizioni. Se questa opzione è impostata su`false`, AWS DMS utilizza il conteggio effettivo delle raccolte. Il valore predefinito è `true`.  | 
|  `"max-records-skip-per-page"`  |  (Facoltativo) Il numero di record da saltare contemporaneamente quando si determinano i limiti di ogni partizione. AWS DMS utilizza un approccio di salto impaginato per determinare il limite minimo per una partizione. Il valore predefinito è 10.000.  L'impostazione di un valore relativamente elevato può causare timeout del cursore e errori delle attività. L'impostazione di un valore relativamente basso comporta un numero maggiore di operazioni per pagina e un pieno carico più lento.   | 
|  `"batch-size"`  |  (Facoltativa) Limita il numero di documenti restituiti in un batch. Ogni batch richiede un round trip al server. Se la dimensione del batch è zero (0), il cursore utilizza la dimensione massima del batch definita dal server. Il valore predefinito è 0.  | 

L'esempio seguente mostra una mappatura delle tabelle per la segmentazione automatica.

```
{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "admin",
                "table-name": "departments"
            },
            "rule-action": "include",
            "filters": []
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "admin",
                "table-name": "departments"
            },
            "parallel-load": {
                "type": "partitions-auto",
                "number-of-partitions": 5,
                "collection-count-from-metadata": "true",
                "max-records-skip-per-page": 1000000,
                "batch-size": 50000
            }
        }
    ]
}
```

La segmentazione automatica presenta le seguenti limitazioni. La migrazione di ogni segmento recupera separatamente il conteggio di raccolte e il valore `_id` minimo della raccolta. Quindi utilizza l'approccio per ignorare con impaginazione per calcolare il limite minimo del segmento. 

Pertanto, assicurati che il valore `_id` minimo di ogni raccolta rimanga costante fino al calcolo di tutti i limiti del segmento della raccolta. La modifica del valore `_id` minimo di una raccolta durante il calcolo dei limiti del segmento può causare la perdita di dati o errori di riga duplicata.

### Migrazione di un database MongoDB in parallelo utilizzando la segmentazione degli intervalli
<a name="CHAP_Source.MongoDB.ParallelLoad.Ranges"></a>

Puoi migrare i documenti in parallelo specificando gli intervalli per ogni segmento di un thread. Utilizzando questo approccio, si dice AWS DMS ai documenti specifici di migrare in ogni thread in base alla scelta degli intervalli di documenti per thread.

L'immagine seguente mostra una raccolta MongoDB con sette elementi e `_id` come chiave primaria.

![\[Raccolta MongoDB con sette elementi.\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-docdb-collection.png)


Per suddividere la raccolta in tre segmenti specifici AWS DMS da migrare in parallelo, puoi aggiungere regole di mappatura delle tabelle all'attività di migrazione. Questo approccio è mostrato nel seguente esempio JSON.

```
{ // Task table mappings:
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "1",
      "object-locator": {
        "schema-name": "testdatabase",
        "table-name": "testtable"
      },
      "rule-action": "include"
    }, // "selection" :"rule-type"
    {
      "rule-type": "table-settings",
      "rule-id": "2",
      "rule-name": "2",
      "object-locator": {
        "schema-name": "testdatabase",
        "table-name": "testtable"
      },
      "parallel-load": {
        "type": "ranges",
        "columns": [
           "_id",
           "num"
        ],
        "boundaries": [
          // First segment selects documents with _id less-than-or-equal-to 5f805c97873173399a278d79
          // and num less-than-or-equal-to 2.
          [
             "5f805c97873173399a278d79",
             "2"
          ],
          // Second segment selects documents with _id > 5f805c97873173399a278d79 and
          // _id less-than-or-equal-to 5f805cc5873173399a278d7c and
          // num > 2 and num less-than-or-equal-to 5.
          [
             "5f805cc5873173399a278d7c",
             "5"
          ]                                   
          // Third segment is implied and selects documents with _id > 5f805cc5873173399a278d7c.
        ] // :"boundaries"
      } // :"parallel-load"
    } // "table-settings" :"rule-type"
  ] // :"rules"
} // :Task table mappings
```

Questa definizione di mappatura delle tabelle divide la raccolta di origine in tre segmenti ed esegue la migrazione in parallelo. Di seguito sono riportati i limiti della segmentazione.

```
Data with _id less-than-or-equal-to "5f805c97873173399a278d79" and num less-than-or-equal-to 2 (2 records)
Data with _id > "5f805c97873173399a278d79" and num > 2 and _id  less-than-or-equal-to "5f805cc5873173399a278d7c" and num less-than-or-equal-to 5 (3 records)
Data with _id > "5f805cc5873173399a278d7c" and num > 5 (2 records)
```

Una volta completata l'attività di migrazione, è possibile verificare nei log delle attività che le tabelle siano state caricate in parallelo, come illustrato nell'esempio seguente. Puoi anche verificare la clausola `find` MongoDB utilizzata per scaricare ogni segmento dalla tabella di origine.

```
[TASK_MANAGER    ] I:  Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86  (replicationtask_util.c:752)

[SOURCE_UNLOAD   ] I:  Range Segmentation filter for Segment #0 is initialized.   (mongodb_unload.c:157)

[SOURCE_UNLOAD   ] I:  Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } }  (mongodb_unload.c:328)

[SOURCE_UNLOAD   ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent.

[TASK_MANAGER    ] I: Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86 (replicationtask_util.c:752)
 
[SOURCE_UNLOAD   ] I: Range Segmentation filter for Segment #0 is initialized. (mongodb_unload.c:157) 

[SOURCE_UNLOAD   ] I: Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } } (mongodb_unload.c:328)
 
[SOURCE_UNLOAD   ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent.

[TARGET_LOAD     ] I: Load finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 1 rows received. 0 rows skipped. Volume transfered 480.

[TASK_MANAGER    ] I: Load finished for segment #1 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. 2 records transferred.
```

Attualmente, AWS DMS supporta i seguenti tipi di dati MongoDB come colonna chiave del segmento:
+ Double
+ Stringa
+ ObjectId
+ Intero a 32 bit
+ Intero a 64 bit

## Migrazione di più database quando si utilizza MongoDB come fonte per AWS DMS
<a name="CHAP_Source.MongoDB.Multidatabase"></a>

AWS DMS le versioni 3.4.5 e successive supportano la migrazione di più database in un'unica attività per tutte le versioni di MongoDB supportate. Se desideri migrare più database, procedi nel modo seguente:

1. Quando crei l'endpoint di origine MongoDB, esegui una delle seguenti operazioni:
   + Nella pagina **Crea endpoint** della console DMS, assicurati che il campo **Nome del database** sia vuoto nella sezione **Configurazione dell'endpoint**.
   + Utilizzando il AWS CLI `CreateEndpoint` comando, assegnate un valore di stringa vuoto al parametro in. `DatabaseName` `MongoDBSettings`

1. Per ogni database che desideri migrare da un'origine MongoDB, specifica il nome del database come nome dello schema nella mappatura della tabella per l'attività. Puoi farlo utilizzando l'input guidato nella console o direttamente in JSON. Per ulteriori informazioni sull'input guidato, consulta [Specifica della selezione delle tabelle e delle regole di trasformazione dalla console](CHAP_Tasks.CustomizingTasks.TableMapping.Console.md). Per ulteriori informazioni sul JSON, consulta [Operazioni e regole di selezione](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md).

Ad esempio, puoi specificare il codice JSON seguente per migrare tre database MongoDB.

**Example Migrazione di tutte le tabelle in uno schema**  
Il codice JSON seguente esegue la migrazione di tutte le tabelle dai database `Customers`, `Orders` e `Suppliers` dell'endpoint di origine all'endpoint di destinazione.  

```
{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "Customers",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        },
        {
            "rule-type": "selection",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "Orders",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        },
        {
            "rule-type": "selection",
            "rule-id": "3",
            "rule-name": "3",
            "object-locator": {
                "schema-name": "Inventory",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        }
    ]
}
```

## Limitazioni nell'utilizzo di MongoDB come fonte per AWS DMS
<a name="CHAP_Source.MongoDB.Limitations"></a>

Di seguito sono riportate le limitazioni relative all'utilizzo di MongoDB come fonte per: AWS DMS
+ In modalità tabella, i documenti di una raccolta devono essere coerenti nel tipo di dati utilizzato per il valore nello stesso campo. Ad esempio, se il documento di una raccolta include `'{ a:{ b:value ... }'`, tutti i documenti della raccolta che fanno riferimento a `value` del campo `a.b` devono utilizzare lo stesso tipo di dati per `value`, ovunque appaia nella raccolta.
+ Quando l'opzione `_id` è impostata come una colonna separata, la stringa ID non deve superare i 200 caratteri.
+ L'ID oggetto e le chiavi del tipo di matrice vengono convertiti in colonne con prefisso `oid` e `array` in modalità tabella.

  Internamente, viene fatto riferimento a queste colonne con i nomi con prefisso. Se utilizzi regole di trasformazione AWS DMS che fanno riferimento a queste colonne, assicurati di specificare la colonna con prefisso. Ad esempio, devi specificare `${oid__id}` e non `${_id}`, oppure `${array__addresses}` e non `${_addresses}`. 
+  I nomi delle raccolte e delle chiavi non possono includere il simbolo del dollaro (\$1). 
+ AWS DMS non supporta raccolte contenenti lo stesso campo con lettere maiuscole e minuscole diverse (maiuscole, minuscole) in modalità tabella con destinazione RDBMS. Ad esempio, non AWS DMS supporta la presenza di due raccolte `Field1` denominate e. `field1` 
+ La modalità tabella e la modalità documento presentano le limitazioni illustrate in precedenza.
+ La migrazione in parallelo utilizzando la segmentazione automatica comporta le limitazioni descritte in precedenza.
+ I filtri di origine non sono supportati per MongoDB.
+ AWS DMS non supporta documenti in cui il livello di nidificazione è maggiore di 97.
+ AWS DMS richiede dati di origine con codifica UTF-8 durante la migrazione verso destinazioni non DocumentDB. Per le sorgenti con caratteri non UTF-8, convertile in UTF-8 prima della migrazione o esegui invece la migrazione ad Amazon DocumentDB.
+ AWS DMS non supporta le seguenti funzionalità della versione 5.0 di MongoDB:
  + Ripartizionamento live
  + Crittografia a livello di campo lato client
  + Migrazione della raccolta di serie temporali
**Nota**  
Una raccolta di serie temporali migrata nella fase di pieno carico viene convertita in una normale raccolta in Amazon DocumentDB perché DocumentDB non supporta le raccolte di serie temporali.

## Impostazioni di configurazione degli endpoint quando si utilizza MongoDB come fonte per AWS DMS
<a name="CHAP_Source.MongoDB.Configuration"></a>

Quando configuri il tuo endpoint sorgente MongoDB, puoi specificare più impostazioni di configurazione dell'endpoint utilizzando la console. AWS DMS 

La tabella seguente descrive le impostazioni di configurazione disponibili quando si utilizzano i database MongoDB come origine. AWS DMS 


| Impostazione (attributo) | Valori validi | Valore predefinito e descrizione | 
| --- | --- | --- | 
|  **Modalità di autenticazione**  |  `"none"` `"password"`  |  Il valore `"password"` richiede un nome utente e una password. Quando si specifica `"none"`, i parametri nome utente e password non vengono utilizzati.  | 
|  **Origine di autenticazione**  |  Un nome di database MongoDB valido.  |  Il nome del database MongoDB che desideri utilizzare per convalidare le credenziali di autenticazione. Il valore predefinito è `"admin"`.   | 
|  **Meccanismo di autenticazione**  |  `"default"` `"mongodb_cr"` `"scram_sha_1"`  |  Il meccanismo di autenticazione. Il valore di ` "default"` è `"scram_sha_1"`. Questa impostazione non viene utilizzata quando `authType` è impostato su `"no"`.  | 
|  **Modalità metadati**  |  Documento e tabella  |  Scegli la modalità documento o la modalità tabella.   | 
|  **Numero di documenti da analizzare** (`docsToInvestigate`)  |  Un numero intero positivo maggiore di `0`.  |  Utilizza questa opzione in modalità tabella solo per specificare la definizione della tabella di destinazione.  | 
|  **\$1id come colonna separata**  |  Segno di spunta nella casella  |  Casella di spunta facoltativa che crea una seconda colonna denominata `_id` che agisce come chiave primaria.  | 
|   `ExtractDocID`   |  `true` `false`  |  `false`: utilizza questo attributo quando `NestingLevel` è impostato su `"none"`.  Quando si utilizza CDC con fonti che producono [transazioni con più documenti](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), il `ExtractDocId` parametro **deve essere** impostato su. `true` Se questo parametro non è abilitato, l' AWS DMS operazione avrà esito negativo quando rileva una transazione con più documenti.  | 
|  `socketTimeoutMS`  |  Un numero intero maggiore o uguale a 0. Solo attributo aggiuntivo di connessione.  |  Questa impostazione è espressa in millisecondi e configura il timeout di connessione per i client MongoDB. Se il valore è minore o uguale a zero, viene utilizzato il client MongoDB predefinito.  | 
|   `UseUpdateLookUp`   |  `true` `false`  |  Se impostato su true, durante gli eventi di aggiornamento del CDC, AWS DMS copia l'intero documento aggiornato nella destinazione. Se impostato su false, AWS DMS utilizza il comando MongoDB update per aggiornare solo i campi modificati nel documento sulla destinazione.  | 
|   `ReplicateShardCollections`   |  `true` `false`  |  Se impostato su true, AWS DMS replica i dati in raccolte di frammenti. AWS DMS utilizza questa impostazione solo se l'endpoint di destinazione è un cluster elastico DocumentDB. Quando questa impostazione è true, è importante tenere presenti le seguenti informazioni: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.MongoDB.html)  | 
|  `useTransactionVerification`  |  `true` `false`  |  Quando`false`, disabilita la verifica tra il flusso di modifiche e gli oplogs.   È possibile che le operazioni non vengano eseguite se si verificano discrepanze tra i flussi di modifica e le voci degli oplog, poiché il comportamento predefinito del DMS prevede il fallimento dell'operazione in tali scenari. Default: `true`.   | 
|  `useOplog`  |  `true` `false`  |  When`true`, consente all'attività DMS di leggere direttamente da 'oplog' anziché utilizzare il flusso di modifiche. Default: `false`.  | 

Se scegli **Documento** come **Modalità metadati**, sono disponibili diverse opzioni. 

Se l'endpoint di destinazione è DocumentDB, assicurati di eseguire la migrazione in **modalità documento**. Inoltre, modifica l'endpoint di origine e seleziona l'opzione **\$1id come colonna separata**. Questo è un prerequisito obbligatorio se il carico di lavoro MongoDB di origine include transazioni.

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

La migrazione dei dati che utilizza MongoDB come fonte AWS DMS supporta la maggior parte dei tipi di dati MongoDB. Nella tabella seguente, puoi trovare i tipi di dati di origine MongoDB supportati durante l' AWS DMS utilizzo e la AWS DMS mappatura predefinita dei tipi di dati. Per ulteriori informazioni sui tipi di dati MongoDB, consulta la sezione relativa ai [ tipi BSON](https://docs.mongodb.com/manual/reference/bson-types) nella documentazione di MongoDB.

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 MongoDB  |  AWS DMS tipi di dati  | 
| --- | --- | 
| Booleano | Bool | 
| Binario | BLOB | 
| Data | Data | 
| Timestamp | Data | 
| Int | INT4 | 
| Long | INT8 | 
| Double | REAL8 | 
| String (UTF-8) | CLOB | 
| Array | CLOB | 
| OID | Stringa | 
| REGEX | CLOB | 
| CODE | CLOB | 

# Utilizzo di Amazon DocumentDB (con compatibilità con MongoDB) come fonte per AWS DMS
<a name="CHAP_Source.DocumentDB"></a>

Per informazioni sulle versioni di Amazon DocumentDB (compatibile con MongoDB) supportate da AWS DMS come origine, consulta [Fonti per AWS DMS](CHAP_Introduction.Sources.md).

 Con Amazon DocumentDB utilizzato come origine, puoi migrare i dati da un cluster Amazon DocumentDB a un altro cluster Amazon DocumentDB. Puoi anche migrare i dati da un cluster Amazon DocumentDB a uno degli altri endpoint di destinazione supportati da. AWS DMS

Se non hai familiarità con Amazon DocumentDB, tieni presente i seguenti concetti importanti sui database Amazon DocumentDB:
+ Un record in Amazon DocumentDB è un *documento*, ossia una struttura di dati costituita da coppie di campi e valori. Il valore di un campo può includere altri documenti, matrici e matrici di documenti. Un documento è approssimativamente equivalente a una riga di una tabella di database relazionali.
+ Una *raccolta* in Amazon DocumentDB è un gruppo di documenti ed è approssimativamente equivalente alla tabella di un database relazionale.
+ Un *database* in Amazon DocumentDB è un insieme di raccolte ed è più o meno equivalente allo schema di un database relazionale.

AWS DMS supporta due modalità di migrazione quando si utilizza Amazon DocumentDB come sorgente, modalità documento e modalità tabella. Specifichi la modalità di migrazione quando crei l'endpoint di origine Amazon DocumentDB nella AWS DMS console, utilizzando l'opzione **Metadata mode** o l'attributo di connessione extra. `nestingLevel` Di seguito è riportata la spiegazione di come la scelta della modalità di migrazione influenza il formato risultante dei dati di destinazione.

**Modalità documento**  
Con la *modalità documento*, il documento JSON viene migrato così com'è. Ciò significa che i dati del documento vengono consolidati in uno dei due elementi. Quando utilizzi un database relazionale come destinazione, i dati sono costituiti da una singola colonna denominata `_doc` in una tabella di destinazione. Quando utilizzi un database non relazionale come destinazione, i dati sono costituiti da un singolo documento JSON. La modalità documento è quella predefinita, consigliata per la migrazione a una destinazione di Amazon DocumentDB.  
Considera, ad esempio, i seguenti documenti in una raccolta Amazon DocumentDB denominata `myCollection`.  

```
 db.myCollection.find()
{ "_id" : ObjectId("5a94815f40bd44d1b02bdfe0"), "a" : 1, "b" : 2, "c" : 3 }
{ "_id" : ObjectId("5a94815f40bd44d1b02bdfe1"), "a" : 4, "b" : 5, "c" : 6 }
```
Una volta completata la migrazione dei dati a una tabella di database relazionale utilizzando la modalità documento, i dati vengono strutturati come segue. I campi dei dati nel documento sono consolidati nella colonna ` _doc`.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.DocumentDB.html)
Puoi impostare facoltativamente l'attributo aggiuntivo di connessione `extractDocID` su `true` per creare una seconda colonna denominata `"_id"` che agisca come chiave primaria. Se intendi utilizzare l'acquisizione dei dati di modifica (CDC), imposta questo parametro su `true` tranne quando utilizzi Amazon DocumentDB come destinazione.  
**Quando si utilizza CDC con fonti che producono [transazioni con più documenti](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), il `ExtractDocId` parametro deve essere impostato su.** `true` Se questo parametro non è abilitato, l' AWS DMS operazione avrà esito negativo quando rileva una transazione con più documenti.  
Se aggiungete una nuova raccolta al database di origine, AWS DMS crea una nuova tabella di destinazione per la raccolta e replica tutti i documenti. 

**Modalità tabella**  
In *modalità tabella *AWS DMS trasforma ogni campo di primo livello di un documento Amazon DocumentDB in una colonna nella tabella di destinazione. Se un campo è nidificato, AWS DMS appiattisce i valori nidificati in un'unica colonna. AWS DMS quindi aggiunge un campo chiave e i tipi di dati al set di colonne della tabella di destinazione.   
Per ogni documento Amazon DocumentDB, AWS DMS aggiunge ogni chiave e tipo al set di colonne della tabella di destinazione. Ad esempio, utilizzando la modalità tabella, AWS DMS migra l'esempio precedente nella tabella seguente.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.DocumentDB.html)
I valori nidificati sono appiattiti in una colonna contenente nomi di chiavi separati da punti. La colonna viene denominata usando la concatenazione dei nomi di campo appiattiti separati da punti. Ad esempio, AWS DMS migra un documento JSON con un campo di valori annidati, ad esempio in una colonna `{"a" : {"b" : {"c": 1}}}` denominata `a.b.c.`  
Per creare le colonne di destinazione, AWS DMS analizza un numero specificato di documenti Amazon DocumentDB e crea un set di tutti i campi e i relativi tipi. AWS DMS utilizza quindi questo set per creare le colonne della tabella di destinazione. Se crei o modifichi l'endpoint di origine di Amazon DocumentDB utilizzando la console, è possibile specificare il numero di documenti per la scansione. Il valore predefinito è 1.000 documenti. Se si utilizza il AWS CLI, è possibile utilizzare l'attributo di connessione extra`docsToInvestigate`.  
In modalità tabella, AWS DMS gestisce documenti e raccolte in questo modo:  
+ Quando aggiungi un documento in una raccolta esistente, il documento viene replicato. Se ci sono campi che non esistono nella destinazione, tali campi non vengono replicati.
+ Quando aggiorni un documento, il documento aggiornato viene replicato. Se ci sono campi che non esistono nella destinazione, tali campi non vengono replicati.
+ L'eliminazione di un documento è supportata integralmente.
+ L'aggiunta di una nuova raccolta non ha come risultato una nuova tabella nella destinazione durante un'attività CDC.
+ Nella fase Change Data Capture (CDC), AWS DMS non supporta la ridenominazione di una raccolta.

**Topics**
+ [Impostazione delle autorizzazioni per utilizzare Amazon DocumentDB come origine](#CHAP_Source.DocumentDB.Permissions)
+ [Configurazione della CDC per un cluster Amazon DocumentDB](#CHAP_Source.DocumentDB.ConfigureCDC)
+ [Connessione ad Amazon DocumentDB tramite TLS](#CHAP_Source.DocumentDB.TLS)
+ [Creazione di un endpoint di origine Amazon DocumentDB](#CHAP_Source.DocumentDB.ConfigureEndpoint)
+ [Segmentazione delle raccolte Amazon DocumentDB e migrazione in parallelo](#CHAP_Source.DocumentDB.ParallelLoad)
+ [Migrazione di più database quando si utilizza Amazon DocumentDB come origine per AWS DMS](#CHAP_Source.DocumentDB.Multidatabase)
+ [Limitazioni nell'utilizzo di Amazon DocumentDB come fonte per AWS DMS](#CHAP_Source.DocumentDB.Limitations)
+ [Utilizzo delle impostazioni degli endpoint con Amazon DocumentDB come origine](#CHAP_Source.DocumentDB.ECAs)
+ [Tipi di dati di origine per Amazon DocumentDB](#CHAP_Source.DocumentDB.DataTypes)

## Impostazione delle autorizzazioni per utilizzare Amazon DocumentDB come origine
<a name="CHAP_Source.DocumentDB.Permissions"></a>

Quando si utilizza il codice sorgente Amazon DocumentDB per una AWS DMS migrazione, è possibile creare un account utente con privilegi di root. In alternativa puoi creare un utente con le autorizzazioni solo per il database da migrare. 

Il codice seguente crea un utente come account root.

```
use admin
db.createUser(
  {
    user: "root",
    pwd: "password",
    roles: [ { role: "root", db: "admin" } ]
  })
```

Per Amazon DocumentDB 3.6, il codice seguente crea un utente con privilegi minimi sul database da migrare.

```
use db_name
db.createUser( 
    {
        user: "dms-user",
        pwd: "password",
        roles: [{ role: "read", db: "db_name" }]
    }
)
```

Per Amazon DocumentDB 4.0 e versioni successive, AWS DMS utilizza un flusso di modifiche a livello di distribuzione. In questo caso, il codice seguente crea un utente con privilegi minimi.

```
db.createUser( 
{ 
    user: "dms-user",
    pwd: "password",
    roles: [ { role: "readAnyDatabase", db: "admin" }] 
})
```

## Configurazione della CDC per un cluster Amazon DocumentDB
<a name="CHAP_Source.DocumentDB.ConfigureCDC"></a>

Per utilizzare la replica continua o CDC con Amazon DocumentDB AWS DMS , è necessario l'accesso ai flussi di modifica del cluster Amazon DocumentDB. Per una descrizione della sequenza temporale degli eventi di aggiornamento nelle raccolte e nei database del cluster, consulta [Using change streams](https://docs.aws.amazon.com/documentdb/latest/developerguide/change_streams.html) nella *Guida per gli sviluppatori di Amazon DocumentDB*. 

Effettua l'autenticazione al cluster Amazon DocumentDB utilizzando la shell (interprete di comandi) MongoDB. Quindi, esegui il comando seguente per abilitare i flussi di modifica.

```
db.adminCommand({modifyChangeStreams: 1,
    database: "DB_NAME",
    collection: "", 
    enable: true});
```

Questo approccio consente l'uso del flusso di modifica per tutte le raccolte del database. Dopo aver abilitato i flussi di modifiche, puoi creare un'attività di migrazione che migra i dati esistenti e allo stesso tempo replica le modifiche in corso. AWS DMS continua ad acquisire e applicare le modifiche anche dopo il caricamento di grandi quantità di dati. I database di origine e di destinazione vengono sincronizzati con tempi di inattività per la migrazione quasi nulli.

**Nota**  
AWS DMS utilizza il registro delle operazioni (oplog) per acquisire le modifiche durante la replica in corso. Se Amazon DocumentDB elimina i record dall'oplog prima di AWS DMS leggerli, le attività avranno esito negativo. Ti consigliamo di dimensionare l'oplog in modo da mantenere le modifiche per almeno 24 ore.

## Connessione ad Amazon DocumentDB tramite TLS
<a name="CHAP_Source.DocumentDB.TLS"></a>

Per impostazione predefinita, un nuovo cluster Amazon DocumentDB creato accetta solo connessioni protette con Transport Layer Security (TLS). Quando TLS è abilitato, ogni connessione ad Amazon DocumentDB richiede una chiave pubblica.

Puoi recuperare la chiave pubblica per Amazon DocumentDB scaricando il `rds-combined-ca-bundle.pem` file da AWS un bucket Amazon S3 ospitato. Per ulteriori informazioni sul download di questo file, consulta [Encrypting connections using TLS](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html) nella *Guida per gli sviluppatori di Amazon DocumentDB.* 

Dopo aver scaricato il `rds-combined-ca-bundle.pem` file, puoi importare la chiave pubblica in cui è contenuto. AWS DMS Di seguito viene descritto come fare.

**Per importare la chiave pubblica utilizzando la AWS DMS console**

1. Accedi a Console di gestione AWS e scegli AWS DMS.

1. Nel riquadro di navigazione, scegliere **Certificates (Certificati)**.

1. Selezionare **Import certificate (Importa certificato)**. Viene visualizzata la pagina **Importa nuovo certificato CA**.

1. Nella sezione **Configurazione del certificato** effettua una delle seguenti operazioni:
   + Per **Identificatore del certificato** immetti un nome univoco per il certificato, ad esempio `docdb-cert`.
   + Seleziona **Scegli file**, vai alla posizione in cui hai salvato il file `rds-combined-ca-bundle.pem` e selezionalo.

1. Scegliere **Add new CA certificate (Aggiungi nuovo certificato emesso da una CA)**.

L'esempio AWS CLI seguente utilizza il AWS DMS `import-certificate` comando per importare il `rds-combined-ca-bundle.pem` file della chiave pubblica.

```
aws dms import-certificate \
    --certificate-identifier docdb-cert \
    --certificate-pem file://./rds-combined-ca-bundle.pem
```

## Creazione di un endpoint di origine Amazon DocumentDB
<a name="CHAP_Source.DocumentDB.ConfigureEndpoint"></a>

Puoi creare un endpoint di origine Amazon DocumentDB utilizzando la console o la AWS CLI. Usa la seguente procedura con la console.

**Per configurare un endpoint di origine Amazon DocumentDB utilizzando la console AWS DMS**

1. Accedi a Console di gestione AWS e scegli. AWS DMS

1. Nel riquadro di navigazione seleziona **Endpoint** e quindi scegli **Crea endpoint**.

1. Per **Identificativo endpoint** fornisci un nome che ti aiuti a identificarlo facilmente, ad esempio `docdb-source`.

1. Per **Motore di origine** scegli **Amazon DocumentDB (compatibile con MongoDB**).

1. Per **Nome del server** inserisci il nome del server in cui risiede l'endpoint del database Amazon DocumentDB. Ad esempio, puoi inserire il nome DNS pubblico della tua istanza Amazon EC2 `democluster.cluster-cjf6q8nxfefi.us-east-2.docdb.amazonaws.com`.

1. Per **Porta** immetti 27017.

1. Per **SSL mode (modalità SSL)**, scegliere **verify-full**. Se la modalità SSL è disabilitata sul cluster Amazon DocumentDB, puoi ignorare questo passaggio.

1. Per **Certificato CA** scegli il certificato Amazon DocumentDB `rds-combined-ca-bundle.pem`. Per le istruzioni sull'aggiunta di questo certificato, consulta [Connessione ad Amazon DocumentDB tramite TLS](#CHAP_Source.DocumentDB.TLS).

1. In **Nome del database** immetti il nome del database da migrare.

Utilizza la seguente procedura con la CLI.

**Per configurare un endpoint di origine Amazon DocumentDB utilizzando AWS CLI**
+ Esegui il AWS DMS `create-endpoint` comando seguente per configurare un endpoint sorgente Amazon DocumentDB, sostituendo i segnaposto con i tuoi valori.

  ```
  aws dms create-endpoint \
             --endpoint-identifier a_memorable_name \
             --endpoint-type source \
             --engine-name docdb \
             --username value \
             --password value \
             --server-name servername_where_database_endpoint_resides \
             --port 27017 \
             --database-name name_of_endpoint_database
  ```

## Segmentazione delle raccolte Amazon DocumentDB e migrazione in parallelo
<a name="CHAP_Source.DocumentDB.ParallelLoad"></a>

Per migliorare le prestazioni di un'attività di migrazione, gli endpoint di origine Amazon DocumentDB supportano due opzioni della funzionalità di caricamento parallelo completo nella mappatura delle tabelle. In altre parole, è possibile migrare una raccolta in parallelo utilizzando le opzioni di segmentazione automatica o segmentazione degli intervalli della mappatura delle tabelle per il caricamento parallelo completo nelle impostazioni JSON. Le opzioni di segmentazione automatica consentono di specificare i criteri per AWS DMS segmentare automaticamente la fonte per la migrazione in ogni thread. Le opzioni di segmentazione degli intervalli consentono di indicare AWS DMS l'intervallo specifico di ciascun segmento da migrare da DMS in ogni thread. Per ulteriori informazioni su queste impostazioni, consulta [Regole e operazioni delle impostazioni di tabella e raccolta](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md).

### Migrazione di un database Amazon DocumentDB in parallelo utilizzando intervalli di segmentazione automatica
<a name="CHAP_Source.DocumentDB.ParallelLoad.AutoPartitioned"></a>

Puoi migrare i tuoi documenti in parallelo specificando i criteri per partizionare ( AWS DMS segmentare) automaticamente i dati per ogni thread, in particolare il numero di documenti da migrare per thread. Utilizzando questo approccio, AWS DMS tenta di ottimizzare i limiti dei segmenti per ottenere le massime prestazioni per ogni thread.

È possibile specificare i criteri di segmentazione utilizzando le opzioni delle impostazioni della tabella riportate di seguito nella mappatura delle tabelle:


|  Opzione delle impostazioni della tabella  |  Description  | 
| --- | --- | 
|  `"type"`  |  (Obbligatoria) Impostato su `"partitions-auto"` per Amazon DocumentDB come origine.  | 
|  `"number-of-partitions"`  |  (Facoltativa) Numero totale di partizioni (segmenti) utilizzate per la migrazione. Il valore predefinito è 16.  | 
|  `"collection-count-from-metadata"`  |  (Facoltativo) Se impostato su`true`, AWS DMS utilizza un numero di raccolte stimato per determinare il numero di partizioni. Se impostato su`false`, AWS DMS utilizza il conteggio effettivo delle raccolte. Il valore predefinito è `true`.  | 
|  `"max-records-skip-per-page"`  |  (Facoltativo) Il numero di record da saltare contemporaneamente quando si determinano i limiti di ogni partizione. AWS DMS utilizza un approccio di salto impaginato per determinare il limite minimo per una partizione. Il valore predefinito è 10000. L'impostazione di un valore relativamente elevato può causare timeout del cursore e errori delle attività. L'impostazione di un valore relativamente basso comporta un numero maggiore di operazioni per pagina e un pieno carico più lento.   | 
|  `"batch-size"`  |  (Facoltativa) Limita il numero di documenti restituiti in un batch. Ogni batch richiede un round trip al server. Se la dimensione del batch è zero (0), il cursore utilizza la dimensione massima del batch definita dal server. Il valore predefinito è 0.  | 

L'esempio seguente mostra una mappatura delle tabelle per la segmentazione automatica.

```
{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "admin",
                "table-name": "departments"
            },
            "rule-action": "include",
            "filters": []
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "admin",
                "table-name": "departments"
            },
            "parallel-load": {
                "type": "partitions-auto",
                "number-of-partitions": 5,
                "collection-count-from-metadata": "true",
                "max-records-skip-per-page": 1000000,
                "batch-size": 50000
            }
        }
    ]
}
```

La segmentazione automatica presenta le seguenti limitazioni. La migrazione di ogni segmento recupera separatamente il conteggio di raccolte e il valore `_id` minimo della raccolta. Quindi utilizza l'approccio per ignorare con impaginazione per calcolare il limite minimo del segmento. Pertanto, assicurati che il valore `_id` minimo di ogni raccolta rimanga costante fino al calcolo di tutti i limiti del segmento della raccolta. La modifica del valore `_id` minimo di una raccolta durante il calcolo dei limiti del segmento può causare la perdita di dati o errori di riga duplicata.

### Migrazione di un database Amazon DocumentDB in parallelo utilizzando intervalli di segmenti specifici
<a name="CHAP_Source.DocumentDB.ParallelLoad.Ranges"></a>

L'esempio seguente mostra una raccolta Amazon DocumentDB con sette elementi e `_id` come chiave primaria.

![\[Raccolta Amazon DocumentDB con sette elementi.\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-docdb-collection.png)


Per dividere la raccolta in tre segmenti ed eseguire la migrazione in parallelo, puoi aggiungere all'attività di migrazione le regole di mappatura delle tabelle, come mostrato nel seguente esempio JSON.

```
{ // Task table mappings:
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "1",
      "object-locator": {
        "schema-name": "testdatabase",
        "table-name": "testtable"
      },
      "rule-action": "include"
    }, // "selection" :"rule-type"
    {
      "rule-type": "table-settings",
      "rule-id": "2",
      "rule-name": "2",
      "object-locator": {
        "schema-name": "testdatabase",
        "table-name": "testtable"
      },
      "parallel-load": {
        "type": "ranges",
        "columns": [
           "_id",
           "num"
        ],
        "boundaries": [
          // First segment selects documents with _id less-than-or-equal-to 5f805c97873173399a278d79
          // and num less-than-or-equal-to 2.
          [
             "5f805c97873173399a278d79",
             "2"
          ],
          // Second segment selects documents with _id > 5f805c97873173399a278d79 and
          // _id less-than-or-equal-to 5f805cc5873173399a278d7c and
          // num > 2 and num less-than-or-equal-to 5.
          [
             "5f805cc5873173399a278d7c",
             "5"
          ]                                   
          // Third segment is implied and selects documents with _id > 5f805cc5873173399a278d7c.
        ] // :"boundaries"
      } // :"parallel-load"
    } // "table-settings" :"rule-type"
  ] // :"rules"
} // :Task table mappings
```

Questa definizione di mappatura delle tabelle divide la raccolta di origine in tre segmenti ed esegue la migrazione in parallelo. Di seguito sono riportati i limiti della segmentazione.

```
Data with _id less-than-or-equal-to "5f805c97873173399a278d79" and num less-than-or-equal-to 2 (2 records)
Data with _id less-than-or-equal-to "5f805cc5873173399a278d7c" and num less-than-or-equal-to 5 and not in (_id less-than-or-equal-to  "5f805c97873173399a278d79" and num less-than-or-equal-to 2) (3 records)
Data not in (_id less-than-or-equal-to "5f805cc5873173399a278d7c" and num less-than-or-equal-to 5) (2 records)
```

Una volta completata l'attività di migrazione, è possibile verificare nei log delle attività che le tabelle siano state caricate in parallelo, come illustrato nell'esempio seguente. È anche possibile verificare la clausola `find` Amazon DocumentDB utilizzata per scaricare ogni segmento dalla tabella di origine.

```
[TASK_MANAGER    ] I:  Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86  (replicationtask_util.c:752)

[SOURCE_UNLOAD   ] I:  Range Segmentation filter for Segment #0 is initialized.   (mongodb_unload.c:157)

[SOURCE_UNLOAD   ] I:  Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } }  (mongodb_unload.c:328)

[SOURCE_UNLOAD   ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent.

[TASK_MANAGER    ] I: Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86 (replicationtask_util.c:752)
 
[SOURCE_UNLOAD   ] I: Range Segmentation filter for Segment #0 is initialized. (mongodb_unload.c:157) 

[SOURCE_UNLOAD   ] I: Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } } (mongodb_unload.c:328)
 
[SOURCE_UNLOAD   ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent.

[TARGET_LOAD     ] I: Load finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 1 rows received. 0 rows skipped. Volume transfered 480.

[TASK_MANAGER    ] I: Load finished for segment #1 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. 2 records transferred.
```

Attualmente, AWS DMS supporta i seguenti tipi di dati Amazon DocumentDB come colonna chiave del segmento:
+ Double
+ Stringa
+ ObjectId
+ Intero a 32 bit
+ Intero a 64 bit

## Migrazione di più database quando si utilizza Amazon DocumentDB come origine per AWS DMS
<a name="CHAP_Source.DocumentDB.Multidatabase"></a>

AWS DMS le versioni 3.4.5 e successive supportano la migrazione di più database in un'unica attività solo per Amazon DocumentDB versioni 4.0 e successive. Se desideri migrare più database, procedi come indicato di seguito:

1. Quando crei l'endpoint di origine di Amazon DocumentDB:
   + **Nel modulo AWS DMS, lascia vuoto Console di gestione AWS il **nome del database** nella sezione **Configurazione dell'endpoint** nella pagina Crea endpoint.**
   + Nella AWS Command Line Interface (AWS CLI), assegnate un valore di stringa vuoto al **DatabaseName**parametro in **Document DBSettings** che specificate per l'azione. **CreateEndpoint**

1. Per ogni database che desideri migrare da questo endpoint di origine Amazon DocumentDB, specifica il nome di ciascun database come nome di schema della mappatura delle tabelle per l'attività utilizzando l'input guidato della console o direttamente in JSON. Per ulteriori informazioni sull'input guidato, consulta la descrizione in [Specifica della selezione delle tabelle e delle regole di trasformazione dalla console](CHAP_Tasks.CustomizingTasks.TableMapping.Console.md). Per ulteriori informazioni sul JSON, consulta [Operazioni e regole di selezione](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md).

Ad esempio, puoi specificare il codice JSON seguente per migrare tre database Amazon DocumentDB.

**Example Migrazione di tutte le tabelle in uno schema**  
Il codice JSON seguente esegue la migrazione di tutte le tabelle dai database `Customers`, `Orders` e `Suppliers` dell'endpoint di origine all'endpoint di destinazione.  

```
{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "Customers",
                "table-name": "%"
            },
            "object-locator": {
                "schema-name": "Orders",
                "table-name": "%"
            },
            "object-locator": {
                "schema-name": "Inventory",
                "table-name": "%"
            },
            "rule-action": "include"
        }
    ]
}
```

## Limitazioni nell'utilizzo di Amazon DocumentDB come fonte per AWS DMS
<a name="CHAP_Source.DocumentDB.Limitations"></a>

Di seguito sono riportate le limitazioni relative all'utilizzo di Amazon DocumentDB come fonte per: AWS DMS
+ Quando l'opzione `_id` è impostata come una colonna separata, la stringa ID non deve superare i 200 caratteri.
+ L'ID oggetto e le chiavi del tipo di matrice vengono convertiti in colonne con prefisso `oid` e `array` in modalità tabella.

  Internamente, viene fatto riferimento a queste colonne con i nomi con prefisso. Se utilizzi regole di trasformazione AWS DMS che fanno riferimento a queste colonne, assicurati di specificare la colonna con prefisso. Ad esempio, devi specificare `${oid__id}` e non `${_id}` oppure `${array__addresses}` e non `${_addresses}`. 
+  I nomi delle raccolte e delle chiavi non possono includere il simbolo del dollaro (\$1). 
+ La modalità tabella e la modalità documento presentano le limitazioni illustrate in precedenza.
+ La migrazione in parallelo utilizzando la segmentazione automatica comporta le limitazioni descritte in precedenza.
+ Un'origine Amazon DocumentDB (compatibile con MongoDB) non supporta l'utilizzo di un timestamp specifico come posizione iniziale per l'acquisizione dei dati di modifica (CDC). Un'attività di replica continua acquisisce le modifiche indipendentemente dal timestamp.
+ AWS DMS non supporta documenti in cui il livello di nidificazione è maggiore di 97 per AWS DMS le versioni precedenti alla 3.5.2.
+ I filtri di origine non sono supportati per DocumentDB.
+ AWS DMS non supporta la replica CDC (change data capture) per DocumentDB come origine in modalità cluster elastico.

## Utilizzo delle impostazioni degli endpoint con Amazon DocumentDB come origine
<a name="CHAP_Source.DocumentDB.ECAs"></a>

È possibile utilizzare le impostazioni degli endpoint per configurare il database di origine Amazon DocumentDB 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 JSON. `--doc-db-settings '{"EndpointSetting": "value", ...}'`

La tabella seguente mostra le impostazioni degli endpoint che puoi utilizzare con Amazon DocumentDB come origine.


| Nome attributo | Valori validi | Valore predefinito e descrizione | 
| --- | --- | --- | 
|   `NestingLevel`   |  `"none"` `"one"`  |  `"none"`: specifica `"none"` per utilizzare la modalità documento. Specificare `"one"` per utilizzare la modalità tabella.  | 
|   `ExtractDocID`   |  `true` `false`  |  `false`: utilizza questo attributo quando `NestingLevel` è impostato su `"none"`.  **Quando si utilizza CDC con fonti che producono [transazioni con più documenti](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), il `ExtractDocId` parametro deve essere impostato su.** `true` Se questo parametro non è abilitato, l' AWS DMS operazione avrà esito negativo quando rileva una transazione con più documenti.  | 
|   `DocsToInvestigate`   |  Un numero intero positivo maggiore di `0`.  |  `1000`: utilizza questo attributo quando `NestingLevel` è impostato su `"one"`.   | 
|   `ReplicateShardCollections `   |  `true` `false`  |  Se impostato su true, AWS DMS replica i dati in raccolte frammentate. AWS DMS utilizza questa impostazione solo se l'endpoint di destinazione è un cluster elastico DocumentDB. Quando questa impostazione è true, è importante tenere presenti le seguenti informazioni: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.DocumentDB.html)  | 

## Tipi di dati di origine per Amazon DocumentDB
<a name="CHAP_Source.DocumentDB.DataTypes"></a>

Nella tabella seguente sono elencati i tipi di dati di origine di Amazon DocumentDB supportati per l'uso in AWS DMS. In questa tabella puoi anche trovare la mappatura predefinita AWS DMS dei tipi di dati. Per ulteriori informazioni sui tipi di dati, consulta [BSON types](https://docs.mongodb.com/manual/reference/bson-types) nella documentazione di MongoDB.

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 Amazon DocumentDB  |  AWS DMS tipi di dati  | 
| --- | --- | 
| Booleano | Bool | 
| Binario | BLOB | 
| Data | Data | 
| Timestamp | Data | 
| Int | INT4 | 
| Long | INT8 | 
| Double | REAL8 | 
| String (UTF-8) | CLOB | 
| Array | CLOB | 
| OID | Stringa | 

# Utilizzo di Amazon S3 come sorgente per AWS DMS
<a name="CHAP_Source.S3"></a>

Puoi migrare i dati da un bucket Amazon S3 utilizzando. AWS DMS Per eseguire questa operazione dovrai fornire l'accesso a un bucket Amazon S3 contenente uno o più file di dati. In questo bucket S3, includi un file JSON che descriva la mappatura tra i dati e le tabelle di database dei dati in questi file.

I file di dati di origine devono essere presenti nel bucket Amazon S3 prima dell'avvio del pieno carico. Specifica il nome del bucket tramite il parametro `bucketName`. 

I file di dati di origine possono avere i seguenti formati:
+ Valore separato da virgole (.csv)
+ Parquet (versione DMS 3.5.3 e successive). Per informazioni sull'uso dei file in formato Parquet, consulta. [Utilizzo di file in formato Parquet in Amazon S3 come origine per AWS DMS](#CHAP_Source.S3.Parquet)

Per i file di dati di origine in formato con valori separati da virgole (.csv), denominateli utilizzando la seguente convenzione di denominazione. In questa convenzione, *`schemaName`* è lo schema di origine e *`tableName`* è il nome di una tabella all'interno di tale schema.

```
/schemaName/tableName/LOAD001.csv
/schemaName/tableName/LOAD002.csv
/schemaName/tableName/LOAD003.csv
...
```

 Ad esempio, supponi che i file di dati siano in `amzn-s3-demo-bucket` nel seguente percorso Amazon S3.

```
s3://amzn-s3-demo-bucket/hr/employee
```

In fase di caricamento, AWS DMS si presuppone che il nome dello schema di origine sia e che il nome della tabella di origine sia`hr`. `employee`

Oltre a `bucketName` (obbligatorio), puoi facoltativamente fornire un `bucketFolder` parametro per AWS DMS specificare dove cercare i file di dati nel bucket Amazon S3. Continuando l'esempio precedente, se lo hai `bucketFolder` impostato su`sourcedata`, AWS DMS legge i file di dati nel percorso seguente.

```
s3://amzn-s3-demo-bucket/sourcedata/hr/employee
```

Puoi specificare il delimitatore di colonna, di riga, l'indicatore di valori null e altri parametri utilizzando gli attributi di connessione aggiuntivi. Per ulteriori informazioni, consulta [Impostazioni degli endpoint per Amazon S3 come origine per AWS DMS](#CHAP_Source.S3.Configuring).

Puoi specificare il proprietario del bucket e impedire lo sniping utilizzando l'impostazione dell'endpoint `ExpectedBucketOwner` Amazon S3, come illustrato di seguito. Quindi, quando effettui una richiesta per testare una connessione o eseguire una migrazione, S3 controlla l'ID account del proprietario del bucket rispetto al parametro specificato.

```
--s3-settings='{"ExpectedBucketOwner": "AWS_Account_ID"}'
```

**Topics**
+ [Definizione di tabelle esterne per Amazon S3 come origine per AWS DMS](#CHAP_Source.S3.ExternalTableDef)
+ [Utilizzo di CDC con Amazon S3 come fonte per AWS DMS](#CHAP_Source.S3.CDC)
+ [Prerequisiti per l'utilizzo di Amazon S3 come sorgente per AWS DMS](#CHAP_Source.S3.Prerequisites)
+ [Limitazioni nell'utilizzo di Amazon S3 come fonte per AWS DMS](#CHAP_Source.S3.Limitations)
+ [Impostazioni degli endpoint per Amazon S3 come origine per AWS DMS](#CHAP_Source.S3.Configuring)
+ [Tipi di dati di origine per Amazon S3](#CHAP_Source.S3.DataTypes)
+ [Utilizzo di file in formato Parquet in Amazon S3 come origine per AWS DMS](#CHAP_Source.S3.Parquet)

## Definizione di tabelle esterne per Amazon S3 come origine per AWS DMS
<a name="CHAP_Source.S3.ExternalTableDef"></a>

Oltre ai file di dati, devi fornire anche una definizione di tabella esterna. Una *definizione di tabella esterna* è un documento JSON che descrive come AWS DMS interpretare i dati di Amazon S3. La dimensione massima di questo documento è 2 MB. Se crei un endpoint di origine utilizzando la console di AWS DMS gestione, puoi inserire il codice JSON direttamente nella casella di mappatura delle tabelle. Se utilizzi AWS Command Line Interface (AWS CLI) o l' AWS DMS API per eseguire le migrazioni, puoi creare un file JSON per specificare la definizione della tabella esterna.

Ad esempio, supponi di avere un file di dati che include quanto segue.

```
101,Smith,Bob,2014-06-04,New York
102,Smith,Bob,2015-10-08,Los Angeles
103,Smith,Bob,2017-03-13,Dallas
104,Smith,Bob,2017-03-13,Dallas
```

Di seguito è riportato un esempio di definizione di tabella esterna per questi dati.

```
{
    "TableCount": "1",
    "Tables": [
        {
            "TableName": "employee",
            "TablePath": "hr/employee/",
            "TableOwner": "hr",
            "TableColumns": [
                {
                    "ColumnName": "Id",
                    "ColumnType": "INT8",
                    "ColumnNullable": "false",
                    "ColumnIsPk": "true"
                },
                {
                    "ColumnName": "LastName",
                    "ColumnType": "STRING",
                    "ColumnLength": "20"
                },
                {
                    "ColumnName": "FirstName",
                    "ColumnType": "STRING",
                    "ColumnLength": "30"
                },
                {
                    "ColumnName": "HireDate",
                    "ColumnType": "DATETIME"
                },
                {
                    "ColumnName": "OfficeLocation",
                    "ColumnType": "STRING",
                    "ColumnLength": "20"
                }
            ],
            "TableColumnsTotal": "5"
        }
    ]
}
```

Gli elementi in questo documento JSON sono i seguenti:

`TableCount`: il numero di tabelle di origine. In questo esempio è presente una sola tabella.

`Tables`: un array costituito da una mappa JSON per tabella di origine. In questo esempio è presente una sola mappa. Ogni mappa è formata dai seguenti elementi:
+ `TableName`: il nome della tabella di origine.
+ `TablePath`: il percorso nel bucket Amazon S3 in cui AWS DMS può trovare il file completo del caricamento dei dati. Se è specificato un valore `bucketFolder`, questo valore viene anteposto al percorso.
+ `TableOwner`: il nome dello schema per la tabella.
+ `TableColumns`: un array di una o più mappe, ognuna delle quali descrive una colonna nella tabella di origine:
  + `ColumnName`: il nome di una colonna nella tabella di origine.
  + `ColumnType`: il tipo di dati della colonna. Per informazioni sui tipi di dati validi, consulta [Tipi di dati di origine per Amazon S3](#CHAP_Source.S3.DataTypes).
  + `ColumnLength`: il numero di byte della colonna. La lunghezza massima delle colonne è limitata a 2147483647 byte (2.047 MegaBytes) poiché una sorgente S3 non supporta la modalità FULL LOB. `ColumnLength`è valido per i seguenti tipi di dati:
    + BYTE
    + STRING
  + `ColumnNullable`: un valore booleano che è `true` se questa colonna può contenere valori NULL (predefinito = `false`).
  + `ColumnIsPk`: un valore booleano che è `true` se questa colonna è parte della chiave primaria (predefinito = `false`).
  + `ColumnDateFormat`: il formato della data di input per una colonna con i tipi DATE, TIME e DATETIME e utilizzato per analizzare una stringa di dati in un oggetto data. I valori possibili includono:

    ```
    - YYYY-MM-dd HH:mm:ss
    - YYYY-MM-dd HH:mm:ss.F
    - YYYY/MM/dd HH:mm:ss
    - YYYY/MM/dd HH:mm:ss.F
    - MM/dd/YYYY HH:mm:ss
    - MM/dd/YYYY HH:mm:ss.F
    - YYYYMMdd HH:mm:ss
    - YYYYMMdd HH:mm:ss.F
    ```
+ `TableColumnsTotal`: il numero totale di colonne. Questo numero deve corrispondere al numero di elementi nella matrice `TableColumns`.

Se non si specifica diversamente, AWS DMS si presuppone che `ColumnLength` sia zero.

**Nota**  
Nelle versioni supportate di AWS DMS, i dati di origine S3 possono contenere anche una colonna operativa opzionale come prima colonna prima del valore della `TableName` colonna. Questa colonna operazione identifica l'operazione (`INSERT`) utilizzata per migrare i dati a un endpoint di destinazione S3 durante un carico completo.   
Se presente, il valore di questa colonna è il carattere iniziale della parola chiave (`I`) dell’operazione `INSERT`. Se specificato, questa colonna generalmente indica che la sorgente di S3 è stata creata da DMS come target S3 durante una migrazione precedente.   
Nelle versioni di DMS precedenti alla 3.4.2, questa colonna non era presente nei dati di origine S3 creati da un precedente pieno carico DMS. Aggiungere questa colonna ai dati target S3 consente al formato di tutte le righe scritte nel target S3 di essere coerenti se sono scritte durante un pieno carico o durante un carico CDC. Per ulteriori informazioni sulle opzioni per la formattazione dei dati target S3, vedere [Indicazione delle operazioni del DB di origine nei dati S3 migrati](CHAP_Target.S3.md#CHAP_Target.S3.Configuring.InsertOps).

Per una colonna di tipo NUMERIC, devi specificare la precisione e la dimensione. La *precisione* è il numero totale di cifre in un numero e la *dimensione* è il numero di cifre a destra del separatore decimale. Puoi utilizzare gli elementi `ColumnScale` e `ColumnPrecision` come illustrato di seguito.

```
...
    {
        "ColumnName": "HourlyRate",
        "ColumnType": "NUMERIC",
        "ColumnPrecision": "5"
        "ColumnScale": "2"
    }
...
```

Per una colonna di tipo DATETIME con dati che contengono frazioni di secondo, specifica la scala. La *scala* è il numero di cifre per le frazioni di secondo e può variare da 0 a 9. Puoi utilizzare l'elemento `ColumnScale` per questo scopo, come illustrato di seguito.

```
...
{
      "ColumnName": "HireDate",
      "ColumnType": "DATETIME",
      "ColumnScale": "3"
}
...
```

Se non specifichi diversamente, AWS DMS assume che `ColumnScale` sia zero e tronca la frazione di secondo.

## Utilizzo di CDC con Amazon S3 come fonte per AWS DMS
<a name="CHAP_Source.S3.CDC"></a>

Dopo aver AWS DMS eseguito un caricamento completo dei dati, può opzionalmente replicare le modifiche ai dati sull'endpoint di destinazione. A tale scopo, carichi i file di acquisizione dei dati di modifica (file CDC) nel tuo bucket Amazon S3. AWS DMS legge questi file CDC quando li carichi e quindi applica le modifiche all'endpoint di destinazione. 

I file CDC sono denominati come segue:

```
CDC00001.csv
CDC00002.csv
CDC00003.csv
...
```

**Nota**  
Per replicare i file CDC nella cartella dei dati di modifica caricarli correttamente in un ordine lessicale (sequenziale). Ad esempio, carica il file CDC00002 .csv prima del file .csv. CDC00003 Altrimenti, il CDC00002 file.csv viene ignorato e non viene replicato se lo carichi dopo .csv. CDC00003 Tuttavia, il file CDC00004 .csv viene replicato correttamente se caricato dopo .csv. CDC00003

Per indicare dove AWS DMS posso trovare i file, specifica il parametro. `cdcPath` Continuando con l'esempio precedente, se imposti `cdcPath` su `changedata`, AWS DMS legge i file CDC dal seguente percorso.

```
s3://amzn-s3-demo-bucket/changedata
```

Se imposti su `cdcPath` su `changedata` e `bucketFolder` su `myFolder`, AWS DMS legge i file CDC nel seguente percorso.

```
s3://amzn-s3-demo-bucket/myFolder/changedata
```

I record in un file CDC sono formattati come segue:
+ Operazione: l'operazione di modifica da eseguire: `INSERT` o `I`, `UPDATE` o `U`, oppure `DELETE` o `D`. Queste parole chiave e i valori dei caratteri non fanno distinzione tra maiuscole e minuscole.
**Nota**  
Nelle AWS DMS versioni supportate, AWS DMS può identificare l'operazione da eseguire per ogni record di caricamento in due modi. AWS DMS può eseguire questa operazione dal valore della parola chiave del record (ad esempio,`INSERT`) o dal carattere iniziale della parola chiave (ad esempio,`I`). Nelle versioni precedenti, AWS DMS riconosceva l'operazione di caricamento solo dal valore completo della parola chiave.   
Nelle versioni precedenti di AWS DMS, il valore completo della parola chiave veniva scritto per registrare i dati CDC. Inoltre, le versioni precedenti scrivevano il valore dell'operazione su qualsiasi destinazione S3 utilizzando solo la parola chiave iniziale.   
Il riconoscimento di entrambi i formati consente di AWS DMS gestire l'operazione indipendentemente dal modo in cui viene scritta la colonna delle operazioni per creare i dati di origine S3. Questo approccio supporta l'utilizzo di dati di destinazione su S3 come sorgente per una successiva migrazione. Grazie a questo approccio, non è necessario modificare il formato di qualsiasi valore iniziale della parola chiave visualizzato nella colonna dell'operazione della successiva sorgente S3.
+ Nome tabella: il nome della tabella di origine.
+ Nome dello schema: il nome dello schema di origine.
+ Dati: una o più colonne che rappresentano i dati da modificare.

Di seguito è riportato un esempio di un file CDC per una tabella denominata `employee`.

```
INSERT,employee,hr,101,Smith,Bob,2014-06-04,New York
UPDATE,employee,hr,101,Smith,Bob,2015-10-08,Los Angeles
UPDATE,employee,hr,101,Smith,Bob,2017-03-13,Dallas
DELETE,employee,hr,101,Smith,Bob,2017-03-13,Dallas
```

## Prerequisiti per l'utilizzo di Amazon S3 come sorgente per AWS DMS
<a name="CHAP_Source.S3.Prerequisites"></a>

Per utilizzare Amazon S3 come origine per AWS DMS, il bucket S3 di origine deve trovarsi nella stessa AWS regione dell'istanza di replica DMS che migra i dati. Inoltre, l'account AWS che utilizzi per la migrazione deve disporre dell'accesso in lettura al bucket di origine. Per la AWS DMS versione 3.4.7 e successive, DMS deve accedere al bucket di origine tramite un endpoint VPC o una route pubblica. Per informazioni sugli endpoint VPC, consulta. [Configurazione degli endpoint VPC per AWS DMS](CHAP_VPC_Endpoints.md)

Il ruolo AWS Identity and Access Management (IAM) assegnato all'account utente utilizzato per creare l'attività di migrazione deve disporre del seguente set di autorizzazioni.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
       {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket*/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket*"
            ]
        }
    ]
}
```

------

Il ruolo AWS Identity and Access Management (IAM) assegnato all'account utente utilizzato per creare l'attività di migrazione deve disporre del seguente set di autorizzazioni se il controllo delle versioni è abilitato nel bucket Amazon S3.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
       {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket*/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket*"
            ]
        }
    ]
}
```

------

## Limitazioni nell'utilizzo di Amazon S3 come fonte per AWS DMS
<a name="CHAP_Source.S3.Limitations"></a>

Le seguenti limitazioni si applicano quando si utilizza Amazon S3 come origine:
+ Non abilitare il controllo delle versioni per S3. Se hai bisogno del controllo delle versioni S3, utilizza le policy del ciclo di vita per eliminare attivamente le vecchie versioni. In caso contrario, è possibile che si verifichino errori della connessione di test dell'endpoint a causa del timeout della chiamata `list-object` S3. Per creare una policy del ciclo di vita per un bucket S3, consulta [Gestione del ciclo di vita dello storage](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html). Per eliminare la versione di un oggetto S3, consulta [Eliminazione di versioni di oggetti da un bucket con funzione Controllo delle versioni abilitata](https://docs.aws.amazon.com/AmazonS3/latest/dev/DeletingObjectVersions.html).
+ Un bucket S3 abilitato per VPC (VPC del gateway) è supportato nelle versioni 3.4.7 e successive.
+ MySQL converte `time` il tipo di dati in. `string` **Per visualizzare `time` i valori dei tipi di dati in MySQL, definisci la colonna nella tabella di destinazione `string` come e imposta l'impostazione della modalità di **preparazione della tabella Target dell'**attività su Truncate.**
+ AWS DMS utilizza il tipo di `BYTE` dati internamente per i dati di entrambi i tipi di dati. `BYTE` `BYTES`
+ Gli endpoint di origine S3 non supportano la funzionalità di ricarica delle tabelle DMS.
+ AWS DMS non supporta la modalità Full LOB con Amazon S3 come sorgente.

Le seguenti limitazioni si applicano all'utilizzo di file in formato Parquet in Amazon S3 come origine:
+ Le date incluse o non `DDMMYYYY` sono supportate per la funzionalità di partizionamento della data di S3 Parquet Source. `MMYYYYDD`

## Impostazioni degli endpoint per Amazon S3 come origine per AWS DMS
<a name="CHAP_Source.S3.Configuring"></a>

È possibile utilizzare le impostazioni degli endpoint per configurare il database di origine Amazon S3 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 contenuto in [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), con la `--s3-settings '{"EndpointSetting": "value", ...}'` sintassi JSON.

**Nota**  
AWS DMS utilizza per impostazione predefinita una connessione sicura all'endpoint Amazon S3 senza la necessità di specificare la modalità o il certificato SSL.

La tabella riportata di seguito mostra le impostazioni degli endpoint che è possibile utilizzare con Amazon S3 come origine.


| **Opzione** | **Descrizione** | 
| --- | --- | 
| BucketFolder |  (Facoltativo) Un nome di cartella nel bucket S3. Se questo attributo è fornito, i file di dati di origine e i file CDC vengono letti dal percorso `s3://amzn-s3-demo-bucket/bucketFolder/schemaName/tableName/` e `s3://amzn-s3-demo-bucket/bucketFolder/` rispettivamente. Se questo attributo non è specificato, viene utilizzato il percorso `schemaName/tableName/`.  `'{"BucketFolder": "sourceData"}'`  | 
| BucketName |  Nome del bucket S3. `'{"BucketName": "amzn-s3-demo-bucket"}'`  | 
| CdcPath | La posizione dei file CDC. Questo attributo è necessario se un'attività acquisisce i dati modificati; altrimenti, è facoltativo. Se CdcPath presente, AWS DMS legge i file CDC da questo percorso e replica le modifiche ai dati sull'endpoint di destinazione. Per ulteriori informazioni, consulta [Utilizzo di CDC con Amazon S3 come fonte per AWS DMS](#CHAP_Source.S3.CDC). `'{"CdcPath": "changeData"}'`  | 
| CsvDelimiter |  Delimitatore utilizzato per separare le colonne nei file di origine. L'impostazione predefinita è una virgola. Di seguito è riportato un esempio. `'{"CsvDelimiter": ","}'`  | 
| CsvNullValue |  Una stringa definita dall'utente che viene considerata nulla AWS DMS durante la lettura dall'origine. L'impostazione predefinita è una stringa vuota. Se non impostate questo parametro, AWS DMS considera una stringa vuota come un valore nullo. Se impostate questo parametro su una stringa come «\$1 N», AWS DMS tratta questa stringa come valore nullo e tratta le stringhe vuote come valore di stringa vuota.  | 
| CsvRowDelimiter |  Delimitatore utilizzato per separare le righe nei file di origine. L'impostazione predefinita è una nuova riga (`\n`). `'{"CsvRowDelimiter": "\n"}'`  | 
| DataFormat |  Imposta questo valore su per leggere i dati `Parquet` in formato Parquet. `'{"DataFormat": "Parquet"}'`  | 
| IgnoreHeaderRows |  Quando questo valore è impostato su 1, AWS DMS ignora l'intestazione della prima riga in un file.csv. Il valore 1 abilita la funzionalità, il valore 0 la disabilita. Il valore predefinito è 0. `'{"IgnoreHeaderRows": 1}'`  | 
| Rfc4180 |  Quando questo valore è impostato su `true` o `y`, le virgolette di apertura devono essere seguite dalle virgolette di chiusura. Questa formattazione è conforme a RFC 4180. Quando questo valore è impostato su `false` o `n`, i valori letterali stringa vengono copiati sulla destinazione così come sono. In questo caso, un delimitatore (riga o colonna) segnala la fine del campo. Pertanto, non è possibile utilizzare un delimitatore come parte della stringa, perché segnala la fine del valore. Il valore predefinito è `true`. Valori validi: `true`, `false`, `y`, `n` `'{"Rfc4180": false}'`  | 

## Tipi di dati di origine per Amazon S3
<a name="CHAP_Source.S3.DataTypes"></a>

Migrazione dei dati che utilizza Amazon S3 come fonte per AWS DMS le esigenze di mappatura dei dati da Amazon S3 AWS DMS ai tipi di dati. Per ulteriori informazioni, consulta [Definizione di tabelle esterne per Amazon S3 come origine per AWS DMS](#CHAP_Source.S3.ExternalTableDef).

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

I seguenti tipi di AWS DMS dati vengono utilizzati con Amazon S3 come fonte:
+ BYTE: richiede `ColumnLength`. Per ulteriori informazioni, consulta [Definizione di tabelle esterne per Amazon S3 come origine per AWS DMS](#CHAP_Source.S3.ExternalTableDef).
+ DATE
+ TIME
+ DATETIME: per ulteriori informazioni e un esempio, consulta il tipo DATETIME in [Definizione di tabelle esterne per Amazon S3 come origine per AWS DMS](#CHAP_Source.S3.ExternalTableDef).
+ INT1
+ INT2
+ INT4
+ INT8
+ NUMERIC: richiede `ColumnPrecision` e. `ColumnScale` AWS DMS supporta i seguenti valori massimi:
  + **ColumnPrecision: 38**
  + **ColumnScale: 31**

  Per ulteriori informazioni e un esempio, consulta il tipo NUMERIC in [Definizione di tabelle esterne per Amazon S3 come origine per AWS DMS](#CHAP_Source.S3.ExternalTableDef).
+ REAL4
+ REAL8
+ STRING: richiede `ColumnLength`. Per ulteriori informazioni, consulta [Definizione di tabelle esterne per Amazon S3 come origine per AWS DMS](#CHAP_Source.S3.ExternalTableDef).
+ UINT1
+ UINT2
+ UINT4
+ UINT8
+ BLOB
+ CLOB
+ BOOLEAN

## Utilizzo di file in formato Parquet in Amazon S3 come origine per AWS DMS
<a name="CHAP_Source.S3.Parquet"></a>

Nella AWS DMS versione 3.5.3 e successive, è possibile utilizzare i file in formato Parquet in un bucket S3 come origine per la replica Full-Load o CDC. 

DMS supporta solo i file in formato Parquet come origine generata da DMS migrando i dati su un endpoint di destinazione S3. I nomi dei file devono essere nel formato supportato, altrimenti DMS non li includerà nella migrazione.

Per i file di dati di origine in formato Parquet, devono trovarsi nella seguente cartella e convenzione di denominazione.

```
schema/table1/LOAD00001.parquet
schema/table2/LOAD00002.parquet
schema/table2/LOAD00003.parquet
```

Per i file di dati di origine per i dati CDC in formato Parquet, denominateli e memorizzateli utilizzando la seguente convenzione di cartella e denominazione.

```
schema/table/20230405-094615814.parquet
schema/table/20230405-094615853.parquet
schema/table/20230405-094615922.parquet
```

Per accedere ai file in formato Parquet, imposta le seguenti impostazioni dell'endpoint:
+ Imposta `DataFormat` su `Parquet`. 
+ Non impostate l'`cdcPath`impostazione. Assicuratevi di creare i file in formato Parquet nelle cartelle schema/tabella specificate. 

[https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html)

### Tipi di dati supportati per i file in formato Parquet
<a name="CHAP_Source.S3.Parquet.Datatypes"></a>

AWS DMS supporta i seguenti tipi di dati di origine e destinazione durante la migrazione di dati da file in formato Parquet. Assicurati che la tabella di destinazione contenga colonne con i tipi di dati corretti prima della migrazione.


| Tipo di dati origine | Tipi di dati di destinazione | 
| --- | --- | 
| BYTE | BINARY | 
| DATE | DATE32 | 
| TIME | TIME32 | 
| DATETIME | TIMESTAMP | 
| INT1 | INT8 | 
| INT2 | INT16 | 
| INT4 | INT32 | 
| INT8 | INT64 | 
| NUMERIC | DECIMAL | 
| REAL4 | FLOAT | 
| REAL8 | DOUBLE | 
| STRING | STRING | 
| UINT1 | UINT8 | 
| UINT2 | UINT16 | 
| UINT4 | UINT32 | 
| UINT8 | UINT | 
| WSTRING | STRING | 
| BLOB | BINARY | 
| NCLOB | STRING | 
| CLOB | STRING | 
| BOOLEAN | BOOL | 

# Utilizzo di IBM Db2 per Linux, Unix, Windows e database Amazon RDS (Db2 LUW) come origine per AWS DMS
<a name="CHAP_Source.DB2"></a>

Puoi migrare i dati da un database IBM Db2 per Linux, Unix, Windows e Amazon RDS (Db2 LUW) a qualsiasi database di destinazione supportato utilizzando (). AWS Database Migration Service AWS DMS

Per informazioni sulle versioni di Db2 su Linux, Unix, Windows e RDS supportate come sorgente, consulta. AWS DMS [Fonti per AWS DMS](CHAP_Introduction.Sources.md) 

Puoi utilizzare il protocollo Secure Sockets Layer (SSL) per crittografare le connessioni tra l'endpoint Db2 LUW e l'istanza di replica. Per ulteriori informazioni sull'utilizzo di SSL con un endpoint Db2 LUW, consulta [Utilizzo di SSL con AWS Database Migration Service](CHAP_Security.SSL.md).

Quando AWS DMS legge i dati da un database di origine IBM Db2, utilizza il livello di isolamento predefinito CURSOR STABILITY (CS) per Db2 versione 9.7 e successive. Per ulteriori informazioni, consulta la documentazione di [IBM Db2](https://www.ibm.com/docs/en/db2/12.1.0) per Linux, UNIX e Windows.

## Prerequisiti per l'utilizzo di Db2 LUW come sorgente per AWS DMS
<a name="CHAP_Source.DB2.Prerequisites"></a>

I seguenti prerequisiti sono necessari prima di poter utilizzare un database Db2 LUW come origine.

Per abilitare la replica continua, denominata anche CDC (Change Data Capture), eseguire le seguenti operazioni:
+ Imposta il database in modo che sia recuperabile, il che AWS DMS richiede l'acquisizione delle modifiche. Un database è recuperabile se uno o entrambi i parametri di configurazione del database `LOGARCHMETH1` e `LOGARCHMETH2` sono impostati su `ON`.

  Se il database è recuperabile, AWS DMS può accedere a Db2 se necessario. `ARCHIVE LOG`
+ Assicurati che i registri DB2 delle transazioni siano disponibili, con un periodo di conservazione sufficiente entro il quale elaborarli. AWS DMS
+ DB2 richiede la `SYSADM` nostra `DBADM` autorizzazione per estrarre i record del registro delle transazioni. Concedi all'account utente le autorizzazioni seguenti:
  + `SYSADM` o `DBADM`
  + `DATAACCESS`
**Nota**  
Per le attività solo pieno carico, l'account utente DMS necessita dell'autorizzazione DATAACCESS.
+ Quando utilizzi IBM DB2 for LUW versione 9.7 come sorgente, imposta l'attributo di connessione aggiuntivo (ECA), `CurrentLsn` come segue:

  `CurrentLsn=LSN` dove `LSN` specifica un numero di sequenza del log (LSN) in cui desideri avviare la replica. In alternativa, imposta `CurrentLsn=scan`.
+ Quando usi Amazon RDS for Db2 LUW come sorgente, assicurati che i log di archivio siano disponibili per. AWS DMS Poiché i database Db2 AWS gestiti eliminano i log di archivio il prima possibile, è necessario aumentare il periodo di tempo in cui i log rimangono disponibili. Ad esempio, per aumentare la conservazione dei log a 24 ore, esegui il comando seguente:

  ```
  db2 "call rdsadmin.set_archive_log_retention( ?, 'TESTDB', '24')"
  ```

  Per ulteriori informazioni sulle procedure LUW di Amazon RDS for Db2, consulta il [riferimento alla stored procedure di Amazon RDS for Db2](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/db2-stored-procedures.html) nella *Amazon Relational Database Service* User Guide.
+ Concedi i seguenti privilegi se utilizzi valutazioni preliminari specifiche: DB2 

  ```
  GRANT CONNECT ON DATABASE TO USER <DMS_USER>;
  GRANT SELECT ON SYSIBM.SYSDUMMY1 TO USER <DMS_USER>;
  GRANT SELECT ON SYSIBMADM.ENV_INST_INFO TO USER <DMS_USER>;
  GRANT SELECT ON SYSIBMADM.DBCFG TO USER <DMS_USER>;
  GRANT SELECT ON SYSCAT.SCHEMATA TO USER <DMS_USER>;
  GRANT SELECT ON SYSCAT.COLUMNS TO USER <DMS_USER>;
  GRANT SELECT ON SYSCAT.TABLES TO USER <DMS_USER>;
  GRANT EXECUTE ON FUNCTION SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID TO <DMS_USER>;
  GRANT EXECUTE ON PACKAGE NULLID.SYSSH200 TO USER <DMS_USER>;
  ```

## Limitazioni nell'utilizzo di Db2 LUW come sorgente per AWS DMS
<a name="CHAP_Source.DB2.Limitations"></a>

AWS DMS non supporta database in cluster. Tuttavia, è possibile definire un Db2 LUW separato per ciascun endpoint di un cluster. Ad esempio, è possibile creare un'attività di migrazione pieno carico con uno qualsiasi dei nodi del cluster, quindi creare attività separate per ogni nodo.

AWS DMS non supporta il tipo di `BOOLEAN` dati nel database Db2 LUW di origine.

Quando si utilizza la replica continua (CDC), si applicano le seguenti limitazioni:
+ Quando una tabella con più partizioni viene troncata, il numero di eventi DDL visualizzati nella AWS DMS console è uguale al numero di partizioni. Questo perché Db2 LUW registra una DDL separata per ciascuna partizione.
+ Le seguenti operazioni DDL non sono supportate sulle tabelle partizionate:
  + ALTER TABLE ADD PARTITION
  + ALTER TABLE DETACH PARTITION
  + ALTER TABLE ATTACH PARTITION
+ AWS DMS non supporta una migrazione di replica continua da un'istanza di standby di disaster recovery (HADR) DB2 ad alta disponibilità. L'istanza di standby è inaccessibile.
+ Il tipo di dati DECFLOAT non è supportato. Di conseguenza, le modifiche alle colonne DECFLOAT vengono ignorate durante la replica continua.
+ L'istruzione RENAME COLUMN non è supportata.
+ Quando si eseguono aggiornamenti alle tabelle Multi-Dimensional Clustering (MDC), ogni aggiornamento viene visualizzato nella console come INSERT \$1 DELETE. AWS DMS 
+ Quando l'impostazione dell'attività **Include LOB columns in replication (Includi le colonne LOB nella replica)** non è disabilitata, qualsiasi tabella con colonne LOB viene sospesa durante la replica continua.
+ Per le versioni Db2 LUW 10.5 e successive, le colonne di stringhe a lunghezza variabile con dati archiviati vengono ignorate. out-of-row Questa limitazione si applica solo alle tabelle create con dimensioni di riga estese per colonne con tipi di dati come VARCHAR e VARGRAPHIC. Per ovviare a questa limitazione, sposta la tabella in uno spazio con una dimensione di pagina maggiore. Per ulteriori informazioni, consulta [Cosa posso fare se voglio cambiare la dimensione]( https://www.ibm.com/support/pages/what-can-i-do-if-i-want-change-pagesize-db2-tablespaces ) della pagina dei tablespace. DB2 
+ Per la replica continua, DMS non supporta la migrazione dei dati caricati a livello di pagina dall'utilità LOAD. DB2 Utilizza invece l'utilità IMPORT che usa inserimenti SQL. Per ulteriori informazioni, consulta [Differences between the import and load utility]( https://www.ibm.com/docs/en/db2/11.1?topic=utilities-differences-between-import-load-utility). 
+ Durante l'esecuzione di un'attività di replica, DMS acquisisce CREATE TABLE DDLs solo se le tabelle sono state create con l'attributo DATA CAPTURE CHANGE.
+ DMS presenta le seguenti limitazioni quando si utilizza la funzionalità Db2 Database Partition Feature (DPF):
  + DMS non è in grado di coordinare le transazioni tra i nodi Db2 in un ambiente DPF. Ciò è dovuto ai vincoli all'interno dell'interfaccia API IBM READLOG. DB2 In DPF, le transazioni possono estendersi su più nodi Db2, a seconda del modo in cui i dati vengono partizionati. DB2 Di conseguenza, la soluzione DMS deve acquisire le transazioni da ciascun nodo Db2 in modo indipendente.
  + DMS può acquisire transazioni locali da ogni nodo Db2 nel cluster DPF `connectNode` impostando `1` su più endpoint di origine DMS. Questa configurazione corrisponde ai numeri di nodi logici definiti nel file di configurazione del server. DB2 `db2nodes.cfg`
  + Le transazioni locali su singoli nodi Db2 possono far parte di una transazione globale più ampia. DMS applica ogni transazione locale in modo indipendente sulla destinazione, senza coordinamento con le transazioni su altri nodi Db2. Questa elaborazione indipendente può portare a complicazioni, specialmente quando le righe vengono spostate tra le partizioni.
  + Quando DMS esegue la replica da più nodi Db2, non vi è alcuna garanzia del corretto ordine delle operazioni sulla destinazione, poiché DMS applica le operazioni in modo indipendente per ogni nodo Db2. È necessario assicurarsi che l'acquisizione delle transazioni locali indipendentemente da ciascun nodo Db2 funzioni per il caso d'uso specifico.
  + Quando si esegue la migrazione da un ambiente DPF, si consiglia di eseguire prima un'attività Full Load senza eventi memorizzati nella cache e quindi eseguire attività solo CDC. Consigliamo di eseguire un'attività per nodo Db2, a partire dal timestamp di inizio Full Load o dal LRI (log record identifier) impostato utilizzando l'attributo di connessione endpoint extra. `StartFromContext` *Per informazioni sulla determinazione del punto di inizio della replica, consulta [Finding the LSN o LRI value for replication start](https://www.ibm.com/support/pages/db2-finding-lsn-or-lri-value-replication-start) nella documentazione di IBM Support.* 
+ Per la replica in corso (CDC), se si prevede di avviare la replica da un timestamp specifico, è necessario impostare l'attributo di connessione aggiuntivo sul timestamp richiesto. `StartFromContext`
+ Attualmente, DMS non supporta la funzionalità Db2 PureScale, un'estensione di LUW che è possibile utilizzare per scalare la soluzione di DB2 database.
+ L'opzione `DATA CAPTURE CHANGES` table è un prerequisito fondamentale per i processi di replica dei dati. DB2 La mancata attivazione di questa opzione durante la creazione delle tabelle può causare la perdita di dati, in particolare per le sole attività di replica CDC (Change Data Capture) avviate da un punto di partenza precedente. AWS DMS abiliterà questo attributo per impostazione predefinita al riavvio di un'attività CDC o FULL\$1CDC. Tuttavia, qualsiasi modifica apportata al database di origine prima del riavvio dell'attività potrebbe non essere effettuata.

  ```
  ALTER TABLE TABLE_SCHEMA.TABLE_NAME DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS;
  ```

## Impostazioni degli endpoint quando si utilizza Db2 LUW come sorgente per AWS DMS
<a name="CHAP_Source.DB2.ConnectionSettings"></a>

È possibile specificare le impostazioni quando si crea l'endpoint di origine utilizzando la AWS DMS console o utilizzando il `create-endpoint` comando in, con [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/create-endpoint.html)

`--ibm-db2-settings '{"EndpointSetting1": "value1","EndpointSetting2": "value2"}'`

Sintassi JSON.

La tabella riportata di seguito mostra le impostazioni degli endpoint che è possibile utilizzare con Db2 LUW come origine.


| Impostazione del nome | Description | 
| --- | --- | 
|  `CurrentLsn`  |  Per la replica in corso (CDC), utilizzare `CurrentLsn` per specificare un numero di sequenza di log (LSN) in cui si desidera che la replica inizi.   | 
|  `MaxKBytesPerRead`  |  Il numero massimo di byte per lettura, come un valore NUMBER. Il valore predefinito è 64 KB.  | 
|  `SetDataCaptureChanges`  |  Abilita la replica in corso (CDC) come valore BOOLEAN. Il valore predefinito è true.  | 

## Attributi di connessione aggiuntivi (ECAs) quando si utilizza Db2 LUW come sorgente per AWS DMS
<a name="CHAP_Source.DB2.ConnectionAttrib"></a>

È possibile specificare gli attributi di connessione aggiuntivi (ECAs) 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/create-endpoint.html), con

`--extra-connection-attributes 'ECAname1=value1;ECAname2=value2;'`

La tabella seguente mostra cosa ECAs è possibile utilizzare con Db2 LUW come sorgente.


| Nome attributo | Description | 
| --- | --- | 
|  `ConnectionTimeout`  |  Utilizzate questo ECA per impostare il timeout di connessione all'endpoint per l'endpoint Db2 LUW, in secondi. Il valore predefinito è 10 secondi. Ad esempio: `ConnectionTimeout=30;`  | 
|  `executeTimeout`  |  Attributo di connessione aggiuntivo che imposta il timeout dell'istruzione (query) per l'endpoint LUW, in secondi. DB2 Il valore predefinito è 60 secondi. Ad esempio: `executeTimeout=120;`  | 
|  `StartFromContext`  |  Per la replica continua (CDC), utilizza `StartFromContext` per specificare il limite minimo di un log da cui iniziare la replica. `StartFromContext` accetta diverse forme di valori. I valori validi includono: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.DB2.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.DB2.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.DB2.html) Per determinare l' LRI/LSN intervallo di un file di registro, esegui il `db2flsn` comando come mostrato nell'esempio seguente. <pre>db2flsn -db SAMPLE -lrirange 2</pre> L'output dell'esempio è simile al seguente.  <pre><br />S0000002.LOG: has LRI range 00000000000000010000000000002254000000000004F9A6 to <br />000000000000000100000000000022CC000000000004FB13</pre> In tale output, il file di registro è S0000002.LOG e il valore **StartFromContext**LRI è costituito dai 34 byte alla fine dell'intervallo. <pre>0100000000000022CC000000000004FB13</pre>  | 

## Tipi di dati di origine per IBM Db2 LUW
<a name="CHAP_Source.DB2.DataTypes"></a>

La migrazione dei dati che utilizza Db2 LUW come fonte AWS DMS supporta la maggior parte dei tipi di dati Db2 LUW. La tabella seguente mostra i tipi di dati di origine Db2 LUW supportati durante l'utilizzo AWS DMS e la mappatura predefinita dei tipi di dati. AWS DMS Per ulteriori informazioni sui tipi di dati di Db2 LUW, consulta la [documentazione di Db2 LUW](https://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0008483.html).

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 Db2 LUW  |  AWS DMS tipi di dati  | 
| --- | --- | 
|  INTEGER  |  INT4  | 
|  SMALLINT  |  INT2  | 
|  BIGINT  |  INT8  | 
|  DECIMAL (p,s)  |  NUMERIC (p,s)  | 
|  FLOAT  |  REAL8  | 
|  DOUBLE  |  REAL8  | 
|  REAL  |  REAL4  | 
|  DECFLOAT (p)  |  Se la precisione è 16, allora REAL8; se la precisione è 34, allora STRING  | 
|  GRAPHIC (n)  |  WSTRING, per stringhe di grafici a lunghezza fissa di caratteri a due byte con lunghezza maggiore di 0 e minore o uguale a 127  | 
|  VARGRAPHIC (n)  |  WSTRING, per stringhe di grafici a lunghezza variabile con lunghezza maggiore di 0 e minore o uguale a 16352 caratteri a due byte  | 
|  LONG VARGRAPHIC (n)  |  CLOB, per stringhe di grafici a lunghezza variabile con lunghezza maggiore di 0 e minore o uguale a 16352 caratteri a due byte  | 
|  CHARACTER (n)  |  STRING, per stringhe a lunghezza fissa di caratteri a due byte con lunghezza maggiore di 0 e minore o uguale a 255  | 
|  VARCHAR (n)  |  STRING, per stringhe a lunghezza variabile di caratteri a due byte con lunghezza maggiore di 0 e minore o uguale a 32704  | 
|  LONG VARCHAR (n)  |  CLOB, per stringhe a lunghezza variabile di caratteri a due byte con lunghezza maggiore di 0 e minore o uguale a 32704  | 
|  CHAR (n) FOR BIT DATA  |  BYTES  | 
|  VARCHAR (n) FOR BIT DATA  |  BYTES  | 
|  LONG VARCHAR FOR BIT DATA  |  BYTES  | 
|  DATE  |  DATE  | 
|  TIME  |  TIME  | 
|  TIMESTAMP  |  DATETIME  | 
|  BLOB(n)  |  BLOB La lunghezza massima è 2.147.483.647 byte  | 
|  CLOB(n)  |  CLOB La lunghezza massima è 2.147.483.647 byte  | 
|  DBCLOB (n)  |  CLOB La lunghezza massima: 1.073.741.824 caratteri a due byte  | 
|  XML  |  CLOB  | 

# Utilizzo di IBM Db2 per i z/OS database come fonte per AWS DMS
<a name="CHAP_Source.DB2zOS"></a>

È possibile migrare i dati da un database IBM for a qualsiasi z/OS database di destinazione supportato utilizzando (). AWS Database Migration Service AWS DMS

Per informazioni sulle versioni di Db2 for z/OS AWS DMS supportate come sorgente, consulta. [Fonti per AWS DMS](CHAP_Introduction.Sources.md)

## Prerequisiti per l'utilizzo di Db2 for z/OS come sorgente per AWS DMS
<a name="CHAP_Source.DB2zOS.Prerequisites"></a>

Per utilizzare un IBM Db2 for z/OS database come sorgente in AWS DMS, concedi i seguenti privilegi all' z/OS utente Db2 for specificato nelle impostazioni di connessione dell'endpoint di origine.

```
GRANT SELECT ON SYSIBM.SYSTABLES TO Db2USER;
GRANT SELECT ON SYSIBM.SYSTABLESPACE TO Db2USER;
GRANT SELECT ON SYSIBM.SYSTABLEPART TO Db2USER;                    
GRANT SELECT ON SYSIBM.SYSCOLUMNS TO Db2USER;
GRANT SELECT ON SYSIBM.SYSDATABASE TO Db2USER;
GRANT SELECT ON SYSIBM.SYSDUMMY1 TO Db2USER
```

Fornisci anche SELECT ON `user defined` per le tabelle di origine.

Un endpoint AWS DMS IBM Db2 for z/OS source si affida all'IBM Data Server Driver for ODBC per accedere ai dati. Il server di database deve disporre di una licenza IBM ODBC Connect valida per consentire a DMS di connettersi a questo endpoint.

## Limitazioni nell'utilizzo di Db2 for come fonte per z/OS AWS DMS
<a name="CHAP_Source.DB2zOS.Limitations"></a>

Le seguenti limitazioni si applicano quando si utilizza un IBM Db2 for z/OS database come origine per: AWS DMS
+ Sono supportate solo le attività di replica pieno carico. Il CDC (Change Data Capture) non è supportato.
+ Il caricamento parallelo non è supportato.
+ La convalida dei dati delle viste non è supportata.
+ I nomi di schemi, tabelle e colonne devono essere specificati in lettere MAIUSCOLE nelle mappature delle tabelle per le trasformazioni di livello e i filtri di selezione a Column/table livello di riga.

## Tipi di dati di origine per IBM Db2 for z/OS
<a name="CHAP_Source.DB2zOS.DataTypes"></a>

Le migrazioni di dati che utilizzano Db2 for z/OS come fonte per AWS DMS supportare la maggior parte dei tipi di dati Db2. z/OS La tabella seguente mostra il Db2 per i tipi di dati di z/OS origine supportati durante l'utilizzo e la AWS DMS mappatura predefinita dei tipi di dati. AWS DMS 

Per ulteriori informazioni su Db2 per z/OS i tipi di dati, consulta [IBM Db2 per la documentazione. z/OS ](https://www.ibm.com/docs/en/db2-for-zos/12?topic=elements-data-types)

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


|  Db2 per i tipi di z/OS dati  |  AWS DMS tipi di dati  | 
| --- | --- | 
|  INTEGER  |  INT4  | 
|  SMALLINT  |  INT2  | 
|  BIGINT  |  INT8  | 
|  DECIMAL (p,s)  |  NUMERIC (p,s) Se un punto decimale è impostato su una virgola (,) nella DB2 configurazione, configura Replicate per supportare l'impostazione. DB2   | 
|  FLOAT  |  REAL8  | 
|  DOUBLE  |  REAL8  | 
|  REAL  |  REAL4  | 
|  DECFLOAT (p)  |  Se la precisione è 16, allora REAL8; se la precisione è 34, allora STRING  | 
|  GRAPHIC (n)  |  If n>=127 then WSTRING, per stringhe di grafici a lunghezza fissa di caratteri a due byte con lunghezza maggiore di 0 e minore o uguale a 127  | 
|  VARGRAPHIC (n)  |  WSTRING, per stringhe di grafici a lunghezza variabile con lunghezza maggiore di 0 e minore o uguale a 16352 caratteri a due byte  | 
|  LONG VARGRAPHIC (n)  |  CLOB, per stringhe di grafici a lunghezza variabile con lunghezza maggiore di 0 e minore o uguale a 16352 caratteri a due byte  | 
|  CHARACTER (n)  |  STRING, per stringhe a lunghezza fissa di caratteri a due byte con lunghezza maggiore di 0 e minore o uguale a 255  | 
|  VARCHAR (n)  |  STRING, per stringhe a lunghezza variabile di caratteri a due byte con lunghezza maggiore di 0 e minore o uguale a 32704  | 
|  LONG VARCHAR (n)  |  CLOB, per stringhe a lunghezza variabile di caratteri a due byte con lunghezza maggiore di 0 e minore o uguale a 32704  | 
|  CHAR (n) FOR BIT DATA  |  BYTES  | 
|  VARCHAR (n) FOR BIT DATA  |  BYTES  | 
|  LONG VARCHAR FOR BIT DATA  |  BYTES  | 
|  DATE  |  DATE  | 
|  TIME  |  TIME  | 
|  TIMESTAMP  |  DATETIME  | 
|  BLOB(n)  |  BLOB La lunghezza massima è 2.147.483.647 byte  | 
|  CLOB(n)  |  CLOB La lunghezza massima è 2.147.483.647 byte  | 
|  DBCLOB (n)  |  CLOB La lunghezza massima: 1.073.741.824 caratteri a due byte  | 
|  XML  |  CLOB  | 
|  BINARY  |  BYTES  | 
|  VARBINARY  |  BYTES  | 
|  ROWID  |  BYTES. Per ulteriori informazioni sull'utilizzo di ROWID, consulta i seguenti argomenti.   | 
|  TIMESTAMP WITH TIME ZONE  |  Non supportato.  | 

Le colonne ROWID vengono migrate per impostazione predefinita quando la modalità di preparazione della tabella di destinazione per l'attività è impostata su DROP\$1AND\$1CREATE (impostazione predefinita). La convalida dei dati ignora queste colonne perché le righe sono prive di significato al di fuori del database e della tabella specifici. Per disattivare la migrazione di queste colonne, è possibile procedere in uno dei seguenti modi preparatori: 
+ Crea in anticipo la tabella di destinazione senza queste colonne. Quindi, imposta la modalità di preparazione della tabella di destinazione dell'attività su DO\$1NOTHING o TRUNCATE\$1BEFORE\$1LOAD. È possibile utilizzare AWS Schema Conversion Tool (AWS SCT) per precreare la tabella di destinazione senza le colonne.
+ Aggiungi una regola di mappatura delle tabelle a un'attività che filtra queste colonne in modo che vengano ignorate. Per ulteriori informazioni, consulta [Operazioni e regole di trasformazione](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).

## Collazioni EBCDIC nel servizio di modernizzazione di PostgreSQL for Mainframe AWS
<a name="CHAP_Source.DB2zOS.EBCDIC"></a>

AWS Il programma di modernizzazione del mainframe consente di modernizzare le applicazioni mainframe in ambienti di runtime gestiti. AWS Offre strumenti e risorse per aiutarti a pianificare e implementare i progetti di migrazione e modernizzazione. [Per ulteriori informazioni sulla modernizzazione e la migrazione del mainframe, vedere Mainframe Modernization with. AWS](https://aws.amazon.com/mainframe/)

Alcuni IBM Db2 per set di z/OS dati sono codificati nel set di caratteri Extended Binary Coded Decimal Interchange (EBCDIC). Si tratta di un set di caratteri sviluppato prima che l'ASCII (American Standard Code for Information Interchange) diventasse comunemente usato. Una *tabella codici* associa ogni carattere di testo ai caratteri di un set di caratteri. Una tabella codici tradizionale contiene le informazioni di mappatura tra un punto di codice e un ID di carattere. Un *ID di carattere* è una stringa di dati di caratteri a 8 byte. Un *punto di codice* è un numero binario a 8 bit che rappresenta un carattere. I punti di codice vengono generalmente visualizzati come rappresentazioni esadecimali dei relativi valori binari.

*Se attualmente utilizzate Micro Focus o un BluAge componente del servizio Mainframe Modernization, dovete decidere di spostare (tradurre) determinati punti di codice. AWS DMS * È possibile utilizzare le impostazioni delle AWS DMS attività per eseguire i turni. L'esempio seguente mostra come utilizzare l' AWS DMS `CharacterSetSettings`operazione per mappare i turni in un'impostazione di attività DMS.

```
"CharacterSetSettings": {
        "CharacterSetSupport": null,
        "CharacterReplacements": [
{"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"}
            }
        ]
    }
```

Esistono già alcune regole di confronto EBCDIC per PostgreSQL che comprendono i cambiamenti necessari. Sono supportate diverse tabelle codici. Le sezioni seguenti forniscono esempi JSON di ciò che è necessario cambiare per tutte le tabelle codici supportate. Puoi semplicemente utilizzare copy-and-past il codice JSON necessario per la tua attività DMS.

### Regole di confronto EBCDIC specifiche per Micro Focus
<a name="CHAP_Source.DB2zOS.EBCDIC.MicroFocus"></a>

Per Micro Focus, cambia un sottoinsieme di caratteri in base alle necessità per le seguenti regole di confronto.

```
 da-DK-cp1142m-x-icu
 de-DE-cp1141m-x-icu
 en-GB-cp1146m-x-icu
 en-US-cp1140m-x-icu
 es-ES-cp1145m-x-icu
 fi-FI-cp1143m-x-icu
 fr-FR-cp1147m-x-icu
 it-IT-cp1144m-x-icu
 nl-BE-cp1148m-x-icu
```

**Example Cambiamenti di dati Micro Focus per regola di confronto:**  
**en\$1us\$1cp1140m**  
Cambiamento di codice:  

```
0000    0180
00A6    0160
00B8    0161
00BC    017D
00BD    017E
00BE    0152
00A8    0153
00B4    0178
```
Mappatura degli input corrispondente per un'attività: AWS DMS   

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1141m**  
Cambiamento di codice:  

```
0000    0180
00B8    0160
00BC    0161
00BD    017D
00BE    017E
00A8    0152
00B4    0153
00A6    0178
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1142m**  
Cambiamento di codice:  

```
0000    0180
00A6    0160
00B8    0161
00BC    017D
00BD    017E
00BE    0152
00A8    0153
00B4    0178
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1143m**  
Cambiamento di codice:  

```
0000    0180
00B8    0160
00BC    0161
00BD    017D
00BE    017E
00A8    0152
00B4    0153
00A6    0178
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1144m**  
Cambiamento di codice:  

```
0000    0180
00B8    0160
00BC    0161
00BD    017D
00BE    017E
00A8    0152
00B4    0153
00A6    0178
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1145m**  
Cambiamento di codice:  

```
0000    0180
00A6    0160
00B8    0161
00A8    017D
00BC    017E
00BD    0152
00BE    0153
00B4    0178
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1146m**  
Cambiamento di codice:  

```
0000    0180
00A6    0160
00B8    0161
00BC    017D
00BD    017E
00BE    0152
00A8    0153
00B4    0178
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1147m**  
Cambiamento di codice:  

```
0000    0180
00B8    0160
00A8    0161
00BC    017D
00BD    017E
00BE    0152
00B4    0153
00A6    0178
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"}
```
**en\$1us\$1cp1148m**  
Cambiamento di codice:  

```
0000    0180
00A6    0160
00B8    0161
00BC    017D
00BD    017E
00BE    0152
00A8    0153
00B4    0178
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"}
,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"}
,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"}
,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"}
,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"}
,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"}
,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"}
```

### BluAge regole di confronto EBCDIC specifiche
<a name="CHAP_Source.DB2zOS.EBCDIC.BluAge"></a>

Infatti BluAge, sposta tutti i seguenti *valori bassi* e *alti* secondo necessità. Queste regole di confronto devono essere utilizzate solo per supportare il servizio Mainframe Migration BluAge .

```
da-DK-cp1142b-x-icu
 da-DK-cp277b-x-icu
 de-DE-cp1141b-x-icu
 de-DE-cp273b-x-icu
 en-GB-cp1146b-x-icu
 en-GB-cp285b-x-icu
 en-US-cp037b-x-icu
 en-US-cp1140b-x-icu
 es-ES-cp1145b-x-icu
 es-ES-cp284b-x-icu
 fi-FI-cp1143b-x-icu
 fi-FI-cp278b-x-icu 
 fr-FR-cp1147b-x-icu
 fr-FR-cp297b-x-icu
 it-IT-cp1144b-x-icu
 it-IT-cp280b-x-icu
 nl-BE-cp1148b-x-icu
 nl-BE-cp500b-x-icu
```

**Example BluAge Cambiamenti di dati:**  
**da-DK-cp277b** e **da-DK-cp1142b**  
Cambiamento di codice:  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**de-DE-273b** e **de-DE-1141b**  
Cambiamento di codice:  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**en-GB-285b** e **en-GB-1146b**  
Cambiamento di codice:  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
{"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**en-us-037b** e **en-us-1140b**  
Cambiamento di codice:  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
{"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**es-ES-284b** e **es-ES-1145b**  
Cambiamento di codice:  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**fi\$1FI-278b** e **fi-FI-1143b**  
Cambiamento di codice:  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**fr-FR-297b** e **fr-FR-1147b**  
Cambiamento di codice:  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
{"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**it-IT-280b** e **it-IT-1144b**  
Cambiamento di codice:  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```
**nl-BE-500b** e **nl-BE-1148b**  
Cambiamento di codice:  

```
0180    0180
0001    0181
0002    0182
0003    0183
009C    0184
0009    0185
0086    0186
007F    0187
0097    0188
008D    0189
008E    018A
000B    018B
000C    018C
000D    018D
000E    018E
000F    018F
0010    0190
0011    0191
0012    0192
0013    0193
009D    0194
0085    0195
0008    0196
0087    0197
0018    0198
0019    0199
0092    019A
008F    019B
001C    019C
001D    019D
001E    019E
001F    019F
0080    01A0
0081    01A1
0082    01A2
0083    01A3
0084    01A4
000A    01A5
0017    01A6
001B    01A7
0088    01A8
0089    01A9
008A    01AA
008B    01AB
008C    01AC
0005    01AD
0006    01AE
0007    01AF
0090    01B0
0091    01B1
0016    01B2
0093    01B3
0094    01B4
0095    01B5
0096    01B6
0004    01B7
0098    01B8
0099    01B9
009A    01BA
009B    01BB
0014    01BC
0015    01BD
009E    01BE
001A    01BF
009F    027F
```
Mappatura degli input corrispondente per un' AWS DMS attività:  

```
 {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"}
,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"}
,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"}
,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"}
,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"}
,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"}
,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"}
,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"}
,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"}
,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"}
,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"}
,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"}
,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"}
,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"}
,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"}
,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"}
,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"}
,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"}
,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"}
,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"}
,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"}
,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"}
,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"}
,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"}
,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"}
,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"}
,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"}
,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"}
,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"}
,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"}
,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"}
,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"}
,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"}
,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"}
,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"}
,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"}
,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"}
,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"}
,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"}
,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"}
,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"}
,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"}
,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"}
,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"}
,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"}
,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"}
,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"}
,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"}
,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"}
,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"}
,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"}
,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"}
,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"}
,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"}
,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"}
,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"}
,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"}
,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"}
,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"}
,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"}
,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"}
,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"}
,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"}
,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"}
,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"}
```