Risoluzione dei problemi relativi alle attività di migrazione in AWS Database Migration Service - AWS Servizio di migrazione del Database
Attività di migrazione eseguite lentamenteLa barra di stato dell'attività non si spostaL'attività è stata completata ma non è stato migrato nullaIndici secondari e chiavi esterne mancantiAWS DMSnon crea registri CloudWatch Problemi con la connessione ad Amazon RDSProblemi di reteBlocco del CDC dopo il pieno caricoErrori di violazione delle chiavi primarie al riavvio di un'attivitàIl caricamento iniziale dello schema ha esito negativoEsito negativo delle attività con errore sconosciutoL'attività riavvia il caricamento delle tabelle dall'inizioIl numero di tabelle per attività causa problemiAttività non riuscite durante la creazione della chiave primaria in una colonna LOBRecord duplicati nella tabella di destinazione senza chiave primariaEndpoint di origine nell'intervallo IP riservatoTimestamp confusi nelle query di Amazon AthenaRisoluzione dei problemi con OracleRisoluzione dei problemi relativi a MySQLRisoluzione dei problemi relativi a PostgreSQLRisoluzione dei problemi relativi a Microsoft SQL ServerRisoluzione dei problemi relativi ad Amazon RedshiftRisoluzione dei problemi relativi ad Amazon Aurora MySQL Risoluzione dei problemi relativi a SAP ASERisoluzione dei problemi relativi a IBM Db2

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

Risoluzione dei problemi relativi alle attività di migrazione in AWS Database Migration Service

Di seguito sono disponibili gli argomenti relativi alla risoluzione dei problemi per AWS Database Migration Service (AWS DMS). Questi argomenti ti consentono di risolvere i problemi più comuni utilizzando AWS DMS e i database degli endpoint selezionati.

Se hai aperto un caso del Supporto AWS, il tecnico dell'assistenza può identificare un potenziale problema con una delle configurazioni del database degli endpoint. Il tecnico può anche chiederti di eseguire uno script di supporto per ottenere di diagnostica sul database. Per informazioni dettagliate su come scaricare, eseguire e caricare le informazioni di diagnostica da questo tipo di script di supporto, consulta Utilizzo degli script di supporto per la diagnostica in AWS DMS.

Ai fini della risoluzione dei problemi, AWS DMS raccoglie i file di traccia e dump nell'istanza di replica. Puoi fornire questi file a AWS Support nel caso in cui si verifichi un problema che richieda la risoluzione dei problemi. Per impostazione predefinita, DMS elimina i file di traccia e di dump più vecchi di trenta giorni. Per disattivare la raccolta di file trace and dump, apri un caso con AWS Support.

Argomenti

Attività di migrazione eseguite lentamente

Sono molteplici i problemi che possono causare l'esecuzione lenta di un'attività di migrazione o il rallentamento delle attività successive rispetto a quella iniziale.

Il motivo più comune per l'esecuzione lenta di un'attività di migrazione è l'allocazione di risorse insufficienti per l'istanza di replica AWS DMS. Per assicurarti che l'istanza disponga di risorse sufficienti per le attività in esecuzione, controlla l'utilizzo di CPU, memoria, file di swap e IOPS dell'istanza di replica. Ad esempio, più attività con Amazon Redshift come endpoint richiedono un utilizzo intensivo di IO. Per una migrazione più efficiente, puoi aumentare gli IOPS per l'istanza di replica o suddividere le attività su più istanze di replica.

Per ulteriori informazioni sulla determinazione delle dimensioni dell'istanza di replica, consulta Selezione della dimensione migliore per un'istanza di replica.

Puoi aumentare la velocità di un carico di migrazione iniziale nel modo seguente:

  • Se la destinazione è un'istanza database Amazon RDS, verifica che la configurazione Multi-AZ non sia abilitata per l'istanza database di destinazione.

  • Disattiva eventuali backup automatici o la registrazione sul database di destinazione durante il caricamento e attiva nuovamente queste funzionalità una volta completata la migrazione.

  • Se la funzionalità è disponibile sulla destinazione, utilizza la capacità di IOPS allocata.

  • Se i dati di migrazione contengono LOB, verifica che l'attività sia ottimizzata per la migrazione di LOB. Per ulteriori informazioni sull'ottimizzazione dei LOB, consulta Impostazioni delle attività dei metadati di destinazione.

La barra di stato dell'attività non si sposta

La barra di stato dell'attività fornisce una stima dell'avanzamento dell'attività. La qualità di questa stima dipende dalla qualità delle statistiche della tabella del database di origine; migliori sono le statistiche della tabella, più accurata è la stima.

Per un'attività con una sola tabella che non prevede alcuna statistica delle righe stimate, AWS DMS non è in grado di fornire alcuna stima della percentuale di completamento. In questo caso, utilizza lo stato dell'attività e l'indicazione delle righe caricate per confermare che l'attività è effettivamente in esecuzione e in avanzamento.

L'attività è stata completata ma non è stato migrato nulla

Effettua le seguenti operazioni se non è stato migrato nulla dopo il completamento dell'attività.

Indici secondari e chiavi esterne mancanti

AWS DMS crea tabelle, chiavi primarie e, in alcuni casi, indici univoci, ma non crea altri oggetti non necessari per migrare in modo efficiente i dati dall'origine. Ad esempio, non crea indici secondari, vincoli di chiavi non primarie o impostazioni predefinite dei dati.

Per eseguire la migrazione di oggetti secondari dal database, utilizza gli strumenti nativi del database in caso di migrazione allo stesso motore di database rispetto al database di origine. Usa AWS Schema Conversion Tool (AWS SCT) se esegui la migrazione di oggetti secondari a un motore di database diverso rispetto a quello impiegato dal database di origine.

AWS DMSnon crea registri CloudWatch

Se l'attività di replica non crea CloudWatch registri, assicurati che il ruolo sia assegnato al tuo account. dms-cloudwatch-logs-role Se questo ruolo non è presente, procedi come segue per crearlo:

  1. Accedi alla AWS Management Console e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.

  2. Scegli la scheda Ruoli. Scegli Crea ruolo.

  3. Nella sezione Seleziona il tipo di identità attendibile scegli Servizio AWS.

  4. Nella sezione Scegli un caso d'uso seleziona DMS.

  5. Scegli Successivo: Autorizzazioni.

  6. Entra AmazonDMSCloudWatchLogsRole nel campo di ricerca e seleziona la casella accanto ad AmazonDMS. CloudWatchLogsRole Ciò concede le AWS DMS autorizzazioni di accesso. CloudWatch

  7. Scegliere Next: Tags (Successivo: Tag).

  8. Scegliere Next:Review (Successivo: Rivedi).

  9. Per Nome ruolo immetti dms-cloudwatch-logs-role. Il nome rispetta la distinzione tra maiuscole e minuscole.

  10. Scegli Crea ruolo.

Problemi con la connessione ad Amazon RDS

Possono essere diversi i motivi per cui non riesci a connetterti a un'istanza database Amazon RDS che hai impostato come origine o destinazione. Di seguito sono riportati alcuni punti da controllare:

  • Verifica che la combinazione nome utente e password sia corretta.

  • Verifica che il valore di endpoint mostrato nella console di Amazon RDS per l'istanza sia lo stesso dell'identificatore dell'endpoint che hai utilizzato per creare l'endpoint AWS DMS.

  • Verifica che il valore di porta mostrato nella console Amazon RDS per l'istanza corrisponda alla porta assegnata all'endpoint AWS DMS.

  • Verifica che il gruppo di sicurezza assegnato all'istanza database di Amazon RDS consenta connessioni dall'istanza di replica AWS DMS.

  • Se l'istanza di replica AWS DMS e l'istanza database Amazon RDS non si trovano nello stesso cloud privato virtuale (VPC), verifica che l'istanza database sia accessibile pubblicamente.

Messaggio di errore: Incorrect thread connection string: incorrect thread value 0 (Stringa di connessione del thread errata: valore 0 del thread errato)

Spesso, questo errore si verifica durante il test della connessione a un endpoint. Questo errore indica che la stringa di connessione non è valida. Ad esempio, contiene uno spazio dopo l'indirizzo IP dell'host. Un altro esempio è un carattere non valido copiato nella stringa di connessione.

Problemi di rete

Il problema di rete più comune riguarda il gruppo di sicurezza VPC utilizzato dall'istanza di replica AWS DMS. Per impostazione predefinita, questo gruppo di sicurezza dispone di regole che consentono la configurazione dell'uscita su 0.0.0.0/0 su tutte le porte. In molti casi, si modifica questo gruppo di sicurezza o si utilizza il proprio gruppo di sicurezza. Assicurati almeno di consentire l'uscita agli endpoint di origine e di destinazione sulle rispettive porte del database.

Altri problemi relativi alla configurazione possono essere:

  • Istanza di replica ed endpoint di origine e di destinazione nello stesso VPC: il gruppo di sicurezza utilizzato dagli endpoint deve consentire l'ingresso sulla porta del database dall'istanza di replica. Assicurati che il gruppo di sicurezza utilizzato dall'istanza di replica abbia accesso agli endpoint. In alternativa, puoi creare una regola nel gruppo di sicurezza utilizzato dagli endpoint, che autorizzi l'indirizzo IP privato dell'accesso all'istanza di replica.

  • L'endpoint di origine è esterno al VPC utilizzato dall'istanza di replica (utilizzando un gateway Internet): il gruppo di sicurezza VPC deve includere le regole di instradamento che inviano al gateway Internet il traffico non destinato al VPC. In questa configurazione, la connessione all'endpoint viene eseguita dall'indirizzo IP pubblico sull'istanza di replica.

  • L'endpoint di origine è esterno al VPC utilizzato dall'istanza di replica (utilizzando un gateway NAT): puoi configurare un gateway Network Address Translation (NAT) utilizzando un singolo indirizzo IP elastico associato a un'unica interfaccia di rete elastica. Questo gateway NAT riceve un identificatore NAT (nat-#####).

    In alcuni casi, il VPC include un percorso predefinito verso il gateway NAT anziché il gateway Internet. In questi casi, l'istanza di replica contatta l'endpoint del database utilizzando l'indirizzo IP pubblico del gateway NAT. In questo caso, l'ingresso all'endpoint del database all'esterno del VPC deve consentire l'ingresso dall'indirizzo NAT anziché dall'indirizzo IP pubblico dell'istanza di replica.

Per informazioni sull'uso del server dei nomi on-premise, consulta Utilizzo del server dei nomi in locale.

Blocco del CDC dopo il pieno carico

Il rallentamento o il blocco delle modifiche di replica può verificarsi dopo la migrazione di un caricamento completo se più impostazioni di AWS DMS sono in conflitto tra loro.

Ad esempio, supponi che il parametro Modalità di preparazione della tabella di destinazione sia impostato su Nessuna operazione o Tronca. In questo caso, hai richiesto ad AWS DMS di non eseguire alcuna configurazione sulle tabelle di destinazione, inclusa la creazione di indici primari e unici. Se non hai creato chiavi primarie o univoche sulle tabelle di destinazione, AWS DMS esegue una scansione completa delle tabelle per ogni aggiornamento. Questo approccio può influire in modo significativo sulle prestazioni.

Errori di violazione delle chiavi primarie al riavvio di un'attività

Questo errore può verificarsi quando i dati rimangono nel database di destinazione da un'attività di migrazione precedente. Se l'opzione Modalità di preparazione della tabella di destinazione è impostata su Nessuna operazione, AWS DMS non effettua alcuna preparazione sulla tabella di destinazione, inclusa la pulizia dei dati inseriti da un'attività precedente.

Per riavviare l'attività ed evitare questi errori, rimuovi le righe inserite nelle tabelle di destinazione dalla precedente esecuzione dell'attività.

Il caricamento iniziale dello schema ha esito negativo

In alcuni casi, il caricamento iniziale dello schema potrebbe non riuscire con l'errore Operation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails=.

In questi casi, l'account utente utilizzato da AWS DMS per connettersi all'endpoint di origine non dispone delle autorizzazioni necessarie.

Esito negativo delle attività con errore sconosciuto

Le cause dei tipi di errore sconosciuto possono essere diverse. Tuttavia, spesso riscontriamo che il problema riguarda risorse insufficienti allocate all'istanza di replica AWS DMS.

Controlla l'utilizzo di CPU, memoria, file di swap e IOPS dell'istanza di replica per verificare che l'istanza disponga di risorse sufficienti per eseguire la migrazione. Per ulteriori informazioni sul monitoraggio, consulta Parametri di AWS Database Migration Service.

L'attività riavvia il caricamento delle tabelle dall'inizio

AWS DMS riavvia il caricamento delle tabelle dall'inizio quando non ha terminato il caricamento iniziale di una tabella. Quando un'attività viene riavviata, AWS DMS ricarica le tabelle dall'inizio se il caricamento iniziale non è stato completato.

Il numero di tabelle per attività causa problemi

Non è previsto alcun limite per il numero di tabelle per attività di replica. Tuttavia, come regola generale, si consiglia di limitare il numero di tabelle in un'attività a meno di 60.000. Spesso, se una singola attività impiega più di 60.000 tabelle, può verificarsi un sovraccarico delle risorse utilizzate.

Attività non riuscite durante la creazione della chiave primaria in una colonna LOB

In modalità LOB completa o modalità LOB limitata, AWS DMS non supporta la replica delle chiavi primarie che sono tipi di dati LOB.

DMS esegue inizialmente la migrazione di una riga con una colonna LOB come null, quindi aggiorna successivamente la colonna LOB. Pertanto, quando la chiave primaria viene creata su una colonna LOB, l'inserimento iniziale non riesce poiché la chiave primaria non può essere null. Come soluzione alternativa, aggiungi un'altra colonna come chiave primaria e rimuovi la chiave primaria dalla colonna LOB.

Record duplicati nella tabella di destinazione senza chiave primaria

L'esecuzione di un'attività di pieno carico e CDC può creare record duplicati sulle tabelle di destinazione prive di chiave primaria o indice univoco. Per evitare la duplicazione dei record nelle tabelle di destinazione durante le attività di pieno carico e CDC, assicurati che le tabelle di destinazione dispongano di una chiave primaria o di un indice univoco.

Endpoint di origine nell'intervallo IP riservato

Se un database di origine AWS DMS utilizza un indirizzo IP compreso nell'intervallo IP riservato 192.168.0.0/24, il test di connessione dell'endpoint di origine non riesce. La procedura seguente fornisce una possibile soluzione alternativa:

  1. Trova un'istanza Amazon EC2 che non si trova nell'intervallo riservato in grado di comunicare al database di origine in 192.168.0.0/24.

  2. Installare un proxy socat ed eseguirlo. Di seguito viene riportato un esempio.

    yum install socat
                
socat -d -d -lmlocal2 tcp4-listen:database port,bind=0.0.0.0,reuseaddr,fork tcp4:source_database_ip_address:database_port
&

Utilizza l'indirizzo IP dell'istanza Amazon EC2 e la porta del database indicata in precedenza per l'endpoint AWS DMS. Assicurati che l'endpoint disponga del gruppo di sicurezza che consente la comunicazione con AWS DMS sulla porta del database. Tieni presente che il proxy deve essere in esecuzione per tutta la durata dell'attività DMS. A seconda del caso d'uso, potrebbe essere necessario automatizzare la configurazione del proxy.

Timestamp confusi nelle query di Amazon Athena

Se i timestamp sono confusi nelle query Athena, usa l'ModifyEndpointazione AWS Management Console o per impostare il valore per il parquetTimestampInMillisecond tuo endpoint Amazon S3 su. true Per ulteriori informazioni, consulta S3Settings.

Risoluzione dei problemi con Oracle

Di seguito vengono descritti i problemi specifici relativi all'uso di AWS DMS con i database Oracle.

Estrazione dei dati dalle viste

Puoi estrarre i dati da una vista una tantum. Non è possibile eseguire l'estrazione per la replica continua. Per poter estrarre i dati dalle viste, è necessario aggiungere il codice seguente alla sezione Impostazioni endpoint nella pagina dell'endpoint di origine Oracle. Quando estrai dati da una vista, quest'ultima viene mostrata come tabella sullo schema di destinazione.

"ExposeViews": true

Migrazione di LOB da Oracle 12c

AWS DMSpuò utilizzare due metodi per acquisire le modifiche a un database Oracle, Binary Reader e Oracle. LogMiner Per impostazione predefinita, AWS DMS utilizza Oracle LogMiner per acquisire le modifiche. Tuttavia, su Oracle 12c, Oracle LogMiner non supporta le colonne LOB. Per acquisire le modifiche alle colonne LOB su Oracle 12c, utilizza Binary Reader.

Passaggio tra Oracle LogMiner e Binary Reader

AWS DMSpuò utilizzare due metodi per acquisire le modifiche a un database Oracle di origine, Binary Reader e Oracle LogMiner. L'impostazione predefinita LogMiner è Oracle. Per passare a utilizzare Binary Reader per l'acquisizione delle modifiche, effettua le seguenti operazioni:

Per utilizzare Binary Reader per l'acquisizione delle modifiche

  1. Accedi a AWS Management Console e apri la AWS DMS console all'indirizzo https://console.aws.amazon.com/dms/v2/.

  2. Scegli Endpoint.

  3. Seleziona l'endpoint di origine Oracle su cui desideri utilizzare Binary Reader.

  4. Scegli Modifica.

  5. Seleziona Avanzato, quindi per Attributi aggiuntivi di connessione aggiungi il seguente codice:

    
useLogminerReader=N

  6. Utilizza uno strumento per sviluppatori Oracle, ad esempio SQL-Plus, per fornire il seguente privilegio aggiuntivo all'account utente AWS DMS impiegato per la connessione all'endpoint Oracle.

    
SELECT ON V_$TRANSPORTABLE_PLATFORM

Errore: Oracle CDC stopped 122301 Oracle CDC maximum retry counter exceeded (CDC Oracle arrestato 122301 Numero di nuovi tentativi di CDC Oracle superato).

Questo errore si verifica quando i log di archivio Oracle necessari sono stati rimossi dal server prima che AWS DMS potesse utilizzarli per acquisire le modifiche. Aumenta le policy relative al periodo di conservazione dei log sul server di database. Per un database Amazon RDS, esegui la procedura seguente per aumentare il periodo di conservazione dei log. Ad esempio, il codice seguente aumenta il periodo di conservazione dei log su un'istanza database di Amazon RDS a 24 ore.


exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

Aggiunta automatica di log supplementare a un endpoint di origine Oracle

Per impostazione predefinita, la funzionalità di log supplementare di AWS DMS è disattivata. Per attivare automaticamente la funzionalità di log supplementare per un endpoint di origine Oracle, effettua le seguenti operazioni:

Per aggiungere automaticamente il log supplementare a un endpoint di origine Oracle

  1. Accedi AWS Management Console e apri la AWS DMS console all'indirizzo https://console.aws.amazon.com/dms/v2/.

  2. Scegli Endpoint.

  3. Seleziona l'endpoint di origine Oracle a cui desideri aggiungere il log supplementare.

  4. Scegli Modifica.

  5. Seleziona Avanzato, quindi per Attributi aggiuntivi di connessione aggiungi il seguente codice:

    
addSupplementalLogging=Y

  6. Scegli Modifica.

Le modifiche ai LOB non vengono acquisite

Attualmente, per acquisire le modifiche ai LOB, una tabella deve disporre di una chiave primaria per AWS DMS. Se una tabella contenente LOB non dispone di una chiave primaria, puoi effettuare diverse operazioni per acquisire le modifiche ai LOB:

  • Aggiungere una chiave primaria alla tabella. A tale scopo, è sufficiente aggiungere una colonna ID e popolarla con una sequenza mediante un trigger.

  • Crea una vista materializzata della tabella che includa un ID generato dal sistema come chiave primaria e migra la vista materializzata anziché la tabella.

  • Creare uno standby logico, aggiungere una chiave primaria alla tabella ed eseguire la migrazione dallo standby logico.

Errore: ORA-12899: valore eccessivo per colonna nome-colonna

L'errore "ORA-12899: valore eccessivo per colonna nome-colonna" è spesso causato da un paio di problemi.

Uno di questi problemi è una mancata corrispondenza tra i set di caratteri utilizzati dai database di origine e di destinazione.

Un altro problema è causato dalle impostazioni NLS (National Language Support) differenti tra i due database. Questo errore si verifica di frequente quando il parametro NLS_LENGTH_SEMANTICS del database di origine è impostato su CHAR e il parametro NLS_LENGTH_SEMANTICS del database di destinazione è impostato su BYTE.

Il tipo di dati NUMBER viene interpretato in modo errato

Il tipo di dati NUMBER di Oracle viene convertito in diversi tipi di dati AWS DMS, a seconda della precisione e del dimensionamento di NUMBER. Queste conversioni sono documentate qui Tipi di dati di origine per Oracle. Il modo in cui il tipo NUMBER viene convertito può essere modificato anche utilizzando le impostazioni degli endpoint per l'endpoint di origine Oracle. Queste impostazioni degli endpoint sono documentate in Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS.

Record mancanti durante il pieno carico

Quando si esegue un pieno carico, AWS DMS cerca le transazioni aperte a livello di database e attende che il commit della transazione venga completato. Ad esempio, con l'impostazione TransactionConsistencyTimeout=600 dell'attività, AWS DMS attende 10 minuti anche se la transazione aperta si trova su una tabella non inclusa nella mappatura della tabella. Tuttavia, se la transazione aperta si trova su una tabella inclusa nella mappatura della tabella e il commit della transazione non viene completato in tempo, risulteranno record mancanti nella tabella di destinazione.

Puoi modificare l'impostazione TransactionConsistencyTimeout dell'attività e aumentare il tempo di attesa se sai che il commit delle transazioni aperte richiede più tempo.

Inoltre, tieni presente che il valore predefinito dell'impostazione FailOnTransactionConsistencyBreached dell'attività è false. Ciò significa che AWS DMS continua ad applicare altre transazioni ma le transazioni aperte vengono perse. Se desideri che l'operazione abbia esito negativo quando le transazioni aperte non vengono chiuse in tempo, puoi impostare FailOnTransactionConsistencyBreached su true.

Errore della tabella

Table Error appare nelle statistiche della tabella durante la replica se una clausola WHERE non fa riferimento a una colonna di chiave primaria e il log supplementare non viene utilizzato per tutte le colonne.

Per risolvere questo problema, attiva il log supplementare per tutte le colonne della tabella di riferimento. Per ulteriori informazioni, consulta Impostazione del log supplementare.

Errore: impossibile recuperare gli ID di destinazione di log redo archiviati da Oracle

Questo errore si verifica quando l'origine Oracle non ha generato alcun log di archiviazione o se V$ARCHIVED_LOG è vuoto. È possibile risolvere l'errore cambiando i log manualmente.

Per un database Amazon RDS, esegui la procedura seguente per cambiare i file di log. La procedura switch_logfile non ha parametri.

exec rdsadmin.rdsadmin_util.switch_logfile;

Per un database di origine Oracle autogestito, utilizza il comando seguente per forzare un cambio di log.

ALTER SYSTEM SWITCH LOGFILE ;

Valutazione delle prestazioni di lettura dei log redo o di archiviazione di Oracle

Se riscontri problemi di prestazioni con l'origine Oracle, puoi valutare le prestazioni di lettura dei log redo o di archiviazione di Oracle per trovare i modi per migliorare le prestazioni. Per testare le prestazioni di lettura dei log redo o di archiviazione, usa l'Amazon machine image (AMI) AWS DMS.

Puoi utilizzare l'AMI di diagnostica AWS DMS per effettuare le seguenti operazioni:

  • Utilizza il metodo bFile per valutare le prestazioni dei file di log redo.

  • Utilizzate il LogMiner metodo per valutare le prestazioni dei redo log file.

  • Utilizza il metodo PL/SQL (dbms_lob.read) per valutare le prestazioni dei file di log redo.

  • Utilizza il single-thread per valutare le prestazioni di lettura su ASMFile.

  • Utilizza il multi-thread per valutare le prestazioni di lettura su ASMFile.

  • Utilizza la funzione Direct OS Readfile() Windows o Pread64 Linux per valutare il file di log redo.

Quindi è possibile adottare misure correttive in base ai risultati.

Per testare le prestazioni di lettura di un file di log redo o di archiviazione di Oracle

  1. Crea un'istanza AWS DMS AMI di diagnostica Amazon EC2 e connettiti.

    Per ulteriori informazioni, consulta Utilizzo dell'AMI di supporto diagnostico AWS DMS.

  2. Esegui il comando awsreplperf.

    $ awsreplperf

    Il comando visualizza le opzioni dell'utilità AWS DMS per le prestazioni di lettura Oracle.

    0.	Quit
1.	Read using Bfile
2.	Read using LogMiner
3.	Read file PL/SQL (dms_lob.read)
4.	Read ASMFile Single Thread
5.	Read ASMFile Multi Thread
6.	Readfile() function

  3. Seleziona un'opzione dall'elenco.

  4. Immetti le seguenti informazioni sulla connessione al database e sul log di archiviazione.

    Oracle user name [system]:
Oracle password:

Oracle connection name [orcllx]:
Connection format hostname:port/instance

Oracle event trace? [N]: 
Default N = No or Y = Yes

Path to redo or archive log file []:

  5. Esamina l'output visualizzato per le informazioni pertinenti sulle prestazioni di lettura. Ad esempio, quanto segue mostra l'output che può derivare dalla selezione dell'opzione numero 2, Read using LogMiner.

    Output dell'utilità per le prestazioni di lettura

  6. Per uscire dall'utilità, immetti 0 (zero).

Passaggi successivi

  • Quando i risultati mostrano che la velocità di lettura è inferiore a una soglia accettabile, esegui lo script di supporto diagnostico Oracle sull'endpoint, esamina le sezioni Tempo di attesa, Profilo del carico e Profilo dell'I/O. Quindi modifica qualsiasi configurazione anomala per migliorare le prestazioni di lettura. Ad esempio, se i tuoi file di log redo hanno una dimensione massima di 2 GB, prova ad aumentare LOG_BUFFER a 200 MB per migliorare le prestazioni.

  • Consulta Best practice per AWS DMS per assicurarti che l'istanza di replica DMS, l'attività e gli endpoint siano configurati in modo ottimale.

Risoluzione dei problemi relativi a MySQL

Di seguito vengono descritti i problemi specifici relativi all'uso di AWS DMS con i database MySQL.

L'attività CDC ha esito negativo per l'endpoint dell'istanza database di Amazon RDS perché la registrazione binaria è disabilitata

Questo problema si verifica con le istanze database di Amazon RDS perché i backup automatici sono disabilitati. Abilita i backup automatici impostando il periodo di retention dei backup su un valore diverso da zero.

Le connessioni a un'istanza MySQL di destinazione vengono disconnesse durante un'attività

Se un'attività con LOB si disconnette da una destinazione MySQL potrebbe essere restituito il seguente tipo di errori nel log dell'attività. 

[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 08S01 NativeError: 
2013 Message: [MySQL][ODBC 5.3(w) Driver][mysqld-5.7.16-log]Lost connection 
to MySQL server during query [122502] ODBC general error.
 [TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
2006 Message: [MySQL][ODBC 5.3(w) Driver]MySQL server has gone away 
[122502] ODBC general error.

In questo caso, potresti dover modificare alcune impostazioni delle attività.

Per risolvere il problema relativo alla disconnessione di un'attività da una destinazione MySQL, effettua le seguenti operazioni:

  • Verifica che la variabile di database max_allowed_packet sia impostata su un valore sufficiente a contenere il LOB di maggiori dimensioni.

  • Verifica che le seguenti variabili siano impostate su un valore di timeout di ampia durata. È consigliabile utilizzare un valore di almeno 5 minuti per ciascuna di queste variabili.

    • net_read_timeout

    • net_write_timeout

    • wait_timeout

Per informazioni sull'impostazione delle variabili di sistema MySQL, consulta Server System Variables nella documentazione di MySQL.

Aggiunta di commit automatico a un endpoint compatibile con MySQL

Per aggiungere il commit automatico a un endpoint di destinazione compatibile con MySQL

  1. Accedere AWS Management Console e aprire la AWS DMS console all'indirizzo https://console.aws.amazon.com/dms/v2/.

  2. Scegli Endpoint.

  3. Seleziona l'endpoint di destinazione compatibile con MySQL a cui desideri aggiungere il commit automatico.

  4. Scegli Modifica.

  5. Seleziona Avanzato, quindi per Attributi aggiuntivi di connessione aggiungi il seguente codice:

    
Initstmt= SET AUTOCOMMIT=1

  6. Scegli Modifica.

Disabilitazione delle chiavi esterne su un endpoint di destinazione compatibile con MySQL

Puoi disabilitare i controlli delle chiavi esterne su MySQL aggiungendo quanto segue a Attributi aggiuntivi di connessione nella sezione Avanzato dell'endpoint di destinazione MySQL, Amazon Aurora edizione compatibile con MySQL o MariaDB.

Per disabilitare le chiavi esterne su un endpoint di destinazione compatibile con MySQL

  1. Accedi AWS Management Console e apri la AWS DMS console all'indirizzo https://console.aws.amazon.com/dms/v2/.

  2. Scegli Endpoint.

  3. Seleziona l'endpoint di destinazione MySQL, Aurora MySQL o MariaDB su cui desideri disabilitare le chiavi esterne.

  4. Scegli Modifica.

  5. Seleziona Avanzato, quindi per Attributi aggiuntivi di connessione aggiungi il seguente codice:

    
Initstmt=SET FOREIGN_KEY_CHECKS=0

  6. Scegli Modifica.

Caratteri sostituiti con punto interrogativo

Questo problema si verifica con maggiore frequenza quando i caratteri dell'endpoint di origine sono stati codificati da un set di caratteri non supportato da AWS DMS.

Voci di log "Evento errato"

In genere, le voci "Evento errato" nei log di migrazione indicano che sull'endpoint del database di origine è stata tentata un'operazione DDL (Data Definition Language) non supportata. Le operazioni DDL non supportate causano un evento che l'istanza di replica non può ignorare, quindi viene registrato un evento errato.

Per risolvere questo problema, riavvia l'attività dall'inizio. Questa operazione ricarica le tabelle e avvia l'acquisizione delle modifiche in un momento successivo all'operazione DDL non supportata.

Change Data Capture con MySQL 5.5

Acquisizione dei dati di modifica (CDC) AWS DMS per database compatibili con Amazon RDS MySQL richiede la registrazione binaria basata su riga dell'immagine completa e tale funzionalità non è supportata in MySQL 5.5 o versioni precedenti. Per utilizzare AWS DMS CDC, devi aggiornare l'istanza database di Amazon RDS a MySQL versione 5.6.

Aumento del periodo di conservazione dei log binari per istanze database di Amazon RDS

AWS DMS richiede la conservazione dei file di log binari per la funzionalità Change Data Capture. Per aumentare il periodo di conservazione dei log su un'istanza database di Amazon RDS, utilizza la seguente procedura. L'esempio seguente consente di aumentare il periodo di conservazione dei log binari a 24 ore. 


call mysql.rds_set_configuration('binlog retention hours', 24);

Messaggio di log: Some changes from the source database had no impact when applied to the target database (Alcune modifiche dal database di origine non hanno avuto alcun impatto quando applicate al database di destinazione).

Quando AWS DMS aggiorna un valore di colonna del database MySQL mantenendo il valore esistente, da MySQL viene restituito un messaggio di zero rows affected. Questo comportamento è diverso da altri motori di database come Oracle e SQL Server. Questi motori aggiornano la riga anche quando il valore di sostituzione è lo stesso di quello corrente.

Errore: Identifier too long (Identificatore troppo lungo)

Il seguente errore si verifica quando un identificatore è troppo lungo:


TARGET_LOAD E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
1059 Message: MySQLhttp://ODBC 5.3(w) Driverhttp://mysqld-5.6.10Identifier 
name 'name' is too long 122502 ODBC general error. (ar_odbc_stmt.c:4054)

In alcuni casi, si imposta AWS DMS per creare le tabelle e le chiavi primarie nel database di destinazione. In questi casi, DMS non utilizza per le chiavi primarie gli stessi nomi usati nel database di origine. Crea invece il nome della chiave primaria in base al nome della tabella. Se il nome della tabella è lungo, la lunghezza dell'identificatore generato automaticamente può superare i limiti consentiti per MySQL.

Per risolvere questo problema, l'approccio attuale consiste nel creare preventivamente le tabelle e le chiavi primarie nel database di destinazione. Quindi per popolare le tabelle di destinazione utilizza un'attività con l'impostazione Modalità di preparazione della tabella di destinazione impostata su Nessuna operazione o Tronca.

Errore: Unsupported Character Set Causes Field Data Conversion to Fail (Il set di caratteri non supportato causa l'esito negativo della conversione dei dati di campo)

Il seguente errore si verifica quando un set di caratteri non supportato causa l'esito negativo della conversione dei dati di campo:


"[SOURCE_CAPTURE ]E: Column 'column-name' uses an unsupported character set [120112] 
A field data conversion failed. (mysql_endpoint_capture.c:2154)

Controlla i parametri del database correlati alle connessioni. Per impostare questi parametri è possibile utilizzare il seguente comando.


SHOW VARIABLES LIKE '%char%';

Errore: Codepage 1252 to UTF8 [120112] A field data conversion failed (Tabella codici 1252 su UTF8 [120112] Esito negativo di una conversione dei dati di campo)

Il seguente errore può verificarsi durante una migrazione se nel database MySQL di origine vi sono caratteri non della tabella codici 1252.

  
[SOURCE_CAPTURE ]E: Error converting column 'column_xyz' in table
'table_xyz with codepage 1252 to UTF8 [120112] A field data conversion failed. 
(mysql_endpoint_capture.c:2248)

Come soluzione alternativa, puoi utilizzare l'attributo aggiuntivo di connessione CharsetMapping con l'endpoint MySQL di origine per specificare la mappatura del set di caratteri. Potrebbe essere necessario riavviare l'attività di migrazione AWS DMS dall'inizio se si aggiunge questa impostazione dell'endpoint.

Ad esempio, la seguente impostazione dell'endpoint potrebbe essere utilizzata per un endpoint di origine MySQL in cui il set di caratteri di origine è Utf8 o latin1. 65001 è l'identificatore della tabella codici UTF8. 

   
CharsetMapping=utf8,65001
CharsetMapping=latin1,65001

Indici, chiavi esterne o aggiornamenti o eliminazioni a cascata non migrati

AWS DMS non supporta la migrazione di oggetti secondari come indici e chiavi esterne. Per replicare le modifiche apportate alle tabelle secondarie da un'operazione di aggiornamento o eliminazione a cascata, è necessario che il vincolo di chiave esterna di attivazione sia abilitato sulla tabella di destinazione. Per aggirare questa limitazione, crea manualmente la chiave esterna nella tabella di destinazione. Quindi, crea una singola attività per il pieno carico e la CDC oppure due attività separate per il pieno carico e la CDC, come descritto di seguito:

Creazione di un'unica attività che supporti pieno carico e CDC

Questa procedura descrive come migrare chiavi esterne e indici utilizzando una singola attività per il pieno carico e la CDC.

Creazione di un'attività di pieno carico e CDC

  1. Crea manualmente le tabelle con chiavi esterne e indici sulla destinazione in modo che corrispondano alle tabelle di origine.

  2. Aggiungi il seguente un attributo aggiuntivo di connessione all'endpoint di destinazione AWS DMS:

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  3. Crea l'attività AWS DMS con TargetTablePrepMode impostato su DO_NOTHING.

  4. Imposta Stop task after full load completes su StopTaskCachedChangesApplied.

  5. Avvia l'attività. AWS DMS interrompe l'attività automaticamente una volta terminato il pieno carico e applica le modifiche memorizzate nella cache.

  6. Rimuovi l'attributo aggiuntivo di connessione SET FOREIGN_KEY_CHECKS che hai aggiunto in precedenza.

  7. Riprendi l'attività. L'attività entra nella fase CDC e applica le modifiche in corso dal database di origine alla destinazione.

Creazione delle attività di pieno carico e CDC separatamente

Queste procedure descrivono come migrare chiavi esterne e indici utilizzando attività separate per il pieno carico e la CDC.

Creazione di un'attività di pieno carico

  1. Crea manualmente le tabelle con chiavi esterne e indici sulla destinazione in modo che corrispondano alle tabelle di origine.

  2. Aggiungi il seguente un attributo aggiuntivo di connessione all'endpoint di destinazione AWS DMS:

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  3. Crea l'attività AWS DMS con il parametro TargetTablePrepMode impostato su DO_NOTHING e EnableValidation impostato su FALSE.

  4. Avvia l'attività. AWS DMS interrompe l'attività automaticamente una volta terminato il pieno carico e applica le modifiche memorizzate nella cache.

  5. Una volta completata l'attività, annota l'ora di inizio dell'attività di pieno carico in UTC o il nome e la posizione del file di log binario, per avviare l'attività di sola CDC. Fai riferimento ai log per ottenere il timestamp in UTC dall'ora iniziale di avvio del pieno carico.

Creazione di un'attività di sola CDC

  1. Rimuovi l'attributo aggiuntivo di connessione SET FOREIGN_KEY_CHECKS che hai impostato in precedenza.

  2. Crea l'attività di sola CDC con la posizione di avvio impostata sull'ora di inizio del pieno carico indicata nel passaggio precedente. In alternativa, è possibile utilizzare la posizione del log binario registrata nel passaggio precedente. Imposta TargetTablePrepMode su DO_NOTHING. Abilita la convalida dei dati configurando l'impostazione EnableValidation su TRUE, se necessario.

  3. Avvia l'attività di sola CDC e monitora i log per individuare eventuali errori.

Nota

Questa soluzione alternativa si applica solo a una migrazione da MySQL a MySQL. Non è possibile utilizzare il metodo con la funzionalità dell'applicazione in batch perché questa richiede che le tabelle di destinazione non abbiano chiavi esterne attive.

Risoluzione dei problemi relativi a PostgreSQL

Di seguito vengono descritti i problemi specifici relativi all'uso di AWS DMS con i database PostgreSQL.

I tipi di dati JSON sono troncati

AWS DMS considera il tipo di dati JSON in PostgreSQL come una colonna del tipo di dati LOB. Di conseguenza, se utilizzi la modalità LOB limitata, il limite delle dimensioni di LOB si applica ai dati JSON.

Ad esempio, supponi che la modalità LOB limitata sia impostata su 4.096 KB. In questo caso, qualsiasi dato JSON di dimensioni superiori a 4.096 KB viene troncato al limite di 4.096 KB e non supera il test di convalida in PostgreSQL.

Le seguenti informazioni di log indicano il troncamento del file JSON a causa dell'impostazione della modalità LOB limitata e il conseguente esito negativo della convalida.

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt.c:2415)

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)

Le colonne di un tipo di dati definito dall'utente non vengono migrate correttamente

Quando si esegue la replica da un'origine PostgreSQL, AWS DMS crea la tabella di destinazione con gli stessi tipi di dati per tutte le colonne, tranne le colonne con i tipi di dati definiti dall'utente. In questi casi, il tipo di dati viene creato come "carattere variabile" nella destinazione.

Errore: No schema has been selected to create in (Nessuno schema selezionato per la creazione)

In alcuni casi, potresti visualizzare l'errore «SQL_ERROR SqlState: 3F000:7 Messaggio NativeError: ERROR: nessuno schema è stato selezionato per la creazione in».

Questo errore può verificarsi quando la mappatura della tabella JSON contiene un valore jolly per lo schema e il database di origine non supporta tale valore.

Le operazioni di eliminazione e aggiornamento su una tabella non vengono replicate mediante CDC

Le operazioni di eliminazione e aggiornamento durante l'acquisizione dei dati di modifica (CDC) vengono ignorate se la tabella di origine non ha una chiave primaria. AWS DMS supporta l'acquisizione dei dati di modifica (CDC) per tabelle PostgreSQL con chiavi primarie.

Se una tabella non dispone di una chiave primaria, i log write-ahead (WAL) non includono un'immagine precedente della riga di database. In questo caso, AWS DMS non è in grado di aggiornare la tabella. Per replicare le operazioni di eliminazione, crea una chiave primaria sulla tabella di origine.

Le istruzioni Truncate non vengono propagate

Quando utilizzi l'acquisizione dei dati di modifica (CDC), le operazioni TRUNCATE non sono supportate da AWS DMS.

Come evitare che PostgreSQL acquisisca DDL

Per evitare che un endpoint di destinazione PostgreSQL acquisisca istruzioni DDL, aggiungi l'istruzione Impostazione dell'endpoint riportata di seguito.


"CaptureDDLs": "N"

Selezione dello schema in cui vengono creati gli oggetti di database per l'acquisizione di DDL

Puoi controllare in quale schema vengono creati gli oggetti di database correlati all'acquisizione di DDL. Aggiungi la seguente istruzione Impostazione dell'endpoint. Il parametro Impostazione dell'endpoint è disponibile nella scheda dell'endpoint di origine.


"DdlArtifactsSchema: "xyzddlschema"

Tabelle Oracle mancanti dopo la migrazione a PostgreSQL

In questo caso, le tabelle e i dati sono generalmente ancora accessibili.

Per impostazione predefinita, per i nomi di tabella Oracle utilizza i caratteri maiuscoli e PostgreSQL i caratteri minuscoli. Quando esegui una migrazione da Oracle a PostgreSQL, ti suggeriamo di fornire le regole di trasformazione nella sezione di mappatura delle tabelle dell'attività. Queste sono regole di trasformazione per convertire le maiuscole e le minuscole dei nomi delle tabelle.

Se hai eseguito la migrazione delle tabelle senza utilizzare le regole di trasformazione per convertire le maiuscole e le minuscole dei nomi delle tabelle, racchiudi i nomi delle tabelle tra virgolette quando vi fai riferimento.

ReplicationSlotDiskUsage aumenta e restart_lsn smette di andare avanti durante transazioni lunghe, come i carichi di lavoro ETL

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/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 quando la replica logica è abilitata. Prova invece a suddividere la transazione in diverse transazioni più piccole.

Un'attività che utilizza la vista come origine non dispone di righe copiate

Per migrare una vista, imposta table-type su all o view. Per ulteriori informazioni, consulta Specifica della selezione delle tabelle e delle regole di trasformazione dalla console.

Le origini che supportano le viste sono riportate di seguito.

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • IBM Db2 LUW

  • SAP Adaptive Server Enterprise (ASE)

Risoluzione dei problemi relativi a Microsoft SQL Server

Di seguito vengono descritti i problemi specifici relativi all'uso di AWS DMS con i database Microsoft SQL Server.

Errori durante l'acquisizione di modifiche per il database SQL Server

Spesso, gli errori che si verificano durante l'acquisizione dei dati di modifica (CDC) possono indicare che uno dei prerequisiti non è stato soddisfatto. Ad esempio, il prerequisito trascurato più di frequente è un backup completo del database. Il log delle attività indica questa omissione con il seguente errore:


SOURCE_CAPTURE E: No FULL database backup found (under the 'FULL' recovery model). 
To enable all changes to be captured, you must perform a full database backup. 
120438 Changes may be missed. (sqlserver_log_queries.c:2623)

Esamina i prerequisiti per l'utilizzo di SQL Server come origine elencati in Utilizzo di un database Microsoft SQL Server come origine per AWS DMS.

Colonne di identità mancanti

AWS DMS non supporta le colonne di identità quando crei uno schema di destinazione. Devi aggiungerle dopo il completamento del caricamento iniziale.

Errore: SQL Server non supporta le pubblicazioni

Il seguente errore viene generato quando utilizzi SQL Server Express come endpoint di origine:


RetCode: SQL_ERROR SqlState: HY000 NativeError: 21106 
Message: This edition of SQL Server does not support publications.

Attualmente, AWS DMS non supporta SQL Server Express come origine o destinazione.

Le modifiche non vengono visualizzate nella destinazione

Per acquisire le modifiche in modo coerente, AWS DMS richiede che un database SQL Server di origine utilizzi il modello di ripristino dei dati 'FULL' o 'BULK LOGGED'. Il modello "SIMPLE" non è supportato.

Il modello di ripristino dei dati "SIMPLE" registra le informazioni minime necessarie per consentire agli utenti di ripristinare i propri database. Tutte le voci di log inattive vengono automaticamente troncate quando si verifica un checkpoint.

Tutte le operazioni sono ancora registrate. Tuttavia, non appena si verifica un checkpoint, il log viene troncato automaticamente. Questo troncamento significa che il log diventa disponibile per il riutilizzo e le voci di log più vecchie possono essere sovrascritte. Quando le voci di log vengono sovrascritte, le modifiche non possono essere acquisite. Questo è il motivo per cui AWS DMS non supporta il modello di recupero dati SIMPLE. Per informazioni sugli altri prerequisiti necessari per l'utilizzo di SQL Server come origine, consulta Utilizzo di un database Microsoft SQL Server come origine per AWS DMS.

Tabella non uniforme mappata tra le partizioni

Durante l'acquisizione dei dati di modifica (CDC), la migrazione di una tabella con una struttura specializzata viene sospesa quando AWS DMS non è in grado di eseguire correttamente la CDC sulla tabella. Vengono inviati messaggi come questi:


[SOURCE_CAPTURE ]W: Table is not uniformly mapped across partitions. Therefore - it is excluded from CDC (sqlserver_log_metadata.c:1415)
[SOURCE_CAPTURE ]I: Table has been mapped and registered for CDC. (sqlserver_log_metadata.c:835)

Quando si esegue il CDC nelle tabelle di SQL Server, AWS DMS analizza i tlog di SQL Server. Su ogni record tlog AWS DMS analizza i valori esadecimali contenenti dati per le colonne inserite, aggiornate o eliminate durante una modifica.

Per analizzare il record esadecimale, AWS DMS legge i metadati della tabella dalle tabelle di sistema di SQL Server. Tali tabelle di sistema identificano quali sono le colonne della tabella appositamente strutturate e rivelano alcune delle loro proprietà interne, come "xoffset" e "null bit position".

AWS DMS prevede che i metadati siano gli stessi per tutte le partizioni non elaborate della tabella. In alcuni casi, tuttavia, le tabelle particolarmente strutturate non hanno gli stessi metadati su tutte le partizioni. AWS DMS può sospendere la CDC su quella tabella per evitare di analizzare le modifiche in modo errato e fornire alla destinazione dati errati. Le soluzioni alternative sono:

  • Se la tabella dispone di un indice cluster, eseguire una ricostruzione dell'indice.

  • Se la tabella non dispone di un indice cluster, aggiungi un indice cluster alla tabella (è possibile eliminarlo in seguito, se necessario).

Risoluzione dei problemi relativi ad Amazon Redshift

Di seguito vengono descritti i problemi specifici relativi all'uso di AWS DMS con i database Amazon Redshift.

Caricamento in un cluster Amazon Redshift in una regione AWS diversa rispetto a quella dell'istanza di replica

Non puoi caricare in un cluster Amazon Redshift in una regione AWS diversa rispetto a quella dell'istanza di replica AWS DMS. DMS richiede che l'istanza di replica e il cluster Amazon Redshift si trovino nella stessa regione.

Errore: Relation "awsdms_apply_exceptions" already exists (Relazione "awsdms_apply_exceptions" già esistente)

Spesso, l'errore "Relazione "awsdms_apply_exceptions" già esistente" si verifica quando un endpoint Redshift viene specificato come endpoint PostgreSQL. Per risolvere questo problema, modifica l'endpoint e l'impostazione Target engine (Motore di destinazione) in "redshift".

Errori con tabelle il cui nome inizia con "awsdms_changes"

I messaggi di errore delle tabelle con nomi che iniziano con "awsdms_changes" si verificano quando due attività che tentano di caricare dati nello stesso cluster Amazon Redshift vengono eseguite contemporaneamente. A causa della modalità di denominazione delle tabelle temporanee, le attività simultanee possono entrare in conflitto durante l'aggiornamento della stessa tabella.

Visualizzazione di tabelle nei cluster con nomi simili a dms.awsdms_changes000000000XXXX

AWS DMS crea tabelle temporanee quando i dati vengono caricati da file archiviati in Amazon S3. I nomi di queste tabelle temporanee includono il prefisso dms.awsdms_changes. Queste tabelle sono necessarie per consentire a AWS DMS di memorizzare i dati al primo caricamento e prima che vengano inseriti nella rispettiva tabella di destinazione finale.

Autorizzazioni necessarie per l'utilizzo di Amazon Redshift

Per utilizzare AWS DMS con Amazon Redshift, l'account utente che usi per accedere ad Amazon Redshift deve disporre delle seguenti autorizzazioni:

  • CRUD (selezione, inserimento, aggiornamento, eliminazione)

  • Caricamento in blocco

  • Creazione, modifica, rimozione (se richieste dalla definizione dell'attività)

Per visualizzare i prerequisiti necessari per l'utilizzo di Amazon Redshift come destinazione, consulta Utilizzo di un database Amazon Redshift come destinazione per AWS Database Migration Service.

Risoluzione dei problemi relativi ad Amazon Aurora MySQL

Di seguito vengono descritti i problemi specifici relativi all'uso di AWS DMS con i database Amazon Aurora MySQL.

Errore: CHARACTER SET UTF8 fields terminated by ',' enclosed by '"' lines terminated by '\n' (Campi SET DI CARATTERI UTF8 terminati da ',' racchiusi tra "" righe terminate da '\n')

Se utilizzi Amazon Aurora MySQL come destinazione, potresti vedere nei log un errore come il seguente. Questo tipo di errore in genere indica che ANSI_QUOTES fa parte del parametro SQL_MODE. Se ANSI_QUOTES fa parte del parametro SQL_MODE, le doppie virgolette vengono considerate come virgolette semplici e ciò può creare problemi quando esegui un'attività.

Per risolvere questo errore, rimuovi ANSI_QUOTES dal parametro SQL_MODE.


2016-11-02T14:23:48 [TARGET_LOAD ]E: Load data sql statement. load data local infile 
"/rdsdbdata/data/tasks/7XO4FJHCVON7TYTLQ6RX3CQHDU/data_files/4/LOAD000001DF.csv" into table 
`VOSPUSER`.`SANDBOX_SRC_FILE` CHARACTER SET UTF8 fields terminated by ',' 
enclosed by '"' lines terminated by '\n'( `SANDBOX_SRC_FILE_ID`,`SANDBOX_ID`,
`FILENAME`,`LOCAL_PATH`,`LINES_OF_CODE`,`INSERT_TS`,`MODIFIED_TS`,`MODIFIED_BY`,
`RECORD_VER`,`REF_GUID`,`PLATFORM_GENERATED`,`ANALYSIS_TYPE`,`SANITIZED`,`DYN_TYPE`,
`CRAWL_STATUS`,`ORIG_EXEC_UNIT_VER_ID` ) ; (provider_syntax_manager.c:2561)

Risoluzione dei problemi relativi a SAP ASE

Di seguito vengono descritti i problemi specifici relativi all'uso di AWS DMS con i database SAP ASE.

Errore: le colonne LOB hanno valori NULL quando l'origine ha un indice univoco composito con valori NULL

Quando si utilizza SAP ASE come origine con tabelle configurate con un indice univoco composito che consente valori NULL, è possibile che i valori LOB non vengano migrati durante la replica continua. Questo comportamento è in genere il risultato di ANSI_NULL impostato su 1 sul client dell'istanza di replica DMS per impostazione predefinita.

Per garantire che i campi LOB migrino correttamente, includi l'impostazione dell'endpoint 'AnsiNull=0' nell'endpoint di origine AWS DMS dell'attività.

Risoluzione dei problemi relativi a IBM Db2

Di seguito vengono descritti i problemi specifici relativi all'uso di AWS DMS con i database IBM Db2.

Errore: la funzione Riprendi dal timestamp non è un'attività supportata

Per la replica continua (CDC), se prevedi di avviare la replica da un timestamp specifico, imposta l'attributo di connessione StartFromContext sul timestamp richiesto. Per ulteriori informazioni, consulta Impostazioni degli endpoint quando si utilizza Db2 LUW. L'impostazione di StartFromContext sul timestamp richiesto evita il seguente problema:

Last Error Resume from timestamp is not supported Task error notification received from 
subtask 0, thread 0 [reptask/replicationtask.c:2822] [1020455] 'Start from timestamp' was blocked to prevent Replicate from 
scanning the log (to find the timestamp). When using IBM DB2 for LUW, 'Start from timestamp' is only supported if an actual 
change was captured by this Replicate task earlier to the specified timestamp.