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 argomenti sulla risoluzione dei problemi relativi al AWS Database Migration Service (AWS DMS). Questi argomenti possono aiutarti a risolvere i problemi più comuni utilizzando entrambi i database degli endpoint AWS DMS e alcuni database degli endpoint.

Se hai aperto un caso di AWS supporto, il tecnico dell'assistenza potrebbe 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 diagnostico 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.

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 cui un'attività di migrazione viene eseguita lentamente è che le risorse allocate all'istanza di replica sono inadeguate. 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:

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 senza statistiche stimate sulle righe, non è AWS DMS possibile fornire alcun tipo di stima 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 che non siano 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 DMS non 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:

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:

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:

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 di non AWS DMS eseguire alcuna configurazione sulle tabelle di destinazione, inclusa la creazione di indici primari e unici. Se non hai creato chiavi primarie o univoche nelle tabelle di destinazione, AWS DMS esegue una scansione completa della tabella 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 della modalità di preparazione della tabella di Target è impostata su AWS DMS Non fare nulla, non esegue 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 AWS Database Migration Service metriche.

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

AWS DMS riavvia il caricamento della tabella dall'inizio quando non ha terminato il caricamento iniziale di una tabella. Quando un'attività viene riavviata, AWS DMS ricarica le tabelle dall'inizio quando 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à FULL LOB o LIMITED LOB, AWS DMS non supporta la replica di 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 AWS DMS origine utilizza un indirizzo IP compreso nell'intervallo IP riservato 192.168.0.0/24, il test di connessione all'endpoint di origine ha esito negativo. La procedura seguente fornisce una possibile soluzione alternativa:

Utilizza l'indirizzo IP dell' EC2 istanza Amazon e la porta del database indicati in precedenza per l' AWS DMS endpoint. Assicurati che l'endpoint disponga del gruppo di sicurezza che consente di accedere AWS DMS alla 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, puoi scoprire come risolvere problemi specifici relativi all'utilizzo con i database Oracle. AWS DMS

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 LOBs da Oracle 12c

AWS DMS può 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 DMS può 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:

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 registri di archivio Oracle necessari sono stati rimossi dal server prima AWS DMS di poterli utilizzare 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 registrazione supplementare AWS DMS è disattivata. Per attivare automaticamente la funzionalità di log supplementare per un endpoint di origine Oracle, effettua le seguenti operazioni:

Le modifiche ai LOB non vengono acquisite

Attualmente, una tabella deve avere una chiave primaria per AWS DMS acquisire le modifiche LOB. Se una tabella che contiene LOBs non ha una chiave primaria, è possibile eseguire diverse azioni per acquisire le modifiche LOB:

Errore: ORA-12899: valore troppo grande per la colonna column-name

L'errore «ORA-12899: valore troppo grande per la colonnacolumn-name" è 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 Oracle NUMBER viene convertito in vari tipi di AWS DMS dati, a seconda della precisione e della scala 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 caricamento completo, AWS DMS cerca le transazioni aperte a livello di database e attende che la transazione venga confermata. Ad esempio, in base all'impostazione dell'attivitàTransactionConsistencyTimeout=600, 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.

È possibile utilizzare l'AMI AWS DMS diagnostica per effettuare le seguenti operazioni:

Quindi è possibile adottare misure correttive in base ai risultati.

Risoluzione dei problemi relativi a MySQL

Di seguito, puoi scoprire come risolvere problemi specifici relativi all'utilizzo 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 hai un'attività LOBs che si disconnette da una destinazione MySQL, potresti vedere il seguente tipo di errori nel registro delle 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:

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

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.

Caratteri sostituiti con punto interrogativo

La situazione più comune che causa questo problema è quando i caratteri dell'endpoint di origine sono stati codificati da un set di caratteri che non AWS DMS supporta.

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

AWS DMS change data capture (CDC) per database compatibili con Amazon RDS MySQL richiede la registrazione binaria completa basata su righe di immagini, che non è supportata nella versione 5.5 o precedente di MySQL. Per utilizzare AWS DMS CDC, devi aggiornare l'istanza DB di Amazon RDS alla versione 5.6 di MySQL.

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

AWS DMS richiede la conservazione di file di log binari per l'acquisizione dei dati di modifica. 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 il valore di una colonna del database MySQL al valore esistente, viene restituito un messaggio zero rows affected di da MySQL. 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 la creazione delle tabelle e delle 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: la conversione dei dati di campo da 1252 a UTF8 [120112] non è riuscita

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 AWS DMS migrazione 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 è latin1 o. 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 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.

Risoluzione dei problemi relativi a PostgreSQL

Di seguito, puoi scoprire come risolvere problemi specifici relativi all'utilizzo AWS DMS con i database PostgreSQL.

I tipi di dati JSON sono troncati

AWS DMS tratta 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, ad eccezione delle colonne con 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: ERROR NativeError: 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 le 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, non è AWS DMS possibile aggiornare la tabella. Per replicare le operazioni di eliminazione, crea una chiave primaria sulla tabella di origine.

Le istruzioni Truncate non vengono propagate

Quando si utilizza 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 interrompe l'avanzamento 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.

Risoluzione dei problemi relativi a Microsoft SQL Server

Di seguito, puoi scoprire come risolvere problemi specifici relativi all'utilizzo AWS DMS con i database di Microsoft SQL Server.

La replica continua non riesce dopo il failover di RDS per SQL Server su server secondario

Se un'istanza di SQL Server di origine esegue il failover sulla secondaria, la replica AWS DMS continua a tentare di connettersi e continua a replicare una volta che l'origine è tornata online. Tuttavia, per le istanze MAZ di RDS per SQL Server, in determinate circostanze è possibile impostare il proprietario del database secondario su. NT AUTHORITY\SYSTEM Dopo un failover, ciò causa il fallimento dell'attività DMS con il seguente errore:

[SOURCE_CAPTURE  ]E:  RetCode: SQL_ERROR  SqlState: 42000 NativeError: 33009 Message: 
                [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]The database owner SID recorded in the master 
                database differs from the database owner SID recorded in database 'rdsadmin'. You should correct 
                this situation by resetting the owner of database 'rdsadmin' using the ALTER AUTHORIZATION statement. 
                Line: 1 Column: -1 [1022502]  (ar_odbc_stmt.c:5035)

Per risolvere il problema, segui la procedura descritta in Modifica dell'account db_owner con l'account rdsa per il database, quindi riprendi l'attività DMS.

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.                
            

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

Le modifiche non vengono visualizzate nella destinazione

AWS DMS richiede che un database SQL Server di origine sia in un modello di recupero dati «FULL» o «BULK LOGGED» per acquisire costantemente le modifiche. 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 non è AWS DMS possibile eseguire correttamente il 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 CDC su tabelle di SQL Server, AWS DMS analizza i tlog di SQL Server. In ogni record tlog, AWS DMS analizza i valori esadecimali contenenti dati per le colonne che sono state 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. In questi casi, AWS DMS può sospendere il CDC su quella tabella per evitare di analizzare le modifiche in modo errato e di fornire alla destinazione dati errati. Le soluzioni alternative sono:

Risoluzione dei problemi relativi ad Amazon Redshift

Di seguito, puoi scoprire come risolvere problemi specifici relativi all'utilizzo 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 AWS regione diversa da quella dell'istanza di AWS DMS replica. 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 AWS DMS poter archiviare i dati quando vengono caricati per la prima volta e prima che vengano inseriti nella tabella di destinazione finale.

Autorizzazioni necessarie per l'utilizzo di Amazon Redshift

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

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, puoi scoprire come risolvere problemi specifici relativi all'utilizzo AWS DMS con i database Amazon Aurora MySQL.

Errore: UTF8 campi CHARACTER SET terminati da ',' racchiusi da '"' 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, puoi scoprire come risolvere problemi specifici relativi all'utilizzo 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 Endpoint nell'endpoint 'AnsiNull=0' di AWS DMS origine dell'attività.

Risoluzione dei problemi relativi a IBM Db2

Di seguito, puoi scoprire come risolvere i problemi specifici relativi all'utilizzo 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.