Best practice per AWS Database Migration Service

Per utilizzare AWS Database Migration Service (AWS DMS) in modo più efficiente, consulta i consigli in questa sezione sul modo più efficiente per migrare i dati.

Pianificazione della migrazione di AWS Database Migration Service

Durante la pianificazione della migrazione di un database tramite AWS Database Migration Service, considera quando segue:

• Dovrai configurare una rete per connettere i database di origine e di destinazione a un'istanza di replica AWS DMS. Per eseguire questa operazione, è sufficiente collegare due risorse AWS nello stesso cloud privato virtuale (VPC) dell'istanza di replica. Tuttavia puoi anche eseguire configurazioni più complesse, come la connessione di un database on-premise a un'istanza database Amazon RDS tramite una rete privata virtuale (VPN). Per ulteriori informazioni, consulta Configurazioni di rete per la migrazione del database.

• Endpoint di origine e di destinazione: dovrai sapere quali informazioni e tabelle del database di origine devono essere migrate al database di destinazione. AWS DMS supporta la migrazione dello schema di base, inclusa la creazione di tabelle e chiavi primarie. Tuttavia, AWS DMS non crea automaticamente nel database di destinazione gli indici secondari, le chiavi esterne, gli account utente e così via. A seconda del motore di database di origine e di destinazione, può essere necessario configurare un log supplementare o modificare altre impostazioni per il database di origine o di destinazione. Per ulteriori informazioni, consultare Origini per la migrazione dei dati e Destinazioni per la migrazione dei dati.

• Migrazione di schema e codice: AWS DMS non esegue la conversione dello schema o del codice. Puoi utilizzare strumenti quali Oracle SQL Developer, MySQL Workbench e pgAdmin III per convertire lo schema. Se desideri convertire uno schema esistente in un altro motore di database, puoi utilizzare AWS Schema Conversion Tool (AWS SCT). Questo strumento può creare e generare uno schema di destinazione per intero con tabelle, indici, viste e così via. Puoi inoltre utilizzare lo strumento per la conversione di PL/SQL o TSQL in PgSQL e altri formati. Per ulteriori informazioni su AWS SCT, consulta la Guida per l'utente di AWS SCT.

• Tipi di dati non supportati: alcuni tipi di dati di origine devono essere convertiti nei tipi di dati equivalenti per il database di destinazione. Per ulteriori informazioni sui tipi di dati supportati, consulta la sezione relativa all'origine o alla destinazione del datastore.

• Risultati degli script di supporto diagnostico: quando pianifichi la migrazione, ti consigliamo di eseguire gli script di supporto diagnostico. Con i risultati di questi script, puoi individuare in anticipo informazioni sui potenziali errori di migrazione.

  Se è disponibile uno script di supporto per il tuo database, scaricalo utilizzando il collegamento presente nell'argomento dello script corrispondente nella sezione seguente. Dopo aver verificato e esaminato lo script, è possibile eseguirlo secondo la procedura descritta nell'argomento dello script nel proprio ambiente locale. Al termine dell'esecuzione dello script, è possibile esaminare i risultati. Ti consigliamo di eseguire questi script come prima fase di qualsiasi operazione di risoluzione dei problemi. I risultati possono essere utili quando si lavora con il team AWS Support. Per ulteriori informazioni, consulta Utilizzo degli script di supporto per la diagnostica in AWS DMS.

• Valutazioni preliminari alla migrazione: una valutazione preliminare alla migrazione analizza i componenti specifici di un'attività di migrazione del database per identificare eventuali problemi che potrebbero impedire l'esecuzione dell'attività di migrazione come previsto. Utilizzando questa valutazione è possibile identificare potenziali problemi prima di eseguire un'attività nuova o modificata. Per ulteriori informazioni sull'utilizzo delle valutazioni preliminari alla migrazione, consulta Abilitazione e utilizzo delle valutazioni preliminari alla migrazione di un'attività.

Conversione dello schema

AWS DMS non esegue la conversione dello schema o del codice. Per convertire uno schema esistente in un motore di database diverso puoi utilizzare AWS SCT. AWS SCT converte gli oggetti di origine, la tabella, gli indici, le viste, i trigger e altri oggetti di sistema nel formato DDL (Data Definition Language) di destinazione. AWS SCT può essere usato anche per convertire la maggior parte del codice dell'applicazione, ad esempio PL/SQL o TSQL, nel linguaggio di destinazione equivalente.

AWS SCT si scarica gratuitamente da AWS. Per ulteriori informazioni su AWS SCT, consulta la Guida per l'utente di AWS SCT.

Se gli endpoint di origine e di destinazione si trovano sullo stesso motore di database, puoi utilizzare strumenti come Oracle SQL Developer, MySQL Workbench PgAdmin o 4 per spostare lo schema.

Revisione della documentazione pubblica di AWS DMS

Ti consigliamo vivamente di consultare le pagine della documentazione pubblica di AWS DMS in relazione agli endpoint di origine e di destinazione prima di eseguire la prima migrazione. Questa documentazione può aiutarti a identificare i prerequisiti della migrazione e comprendere le limitazioni attuali prima di iniziare. Per ulteriori informazioni, consulta Utilizzo degli endpoint AWS DMS.

Durante la migrazione, la documentazione pubblica può aiutarti a risolvere eventuali problemi relativi ad AWS DMS. Le pagine della risoluzione dei problemi della documentazione ti consentono di risolvere i problemi più comuni utilizzando AWS DMS e i database degli endpoint selezionati. Per ulteriori informazioni, consulta Risoluzione dei problemi relativi alle attività di migrazione in AWS Database Migration Service.

Esecuzione di un proof of concept

Per facilitare l'individuazione dei problemi relativi all'ambiente nelle prime fasi della migrazione del database, ti consigliamo di eseguire una piccola migrazione di prova. In questo modo puoi anche impostare una tempistica di migrazione più realistica. Inoltre, potrebbe essere necessario eseguire una migrazione di prova completa per valutare se AWS DMS gestisce la velocità di trasmissione effettiva del database sulla rete. Durante questa attività ti consigliamo di eseguire il benchmark e ottimizzare il pieno carico iniziale e la replica continua. In questo modo puoi comprendere la latenza della rete e valutare le prestazioni complessive.

Inoltre, hai anche l'opportunità di capire il tuo profilo di dati e le dimensioni del database, tra cui:

• quante tabelle sono di dimensioni grandi, medie e piccole;

• in che modo AWS DMS gestisce le conversioni dei tipi di dati e dei set di caratteri;

• quante tabelle hanno colonne di oggetti di grandi dimensioni (LOB);

• quanto tempo è necessario per eseguire una migrazione di prova.

Miglioramento delle prestazioni di una migrazione AWS DMS

Le prestazioni della migrazione AWS DMS sono influenzate da una serie di fattori:

• la disponibilità di risorse nell'origine;

• la velocità di trasmissione effettiva della rete disponibile;

• la capacità di risorse del server di replica;

• la possibilità della destinazione di acquisire le modifiche;

• il tipo e la distribuzione dei dati di origine;

• il numero di oggetti da migrare.

È possibile migliorare le prestazioni utilizzando alcune o tutte le best practice riportate di seguito. La possibilità di utilizzare una di queste procedure dipende dal caso d'uso specifico. Di seguito sono riportate alcune limitazioni.

Provisioning di un server di replica appropriato

AWS DMS è un servizio gestito che viene eseguito su un'istanza Amazon EC2. Il servizio si connette al database di origine, legge i dati di origine, formatta i dati per l'utilizzo da parte del database di destinazione e carica i dati nel database di destinazione.

La maggior parte di questo processo si verifica in memoria. Tuttavia, per le transazioni di grandi dimensioni potrebbe essere necessario il buffering su disco. Anche le transazioni e i file di log memorizzati nella cache vengono scritti su disco. Nelle seguenti sezioni sono disponibili informazioni sui fattori da considerare nella scelta del server di replica.

CPU

AWS DMS è progettato per migrazioni eterogenee, ma supporta anche migrazioni omogenee. Per eseguire una migrazione omogenea, occorre innanzitutto convertire ogni tipo di dati di origine nel tipo di dati AWS DMS equivalente. Quindi, è necessario convertire ogni tipo di dati AWS DMS nel tipo di dati di destinazione. I riferimenti delle conversioni per ogni motore di database sono disponibili nella Guida per l'utente di AWS DMS.

AWS DMS esegue queste conversioni in modo ottimale quando la CPU è disponibile al momento delle conversioni. Il sovraccarico e la mancanza di risorse sufficienti della CPU possono causare migrazioni lente che possono anche provocare altri effetti collaterali.

Classe di istanza di replica

Alcune delle classi di istanze più piccole sono sufficienti per testare il servizio o per migrazioni di piccole dimensioni. Se la migrazione coinvolge un numero elevato di tabelle oppure se desideri eseguire diverse attività di replica simultaneamente, puoi valutare l'utilizzo di un'istanza di dimensioni maggiori. Un'istanza di dimensioni maggiori può essere l'ideale perché il servizio utilizza la giusta quantità di memoria e CPU.

Le istanze di tipo T2 sono progettate per offrire prestazioni di base moderate e garantire prestazioni notevolmente maggiori se il carico di lavoro lo richiede. Sono concepite per carichi di lavoro che non utilizzano completamente la CPU spesso o in maniera regolare, ma che occasionalmente necessitano di un incremento delle prestazioni. Le istanze T2 sono particolarmente adatte per carichi di lavoro a scopo generico, come server Web, ambienti di sviluppo e piccoli database. Se per risolvere i problemi relativi a una migrazione lenta utilizzi un tipo di istanza T2, controlla il parametro dell'host relativo all'utilizzo della CPU in quanto può indicarti se stai superando i valori di base per quel tipo di istanza.

Le classi di istanze C4 sono state concepite per fornire il livello più elevato di prestazioni del processore per i carichi di lavoro che richiedono un'elevata capacità di elaborazione. Raggiungono prestazioni significativamente più elevate in termini di pacchetti al secondo (PPS) e offrono minore instabilità di rete e minore latenza di rete. AWS DMS può richiedere un uso intensivo della CPU, soprattutto quando si eseguono migrazioni e repliche eterogenee, come la migrazione da Oracle a PostgreSQL. In questi casi, le istanze C4 possono rappresentare una scelta adeguata.

Le classi di istanze R4 sono ottimizzate per carichi di lavoro di database a memoria elevata. Le migrazioni o le repliche continue di sistemi di transazioni con velocità di trasmissione effettiva elevata che usano AWS DMS possono a volte utilizzare grandi quantità di CPU e memoria. Le istanze R4 includono una maggiore quantità di memoria per vCPU.

Supporto di AWS DMS per le classi di istanza R5 e C5

Le classi di istanza R5 includono istanze ottimizzate per la memoria che offrono prestazioni elevate per carichi di lavoro che elaborano in memoria set di dati di grandi dimensioni. Le migrazioni o le repliche continue di sistemi di transazioni con velocità di trasmissione effettiva elevata che usano AWS DMS possono a volte utilizzare grandi quantità di CPU e memoria. Le istanze R5 offrono il 5% di memoria aggiuntiva per vCPU rispetto alle istanze R4 e la dimensione più elevata fornisce 768 GiB di memoria. Inoltre, le istanze R5 consentono un miglioramento del prezzo per GiB del 10% e un aumento delle prestazioni della CPU di circa il 20% rispetto alle istanze R4.

Le classi di istanze C5 sono ottimizzate per carichi di lavoro ad alta intensità di calcolo e offrono prestazioni elevate a costi contenuti a un basso rapporto prezzo/elaborazione. Raggiungono prestazioni di rete notevolmente superiori. L'Adattatore elastico di rete (ENA) fornisce istanze C5 con un massimo di 25 Gbps di larghezza di banda della rete e fino a 14 Gbps di larghezza di banda dedicata ad Amazon EBS. AWS DMS può richiedere un uso intensivo della CPU, soprattutto quando si eseguono migrazioni e repliche eterogenee, come la migrazione da Oracle a PostgreSQL. In questi casi, le istanze C5 possono rappresentare una scelta adeguata.

Storage

In base alla classe di istanza, il server di replica dispone di 50 GB o 100 GB di archiviazione di dati. Questo spazio di archiviazione viene utilizzato per i file di log e per tutte le modifiche memorizzate nella cache raccolte durante il caricamento. Se il sistema di origine è occupato o richiede transazioni di grandi dimensioni, potrebbe essere necessario aumentare lo spazio di archiviazione. Anche se si eseguono più attività sul server di replica, potrebbe essere necessario aumentare lo spazio di archiviazione. Tuttavia, la quantità predefinita è generalmente sufficiente.

Tutti i volumi di archiviazione in AWS DMS sono GP2 o unità di memoria a stato solido (SSD) per uso generico. I volumi GP2 offrono prestazioni di base di tre operazioni di I/O al secondo (IOPS), con capacità di arrivare fino a 3.000 IOPS su una base di credito. Come regola generale, controlla i parametri ReadIOPS e WriteIOPS e per l'istanza di replica. Assicurati che la somma di questi valori non superi le prestazioni di base del volume.

Multi-AZ

La scelta di un'istanza Multi-AZ può proteggere la migrazione dagli errori di archiviazione. La maggior parte delle migrazioni sono transitorie e non sono destinate a durare per lunghi periodi di tempo. Se si utilizza AWS DMS per scopi di replica continua, la scelta di un'istanza Multi-AZ può migliorare la disponibilità in caso di problemi di archiviazione.

Quando si utilizza un'istanza di replica singola AZ o multi-AZ durante un FULL LOAD e si verifica un failover o la sostituzione dell'host, si prevede che l'attività di pieno carico abbia esito negativo. È possibile riavviare l'attività dal punto di errore per le tabelle rimanenti che non sono state completate o che si trovano in uno stato di errore.

Caricamento di più tabelle in parallelo

Per impostazione predefinita, AWS DMS carica otto tabelle alla volta. È possibile ottenere un miglioramento delle prestazioni aumentando leggermente tale numero quando si usa un server di replica di dimensioni molto grandi, ad esempio un'istanza dms.c4.xlarge o maggiore. Tuttavia, in un determinato momento, l'aumento di questo parallelismo riduce le prestazioni. Se il server di replica è relativamente piccolo, ad esempio un dms.t2.medium, ti consigliamo di ridurre il numero di tabelle caricate in parallelo.

Per modificare questo numero nella AWS Management Console, apri la console, seleziona Attività, scegli di creare o modificare un'attività, quindi seleziona Impostazioni avanzate. In Tuning Settings (Impostazioni di tuning), modifica l'opzione Maximum number of tables to load in parallel (Numero massimo di tabelle da caricare in parallelo).

Per cambiare questo numero utilizzando la AWS CLI, modifica il parametro MaxFullLoadSubTasks in TaskSettings.

Utilizzo del pieno carico parallelo

È possibile utilizzare il caricamento parallelo dalle origini Oracle, Microsoft SQL Server, MySQL, Sybase e IBM Db2 LUW in base a partizioni e sottopartizioni. In questo modo è possibile migliorare la durata complessiva del pieno carico. Inoltre, durante l'esecuzione di un'attività di migrazione AWS DMS, è possibile accelerare la migrazione delle tabelle di grandi dimensioni o partizionate. Per farlo, dividi la tabella in segmenti e carica i segmenti in parallelo nella stessa attività di migrazione.

Per utilizzare il caricamento in parallelo, è necessario creare una regola di mappatura della tabella di tipo table-settings con l'opzione parallel-load. Nella regola table-settings, è necessario specificare i criteri di selezione per la tabella o le tabelle che desideri caricare in parallelo. Per specificare i criteri di selezione, imposta l'elemento type per parallel-load su una delle impostazioni seguenti:

• partitions-auto

• subpartitions-auto

• partitions-list

• ranges

• none

Per ulteriori informazioni su queste impostazioni, consulta Regole e operazioni delle impostazioni di tabella e raccolta.

Utilizzo di indici, trigger e vincoli di integrità referenziale

Gli indici, i trigger e i vincoli di integrità referenziale possono influenzare le prestazioni di migrazione e impedirne il completamento. Il modo in cui ciò influenza la migrazione dipende dal fatto che l'attività di replica sia un'attività di pieno carico o un'attività di replica continua (acquisizione dei dati di modifica o CDC).

Per un'attività di caricamento completo, ti consigliamo di rimuovere gli indici delle chiavi primari, gli indici secondari, i vincoli di integrità referenziale e i trigger DML (Data Manipulation Language). In alternativa, è possibile ritardarne la creazione fino alla conclusione delle attività di pieno carico. Non sono necessari indici durante un'attività di pieno carico e, nel caso siano presenti, determinano costi di manutenzione. Poiché l'attività di caricamento completo carica gruppi di tabelle contemporaneamente, i vincoli di integrità referenziale sono violati. Analogamente, l'inserimento, l'aggiornamento e l'eliminazione di trigger può causare errori, ad esempio se l'inserimento di una riga viene attivato per una tabella precedentemente caricata in blocco. Anche altri tipi di trigger influenzano le prestazioni a causa di un'ulteriore elaborazione.

È possibile creare indici di chiavi primarie e secondarie prima di un'attività di pieno carico nel caso in cui i volumi di dati siano relativamente piccoli e il tempo di migrazione aggiuntivo non rappresenti un problema. I vincoli di integrità referenziale e i trigger devono essere sempre disattivati.

Per un'attività di pieno carico e CDC, ti consigliamo di aggiungere indici secondari prima della fase CDC. Poiché AWS DMS utilizza la replica logica, assicurati che gli indici secondari che supportano le operazioni DML siano presenti per evitare le scansioni dell'intera tabella. È possibile sospendere l'attività di replica prima della fase CDC per creare indici e vincoli di integrità referenziale prima di riavviare l'attività.

È necessario abilitare i trigger subito prima della conversione.

Disattivazione del log di backup e delle transazioni

Durante la migrazione a un database Amazon RDS, è consigliabile disattivare i backup e Multi-AZ sulla destinazione finché non sei pronto per la conversione. Analogamente, durante la migrazione a sistemi non Amazon RDS, è consigliabile disattivare qualsiasi log sulla destinazione fino alla conclusione della conversione.

Utilizzo di più attività

A volte l'utilizzo di più attività per una singola migrazione può migliorare le prestazioni. Se disponi di set di tabelle che non partecipano a transazioni comuni, puoi suddividere la migrazione in più attività. La coerenza transazionale viene mantenuta all'interno dell'attività, quindi è importante che le tabelle in attività separate non partecipino a transazioni comuni. Inoltre, ogni attività legge in modo indipendente il flusso di transazioni, quindi fai attenzione a non sovraccaricare il database di origine.

È possibile utilizzare più attività per creare flussi di replica separati. In questo modo, è possibile parallelizzare le letture sull'origine, i processi sull'istanza di replica e le scritture nel database di destinazione.

Ottimizzazione dell'elaborazione delle modifiche

Per impostazione predefinita, AWS DMS elabora le modifiche in una modalità transazionale, che conserva l'integrità delle transazioni. Se puoi permetterti vuoti temporanei nell'integrità delle transazioni, puoi utilizzare in alternativa l'opzione di applicazione ottimizzata in batch. Questa opzione raggruppa in modo efficiente le transazioni e le applica in batch per garantire l'efficienza. L'utilizzo dell'opzione di applicazione ottimizzata in batch viola quasi sempre i vincoli di integrità referenziale. Pertanto, ti consigliamo di disattivare questi vincoli durante il processo di migrazione e di riattivarli nel processo di conversione.

Utilizzo del server dei nomi in locale

Di solito, un'istanza di replica AWS DMS utilizza il risolutore del sistema dei nomi di dominio (DNS) in un'istanza Amazon EC2 per risolvere gli endpoint di dominio. Tuttavia, puoi utilizzare il server dei nomi on-premise per risolvere determinati endpoint se utilizzi il risolutore Amazon Route 53. Con questo strumento, puoi eseguire query tra dispositivi on-premise e AWS utilizzando gli endpoint in entrata e in uscita, le regole di inoltro e una connessione privata. I vantaggi dell'utilizzo di un server dei nomi on-premise includono una maggiore sicurezza e facilità d'uso con un firewall.

Se disponi di endpoint in entrata, puoi utilizzare le query DNS che hanno origine on-premise per risolvere i domini ospitati in AWS. Per configurare gli endpoint, assegna gli indirizzi IP in ogni sottorete a cui desideri fornire un risolutore. Per stabilire la connettività tra l'infrastruttura DNS on-premise e AWS, utilizza AWS Direct Connect o una rete privata virtuale (VPN).

Gli endpoint in uscita si connettono al server dei nomi on-premise. Il server dei nomi concede l'accesso solo agli indirizzi IP inclusi nell'elenco degli indirizzi consentiti e impostati in un endpoint in uscita. L'indirizzo IP del server dei nomi è l'indirizzo IP di destinazione. Quando scegli un gruppo di sicurezza per un endpoint in uscita, seleziona lo stesso gruppo di sicurezza utilizzato dall'istanza di replica.

Per selezionare i domini da inoltrare al server dei nomi, utilizza le regole di inoltro. Un endpoint in uscita può gestire più regole di inoltro. L'ambito della regola di inoltro è il cloud privato virtuale (VPC). Con una regola di inoltro associata a un VPC, puoi effettuare il provisioning di una sezione logicamente isolata del cloud AWS. Da questa sezione logicamente isolata, puoi avviare risorse AWS in una rete virtuale.

Puoi configurare i domini ospitati nell'infrastruttura DNS on-premise come regole di inoltro condizionale che impostano le query DNS in uscita. Quando viene effettuata una query a uno di questi domini, le regole attivano un tentativo di inoltro delle richieste DNS ai server configurati con le regole. Anche in questo caso, è necessaria una connessione privata tramite AWS Direct Connect o VPN.

Il diagramma seguente illustra l'architettura del risolutore Route 53.

Per ulteriori informazioni sul risolutore DNS Route 53, consulta Nozioni di base su Route 53 Resolver nella Guida per gli sviluppatori di Amazon Route 53.

Utilizzo del risolutore Amazon Route 53 con AWS DMS

Puoi creare un server dei nomi on-premise per AWS DMS per risolvere gli endpoint utilizzando Amazon Route 53 Resolver.

Per creare un server dei nomi on-premise per AWS DMS basato su Route 53

1. Accedi alla AWS Management Console quindi apri la console Route 53 all'indirizzo https://console.aws.amazon.com/route53/.

2. Sulla console Route 53, scegli la Regione AWS in cui desideri configurare il risolutore Route 53. Il risolutore Route 53 è specifico per una regione.

3. Scegli la direzione della query: in entrata, in uscita o entrambe.

4. Fornisci la configurazione delle query in entrata:

   1. Immetti un nome di endpoint e scegli un VPC.

   2. Assegnare una o più sottoreti dal VPC (ad esempio, scegliere due per la disponibilità).

   3. Assegna indirizzi IP specifici da utilizzare come endpoint o lascia che il risolutore Route 53 li assegni automaticamente.

5. Creare una regola per il dominio in locale in modo che i carichi di lavoro all'interno del VPC possano instradare le query DNS all'infrastruttura DNS.

6. Immetti uno o più indirizzi IP per i server DNS on-premise.

7. Invia la regola.

Al termine della creazione, il VPC è associato alle regole in entrata e in uscita e può iniziare a instradare il traffico.

Per ulteriori informazioni sul risolutore Route 53, consulta Nozioni di base su Route 53 Resolver nella Guida per gli sviluppatori di Amazon Route 53.

Migrazione di oggetti binari di grandi dimensioni (LOB)

In generale, AWS DMS esegue la migrazione di dati LOB in due fasi:

1. AWS DMS crea una nuova riga nella tabella di destinazione e la popola con tutti i dati eccetto il valore LOB associato.

2. AWS DMS aggiorna la riga nella tabella di destinazione con i dati LOB.

Questo processo di migrazione per i LOB richiede che, durante la migrazione, tutte le colonne LOB nella tabella di destinazione siano nullable. Ciò vale anche se le colonne LOB non sono nullable nella tabella di origine. Se AWS DMS crea le tabelle di destinazione, imposta le colonne LOB su nullable per impostazione predefinita. In alcuni casi, è possibile creare le tabelle di destinazione utilizzando altri meccanismi, come l'importazione o l'esportazione. In questi casi, assicurati che le colonne LOB siano annullabili prima di iniziare l'attività di migrazione.

Questo requisito ha un'eccezione. Supponi di eseguire una migrazione omogenea da un'origine Oracle a una destinazione Oracle e di scegliere Limited Lob mode (Modalità LOB limitata). In questo caso, l'intera riga viene popolata contemporaneamente, inclusi i valori LOB. Per questi casi, AWS DMS può creare le colonne LOB della tabella di destinazione con vincoli non nullable, se necessario.

Utilizzo della modalità LOB limitata

AWS DMS utilizza due metodi che bilanciano prestazioni e convenienza nel caso in cui la migrazione contenga valori LOB:

1. Limited LOB mode (Modalità LOB limitata) migra tutti i valori LOB fino a un limite di dimensioni specificato dall'utente (l'impostazione predefinita è 32 KB). I valori LOB di dimensioni superiori a questo limite devono essere migrati manualmente. Limited LOB mode (Modalità LOB limitata), l'impostazione predefinita per tutte le attività di migrazione, fornisce generalmente le prestazioni migliori. Tuttavia, accertati che l'impostazione del parametro Dimensione LOB massima sia corretta. Imposta questo parametro sulla dimensione LOB maggiore per tutte le tabelle.

2. Full LOB mode (Modalità LOB completa) migra tutti i dati LOB nelle tabelle, indipendentemente dalla dimensione. Full LOB mode (Modalità LOB completa) offre la praticità di spostare tutti i dati LOB nelle tabelle, ma il processo può avere un impatto significativo sulle prestazioni.

Per alcuni motori di database, come PostgreSQL, AWS DMS gestisce i tipi di dati JSON come LOB. Se hai scelto Modalità LOB limitata, assicurati che l'opzione Dimensione LOB massima sia impostata su un valore che non causa il troncamento dei dati JSON.

AWS DMS fornisce supporto completo per l'utilizzo di tipi di dati di oggetti di grandi dimensioni (BLOB, CLOB e NCLOB). I seguenti endpoint di origine hanno supporto LOB completo:

• Oracle

• Microsoft SQL Server

• ODBC

I seguenti endpoint di destinazione hanno supporto LOB completo:

• Oracle

• Microsoft SQL Server

Il seguente endpoint di destinazione ha supporto LOB limitato. Non è possibile utilizzare una dimensione LOB illimitata per questo endpoint di destinazione.

• Amazon Redshift

• Amazon S3

Per gli endpoint che hanno supporto LOB completo, è possibile impostare anche un limite di dimensione per i tipi di dati LOB.

Prestazioni LOB migliorate

Quando si migrano i dati LOB è possibile specificare le seguenti diverse impostazioni di ottimizzazione LOB.

Impostazioni LOB per tabella

Utilizzando le impostazioni LOB per tabella, è possibile sovrascrivere le impostazioni LOB a livello di attività per alcune o tutte le tabelle. Per farlo, definisci lob-settings nella regola table-settings. Di seguito è riportato un esempio di tabella che include valori LOB di grandi dimensioni.

SET SERVEROUTPUT ON
CREATE TABLE TEST_CLOB
(
ID NUMBER,
C1 CLOB,
C2 VARCHAR2(4000)
);
DECLARE
bigtextstring CLOB := '123';
iINT;
BEGIN
WHILE Length(bigtextstring) <= 60000 LOOP
bigtextstring := bigtextstring || '000000000000000000000000000000000';
END LOOP;
INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue');
END;
/
SELECT * FROM TEST_CLOB;
COMMIT

Quindi, crea un'attività di migrazione e modifica la gestione LOB per la tabella utilizzando la nuova regola lob-settings. Il valore bulk-max-siz determina la dimensione LOB massima (KB). I dati LOB vengono troncati se sono maggiori della dimensione specificata.

{
	"rules": [{
			"rule-type": "selection",
			"rule-id": "1",
			"rule-name": "1",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"rule-action": "include"
		},
		{
			"rule-type": "table-settings",
			"rule-id": "2",
			"rule-name": "2",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"lob-settings": {
				"mode": "limited",
				"bulk-max-size": "16"
			}
		}
	]
}

Anche se questa attività AWS DMS viene creata con FullLobMode : true, le impostazioni LOB per tabella indicano a AWS DMS di troncare i dati LOB in questa particolare tabella a 16.000. È possibile controllare i log delle attività per verificare.

721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table
'HR.TEST_CLOB' was truncated to length 16384

Impostazioni LOB in linea

Quando si crea un'attività AWS DMS, la modalità LOB determina come vengono gestiti i LOB.

È disponibile la modalità LOB completa e la modalità LOB limitata, ognuna con vantaggi e svantaggi. La modalità LOB in linea combina i vantaggi della modalità LOB completa e della modalità LOB limitata.

È possibile utilizzare la modalità LOB in linea quando è necessario replicare LOB di piccole e grandi dimensioni e la maggior parte dei LOB è di piccole dimensioni. Quando si sceglie questa opzione, durante il pieno carico l'attività AWS DMS trasferisce i LOB di piccole dimensioni in linea, ottenendo maggiore efficienza. L'attività AWS DMS trasferisce i LOB di grandi dimensioni eseguendo una ricerca nella tabella di origine.

Durante l'elaborazione delle modifiche, i LOB di piccole e grandi dimensioni vengono replicati eseguendo una ricerca nella tabella di origine.

Quando si utilizza la modalità LOB in linea, l'attività AWS DMS controlla tutte le dimensioni dei LOB per determinare quali trasferire in linea. I LOB più grandi della dimensione specificata vengono replicati utilizzando la modalità LOB completa. Pertanto, se la maggior parte dei LOB è più grande dell'impostazione specificata, è consigliabile non utilizzare questa opzione. Abilita invece la dimensione LOB illimitata.

Questa opzione viene configurata nelle impostazioni dell'attività utilizzando l'attributo InlineLobMaxSize, che è disponibile solo quando FullLobMode è impostato su true. Il valore predefinito per InlineLobMaxSize è 0 e l'intervallo è compreso tra 1 e 102400 kilobyte (100 MB).

Ad esempio, si potrebbero utilizzare le seguenti impostazioni dell'attività AWS DMS. In questo caso, impostando InlineLobMaxSize sul valore 5, tutti i LOB inferiori o uguali a 5 KiB (5.120 byte) vengono trasferiti in linea.

{
  "TargetMetadata": {
  "TargetSchema": "",
  "SupportLobs": true,
  "FullLobMode": true,
  "LobChunkSize": 64,
  "LimitedSizeLobMode": false,
  "LobMaxSize": 32,
  "InlineLobMaxSize": 5,
  "LoadMaxFileSize": 0,
  "ParallelLoadThreads": 0,
  "ParallelLoadBufferSize":0,
  "BatchApplyEnabled": false,
  "TaskRecoveryTableEnabled": false},
  . . .
}

Miglioramento delle prestazioni per la migrazione di tabelle di grandi dimensioni usando il filtro di riga

Per migliorare le prestazioni della migrazione di una tabella di grandi dimensioni, è possibile suddividere la migrazione in più attività. Per suddividere la migrazione in più attività utilizzando il filtro delle righe, utilizza una chiave o una chiave di partizione. Ad esempio, se hai un ID della chiave primaria intero da 1 a 8.000.000, puoi creare otto attività utilizzando il filtro delle righe per migrare 1 milione di record in ciascuna attività.

Per applicare il filtro di riga nella console:

1. Apri la AWS Management Console.

2. Scegli Attività e crea una nuova attività.

3. Scegli la scheda Mappature delle tabelle ed espandi Regole di selezione.

4. Scegli Aggiungi nuova regola di selezione. A questo punto puoi aggiungere un filtro di colonna con una condizione inferiore o uguale a, maggiore o uguale a, uguale a o di intervallo tra due valori. Per ulteriori informazioni sul filtro di colonna, consulta Specifica della selezione delle tabelle e delle regole di trasformazione dalla console.

Se hai una tabella di grandi dimensioni partizionata per data, puoi migrare i dati in base alla data. Ad esempio, supponi di disporre di una tabella partizionata per mese e solo i dati del mese corrente sono aggiornati. In questo caso, puoi creare un'attività di pieno carico per ogni partizione mensile statica e creare un'attività di pieno carico e CDC per la partizione attualmente aggiornata.

Se la tabella dispone di una chiave primaria a colonna singola o un indice univoco, puoi fare in modo che l'attività AWS DMS segmenti la tabella utilizzando un caricamento parallelo di tipo intervallo per caricare i dati in parallelo. Per ulteriori informazioni, consulta Regole e operazioni delle impostazioni di tabella e raccolta.

La replica continua

AWS DMS fornisce la replica continua dei dati, mantenendo i database di origine e di destinazione sincronizzati. Replica solo una quantità limitata di istruzioni DDL (Data Definition Language). AWS DMS non propaga elementi come gli indici, gli utenti, i privilegi, le stored procedure e altre modifiche di database non direttamente correlate alla tabella dei dati.

Se prevedi di utilizzare la replica continua, imposta l'opzione Multi-AZ al momento della creazione dell'istanza di replica. Scegliendo Multi-AZ, ottieni elevata disponibilità e il supporto per il failover dell'istanza di replica. Tuttavia, questa opzione può avere un impatto sulle prestazioni e rallentare la replica durante l'applicazione delle modifiche al sistema di destinazione.

Prima di aggiornare i database di origine o di destinazione, si consiglia di interrompere tutte le attività AWS DMS in esecuzione su questi database. Riprendi le attività una volta completati gli aggiornamenti.

Durante la replica continua, è fondamentale identificare la larghezza di banda della rete tra il sistema di database di origine e l'istanza di replica AWS DMS. Assicurati che la rete non causi colli di bottiglia durante la replica continua.

È inoltre importante identificare la percentuale di modifica e la generazione dei log di archiviazione per ora sul sistema di database di origine. In questo modo è possibile comprendere la velocità di trasmissione effettiva che si può ottenere durante la replica continua.

Riduzione del carico del database di origine

AWS DMS utilizza alcune risorse del database di origine. Durante un'attività di caricamento completo, AWS DMS esegue la scansione completa della tabella di origine per ciascuna tabella elaborata in parallelo. Inoltre, ogni attività creata nell'ambito di una migrazione esegue sull'origine query relative alle modifiche come parte del processo della CDC. Affinché AWS DMS esegua il CDC per alcune origini, come Oracle, potrebbe essere necessario aumentare la quantità di dati scritti nel change log del database.

Se riscontri un sovraccarico del database di origine, riduci il numero di attività o tabelle per ogni attività per la migrazione. Ogni attività ottiene le modifiche dell'origine in modo indipendente, perciò il consolidamento delle attività può ridurre il carico di lavoro di acquisizione delle modifiche.

Riduzione dei colli di bottiglia sul database di destinazione

Durante la migrazione, prova a rimuovere tutti i processi relativi alle risorse di scrittura sul database di destinazione:

• Disattiva i trigger non necessari.

• Disattiva gli indici secondari durante il caricamento iniziale e riattivali in un secondo momento durante la replica continua.

• Con i database Amazon RDS è opportuno disattivare i backup e Multi-AZ fino al momento della conversione.

• Durante la migrazione in sistemi non RDS, è opportuno disattivare qualsiasi log sulla destinazione fino alla conversione.

Utilizzo della convalida dei dati durante la migrazione

Per garantire che i dati siano stati migrati in modo accurato dall'origine alla destinazione, ti consigliamo vivamente di utilizzare la convalida dei dati. Se attivi la convalida dei dati per un'attività, AWS DMS inizia a confrontare i dati di origine e di destinazione immediatamente dopo l'esecuzione di un pieno carico per una tabella.

La convalida dei dati funziona con i seguenti database se AWS DMS li supporta come endpoint di origine e di destinazione:

• Oracle

• PostgreSQL

• MySQL

• MariaDB

• Microsoft SQL Server

• Amazon Aurora edizione compatibile con MySQL

• Amazon Aurora PostgreSQL-Compatible Edition

• IBM Db2 LUW

• Amazon Redshift

Per ulteriori informazioni, consulta Convalida dei dati in AWS DMS.

Monitoraggio delle attività AWS DMS tramite i parametri

Sono disponibili diverse opzioni per monitorare i parametri relativi alle attività tramite la console AWS DMS:

Parametri degli host

Puoi trovare le metriche degli host nella scheda Metriche per ogni particolare istanza di replica. CloudWatch Qui puoi controllare se l'istanza di replica è dimensionata in modo appropriato.

Parametri dell'attività di replica

Le metriche relative alle attività di replica, comprese le modifiche in entrata e confermate, e la latenza tra l'host di replica e i database di origine/destinazione sono disponibili nella scheda Metriche per ogni attività particolare. CloudWatch

Parametri della tabella

I parametri delle singole tabelle sono disponibili nella scheda Statistiche della tabella per ogni singola attività. I parametri includono i seguenti numeri:

• righe caricate durante il pieno carico;

• inserimenti, aggiornamenti ed eliminazioni dall'inizio dell'attività;

• operazioni DDL dall'inizio dell'attività.

Per ulteriori informazioni sul monitoraggio dei parametri, consulta Monitoraggio delle attività AWS DMS.

Eventi e notifiche

AWS DMS utilizza Amazon SNS per inviare notifiche quando si verifica un evento di AWS DMS, ad esempio la creazione o l'eliminazione di un'istanza di replica. Puoi utilizzare queste notifiche in qualsiasi formato supportato da Amazon SNS per una regione AWS. Possono includere messaggi e-mail, messaggi di testo o chiamate a un endpoint HTTP.

Per ulteriori informazioni, consulta Utilizzo degli eventi e delle notifiche Amazon SNS in AWS Database Migration Service.

Utilizzo del log delle attività per risolvere i problemi relativi alla migrazione

In alcuni casi, AWS DMS può riscontrare problemi per cui vengono visualizzati avvisi o messaggi di errore solo nel log delle attività. In particolare, i problemi di troncamento dei dati o rifiuti di righe a causa di violazioni delle chiavi esterne vengono scritti solo nel log delle attività. Pertanto, assicurati di esaminare il log delle attività durante la migrazione di un database. Per visualizzare il registro delle attività, configura Amazon CloudWatch come parte della creazione delle attività.

Per ulteriori informazioni, consulta Monitoraggio delle attività di replica tramite Amazon CloudWatch.

Risoluzione dei problemi delle attività di replica con Time Travel

Per risolvere i problemi di migrazione di AWS DMS puoi utilizzare Time Travel. Per ulteriori informazioni su Time Travel, consulta Impostazioni delle attività Time Travel.

Quando utilizzi Time Travel, tieni presente le seguenti considerazioni:

• Per evitare il sovraccarico su un'istanza di replica DMS, attiva Time Travel solo per le attività che richiedono il debug.

• Quando utilizzi Time Travel per risolvere i problemi relativi alle attività di replica che potrebbero durare diversi giorni, monitora i parametri delle istanze di replica per verificare il sovraccarico delle risorse. Questo approccio si applica soprattutto nei casi in cui carichi di transazioni elevati vengono eseguiti sui database di origine per lunghi periodi di tempo. Per ulteriori dettagli, consulta Monitoraggio delle attività AWS DMS.

• Quando l'impostazione dell'attività Time Travel EnableRawData è impostata su true, l'utilizzo della memoria delle attività durante la replica DMS potrebbe essere maggiore rispetto a quando Time Travel non è attivato. Se attivi Time Travel per lunghi periodi di tempo, monitora l'attività.

• Attualmente puoi attivare Time Travel solo a livello di attività. Le modifiche a tutte le tabelle vengono registrate nei log di Time Travel. Se occorre risolvere problemi relativi a tabelle specifiche in un database con un volume di transazioni elevato, crea un'attività separata.

Modifica dell'utente e dello schema per una destinazione Oracle

Quando utilizzi Oracle come destinazione, AWS DMS esegue la migrazione dei dati allo schema di proprietà dell'utente dell'endpoint di destinazione.

Ad esempio, supponi di eseguire la migrazione di uno schema denominato PERFDATA a un endpoint di destinazione Oracle e che il nome utente dell'endpoint di destinazione sia MASTER. AWS DMS si collega alla destinazione Oracle come MASTER e popola lo schema MASTER con gli oggetti di database di PERFDATA.

Per sostituire questo comportamento, fornisci una trasformazione dello schema. Ad esempio, per migrare gli oggetti dello schema PERFDATA a uno schema PERFDATA nell'endpoint di destinazione, utilizza la seguente trasformazione.

{
    "rule-type": "transformation",
    "rule-id": "2",
    "rule-name": "2",
    "object-locator": {
        "schema-name": "PERFDATA"
    },
    "rule-target": "schema",
    "rule-action": "rename",
    "value": "PERFDATA"
}

Per ulteriori informazioni sulle trasformazioni, consulta Specifica della selezione delle tabelle e delle regole di trasformazione tramite JSON.

Modifica di spazi di tabella per tabelle e indici di una destinazione Oracle

Quando si utilizza Oracle come destinazione, AWS DMS esegue la migrazione di tutte le tabelle e gli indici nello spazio di tabella predefinito nella destinazione. Ad esempio, supponi che l'origine sia un motore di database diverso da Oracle. Tutte le tabelle e gli indici della destinazione vengono migrati negli stessi spazi di tabella predefiniti.

Per sostituire questo comportamento, fornisci le corrispondenti trasformazioni degli spazi di tabella. Ad esempio, supponi di eseguire la migrazione di tabelle e indici negli spazi tabella delle tabelle e degli indici nella destinazione Oracle che sono denominati dopo lo schema nell'origine. In questo caso, puoi utilizzare trasformazioni simili alla seguente: Di seguito, lo schema nell'origine è denominato INVENTORY e gli spazi di tabella corrispondenti delle tabelle e degli indici nella destinazione sono denominati INVENTORYTBL e INVENTORYIDX.

{
   "rule-type": "transformation",
   "rule-id": "3",
   "rule-name": "3",
   "rule-action": "rename",
   "rule-target": "table-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "table-tablespace-name": "%"
   },
   "value": "INVENTORYTBL"
},
{
   "rule-type": "transformation",
   "rule-id": "4
   "rule-name": "4",
   "rule-action": "rename",
   "rule-target": "index-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "index-tablespace-name": "%"
   },
   "value": "INVENTORYIDX"
}

Per ulteriori informazioni sulle trasformazioni, consulta Specifica della selezione delle tabelle e delle regole di trasformazione tramite JSON.

Quando Oracle è sia origine che destinazione, è possibile mantenere le assegnazioni dello spazio di tabella per tabelle o indici esistenti impostando l'attributo aggiuntivo di connessione di origine Oracle enableHomogenousTablespace=true. Per ulteriori informazioni, consulta Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS.

Aggiornamento della versione di un'istanza di replica

AWS rilascia periodicamente nuove versioni del software del motore di replica AWS DMS, contenenti nuove funzionalità e miglioramenti in termini di prestazioni. Ogni versione del software del motore di replica dispone di un proprio numero di versione. È fondamentale testare la versione esistente dell'istanza di replica AWS DMS che esegue un carico di lavoro di produzione prima di aggiornare l'istanza di replica a una versione successiva. Per ulteriori informazioni sugli aggiornamenti delle versioni disponibili, consulta AWS Note di rilascio DMS.

Comprensione dei costi di migrazione

AWS Database Migration Service consente di migrare i database in AWS in modo semplice e sicuro. Paghi solo per le istanze di replica e l'eventuale archiviazione di log aggiuntiva. Ogni istanza di migrazione del database include un'archiviazione sufficiente per lo spazio di scambio, i log di replica e la cache dei dati per la maggior parte delle repliche e il trasferimento dei dati in entrata è gratuito.

Potrebbero essere necessarie più risorse durante il caricamento iniziale o durante i picchi di caricamento. Puoi monitorare attentamente l'utilizzo delle risorse delle istanze di replica con i parametri di CloudWatch. Quindi puoi aumentare e ridurre la dimensione dell'istanza di replica in base all'utilizzo.

Per ulteriori informazioni sulla stima dei costi di migrazione, consulta:

• Prezzi di AWS Database Migration Service

• AWS Pricing Calculator