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

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:

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:

Miglioramento delle prestazioni di una migrazione AWS DMS

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

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

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.

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:

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:

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:

I seguenti endpoint di destinazione hanno supporto LOB completo:

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

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

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:

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:

Per ulteriori informazioni, consulta AWS Convalida dei dati 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:

Per ulteriori informazioni sul monitoraggio dei parametri, consulta AWS DMSAttività di monitoraggio.

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:

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 DMSnote di rilascio.

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: