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](CHAP_SupportScripts.md). 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. **Topics** + [Attività di migrazione eseguite lentamente](#CHAP_Troubleshooting.General.SlowTask) + [La barra di stato dell'attività non si sposta](#CHAP_Troubleshooting.General.StatusBar) + [L'attività è stata completata ma non è stato migrato nulla](#CHAP_Troubleshooting.General.NothingMigrated) + [Indici secondari e chiavi esterne mancanti](#CHAP_Troubleshooting.General.MissingSecondaryObjs) + [AWS DMS non crea registri CloudWatch](#CHAP_Troubleshooting.General.CWL) + [Problemi con la connessione ad Amazon RDS](#CHAP_Troubleshooting.General.RDSConnection) + [Problemi di rete](#CHAP_Troubleshooting.General.Network) + [Blocco del CDC dopo il pieno carico](#CHAP_Troubleshooting.General.CDCStuck) + [Errori di violazione delle chiavi primarie al riavvio di un'attività](#CHAP_Troubleshooting.General.PKErrors) + [Il caricamento iniziale dello schema ha esito negativo](#CHAP_Troubleshooting.General.SchemaLoadFail) + [Esito negativo delle attività con errore sconosciuto](#CHAP_Troubleshooting.General.TasksFail) + [L'attività riavvia il caricamento delle tabelle dall'inizio](#CHAP_Troubleshooting.General.RestartLoad) + [Il numero di tabelle per attività causa problemi](#CHAP_Troubleshooting.General.TableLimit) + [Attività non riuscite durante la creazione della chiave primaria in una colonna LOB](#CHAP_Troubleshooting.General.PKLOBColumn) + [Record duplicati nella tabella di destinazione senza chiave primaria](#CHAP_Troubleshooting.General.DuplicateRecords) + [Endpoint di origine nell'intervallo IP riservato](#CHAP_Troubleshooting.General.ReservedIP) + [Timestamp confusi nelle query di Amazon Athena](#CHAP_Troubleshooting.General.GarbledTimestamps) + [Risoluzione dei problemi con Oracle](#CHAP_Troubleshooting.Oracle) + [Risoluzione dei problemi relativi a MySQL](#CHAP_Troubleshooting.MySQL) + [Risoluzione dei problemi relativi a PostgreSQL](#CHAP_Troubleshooting.PostgreSQL) + [Risoluzione dei problemi relativi a Microsoft SQL Server](#CHAP_Troubleshooting.SQLServer) + [Risoluzione dei problemi relativi ad Amazon Redshift](#CHAP_Troubleshooting.Redshift) + [Risoluzione dei problemi relativi ad Amazon Aurora MySQL](#CHAP_Troubleshooting.Aurora) + [Risoluzione dei problemi relativi a SAP ASE](#CHAP_Troubleshooting.SAP) + [Risoluzione dei problemi relativi a IBM Db2](#CHAP_Troubleshooting.Db2) + [Table ha sospeso una tabella con l'errore «Impossibile creare l'istruzione 'where'»](#CHAP_Troubleshooting.table.suspended) + [Risoluzione dei problemi di latenza in AWS Database Migration Service](CHAP_Troubleshooting_Latency.md) + [Utilizzo degli script di supporto diagnostico in AWS DMS](CHAP_SupportScripts.md) + [Utilizzo dell'AMI di supporto AWS DMS diagnostico](CHAP_SupportAmi.md) ## 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 sono intensive. I/O 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](CHAP_BestPractices.SizingReplicationInstance.md). 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 lo contengono LOBs, assicurati che l'attività sia ottimizzata per la migrazione LOB. Per ulteriori informazioni sull'ottimizzazione per LOBs, consulta. [Impostazioni delle attività dei metadati di destinazione](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md) ## 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à. + Verifica che l'utente che ha creato l'endpoint abbia accesso in lettura alla tabella che intendi migrare. + Controlla che l'oggetto che vuoi migrare sia una tabella. Se si tratta di una vista, aggiorna le mappature della tabella e specifica il localizzatore di oggetti come "visualizzazione" o "tutto". Per ulteriori informazioni, consulta [Specifica della selezione delle tabelle e delle regole di trasformazione dalla console](CHAP_Tasks.CustomizingTasks.TableMapping.Console.md). ## 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: 1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 1. Scegli la scheda **Ruoli**. Scegli **Crea ruolo**. 1. Nella sezione **Seleziona il tipo di identità attendibile** scegli **Servizio AWS**. 1. Nella sezione **Scegli un caso d'uso** seleziona **DMS**. 1. Scegli **Successivo: autorizzazioni**. 1. Entra **AmazonDMSCloudWatchLogsRole** nel campo di ricerca e seleziona la casella accanto ad **Amazon DMSCloud WatchLogsRole**. Ciò concede AWS DMS le autorizzazioni di accesso. CloudWatch 1. Scegliere **Next: Tags (Successivo: Tag)**. 1. Scegliere **Next:Review (Successivo: Rivedi)**. 1. Per **Nome ruolo** immetti **dms-cloudwatch-logs-role**. Il nome rispetta la distinzione tra maiuscole e minuscole. 1. Scegli **Crea ruolo**. **Nota** Se il tuo account fa parte di AWS Organizations, verifica che le Service Control Policies (SCPs) non limitino le autorizzazioni del tuo ruolo IAM. SCPs può sovrascrivere e limitare le autorizzazioni dei ruoli IAM anche se configurate correttamente. ## 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 AWS DMS replica e l'istanza DB Amazon RDS non si trovano nello stesso cloud privato virtuale (VPC), verifica che l'istanza DB 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-\$1\$1\$1\$1\$1). 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](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver). ## 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](CHAP_Monitoring.md#CHAP_Monitoring.Metrics). ## 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: 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. 1. 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 di accedere alla porta del database. AWS DMS 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'[ModifyEndpoint](https://docs.aws.amazon.com/dms/latest/APIReference/API_ModifyEndpoint.html)azione Console di gestione AWS o per impostare il valore per il `parquetTimestampInMillisecond` tuo endpoint Amazon S3 su. `true` Per ulteriori informazioni, consulta [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html). ## Risoluzione dei problemi con Oracle Di seguito, puoi scoprire come risolvere problemi specifici relativi all'utilizzo con i database Oracle. AWS DMS **Topics** + [Estrazione dei dati dalle viste](#CHAP_Troubleshooting.Oracle.Views) + [Migrazione LOBs da Oracle 12c](#CHAP_Troubleshooting.Oracle.12cLOBs) + [Passaggio tra Oracle LogMiner e Binary Reader](#CHAP_Troubleshooting.Oracle.LogMinerBinaryReader) + [Errore: Oracle CDC stopped 122301 Oracle CDC maximum retry counter exceeded (CDC Oracle arrestato 122301 Numero di nuovi tentativi di CDC Oracle superato).](#CHAP_Troubleshooting.Oracle.CDCStopped) + [Aggiunta automatica di log supplementare a un endpoint di origine Oracle](#CHAP_Troubleshooting.Oracle.AutoSupplLogging) + [Le modifiche ai LOB non vengono acquisite](#CHAP_Troubleshooting.Oracle.LOBChanges) + [Errore: ORA-12899: valore troppo grande per la colonna *column-name*](#CHAP_Troubleshooting.Oracle.ORA12899) + [Il tipo di dati NUMBER viene interpretato in modo errato](#CHAP_Troubleshooting.Oracle.Numbers) + [Record mancanti durante il pieno carico](#CHAP_Troubleshooting.Oracle.RecordsMissing) + [Errore della tabella](#CHAP_Troubleshooting.Oracle.TableError) + [Errore: impossibile recuperare gli ID di destinazione di log redo archiviati da Oracle](#CHAP_Troubleshooting.Oracle.RedoLogError) + [Valutazione delle prestazioni di lettura dei log redo o di archiviazione di Oracle](#CHAP_Troubleshooting.Oracle.ReadPerformUtil) + [Impossibile recuperare i dati LOB](#CHAP_Troubleshooting.Oracle.LOBdata) ### 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: **Per utilizzare Binary Reader per l'acquisizione delle modifiche** 1. Accedi a Console di gestione AWS e apri la AWS DMS console nella versione [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). 1. Scegli **Endpoint**. 1. Seleziona l'endpoint di origine Oracle su cui desideri utilizzare Binary Reader. 1. Scegli **Modifica**. 1. Seleziona **Avanzato**, quindi per **Attributi aggiuntivi di connessione** aggiungi il seguente codice: ``` useLogminerReader=N ``` 1. Utilizza uno strumento di sviluppo Oracle come SQL-Plus per concedere i seguenti privilegi aggiuntivi all'account AWS DMS utente utilizzato per connettersi 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 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: **Per aggiungere automaticamente il log supplementare a un endpoint di origine Oracle** 1. [Accedi a Console di gestione AWS e apri la AWS DMS console alla https://console.aws.amazon.com/dms/ v2/.](https://console.aws.amazon.com/dms/v2/) 1. Scegli **Endpoint**. 1. Seleziona l'endpoint di origine Oracle a cui desideri aggiungere il log supplementare. 1. Scegli **Modifica**. 1. Seleziona **Avanzato**, quindi per **Attributi aggiuntivi di connessione** aggiungi il seguente codice: ``` addSupplementalLogging=Y ``` 1. Scegli **Modifica**. ### 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: + 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 troppo grande per la colonna *column-name* L'errore «ORA-12899: valore troppo grande per la colonna*column-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\$1LENGTH\$1SEMANTICS del database di origine è impostato su CHAR e il parametro NLS\$1LENGTH\$1SEMANTICS 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](CHAP_Source.Oracle.md#CHAP_Source.Oracle.DataTypes). 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](CHAP_Source.Oracle.md#CHAP_Source.Oracle.ConnectionAttrib). ### Record mancanti durante il pieno carico Quando 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](CHAP_Source.Oracle.md#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging). ### 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\$1ARCHIVED\$1LOG è 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](CHAP_SupportAmi.md). È possibile utilizzare l'AMI AWS DMS diagnostica 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. + Utilizzate il metodo PL/SQL (`dbms_lob.read`) per valutare le prestazioni dei redo log file. + Utilizzate Single-thread per valutare le prestazioni di lettura su. ASMFile + Usa 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 diagnostica AMI Amazon EC2 e connettiti ad essa. Per ulteriori informazioni, consulta [Utilizzo dell'AMI AWS DMS diagnostica](CHAP_SupportAmi.md). 1. Esegui il comando **awsreplperf**. ``` $ awsreplperf ``` Il comando visualizza le opzioni di AWS DMS Oracle Read Performance Utility. ``` 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 ``` 1. Seleziona un'opzione dall'elenco. 1. 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 []: ``` 1. 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\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-oracle-read-perf-util.png) 1. Per uscire dall'utilità, immetti **0** (zero). **Fasi successive** + Quando i risultati mostrano che la velocità di lettura è inferiore a una soglia accettabile, esegui lo [script di supporto diagnostico Oracle](CHAP_SupportScripts.Oracle.md) 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\$1BUFFER a 200 MB per migliorare le prestazioni. + Consulta [Best practice per AWS DMS](CHAP_BestPractices.md) per assicurarti che l'istanza di replica DMS, l'attività e gli endpoint siano configurati in modo ottimale. ### Impossibile recuperare i dati LOB Gli errori di ricerca LOB (Large Object) AWS DMS si verificano in circostanze specifiche durante i processi di migrazione dei dati. Durante la fase di caricamento completo, AWS DMS utilizza il metodo di ricerca per la migrazione dei dati LOB quando l'attività è configurata per la modalità FULL LOB. In particolare, durante la fase CDC (Change Data Capture), utilizza AWS DMS costantemente il metodo Lookup indipendentemente dalle impostazioni LOB. AWS DMS replica innanzitutto le righe senza la colonna LOB, recupera i dati LOB utilizzando un **SELECT** comando ed esegue un **UPDATE** comando per replicare il campo LOB sulla destinazione. Questa operazione sequenziale di INSERT e UPDATE caratterizza il comportamento LOOKUP. La ricerca LOB durante la fase CDC non è universalmente applicabile a tutti i motori di database e, a seconda della dimensione dei dati, le attività possono replicare righe in linea insieme ai dati delle colonne. L'errore del processo di ricerca LOB è un problema comune che può verificarsi durante la migrazione e viene visualizzato il messaggio di errore «Failed to get lob data, going to set to null». Durante questo errore, i dati parziali della tabella sulla destinazione, in particolare le colonne LOB, vengono visualizzati come valori NULL. Vari fattori possono innescare questi errori: + Eliminazione della riga di origine che avviene prima che DMS completi il processo di ricerca + Problemi di connettività intermittenti che interrompono i thread di ricerca + Le query di ricerca DMS entrano in uno stato di attesa a causa di scenari di blocco della tabella di origine Per risolvere questi errori di ricerca LOB, è possibile effettuare le seguenti operazioni: + Implementa impostazioni LOB limitate durante la fase di caricamento completo per eliminare il comportamento di ricerca e migliorare le prestazioni. + Ricarica le tabelle interessate quando vengono rilevati messaggi di errore di ricerca e dati parziali sulla destinazione. + Per i problemi che si verificano a causa di problemi intermittenti di disponibilità della rete o del database di origine, riavvia l'attività per risolvere tutte le incongruenze nei dati delle tabelle. Questi passaggi per la gestione degli errori di LOB Lookup garantiscono una migrazione dei dati più affidabile e aiutano a mantenere l'integrità dei dati durante l'intero processo. ## Risoluzione dei problemi relativi a MySQL Di seguito, puoi scoprire come risolvere problemi specifici relativi all'utilizzo AWS DMS con i database MySQL. **Topics** + [L'attività CDC ha esito negativo per l'endpoint dell'istanza database di Amazon RDS perché la registrazione binaria è disabilitata](#CHAP_Troubleshooting.MySQL.CDCTaskFail) + [Le connessioni a un'istanza MySQL di destinazione vengono disconnesse durante un'attività](#CHAP_Troubleshooting.MySQL.ConnectionDisconnect) + [Aggiunta di commit automatico a un endpoint compatibile con MySQL](#CHAP_Troubleshooting.MySQL.Autocommit) + [Disabilitazione delle chiavi esterne su un endpoint di destinazione compatibile con MySQL](#CHAP_Troubleshooting.MySQL.DisableForeignKeys) + [Caratteri sostituiti con punto interrogativo](#CHAP_Troubleshooting.MySQL.CharacterReplacement) + [Voci di log "Evento errato"](#CHAP_Troubleshooting.MySQL.BadEvent) + [Change Data Capture con MySQL 5.5](#CHAP_Troubleshooting.MySQL.MySQL55CDC) + [Aumento del periodo di conservazione dei log binari per istanze database di Amazon RDS](#CHAP_Troubleshooting.MySQL.BinLogRetention) + [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).](#CHAP_Troubleshooting.MySQL.NoImpact) + [Errore: Identifier too long (Identificatore troppo lungo)](#CHAP_Troubleshooting.MySQL.IDTooLong) + [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)](#CHAP_Troubleshooting.MySQL.UnsupportedCharacterSet) + [Errore: la conversione dei dati da 1252 a UTF8 [120112] non è riuscita](#CHAP_Troubleshooting.MySQL.DataConversionFailed) + [Indici, chiavi esterne o aggiornamenti o eliminazioni a cascata non migrati](#CHAP_Troubleshooting.MySQL.FKsAndIndexes) ### 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: + 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](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html) nella [documentazione di MySQL](https://dev.mysql.com/). ### Aggiunta di commit automatico a un endpoint compatibile con MySQL **Per aggiungere il commit automatico a un endpoint di destinazione compatibile con MySQL** 1. [Accedi a Console di gestione AWS e apri la AWS DMS console nella versione v2/. https://console.aws.amazon.com/dms/](https://console.aws.amazon.com/dms/v2/) 1. Scegli **Endpoint**. 1. Seleziona l'endpoint di destinazione compatibile con MySQL a cui desideri aggiungere il commit automatico. 1. Scegli **Modifica**. 1. Seleziona **Avanzato**, quindi per **Attributi aggiuntivi di connessione** aggiungi il seguente codice: ``` Initstmt= SET AUTOCOMMIT=1 ``` 1. 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 a Console di gestione AWS e apri la AWS DMS console su https://console.aws.amazon.com/dms/ v2/.](https://console.aws.amazon.com/dms/v2/) 1. Scegli **Endpoint**. 1. Seleziona l'endpoint di destinazione MySQL, Aurora MySQL o MariaDB su cui desideri disabilitare le chiavi esterne. 1. Scegli **Modifica**. 1. Seleziona **Avanzato**, quindi per **Attributi aggiuntivi di connessione** aggiungi il seguente codice: ``` Initstmt=SET FOREIGN_KEY_CHECKS=0 ``` 1. Scegli **Modifica**. ### 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 i database compatibili con Amazon RDS MySQL richiede la registrazione binaria basata su righe di immagini complete, 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 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 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. 1. Aggiungi la seguente ECA all'endpoint di destinazione: AWS DMS ``` Initstmt=SET FOREIGN_KEY_CHECKS=0; ``` 1. Crea l' AWS DMS attività con `TargetTablePrepMode` set to. `DO_NOTHING` 1. Imposta `Stop task after full load completes` su `StopTaskCachedChangesApplied`. 1. Avvia l'attività. AWS DMS interrompe l'attività automaticamente dopo il completamento del caricamento completo e applica le modifiche memorizzate nella cache. 1. Rimuovi l'attributo aggiuntivo di connessione `SET FOREIGN_KEY_CHECKS` che hai aggiunto in precedenza. 1. 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. 1. Aggiungere la seguente ECA all'endpoint di destinazione AWS DMS : ``` Initstmt=SET FOREIGN_KEY_CHECKS=0; ``` 1. Creare l' AWS DMS attività con il `TargetTablePrepMode` parametro impostato su `DO_NOTHING` e `EnableValidation` impostato su. `FALSE` 1. Avviate l'operazione. AWS DMS interrompe l'attività automaticamente dopo il completamento del caricamento completo e applica le modifiche memorizzate nella cache. 1. 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. 1. 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. 1. 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, puoi scoprire come risolvere problemi specifici relativi all'utilizzo AWS DMS con i database PostgreSQL. **Topics** + [I tipi di dati JSON sono troncati](#CHAP_Troubleshooting.PostgreSQL.JSONTruncation) + [Le colonne di un tipo di dati definito dall'utente non vengono migrate correttamente](#CHAP_Troubleshooting.PostgreSQL.UserDefinedDataType) + [Errore: No schema has been selected to create in (Nessuno schema selezionato per la creazione)](#CHAP_Troubleshooting.PostgreSQL.NoSchema) + [Le operazioni di eliminazione e aggiornamento su una tabella non vengono replicate mediante CDC](#CHAP_Troubleshooting.PostgreSQL.DeletesNotReplicated) + [Le istruzioni Truncate non vengono propagate](#CHAP_Troubleshooting.PostgreSQL.Truncate) + [Come evitare che PostgreSQL acquisisca DDL](#CHAP_Troubleshooting.PostgreSQL.NoCaptureDDL) + [Selezione dello schema in cui vengono creati gli oggetti di database per l'acquisizione di DDL](#CHAP_Troubleshooting.PostgreSQL.SchemaDDL) + [Tabelle Oracle mancanti dopo la migrazione a PostgreSQL](#CHAP_Troubleshooting.PostgreSQL.OracleTablesMissing) + [ReplicationSlotDiskUsage aumenta e restart\$1lsn interrompe l'avanzamento durante transazioni lunghe, come i carichi di lavoro ETL](#CHAP_Troubleshooting.PostgreSQL.AvoidLongTransactions) + [Un'attività che utilizza la vista come origine non dispone di righe copiate](#CHAP_Troubleshooting.PostgreSQL.ViewTask) + [Sequenza di byte non valida per la codifica "» UTF8](#CHAP_Troubleshooting.PostgreSQL.invalidbyte) ### 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\$1ERROR 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\$1lsn 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 fino al termine della transazione e del rollback. completed/aborted 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](CHAP_Tasks.CustomizingTasks.TableMapping.Console.md). Le origini che supportano le viste sono riportate di seguito. + Oracle + Microsoft SQL Server + MySQL + PostgreSQL + IBM Db2 LUW + SAP Adaptive Server Enterprise (ASE) ### Sequenza di byte non valida per la codifica "» UTF8 La migrazione dei dati da Oracle a AWS DMS PostgreSQL presenta sfide uniche a causa delle differenze di codifica dei set di caratteri tra i due database. Un problema significativo deriva dal set di AL32 UTF8 caratteri di Oracle, che supporta completamente i caratteri a 4 byte, mentre l'implementazione del set di caratteri di PostgreSQL non dispone di questa funzionalità. UTF8 Questa disparità spesso porta a errori di migrazione, in particolare quando si tratta di tabelle o colonne nel codice sorgente Oracle che contengono caratteri a 4 byte. Durante i tentativi di migrazione, è possibile che vengano visualizzati messaggi di errore sia nei log delle attività DMS che nei log del database di destinazione PostgreSQL che indicano problemi con sequenze di byte non valide. UTF8 Viene visualizzato un tipico messaggio di errore «ERROR: invalid byte sequence for encoding" «: 0xed 0xb0 0x86". UTF8 Per risolvere questo problema, fornisce una soluzione tramite le impostazioni "». AWS DMS `ReplaceChars` Sostituisce o elimina automaticamente i caratteri non validi durante il processo di migrazione. Questo approccio previene efficacemente gli errori relativi alla codifica senza richiedere modifiche ai dati di origine. Per ulteriori informazioni, vedete l'elenco «*Convalida e sostituzione dei set di caratteri*» [nell'argomento Impostazioni dell'attività di sostituzione dei caratteri](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.CharacterSubstitution.html). ## 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. **Topics** + [La replica continua non riesce dopo il failover di RDS per SQL Server su server secondario](#CHAP_Troubleshooting.SQLServer.RepFailover) + [Errori durante l'acquisizione di modifiche per il database SQL Server](#CHAP_Troubleshooting.SQLServer.CDCErrors) + [Colonne di identità mancanti](#CHAP_Troubleshooting.SQLServer.IdentityColumns) + [Errore: SQL Server non supporta le pubblicazioni](#CHAP_Troubleshooting.SQLServer.Publications) + [Le modifiche non vengono visualizzate nella destinazione](#CHAP_Troubleshooting.SQLServer.NoChanges) + [Tabella non uniforme mappata tra le partizioni](#CHAP_Troubleshooting.SQLServer.Nonuniform) + [Errore: operazione CDC non riuscita con una busta errata, codice dati non valido durante l'elaborazione di una transazione context/LCX](#CHAP_Troubleshooting.SQLServer.badenvelope.cdc) ### 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\$1owner con l'account rdsa per il database, quindi riprendi](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.SQLServer.CommonDBATasks.ChangeDBowner.html) 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](CHAP_Source.SQLServer.md). ### 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 non AWS DMS 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](CHAP_Source.SQLServer.md). ### 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: + Se la tabella dispone di un indice cluster, eseguire una ricostruzione dell'indice. + Se la tabella non dispone di un indice cluster, aggiungere un indice cluster alla tabella (è possibile eliminarlo in seguito, se lo si desidera). ### Errore: operazione CDC non riuscita con una busta errata, codice dati non valido durante l'elaborazione di una transazione context/LCX L'errore «Bad Envelope» si verifica quando non AWS DMS è possibile convalidare tipi di eventi specifici nella replica della fase CDC durante il processo di convalida. Questo errore si verifica in genere quando si riprendono le attività da un timestamp specifico che rientra nel bel mezzo di una transazione. In questi casi, l'attività potrebbe leggere un evento di commit senza trovare l'evento «start transaction» corrispondente, generando un contesto di transazione non valido e generando l'errore «Bad Envelope». Per risolvere questo problema, è necessario modificare la configurazione dell'endpoint di origine di SQL Server impostando il `ignoreTxnCtxValidityCheck` parametro su `true` nella sezione Extra Connection Attribute, prima di riprendere l'attività. [Se l'errore persiste dopo l'implementazione di questa soluzione, invia un ticket di supporto. AWS](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) ## 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. **Topics** + [Caricamento in un cluster Amazon Redshift in una regione diversa AWS](#CHAP_Troubleshooting.Redshift.Regions) + [Errore: Relation "awsdms\$1apply\$1exceptions" already exists (Relazione "awsdms\$1apply\$1exceptions" già esistente)](#CHAP_Troubleshooting.Redshift.AlreadyExists) + [Errori con tabelle il cui nome inizia con "awsdms\$1changes"](#CHAP_Troubleshooting.Redshift.Changes) + [Visualizzazione di tabelle nei cluster con nomi simili a dms.awsdms\$1changes000000000XXXX](#CHAP_Troubleshooting.Redshift.TempTables) + [Autorizzazioni necessarie per l'utilizzo di Amazon Redshift](#CHAP_Troubleshooting.Redshift.Permissions) ### Caricamento in un cluster Amazon Redshift in una regione diversa AWS 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\$1apply\$1exceptions" already exists (Relazione "awsdms\$1apply\$1exceptions" già esistente) Spesso, l'errore "Relazione "awsdms\$1apply\$1exceptions" 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\$1changes" I messaggi di errore delle tabelle con nomi che iniziano con "awsdms\$1changes" 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\$1changes000000000XXXX 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: + 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](CHAP_Target.Redshift.md). ## 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. **Topics** + [Errore: UTF8 campi CHARACTER SET terminati da ',' racchiusi da '"' righe terminate da '\$1n'](#CHAP_Troubleshooting.Aurora.ANSIQuotes) ### Errore: UTF8 campi CHARACTER SET terminati da ',' racchiusi da '"' righe terminate da '\$1n' 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\$1QUOTES fa parte del parametro SQL\$1MODE. Se ANSI\$1QUOTES fa parte del parametro SQL\$1MODE, le doppie virgolette vengono considerate come virgolette semplici e ciò può creare problemi quando esegui un'attività. Per risolvere questo errore, rimuovi ANSI\$1QUOTES dal parametro SQL\$1MODE. ``` 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\$1NULL 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 in corso (CDC), se prevedi di avviare la replica da un timestamp specifico, imposta l'attributo di connessione aggiuntivo sul timestamp richiesto. `StartFromContext` Per ulteriori informazioni, vedete [Attributi di connessione aggiuntivi ()](CHAP_Source.DB2.md#CHAP_Source.DB2.ConnectionAttrib) quando si utilizza Db2 LUW. ECAs 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. ``` ## Table ha sospeso una tabella con l'errore «Impossibile creare l'istruzione 'where'» In DMS, quando si tenta di aggiornare un record in una tabella che non ha una chiave primaria, il sistema non è in grado di creare una condizione WHERE e visualizza il seguente errore: ``` [TARGET_APPLY ]E: Failed to build 'where' statement ``` Ciò può verificarsi a causa di diversi problemi o limitazioni noti, tra cui: + La colonna chiave primaria viene rimossa utilizzando la regola di `remove-column` trasformazione. + La struttura della tabella presenta una mancata corrispondenza tra il database di origine e quello di destinazione, ovvero la colonna chiave primaria esistente nell'origine ma non nella destinazione o potrebbe essere stata rimossa. + Limitazioni note o prerequisiti mancanti: + La registrazione supplementare non è abilitata correttamente nelle tabelle Oracle. + Tabella Oracle creata con nomi di oggetti lunghi (oltre 30 byte), quindi i nomi degli oggetti potrebbero essere nomi di tabelle o colonne. + Replica da Oracle Application Containers PDB. # Risoluzione dei problemi di latenza in AWS Database Migration Service Questa sezione fornisce una panoramica delle cause più comuni della latenza delle AWS DMS attività durante la fase di replica in corso (CDC). AWS DMS replica i dati in modo asincrono. La latenza è il ritardo tra il momento in cui una modifica è stata salvata sull'origine e il momento in cui la modifica è stata replicata sulla destinazione. La latenza può essere causata da un'errata configurazione dei componenti di replica, ad esempio: + Endpoint oppure origine dati di origine + Endpoint oppure origine dati di destinazione + Istanze di replica + La rete tra questi componenti Ti consigliamo di eseguire una migrazione di test come prova concettuale per raccogliere le informazioni sulla replica. Quindi puoi utilizzare queste informazioni per ottimizzare la configurazione di replica in modo da ridurre al minimo la latenza. Per informazioni sull'esecuzione di una migrazione di tipo proof of concept, consulta [Esecuzione di un proof of concept](CHAP_BestPractices.md#CHAP_BestPractices.RunPOC). **Topics** + [Tipi di latenza CDC](#CHAP_Troubleshooting_Latency_Types) + [Cause comuni della latenza CDC](#CHAP_Troubleshooting_Latency_Causes) + [Risoluzione dei problemi di latenza](CHAP_Troubleshooting_Latency_Troubleshooting.md) ## Tipi di latenza CDC Questa sezione include i tipi di latenza di replica che possono verificarsi durante la CDC. ### Latenza di origine Il ritardo, in secondi, tra l'ora del commit dell'ultimo evento acquisito dall'endpoint di origine e il timestamp di sistema corrente dell'istanza di replica. È possibile monitorare la latenza tra l'origine dati e l'istanza di replica utilizzando la metrica. `CDCLatencySource` CloudWatch Una metrica `CDCLatencySource` elevata indica che il processo di acquisizione delle modifiche dall'origine è ritardato. Ad esempio, se l'applicazione esegue il commit di un inserto nell'origine alle 10:00 e AWS DMS utilizza la modifica alle 10:02, la metrica è 120 secondi. `CDCLatencySource` Per informazioni sulle metriche per, consulta. CloudWatch AWS DMS[Parametri dell'attività di replica](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task) ### Latenza della destinazione Il ritardo, in secondi, tra l'ora del commit sull'origine del primo evento in attesa di eseguire il commit sulla destinazione e il timestamp corrente dell'istanza di replica DMS. Puoi monitorare la latenza tra i commit sull'origine dati e sulla destinazione dei dati utilizzando la metrica. `CDCLatencyTarget` CloudWatch Ciò significa che `CDCLatencyTarget` include eventuali ritardi nella lettura dall'origine. Di conseguenza, `CDCLatencyTarget` è sempre maggiore o uguale a `CDCLatencySource`. Ad esempio, se l'applicazione esegue il commit di un inserto nell'origine alle 10:00, lo AWS DMS consuma alle 10:02 e lo scrive nella destinazione alle 10:05, la metrica è di 300 secondi. `CDCLatencyTarget` ## Cause comuni della latenza CDC Questa sezione include le cause di latenza che la replica potrebbe riscontrare durante la CDC. **Topics** + [Risorse degli endpoint](#CHAP_Troubleshooting_Latency_Causes_Endpoint) + [Risorse dell'istanza di replica](#CHAP_Troubleshooting_Latency_Causes_Replication_Instance) + [Velocità e larghezza di banda della rete](#CHAP_Troubleshooting_Latency_Causes_Replication_Network) + [Configurazione di DMS](#CHAP_Troubleshooting_Latency_Causes_Replication_DMS_Config) + [Scenari di replica](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios) ### Risorse degli endpoint I seguenti fattori influiscono in modo significativo sulle prestazioni e sulla latenza della replica: + Configurazioni del database di origine e di destinazione + Dimensioni istanza + Datastore di origine o di destinazione con provisioning insufficiente o configurati in modo errato Per identificare le cause della latenza causate dai problemi degli endpoint per le sorgenti e le destinazioni -hosted, monitora le seguenti metriche AWS: CloudWatch + `FreeMemory` + `CPUUtilization` + Throughput e I/O metriche, ad esempio, o `WriteIOPS` `WriteThroughput` `ReadLatency` + Metriche del volume delle transazioni, ad esempio `CDCIncomingChanges`. Per informazioni sul monitoraggio delle CloudWatch metriche, consulta. [AWS Database Migration Service metriche](CHAP_Monitoring.md#CHAP_Monitoring.Metrics) ### Risorse dell'istanza di replica Le risorse dell'istanza di replica sono fondamentali per la replica ed è necessario assicurarsi che non si verifichino colli di bottiglia, in quanto possono portare alla latenza sia sull'origine che sulla destinazione. Per identificare i colli di bottiglia relativi alle risorse per l'istanza di replica, verifica quanto segue: + CloudWatch Le metriche critiche come CPU, memoria, velocità I/O al secondo e storage non registrano picchi o valori costantemente elevati. + L'istanza di replica è dimensionata in modo appropriato per il carico di lavoro. Per informazioni sulla determinazione della dimensione corretta dell'istanza di replica, consulta [Selezione della dimensione migliore per un'istanza di replica](CHAP_BestPractices.SizingReplicationInstance.md). ### Velocità e larghezza di banda della rete La larghezza di banda della rete è un fattore che influisce sulla trasmissione dei dati. Per analizzare le prestazioni di rete della replica, esegui una delle operazioni riportate di seguito: + Controlla le metriche `ReadThroughput` e `WriteThroughput` a livello di istanza. Per informazioni sul monitoraggio delle CloudWatch metriche, consulta. [AWS Database Migration Service metriche](CHAP_Monitoring.md#CHAP_Monitoring.Metrics) + Usa l'AMI AWS DMS Diagnostic Support. Se l'AMI del supporto di diagnostica non è disponibile nella tua regione, puoi scaricarla da qualsiasi regione supportata e copiarla nella tua regione per eseguire l'analisi della rete. Per informazioni sull'AMI del supporto di diagnostica, consulta [Utilizzo dell'AMI di supporto AWS DMS diagnostico](CHAP_SupportAmi.md). L'ingresso CDC AWS DMS è a thread singolo per garantire la coerenza dei dati. Di conseguenza, è possibile determinare il volume di dati che la rete è in grado di supportare calcolando la velocità di trasferimento dei dati a thread singolo. Ad esempio, se l'attività si connette alla fonte utilizzando una rete da 100 Mbps (megabit al secondo), la replica ha un'allocazione teorica massima della larghezza di banda di 12,5 (megabyte al secondo). MBps Ciò equivale a 45 gigabit all'ora. Se la velocità di generazione del log delle transazioni sull'origine è superiore a 45 gigabit all'ora, significa che l'attività ha una latenza della CDC. Per una MBps rete a 100, queste velocità sono massime teoriche; altri fattori, come il traffico di rete e il sovraccarico di risorse sull'origine e sulla destinazione, riducono la larghezza di banda effettiva disponibile. ### Configurazione di DMS Questa sezione contiene le configurazioni di replica consigliate che possono aiutare a ridurre la latenza. + **Impostazioni degli endpoint**: le impostazioni degli endpoint di origine e di destinazione possono causare un calo delle prestazioni dell'istanza di replica. Le impostazioni degli endpoint che attivano funzionalità a uso intensivo di risorse influiscono sulle prestazioni. Ad esempio, per un endpoint Oracle, la disabilitazione LogMiner e l'utilizzo di Binary Reader migliorano le prestazioni, poiché richiedono molte risorse. LogMiner La seguente impostazione migliora le prestazioni di un endpoint Oracle: ``` useLogminerReader=N;useBfile=Y ``` Per ulteriori informazioni sulle impostazioni degli endpoint, consulta la documentazione per il motore dell'endpoint di origine e di destinazione nell'argomento [Utilizzo degli AWS endpoint DMS](CHAP_Endpoints.md). + **Impostazioni delle attività**: alcune impostazioni delle attività per uno specifico scenario di replica possono causare un calo delle prestazioni dell'istanza di replica. Ad esempio, AWS DMS utilizza la modalità di applicazione transazionale per impostazione predefinita (`BatchApplyEnabled=false`) per CDC per tutti gli endpoint, ad eccezione di Amazon Redshift. Tuttavia, per le origini con un numero elevato di modifiche, l'impostazione `BatchApplyEnabled` su `true` può migliorare le prestazioni. Per ulteriori informazioni sulle impostazioni delle attività, consulta [Specificazione delle impostazioni delle attività per le attività del AWS Database Migration Service](CHAP_Tasks.CustomizingTasks.TaskSettings.md). + **Posizione iniziale di un'attività di sola CDC**: l'avvio di un'attività di sola CDC da una posizione o da un timestamp precedente comporta l'avvio dell'attività con una maggiore latenza dell'origine CDC. A seconda del volume delle modifiche all'origine, la latenza dell'attività richiede del tempo per la riduzione. + **Impostazioni LOB**: i tipi di dati Large Object possono ostacolare le prestazioni di replica a causa del modo in cui vengono replicati dati binari di grandi dimensioni. AWS DMS Per ulteriori informazioni, consulta i seguenti argomenti: + [Impostazione del supporto LOB per i database di origine in un task AWS DMS](CHAP_Tasks.LOBSupport.md) + [Migrazione di oggetti binari di grandi dimensioni () LOBs](CHAP_BestPractices.md#CHAP_BestPractices.LOBS). ### Scenari di replica In questa sezione sono descritti specifici scenari di replica e in che modo possono influire sulla latenza. **Topics** + [Interruzione di un'attività per un periodo di tempo esteso](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Stoptask) + [Modifiche memorizzate nella cache](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Cachedchanges) + [Replica in più regioni](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Crossregion) #### Interruzione di un'attività per un periodo di tempo esteso Quando si interrompe un'operazione, AWS DMS salva la posizione dell'ultimo registro delle transazioni letto dall'origine. Quando si riprende l'attività, DMS tenta di continuare la lettura dalla stessa posizione del log delle transazioni. La ripresa di un'attività dopo diverse ore o giorni causa un aumento della latenza dell'origine CDC fino a quando DMS non finisce di consumare il backlog delle transazioni. #### Modifiche memorizzate nella cache Le **modifiche memorizzate nella cache** sono modifiche che l'applicazione scrive nell'origine dati durante l' AWS DMS esecuzione della fase di replica a pieno carico. DMS non applica queste modifiche fino al completamento della fase di pieno carico e all'avvio della fase CDC. Per un'origine con un numero elevato di transazioni, le modifiche memorizzate nella cache richiedono più tempo per essere applicate, quindi la latenza dell'origine aumenta all'inizio della fase CDC. Ti consigliamo di eseguire la fase di pieno carico quando i volumi delle transazioni sono bassi per ridurre al minimo il numero di modifiche memorizzate nella cache. #### Replica in più regioni La localizzazione degli endpoint DMS o dell'istanza di replica in aree diverse aumenta la latenza di rete. AWS Di conseguenza aumenta la latenza della replica. Per ottenere prestazioni ottimali, posiziona l'endpoint di origine, l'endpoint di destinazione e l'istanza di replica nella stessa regione. AWS # Risoluzione dei problemi di latenza In questa sezione sono indicate le procedure per la risoluzione dei problemi relativi alla latenza di replica. Per risolvere i problemi di latenza, esegui questi passaggi: + Innanzitutto, determina il tipo e la quantità di latenza per l'attività. Controlla la sezione Statistiche della tabella dell'attività nella console DMS o nella CLI. Se i contatori cambiano, la trasmissione dei dati è in corso. Controlla insieme le metriche `CDCLatencySource` e `CDCLatencyTarget` per determinare se c'è un collo di bottiglia durante la CDC. + Se la metrica `CDCLatencySource` o `CDCLatencyTarget` riporta valori elevati indica un ostacolo nella replica, quindi controlla quanto segue: + Se `CDCLatencySource` è alto e `CDCLatencyTarget` uguale a`CDCLatencySource`, indica che c'è un collo di bottiglia nell'endpoint di origine e che la scrittura dei dati sulla destinazione avviene senza AWS DMS problemi. Leggi [Risoluzione dei problemi di latenza dell'origine](CHAP_Troubleshooting_Latency_Source.md) quanto segue. + Se `CDCLatencySource` è basso e alto, ciò indica che c'`CDCLatencyTarget`è un collo di bottiglia nell'endpoint di destinazione e che la lettura dei dati dalla fonte AWS DMS è fluida. Consulta [Risoluzione dei problemi di latenza della destinazione](CHAP_Troubleshooting_Latency_Target.md) di seguito. + Se `CDCLatencySource` è elevato e `CDCLatencyTarget` è significativamente superiore a `CDCLatencySource`, indica problemi sia nella lettura dell'origine che nella scrittura della destinazione. Analizza prima la latenza dell'origine, quindi analizza la latenza di destinazione. Per informazioni sul monitoraggio delle metriche dell'attività DMS, consulta [Monitoraggio delle attività AWS DMS](CHAP_Monitoring.md). # Risoluzione dei problemi di latenza dell'origine Nei seguenti argomenti vengono descritti gli scenari di replica specifici dei tipi di endpoint di origine. **Topics** + [Risoluzione dei problemi relativi all'endpoint Oracle](CHAP_Troubleshooting_Latency_Source_Oracle.md) + [Risoluzione dei problemi relativi all'endpoint MySQL](CHAP_Troubleshooting_Latency_Source_MySQL.md) + [Risoluzione dei problemi relativi all'endpoint PostgreSQL](CHAP_Troubleshooting_Latency_Source_PostgreSQL.md) + [Risoluzione dei problemi relativi all'endpoint SQL Server](CHAP_Troubleshooting_Latency_Source_SQLServer.md) # Risoluzione dei problemi relativi all'endpoint Oracle In questa sezione vengono descritti gli scenari di replica specifici di Oracle. ## Lettura dell'origine sospesa AWS DMS sospende la lettura da una fonte Oracle nei seguenti scenari. Si tratta di un comportamento predefinito. È possibile indagare sulle cause utilizzando il log delle attività. Cerca messaggi simili ai seguenti nel log delle attività. Per informazioni sull'utilizzo del log delle attività, consulta [Visualizzazione e gestione dei registri delle attività AWS DMS](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs). + **Messaggio SORTER**: indica che DMS sta memorizzando nella cache le transazioni sull'istanza di replica. Per ulteriori informazioni, consulta la sezione seguente: [Messaggio SORTER nel log delle attività](CHAP_Troubleshooting_Latency_Target.md#CHAP_Troubleshooting_Latency_Target_Sorter). + **Log delle attività di debug**: se DMS interrompe il processo di lettura, l'attività scrive ripetutamente il seguente messaggio nei log delle attività di debug, senza modificare il campo di contesto o il timestamp: + **Binary Reader**: ``` [SOURCE_CAPTURE ]T: Produce CTI event: context '00000020.f23ec6e5.00000002.000a.00.0000:190805.3477731.16' xid [00000000001e0018] timestamp '2021-07-19 06:57:55' thread 2 (oradcdc_oralog.c:817) ``` + **LogMiner**: ``` [SOURCE_CAPTURE ]T: Produce INSERT event: object id 1309826 context '000000000F2CECAA010000010005A8F500000275016C0000000000000F2CEC58' xid [000014e06411d996] timestamp '2021-08-12 09:20:32' thread 1 (oracdc_reader.c:2269) ``` + AWS DMS registra il seguente messaggio per ogni nuova operazione di ripristino o di registro archiviata. ``` 00007298: 2021-08-13T22:00:34 [SOURCE_CAPTURE ]I: Start processing archived Redo log sequence 14850 thread 2 name XXXXX/XXXXX/ARCHIVELOG/2021_08_14/thread_2_seq_14850.22977.1080547209 (oradcdc_redo.c:754) ``` Se l'origine presenta nuove operazioni di redo o di log archiviate e non scrive questi messaggi nel registro, significa che l'operazione non AWS DMS sta elaborando gli eventi. ## Elevata generazione di log redo Se la tua attività sta elaborando log redo o di archiviazione, ma la latenza dell'origine rimane elevata, prova a identificare la velocità di generazione e i modelli di generazione dei log redo. Se il livello di generazione di log redo è elevato, aumenta la latenza dell'origine perché l'attività legge tutti i log redo e di archiviazione per recuperare le modifiche relative alle tabelle replicate. Per determinare la frequenza di generazione dei log redo, utilizza le seguenti query. + Frequenza di generazione di log redo al giorno: ``` select trunc(COMPLETION_TIME,'DD') Day, thread#, round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) GB, count(*) Archives_Generated from v$archived_log where completion_time > sysdate- 1 group by trunc(COMPLETION_TIME,'DD'),thread# order by 1; ``` + Frequenza di generazione di log redo all'ora: ``` Alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS'; select trunc(COMPLETION_TIME,'HH') Hour,thread# , round(sum(BLOCKS*BLOCK_SIZE)/1024/1024) "REDO PER HOUR (MB)", count(*) Archives from v$archived_log where completion_time > sysdate- 1 group by trunc(COMPLETION_TIME,'HH'),thread# order by 1 ; ``` Per risolvere i problemi di latenza in questo scenario, verifica quanto segue: + Controlla la larghezza di banda della rete e le prestazioni a thread singolo della replica per assicurarti che la rete sottostante sia in grado di supportare la velocità di generazione dei log redo di origine. Per informazioni su come la larghezza di banda della rete può influire sulle prestazioni della replica, consulta [Velocità e larghezza di banda della rete](CHAP_Troubleshooting_Latency.md#CHAP_Troubleshooting_Latency_Causes_Replication_Network) in precedenza. + Controllate se la registrazione supplementare è stata impostata correttamente. Evita la registrazione aggiuntiva sull'origine, ad esempio abilitando la registrazione di tutte le colonne di una tabella. Per informazioni sulla configurazione del log supplementare, consulta [Impostazione del log supplementare](CHAP_Source.Oracle.md#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging). + Verifica di utilizzare l'API corretta per leggere i log redo o di archiviazione. È possibile utilizzare Oracle LogMiner o AWS DMS Binary Reader. Mentre LogMiner legge i redo log online e i redo log file archiviati, Binary Reader legge e analizza direttamente i redo log file non elaborati. Di conseguenza, Binary Reader è più performante. Ti consigliamo di utilizzare Binary Reader se la generazione dei log redo supera i 10 GB/ora. Per ulteriori informazioni, consulta [Utilizzo di Oracle LogMiner o AWS DMS Binary Reader for CDC](CHAP_Source.Oracle.md#CHAP_Source.Oracle.CDC). + Controlla se `ArchivedLogsOnly` è impostato su `Y`. Se questa impostazione dell'endpoint è configurata, AWS DMS legge dai log redo archiviati. Ciò aumenta la latenza di origine, poiché AWS DMS attende che il redo log online venga archiviato prima della lettura. Per ulteriori informazioni, consulta [ArchivedLogsOnly](https://docs.aws.amazon.com/dms/latest/APIReference/API_OracleSettings.html#DMS-Type-OracleSettings-ArchivedLogsOnly). + Se l'origine Oracle utilizza Automatic Storage Management (ASM), consulta [Memorizzazione di REDO su Oracle ASM quando si utilizza Oracle come origine per AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.REDOonASM) per informazioni su come configurare correttamente il datastore. Puoi ottimizzare ulteriormente le prestazioni di lettura utilizzando l'attributo aggiuntivo di connessione `asmUsePLSQLArray`. Per ulteriori informazioni sull'uso di `asmUsePLSQLArray`, consultare [Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.ConnectionAttrib). # Risoluzione dei problemi relativi all'endpoint MySQL Questa sezione contiene scenari di replica specifici per MySQL. AWS DMS analizza periodicamente il log binario di MySQL per replicare le modifiche. Questo processo può aumentare la latenza negli scenari riportati di seguito: **Topics** + [Transazione di lunga durata sull'origine](#CHAP_Troubleshooting_Latency_Source_MySQL_Longrunning) + [Carico di lavoro elevato sull'origine](#CHAP_Troubleshooting_Latency_Source_MySQL_Highworkload) + [Conflitto di log binari](#CHAP_Troubleshooting_Latency_Source_MySQL_Binarylog) ## Transazione di lunga durata sull'origine Poiché MySQL scrive solo transazioni sottoposte al commit nel log binario, le transazioni di lunga durata causano picchi di latenza proporzionali al tempo di esecuzione della query. Per identificare le transazioni di lunga durata, utilizza la seguente query o il log delle query lente: ``` SHOW FULL PROCESSLIST; ``` Per informazioni sull'utilizzo del log delle query lente, consulta [The Slow Query Log](https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) nella [documentazione di MySQL](https://dev.mysql.com/doc/). Per evitare picchi di latenza dovuti alle transazioni di lunga durata, ristruttura le transazioni di origine per ridurre il tempo di esecuzione delle query o aumentare la frequenza di commit. ## Carico di lavoro elevato sull'origine Poiché DMS CDC è a thread singolo, un numero elevato di transazioni può aumentare la latenza dell'origine. Per determinare se la latenza dell'origine è dovuta a un carico di lavoro intenso, confronta il numero e la dimensione dei log binari generati durante il periodo di latenza con i log generati prima della latenza. Per verificare i log binari e lo stato dei thread DMS CDC, utilizza le seguenti query: ``` SHOW BINARY LOGS; SHOW PROCESSLIST; ``` Per ulteriori informazioni sugli stati dei thread di dump dei log binari CDC, consulta [Replication Source Thread States](https://dev.mysql.com/doc/refman/8.0/en/source-thread-states.html). È possibile determinare la latenza confrontando l'ultima posizione del log binario generata sull'origine con l'evento che DMS sta attualmente elaborando. Per identificare il log binario più recente nell'origine, esegui queste operazioni: + Abilita i log di debug sul componente SOURCE\$1CAPTURE. + Recupera il log binario di elaborazione DMS e i dettagli sulla posizione dai log di debug delle attività. + Utilizza la seguente query per identificare il log binario più recente nell'origine: ``` SHOW MASTER STATUS; ``` Per ottimizzare ulteriormente le prestazioni, modifica `EventsPollInterval`. Per impostazione predefinita, DMS esegue il polling del log binario ogni 5 secondi, ma è possibile migliorare le prestazioni riducendo questo valore. Per ulteriori informazioni sull'impostazione `EventsPollInterval`, consulta [Impostazioni degli endpoint quando si utilizza MySQL come sorgente per AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.ConnectionAttrib). ## Conflitto di log binari Quando si migrano più tabelle con una grande quantità di dati, ti consigliamo di suddividere le tabelle in attività separate per MySQL 5.7.2 o versioni successive. Nelle MySQL 5.7.2 e versioni successive, il thread di dump master crea meno conflitti di blocco e migliora la velocità di trasmissione effettiva. Di conseguenza, il thread di dump non blocca più il log binario ogni volta che legge un evento. Ciò significa che più thread di dump possono leggere contemporaneamente il file di log binario. Ciò significa anche che i thread di dump possono leggere il log binario mentre i client scrivono. Per ulteriori informazioni sui thread di dump, consulta [Replication Threads](https://dev.mysql.com/doc/refman/8.0/en/replication-threads.html) e [MySQL 5.7.2 release notes](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-2.html). Per migliorare le prestazioni della replica per le versioni delle origini MySQL precedenti alla 5.7.2, prova a consolidare le attività con i componenti CDC. # Risoluzione dei problemi relativi all'endpoint PostgreSQL In questa sezione vengono descritti gli scenari di replica specifici di PostgreSQL. **Topics** + [Transazione di lunga durata sull'origine](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning) + [Carico di lavoro elevato sull'origine](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload) + [Velocità di trasmissione effettiva della rete elevata](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork) + [Versare file in Aurora PostgreSQL](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill) ## Transazione di lunga durata sull'origine Quando nel database di origine sono presenti transazioni di lunga durata, ad esempio migliaia di inserimenti in una singola transazione, i contatori degli eventi e delle transazioni DMS CDC non aumentano fino al completamento della transazione. Questo ritardo può causare problemi di latenza che è possibile misurare utilizzando la metrica `CDCLatencyTarget`. Per esaminare le transazioni di lunga durata, effettua una delle operazioni riportate di seguito: + Usa la vista `pg_replication_slots`. Se il `restart_lsn` valore non si aggiorna, è probabile che PostgreSQL non sia in grado di rilasciare Write Ahead Logs WALs () a causa di transazioni attive di lunga durata. Per informazioni sulla vista `pg_replication_slots`, consulta [pg\$1replication\$1slots](https://www.postgresql.org/docs/15/view-pg-replication-slots.html) nella [documentazione di PostgreSQL 15.4](https://www.postgresql.org/docs/15/). + Utilizza la seguente query per ottenere l'elenco di tutte le query attive nel database, insieme alle informazioni correlate: ``` SELECT pid, age(clock_timestamp(), query_start), usename, query FROM pg_stat_activity WHERE query != '' AND query NOT ILIKE '%pg_stat_activity%' ORDER BY query_start desc; ``` Nei risultati delle query, il campo `age` mostra la durata attiva di ogni query, che è possibile utilizzare per identificare le query di lunga durata. ## Carico di lavoro elevato sull'origine Se l'origine PostgreSQL ha un carico di lavoro elevato, controlla quanto segue per ridurre la latenza: + Potresti riscontrare un'elevata latenza quando utilizzi il plug-in `test_decoding` durante la migrazione di un sottoinsieme di tabelle dal database di origine con un valore di transazioni al secondo (TPS) elevato. Questo perché il plug-in `test_decoding` invia tutte le modifiche del database all'istanza di replica, che DMS filtra in base alla mappatura delle tabelle dell'attività. Gli eventi delle tabelle che non fanno parte della mappatura delle tabelle dell'attività possono aumentare la latenza della origine. + Verifica la velocità di trasmissione effettiva TPS utilizzando uno dei metodi riportati di seguito. + Per i sorgenti Aurora PostgreSQL, usa la metrica. `CommitThroughput` CloudWatch + Per PostgreSQL in esecuzione su Amazon RDS o on-premise, usa la seguente query con un client PSQL versione 11 o successiva (premi **enter** durante la query per ottenere i risultati): ``` SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset select pg_sleep(60); SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second"; ``` + Per ridurre la latenza quando usi il plug-in `test_decoding`, puoi considerare di utilizzare il plug-in `pglogical`. A differenza del plug-in `test_decoding`, il plug-in `pglogical` filtra le modifiche WAL all'origine e invia solo le modifiche pertinenti all'istanza di replica. Per informazioni sull'utilizzo del plugin con, consulta. `pglogical` AWS DMS[Configurazione del plug-in pglogical](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security.Pglogical) ## Velocità di trasmissione effettiva della rete elevata La replica potrebbe richiedere un elevato utilizzo della larghezza di banda della rete quando si utilizza il plug-in `test_decoding`, specialmente durante transazioni con volumi elevati. Questo perché il plug-in `test_decoding` elabora le modifiche e le converte in un formato leggibile dall'uomo più grande del formato binario originale. Per migliorare le prestazioni, considera di utilizzare `pglogical` che è un plug-in binario. A differenza del plug-in `test_decoding`, il plug-in `pglogical` genera un output in formato binario, con conseguenti modifiche del flusso WAL compresso. ## Versare file in Aurora PostgreSQL Nella versione 13 e successive di PostgreSQL, il parametro determina l'allocazione della memoria per `logical_decoding_work_mem` la decodifica e lo streaming. [Per ulteriori informazioni sul `logical_decoding_work_mem` parametro, vedere [Consumo di risorse in PostgreSQL nella documentazione di PostgreSQL](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM) 13.13.](https://www.postgresql.org/docs/13/) La replica logica accumula le modifiche per tutte le transazioni in memoria fino al completamento di tali transazioni. Se la quantità di dati archiviati in tutte le transazioni supera la quantità specificata dal parametro del database`logical_decoding_work_mem`, DMS trasferisce i dati della transazione su disco per liberare memoria per i nuovi dati di decodifica. Le transazioni a esecuzione prolungata, o molte sottotransazioni, possono comportare un maggiore consumo di memoria di decodifica logica da parte del DMS. Questo maggiore utilizzo della memoria fa sì che DMS crei file di fuoriuscita su disco, il che causa un'elevata latenza del codice sorgente durante la replica. Per ridurre l'impatto di un aumento del carico di lavoro di origine, procedi come segue: + Riduci le transazioni di lunga durata. + Riduci il numero di sottotransazioni. + Evita di eseguire operazioni che generano una grande quantità di record di log, come l'eliminazione o l'aggiornamento di un'intera tabella in una singola transazione. Esegui invece operazioni in batch più piccoli. Puoi utilizzare le seguenti CloudWatch metriche per monitorare il carico di lavoro sulla fonte: + `TransactionLogsDiskUsage`: Il numero di byte attualmente occupati dal WAL logico. Questo valore aumenta in modo monotono se gli slot di replica logica non sono in grado di tenere il passo con il ritmo delle nuove scritture o se transazioni di lunga durata impediscono la raccolta indesiderata di file più vecchi. + `ReplicationSlotDiskUsage`: la quantità di spazio su disco attualmente utilizzata dagli slot di replica logica. È possibile ridurre la latenza della sorgente ottimizzando il parametro. `logical_decoding_work_mem` Il valore predefinito per questo parametro è 64 MB. Questo parametro limita la quantità di memoria utilizzata da ogni connessione di replica in streaming logico. Si consiglia di impostare un `logical_decoding_work_mem` valore significativamente più alto rispetto al `work_mem` valore per ridurre la quantità di modifiche decodificate che DMS scrive su disco. Si consiglia di verificare periodicamente la presenza di file fuoriusciti, in particolare durante i periodi di intensa attività di migrazione o di latenza. Se DMS sta creando un numero significativo di file di spill, significa che la decodifica logica non funziona in modo efficiente, il che può aumentare la latenza. Per mitigare questo problema, aumentate il valore del parametro. `logical_decoding_work_mem` È possibile controllare l'attuale eccesso di transazioni con la `aurora_stat_file` funzione. Per ulteriori informazioni, consulta [Adjusting working memory for logical decoding](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem) nella *Amazon Relational Database* Service Developer Guide. # Risoluzione dei problemi relativi all'endpoint SQL Server In questa sezione vengono descritti gli scenari di replica specifici di SQL Server. Per determinare quali modifiche replicare da SQL Server, AWS DMS legge i log delle transazioni ed esegue scansioni periodiche sul database di origine. La latenza della replica in genere deriva dalla limitazione (della larghezza di banda della rete) di SQL Server per queste scansioni a causa dei vincoli delle risorse. Può anche derivare da un aumento significativo del numero di eventi scritti nel log delle transazioni in un breve periodo di tempo. **Topics** + [Ricostruzione degli indici](#CHAP_Troubleshooting_Latency_Source_SQLServer_Indexrebuilds) + [Transazioni di grandi dimensioni](#CHAP_Troubleshooting_Latency_Source_SQLServer_Largetransactions) + [Intervallo di polling dell'acquisizione MS-CDC non configurato correttamente per Amazon RDS SQL Server](#CHAP_Troubleshooting_Latency_Source_SQLServer_MisconfiguredCDC) + [Replica di più attività di CDC dallo stesso database di origine](#CHAP_Troubleshooting_Latency_Source_SQLServer_MultipleCDC) + [Elaborazione del backup del registro delle transazioni per RDS per SQL Server](#CHAP_Troubleshooting_Latency_Source_SQLServer_backup) ## Ricostruzione degli indici Quando SQL Server ricrea un indice di grandi dimensioni, utilizza una singola transazione. Questo approccio genera molti eventi e può utilizzare una grande quantità di spazio di log se SQL Server ricostruisce più indici contemporaneamente. In tal caso, è possibile aspettarsi brevi picchi nella replica. Se l'origine SQL Server presenta picchi di log elevati, verifica quanto segue: + Innanzitutto, controllate il periodo di tempo in cui si verificano i picchi di latenza utilizzando le `CDCLatencySource` CloudWatch metriche `CDCLatencySource` and o controllando i messaggi di Throughput Monitoring nei log delle attività. Per informazioni sulle metriche per, consulta CloudWatch . AWS DMS[Parametri dell'attività di replica](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task) + Verifica se la dimensione dei log delle transazioni o dei backup dei log attivi è aumentata durante il picco di latenza. Controlla anche se durante quel periodo è stato eseguito un intervento di manutenzione o una ricostruzione. Per informazioni sulla verifica della dimensione del log delle transazioni, consulta [Monitoraggio dell'utilizzo dello spazio dei log](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) nella [documentazione tecnica di SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16). + Verifica che il tuo piano di manutenzione segua le best practice di SQL Server. Per informazioni sulle best practice di manutenzione di SQL Server, consulta [Index maintenance strategy](https://learn.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver16#index-maintenance-strategy) nella [documentazione tecnica di SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16). Per risolvere i problemi di latenza durante le ricostruzioni degli indici, prova a eseguire queste operazioni: + Utilizza il modello di ripristino `BULK_LOGGED` per le ricostruzioni offline per ridurre gli eventi che l'attività deve elaborare. + Se possibile, interrompi l'attività durante la ricostruzione dell'indice. In alternativa, prova a pianificare la ricostruzione dell'indice durante le ore non di punta per mitigare l'impatto di un picco di latenza. + Prova a identificare i punti deboli delle risorse che rallentano le letture DMS, come la latenza del disco o la velocità effettiva, e risolvili. I/O ## Transazioni di grandi dimensioni Le transazioni con molti eventi o le transazioni di lunga durata fanno aumentare la dimensione del log delle transazioni. Pertanto le letture DMS impiegano più tempo, con conseguente latenza. Questo approccio è simile all'effetto che le ricostruzioni degli indici hanno sulle prestazioni della replica. Potrebbe essere difficile identificare questo problema se non si conosce il carico di lavoro tipico del database di origine. Per risolvere questo problema, esegui questi passaggi: + Innanzitutto, identifica il momento in cui si è verificato il picco di latenza utilizzando le `WriteThroughput` CloudWatch metriche `ReadThroughput` and o controllando i messaggi di Throughput Monitoring nei log delle attività. + Controlla se sono state eseguite query di lunga durata sul database di origine durante il picco di latenza. Per informazioni sulle query di lunga durata, consulta [Troubleshoot slow-running queries in SQL Server](https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance/troubleshoot-slow-running-queries) nella [documentazione tecnica di SQL Server.](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16) + Verifica se la dimensione dei log delle transazioni o dei backup dei log attivi è aumentata. Per ulteriori informazioni, consulta [Monitoraggio dell'utilizzo dello spazio dei log](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) nella [documentazione tecnica di SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16). Per risolvere il problema, procedi in uno dei seguenti modi: + La soluzione migliore è ristrutturare le transazioni sul lato dell'applicazione in modo che vengano completate rapidamente. + Se non è possibile ristrutturare le transazioni, una soluzione alternativa a breve termine consiste nel verificare eventuali problemi di risorse, ad esempio attese del disco o conflitti di CPU. Se riscontri colli di bottiglia nel database di origine, puoi ridurre la latenza aumentando le risorse del disco, della CPU e della memoria per il database di origine. In tal modo riduci il conflitto per le risorse di sistema, permettendo alle query DMS di essere completate più rapidamente. ## Intervallo di polling dell'acquisizione MS-CDC non configurato correttamente per Amazon RDS SQL Server Un'impostazione errata dell'intervallo di polling per le istanze Amazon RDS può causare un aumento della dimensione del log delle transazioni. Questo avviene perché la replica impedisce il troncamento del log. Sebbene le attività in esecuzione possano continuare la replica con una latenza minima, l'interruzione e la ripresa delle attività o l'avvio di attività di sola CDC possono causare errori. Ciò è dovuto ai timeout che si verificano durante la scansione del log delle transazioni di grandi dimensioni. Per risolvere il problema relativo a un intervallo di polling configurato in modo errato, esegui queste operazioni: + Controlla se la dimensione del log delle transazioni attivo sta aumentando e se l'utilizzo del log è vicino al 100%. Per ulteriori informazioni, consulta [Monitoraggio dell'utilizzo dello spazio dei log](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) nella [documentazione tecnica di SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16). + Controlla se il troncamento del log viene ritardato con `log_reuse_wait_desc value` pari a `REPLICATION`. Per ulteriori informazioni, consulta [Log delle transazioni (SQL Server)](https://learn.microsoft.com/en-us/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver16#FactorsThatDelayTruncation) nella [documentazione tecnica di SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16). Se riscontri problemi con uno qualsiasi degli elementi dell'elenco precedente, ottimizza l'intervallo di polling dell'acquisizione MS-CDC. Per informazioni sull'ottimizzazione dell'intervallo di polling, consulta [Impostazioni consigliate quando si utilizza RDS per SQL Server come origine per AWS DMS](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.Configuration.Settings). ## Replica di più attività di CDC dallo stesso database di origine Durante la fase di pieno carico, consigliamo di suddividere le tabelle tra le attività per migliorare le prestazioni, separare logicamente le tabelle dipendenti e mitigare l'impatto di un errore dell'attività. Tuttavia, durante la fase CDC, consigliamo di consolidare le attività per ridurre al minimo le scansioni DMS. Durante la fase CDC, ogni attività DMS analizza i log delle transazioni alla ricerca di nuovi eventi più volte ogni minuto. Poiché ogni attività viene eseguita in modo indipendente, ciascuna attività analizza ogni log delle transazioni singolarmente. Questo approccio aumenta l'utilizzo del disco e della CPU nel database SQL Server di origine. Di conseguenza, un elevato numero di attività eseguite in parallelo può far sì che SQL Server limiti le letture DMS, con conseguente aumento della latenza. Potrebbe essere difficile identificare questo problema se più attività vengono avviate gradualmente. Il sintomo più comune di questo problema è che la maggior parte delle scansioni delle attività inizia a richiedere molto tempo. Ciò comporta una maggiore latenza per le scansioni. SQL Server dà la priorità ad alcune scansioni delle attività, quindi alcune di esse mostrano la latenza normale. Per risolvere questo problema, controlla la metrica `CDCLatencySource` per tutte le attività. Se alcune attività registrano un aumento di `CDCLatencySource`, mentre altre attività indicano un valore basso per `CDCLatencySource`, è probabile che SQL Server stia limitando le letture DMS per alcune attività. Se SQL Server limita la lettura delle attività durante la fase CDC, consolida le attività per ridurre al minimo il numero di scansioni DMS. Il numero massimo di attività che possono connettersi al database di origine senza creare conflitti dipende da fattori quali la capacità del database di origine, la percentuale di aumento del log delle transazioni o il numero di tabelle. Per determinare il numero ideale di attività per il tuo scenario di replica, prova la replica in un ambiente di test simile all'ambiente di produzione. ## Elaborazione del backup del registro delle transazioni per RDS per SQL Server AWS DMS 3.5.3 e versioni successive supportano la replica da RDS per i backup dei log di SQL Server. La replica degli eventi dai log di backup sulle istanze RDS è più lenta della replica degli eventi dal registro delle transazioni attivo. Questo perché DMS richiede l'accesso ai backup in modo seriale per garantire che mantenga la sequenza delle transazioni e per ridurre al minimo il rischio che lo storage delle istanze Amazon RDS si riempia. Inoltre, alla fine di Amazon RDS, il tempo necessario per rendere i backup disponibili su DMS varia a seconda delle dimensioni del backup del log e del carico sull'istanza RDS per SQL Server. A causa di questi vincoli, si consiglia di impostare l'ECA su. `ActivateSafeguard` `true` Ciò garantisce che non venga eseguito il backup delle transazioni mentre l'attività DMS sta leggendo dal registro delle transazioni attivo. Questa impostazione impedisce inoltre ad Amazon RDS di archiviare le transazioni nel log attivo quando DMS legge le transazioni dal backup, eliminando così la possibilità che DMS non riesca a recuperare il log attivo. Tieni presente che ciò può causare un aumento della dimensione del log attivo mentre l'attività sta recuperando terreno. Assicurati che l'istanza disponga di spazio di archiviazione sufficiente per evitare che lo spazio sull'istanza si esaurisca. Per un'attività esclusivamente CDC che esegue la replica da sorgenti RDS per SQL Server, utilizza la posizione iniziale del CDC nativa rispetto all'ora di avvio del CDC nativa, se possibile. Questo perché DMS si affida alle tabelle di sistema per identificare il punto di partenza per la posizione iniziale nativa, anziché eseguire la scansione dei singoli backup dei log quando si specifica un'ora di inizio nativa. # Risoluzione dei problemi di latenza della destinazione In questa sezione sono illustrati gli scenari che possono contribuire alla latenza della destinazione. **Topics** + [Problemi di indicizzazione](#CHAP_Troubleshooting_Latency_Target_Indexing) + [Messaggio SORTER nel log delle attività](#CHAP_Troubleshooting_Latency_Target_Sorter) + [Blocco del database](#CHAP_Troubleshooting_Latency_Target_Locking) + [Ricerche LOB lente](#CHAP_Troubleshooting_Latency_Target_LOB) + [Multi-AZ: registrazione di audit e backup](#CHAP_Troubleshooting_Latency_Target_MultiAZ) ## Problemi di indicizzazione Durante la fase CDC, AWS DMS replica le modifiche all'origine eseguendo istruzioni DML (inserimento, aggiornamento ed eliminazione) sulla destinazione. Per le migrazioni eterogenee che utilizzano DMS, le differenze nelle ottimizzazioni degli indici sull'origine e sulla destinazione possono far sì che le scritture sulla destinazione richiedano più tempo. Questo approccio comporta problemi di latenza e prestazioni della destinazione. Per risolvere i problemi di indicizzazione, procedi come segue. Le procedure per questi passaggi variano a seconda dei diversi motori di database. + Monitora il tempo di query per il database di destinazione. Il confronto del tempo di esecuzione delle query sulla destinazione e sull'origine può indicare quali indici devono essere ottimizzati. + Abilita la registrazione per le query a esecuzione lenta. Per risolvere i problemi di indicizzazione per le repliche di lunga durata, esegui queste operazioni: + Ottimizza gli indici sui database di origine e di destinazione in modo che il tempo di esecuzione delle query sia simile sull'origine e sulla destinazione. + Confronta gli indici secondari utilizzati nelle query DML per l'origine e la destinazione. Assicurati che le prestazioni DML sulla destinazione siano paragonabili o migliori delle prestazioni DML sull'origine. Tieni presente che la procedura per l'ottimizzazione degli indici è specifica del motore di database in uso. Non è disponibile alcuna funzionalità DMS per l'ottimizzazione degli indici di origine e di destinazione. ## Messaggio SORTER nel log delle attività Se un endpoint di destinazione non riesce a tenere il passo con il volume di modifiche che vi AWS DMS scrive, l'operazione memorizza le modifiche nella cache dell'istanza di replica. Se la cache supera la soglia interna, l'attività interrompe la lettura di ulteriori modifiche dall'origine. DMS esegue questa operazione per evitare che l'istanza di replica esaurisca lo spazio di archiviazione o che l'attività si blocchi durante la lettura di un grande volume di eventi in sospeso. Per risolvere questo problema, controlla la presenza di un messaggio simile a uno dei seguenti CloudWatch nei log: ``` [SORTER ]I: Reading from source is paused. Total disk usage exceeded the limit 90% (sorter_transaction.c:110) [SORTER ]I: Reading from source is paused. Total storage used by swap files exceeded the limit 1048576000 bytes (sorter_transaction.c:110) ``` Se i log contengono un messaggio simile al primo, disabilita qualsiasi registrazione di traccia per l'attività e aumenta lo spazio di archiviazione dell'istanza di replica. Per informazioni sull'aumento dello spazio di archiviazione delle istanze di replica, consulta [Modifica di un'istanza di replica](CHAP_ReplicationInstance.Modifying.md). Se i log contengono un messaggio simile al secondo, esegui queste operazioni: + Sposta le tabelle con numerose transazioni o operazioni DML di lunga durata in un'attività separata, se non hanno alcuna dipendenza da altre tabelle dell'attività. + Aumenta le impostazioni `MemoryLimitTotal` e `MemoryKeepTime` per mantenere la transazione in memoria per un periodo più lungo. Ciò non aiuta se la latenza è sostenuta, ma può contribuire a mantenere bassa la latenza durante brevi aumenti di volume transazionale. Per informazioni su queste impostazioni dell'attività, consulta [Impostazioni di ottimizzazione dell'elaborazione delle modifiche](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md). + Valuta se puoi utilizzare l'applicazione in batch per la transazione impostando `BatchApplyEnabled` su `true`. Per informazioni sull'impostazione `BatchApplyEnabled`, consulta [Impostazioni delle attività dei metadati di destinazione](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md). ## Blocco del database Se un'applicazione accede a un database utilizzato come destinazione di replica, l'applicazione può bloccare una tabella a cui DMS AWS DMS sta tentando di accedere. Questo crea un conflitto di blocco. Poiché DMS scrive le modifiche nel database di destinazione nell'ordine in cui sono state applicate nell'origine, il ritardo della scrittura in una tabella dovuti al conflitto di blocco creano ritardi della scrittura in tutte le tabelle. Per risolvere questo problema, esegui una query sul database di destinazione per verificare se un conflitto di blocco sta bloccando le transazioni di scrittura DMS. Se il database di destinazione blocca le transazioni di scrittura DMS, esegui una o più delle operazioni riportate di seguito: + Ristruttura le query per eseguire il commit delle modifiche più frequentemente. + Modifica le impostazioni del timeout di blocco. + Partiziona le tabelle per ridurre al minimo i conflitti di blocco. Tieni presente che la procedura per l'ottimizzazione dei conflitti di blocco è specifica del motore di database in uso. Non è disponibile alcuna funzionalità DMS per ottimizzare i conflitti di blocco. ## Ricerche LOB lente Quando AWS DMS replica una colonna di oggetti di grandi dimensioni (LOB), esegue una ricerca sull'origine appena prima di scrivere le modifiche alla destinazione. Questa ricerca normalmente non causa alcuna latenza sulla destinazione, ma se il database di origine ritarda la ricerca a causa del blocco, la latenza della destinazione potrebbe aumentare. Questo problema è in genere difficile da diagnosticare. Per risolverlo, abilita il debug dettagliato nei log delle attività e confronta i timestamp delle chiamate di ricerca LOB DMS. Per informazioni su come abilitare il debug dettagliato, consulta [Visualizzazione e gestione dei registri delle attività AWS DMS](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs). Per risolvere il problema, procedi come segue: + Migliora le prestazioni delle query SELECT sul database di origine. + Ottimizza le impostazioni LOB DMS. Per informazioni sull'ottimizzazione delle impostazioni LOB, consulta [Migrazione di oggetti binari di grandi dimensioni () LOBs](CHAP_BestPractices.md#CHAP_BestPractices.LOBS). ## Multi-AZ: registrazione di audit e backup Per le destinazione Amazon RDS, la latenza di destinazione può aumentare nelle seguenti situazioni: + Backup + Dopo aver abilitato più zone di disponibilità (multi-AZ) + Dopo aver abilitato la registrazione del database, ad esempio i log di audit o delle query lente. Questi problemi sono in genere difficili da diagnosticare. Per risolverli, monitora la latenza per rilevare eventuali picchi periodici durante le finestre di manutenzione di Amazon RDS o i periodi di intenso carico del database. Per risolvere questi problemi, prova a eseguire queste operazioni: + Se possibile, durante la migrazione a breve termine, disabilita le multi-AZ, i backup o la registrazione. + Riprogramma le finestre di manutenzione in periodi di scarsa attività. # Utilizzo degli script di supporto diagnostico in AWS DMS Se riscontri un problema durante l'utilizzo AWS DMS, il tecnico dell'assistenza potrebbe aver bisogno di ulteriori informazioni sul database di origine o di destinazione. Vogliamo assicurarci che AWS Support riceva quante più informazioni richieste possibile nel più breve tempo possibile. Pertanto, abbiamo sviluppato degli script per eseguire le query di queste informazioni per diversi tra i principali motori di database relazionale. Se è disponibile uno script di supporto per il tuo database, puoi scaricarlo utilizzando il collegamento nell'argomento dello script corrispondente descritto di seguito. Dopo aver verificato e esaminato lo script (descritto di seguito), puoi eseguirlo secondo la procedura indicata nell'argomento dello script. Una volta completata l'esecuzione dello script, puoi caricarne l'output nel tuo caso AWS Support (di nuovo, descritto di seguito). Prima di eseguire lo script, è possibile rilevare eventuali errori che potrebbero essere stati introdotti durante il download o l'archiviazione dello script di supporto. A tale scopo, confronta il checksum del file di script con un valore fornito da AWS. AWS utilizza l' SHA256 algoritmo per il checksum. **Per verificare il file di script di supporto utilizzando un checksum** 1. Apri il file di checksum più recente fornito per verificare gli script di supporto all'indirizzo [https://d2pwp9zz55emqw.cloudfront.net/sha256Check.txt](https://d2pwp9zz55emqw.cloudfront.net/sha256Check.txt). Il file può avere un contenuto simile al seguente esempio. ``` MYSQL dfafd0d511477c699f96c64693ad0b1547d47e74d5c5f2f2025b790b1422e3c8 ORACLE 6c41ebcfc99518cfa8a10cb2ce8943b153b2cc7049117183d0b5de3d551bc312 POSTGRES 6ccd274863d14f6f3146fbdbbba43f2d8d4c6a4c25380d7b41c71883aa4f9790 SQL_SERVER 971a6f2c46aec8d083d2b3b6549b1e9990af3a15fe4b922e319f4fdd358debe7 ``` 1. Esegui il comando SHA256 di convalida per il tuo sistema operativo nella directory che contiene il file di supporto. Ad esempio, sul sistema operativo macOS è possibile eseguire il comando seguente per uno script di supporto Oracle, descritto successivamente in questo argomento. ``` shasum -a 256 awsdms_support_collector_oracle.sql ``` 1. Confronta i risultati del comando con il valore mostrato nell'ultimo file `sha256Check.txt` che hai aperto. I due valori devono corrispondere. In caso contrario, contatta il tecnico del supporto per informazioni sulla mancata corrispondenza e su come ottenere un file di script di supporto pulito. Se disponi di un file di script di supporto pulito, prima di eseguirlo assicurati di leggere e comprendere il codice SQL sia dal punto di vista delle prestazioni che della sicurezza. Se non desideri eseguire codice SQL nello script, puoi commentare o rimuovere l'SQL problematico. Puoi anche contattare il tecnico del supporto per ottenere eventuali soluzioni alternative accettabili. Una volta completato correttamente, lo script restituisce l'output in un formato HTML leggibile, salvo diversa indicazione. Lo script è progettato per escludere dall'output HTML tutti i dati o i dettagli di sicurezza che possono compromettere l'azienda. Inoltre, non apporta modifiche al database o all'ambiente. Tuttavia, se nell'output HTML sono presenti informazioni che non desideri condividere, sentiti libero di rimuoverle prima di caricare l'output HTML. Se l'output HTML è accettabile, caricalo utilizzando gli **allegati** nei **dettagli del caso** del tuo caso di supporto. Ciascuno dei seguenti argomenti descrive gli script disponibili per un AWS DMS database supportato e come eseguirli. Il tecnico del supporto ti indicherà di usare uno script specifico documentato di seguito. **Topics** + [Script di supporto per la diagnostica Oracle](CHAP_SupportScripts.Oracle.md) + [Script di supporto per la diagnostica SQL Server](CHAP_SupportScripts.SQLServer.md) + [Script di supporto diagnostico per database compatibili con MySQL](CHAP_SupportScripts.MySQL.md) + [Script di supporto diagnostico PostgreSQL](CHAP_SupportScripts.PostgreSQL.md) # Script di supporto per la diagnostica Oracle Di seguito, puoi trovare gli script di supporto diagnostico disponibili per analizzare un database locale o Amazon RDS for Oracle nella tua configurazione di migrazione. AWS DMS Questi script funzionano con un endpoint di origine o di destinazione e sono tutti scritti per essere eseguiti nell'utilità della linea di comando SQL\$1Plus. Per ulteriori informazioni sull'utilizzo di questa utilità, consulta [A Using SQL Command Line](https://docs.oracle.com/cd/B25329_01/doc/appdev.102/b25108/xedev_sqlplus.htm) nella documentazione di Oracle. Prima di eseguire lo script, assicurati che l'account utente in uso disponga delle autorizzazioni necessarie per accedere al database Oracle. Le impostazioni delle autorizzazioni mostrate presuppongono che l'utente sia stato creato come segue. ``` CREATE USER script_user IDENTIFIED BY password; ``` Per un database on-premise, imposta per `script_user` le autorizzazioni minime come illustrato di seguito. ``` GRANT CREATE SESSION TO script_user; GRANT SELECT on V$DATABASE to script_user; GRANT SELECT on V$VERSION to script_user; GRANT SELECT on GV$SGA to script_user; GRANT SELECT on GV$INSTANCE to script_user; GRANT SELECT on GV$DATAGUARD_CONFIG to script_user; GRANT SELECT on GV$LOG to script_user; GRANT SELECT on DBA_TABLESPACES to script_user; GRANT SELECT on DBA_DATA_FILES to script_user; GRANT SELECT on DBA_SEGMENTS to script_user; GRANT SELECT on DBA_LOBS to script_user; GRANT SELECT on V$ARCHIVED_LOG to script_user; GRANT SELECT on DBA_TAB_MODIFICATIONS to script_user; GRANT SELECT on DBA_TABLES to script_user; GRANT SELECT on DBA_TAB_PARTITIONS to script_user; GRANT SELECT on DBA_MVIEWS to script_user; GRANT SELECT on DBA_OBJECTS to script_user; GRANT SELECT on DBA_TAB_COLUMNS to script_user; GRANT SELECT on DBA_LOG_GROUPS to script_user; GRANT SELECT on DBA_LOG_GROUP_COLUMNS to script_user; GRANT SELECT on V$ARCHIVE_DEST to script_user; GRANT SELECT on DBA_SYS_PRIVS to script_user; GRANT SELECT on DBA_TAB_PRIVS to script_user; GRANT SELECT on DBA_TYPES to script_user; GRANT SELECT on DBA_CONSTRAINTS to script_user; GRANT SELECT on V$TRANSACTION to script_user; GRANT SELECT on GV$ASM_DISK_STAT to script_user; GRANT SELECT on GV$SESSION to script_user; GRANT SELECT on GV$SQL to script_user; GRANT SELECT on DBA_ENCRYPTED_COLUMNS to script_user; GRANT SELECT on DBA_PDBS to script_user; GRANT EXECUTE on dbms_utility to script_user; ``` Per un database Amazon RDS, imposta le autorizzazioni minime come illustrato di seguito. ``` GRANT CREATE SESSION TO script_user; exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$VERSION','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$SGA','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$INSTANCE','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$DATAGUARD_CONFIG','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$LOG','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TABLESPACES','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_DATA_FILES','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_SEGMENTS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_LOBS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TAB_MODIFICATIONS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TABLES','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TAB_PARTITIONS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_MVIEWS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_OBJECTS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TAB_COLUMNS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_LOG_GROUPS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_LOG_GROUP_COLUMNS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVE_DEST','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_SYS_PRIVS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TAB_PRIVS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TYPES','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_CONSTRAINTS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TRANSACTION','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$ASM_DISK_STAT','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$SESSION','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$SQL','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_ENCRYPTED_COLUMNS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_PDBS','script_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_UTILITY','script_user','EXECUTE'); ``` Di seguito sono riportate le indicazioni per scaricare, rivedere ed eseguire ogni script di supporto SQL\$1Plus disponibile per Oracle. Viene anche descritto in che modo puoi esaminare e caricare l'output nel tuo caso del Supporto AWS . **Topics** + [Script awsdms\$1support\$1collector\$1oracle.sql](#CHAP_SupportScripts.Oracle.Awsdms_Support_Collector_Oracle_Script) ## Script awsdms\$1support\$1collector\$1oracle.sql Scarica lo script [https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_oracle.sql](https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_oracle.sql). Questo script raccoglie informazioni sulla configurazione del database Oracle. Ricordati di controllare il checksum dello script e, se il checksum esegue la verifica, esamina il codice SQL contenuto nello script per commentare le parti che non desideri eseguire. Una volta che l'integrità e il contenuto sono validi, puoi eseguire lo script. **Per eseguire lo script e caricare i risultati nel caso di supporto** 1. Esegui lo script dall'ambiente di database utilizzando la seguente linea di comando SQL\$1Plus. ``` SQL> @awsdms_support_collector_oracle.sql ``` Lo script visualizza una breve descrizione e la richiesta di continuare o interrompere l'esecuzione. Premi [Invio] per continuare. 1. Alla successiva richiesta, immetti il nome di uno solo degli schemi che vuoi migrare. 1. Alla successiva richiesta, immetti il nome dell'utente (*script\$1user*) che hai definito per la connessione al database. 1. Alla successiva richiesta, immetti il numero di giorni per i dati che desideri esaminare o accetta il valore predefinito. Lo script quindi raccoglie i dati specificati dal database. Una volta completato, lo script visualizza il nome del file HTML di output, ad esempio `dms_support_oracle-2020-06-22-13-20-39-ORCL.html`. Lo script salva questo file nella directory di lavoro. 1. Esamina il file HTML e rimuovi tutte le informazioni che non desideri condividere. Quando il codice HTML è accettabile per la condivisione, carica il file nel tuo caso AWS Support. Per ulteriori informazioni sul caricamento del file, consulta [Utilizzo degli script di supporto diagnostico in AWS DMS](CHAP_SupportScripts.md). # Script di supporto per la diagnostica SQL Server Di seguito, puoi trovare una descrizione degli script di supporto diagnostico disponibili per analizzare un database locale o Amazon RDS for SQL Server nella AWS DMS tua configurazione di migrazione. Questi script funzionano con un endpoint di origine o di destinazione Per un database on-premise, esegui questi script nell'utilità della linea di comando sqlcmd. Per ulteriori informazioni sull'utilizzo di questa utilità, consulta [sqlcmd - Use the utility](https://docs.microsoft.com/en-us/sql/ssms/scripting/sqlcmd-use-the-utility?view=sql-server-ver15) nella documentazione di Microsoft. Non è possibile connettersi a un database Amazon RDS utilizzando l'utilità della linea di comando sqlcmd. Esegui questi script usando qualsiasi strumento client che si connetta ad Amazon RDS SQL Server. Prima di eseguire lo script, assicurati che l'account utente in uso disponga delle autorizzazioni necessarie per accedere al database SQL Server. Sia per un database on-premise che per un database Amazon RDS, puoi utilizzare le stesse autorizzazioni che usi per accedere al database SQL Server senza il ruolo `SysAdmin`. **Topics** + [Impostazione delle autorizzazioni minime per un database SQL Server on-premise](#CHAP_SupportScripts.SQLServer.onprem) + [Impostazione delle autorizzazioni minime per un database Amazon RDS SQL Server](#CHAP_SupportScripts.SQLServer.rds) + [Script di supporto SQL Server](#CHAP_SupportScripts.SQLServer.Scripts) ## Impostazione delle autorizzazioni minime per un database SQL Server on-premise **Per impostare le autorizzazioni minime per l'esecuzione di un database SQL Server on-premise** 1. Crea un nuovo account SQL Server con l'autenticazione tramite password utilizzando SQL Server Management Studio (SSMS), ad esempio `on-prem-user`. 1. Nella sezione **Mapping utente** di SSMS, scegli i database **MSDB** e **MASTER** (che forniscono l'autorizzazione pubblica) e assegna il ruolo `DB_OWNER` al database in cui desideri eseguire lo script. 1. Apri il menu contestuale (pulsante destro del mouse) del nuovo account, scegli **Sicurezza** e assegna esplicitamente il privilegio `Connect SQL`. 1. Esegui i seguenti comandi per l'assegnazione. ``` GRANT VIEW SERVER STATE TO on-prem-user; USE MSDB; GRANT SELECT ON MSDB.DBO.BACKUPSET TO on-prem-user; GRANT SELECT ON MSDB.DBO.BACKUPMEDIAFAMILY TO on-prem-user; GRANT SELECT ON MSDB.DBO.BACKUPFILE TO on-prem-user; ``` ## Impostazione delle autorizzazioni minime per un database Amazon RDS SQL Server **Per impostare le autorizzazioni minime per un database Amazon RDS SQL Server** 1. Crea un nuovo account SQL Server con l'autenticazione tramite password utilizzando SQL Server Management Studio (SSMS), ad esempio `rds-user`. 1. Nella sezione **Mapping utente** di SSMS, scegli il database **MSDB** (che fornisce l'autorizzazione pubblica) e assegna il ruolo `DB_OWNER` al database in cui desideri eseguire lo script. 1. Apri il menu contestuale (pulsante destro del mouse) del nuovo account, scegli **Sicurezza** e assegna esplicitamente il privilegio `Connect SQL`. 1. Esegui i seguenti comandi per l'assegnazione. ``` GRANT VIEW SERVER STATE TO rds-user; USE MSDB; GRANT SELECT ON MSDB.DBO.BACKUPSET TO rds-user; GRANT SELECT ON MSDB.DBO.BACKUPMEDIAFAMILY TO rds-user; GRANT SELECT ON MSDB.DBO.BACKUPFILE TO rds-user; ``` ## Script di supporto SQL Server Negli argomenti seguenti viene descritto come scaricare, rivedere ed eseguire ogni script di supporto disponibile per SQL Server. Viene anche illustrato come esaminare e caricare l'output dello script nel caso del Supporto AWS . **Topics** + [Script awsdms\$1support\$1collector\$1sql\$1server.sql](#CHAP_SupportScripts.SQLServer.Awsdms_Support_Collector_SQLServer_Script) ### Script awsdms\$1support\$1collector\$1sql\$1server.sql Scarica lo script [https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_sql_server.sql](https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_sql_server.sql). **Nota** Esegui questo script di supporto per la diagnostica SQL Server solo su SQL Server 2014 e versioni successive. Questo script raccoglie informazioni sulla configurazione del database SQL Server. Ricordati di controllare il checksum dello script e, se il checksum esegue la verifica, esamina il codice SQL contenuto nello script per commentare le parti che non desideri eseguire. Una volta che l'integrità e il contenuto sono validi, puoi eseguire lo script. **Per eseguire lo script per un database SQL Server on-premise** 1. Esegui lo script utilizzando la linea di comando sqlcmd seguente. ``` sqlcmd -Uon-prem-user -Ppassword -SDMS-SQL17AG-N1 -y 0 -iC:\Users\admin\awsdms_support_collector_sql_server.sql -oC:\Users\admin\DMS_Support_Report_SQLServer.html -dsqlserverdb01 ``` I parametri del comando sqlcmd specificati sono: + `-U`: nome dell'utente del database. + `-P`: password dell'utente del database. + `-S`: nome del server di database SQL Server. + `-y`: larghezza massima delle colonne di output dell'utilità sqlcmd. Il valore 0 specifica colonne con larghezza illimitata. + `-i`: percorso dello script di supporto da eseguire, in questo caso`awsdms_support_collector_sql_server.sql`. + `-o`: percorso del file HTML di output, con il nome file che hai specificato, contenente le informazioni di configurazione del database raccolte. + `-d`: nome del database SQL Server. 1. Una volta completato lo script, esamina il file HTML di output e rimuovi tutte le informazioni che non desideri condividere. Quando il codice HTML è accettabile per la condivisione, carica il file nel tuo caso AWS Support. Per ulteriori informazioni sul caricamento del file, consulta [Utilizzo degli script di supporto diagnostico in AWS DMS](CHAP_SupportScripts.md). Con Amazon RDS per SQL Server, non è possibile connettersi tramite l'utilità della linea di comando sqlcmd, quindi utilizza la procedura seguente. **Per eseguire lo script per un database RDS SQL Server** 1. Esegui lo script utilizzando qualsiasi strumento client che ti consenta di connetterti a RDS SQL Server come utente `Master` e salvare l'output come file HTML. 1. Esamina il file HTML di output e rimuovi tutte le informazioni che non desideri condividere. Quando il codice HTML è accettabile per la condivisione, carica il file nel tuo caso AWS Support. Per ulteriori informazioni sul caricamento del file, consulta [Utilizzo degli script di supporto diagnostico in AWS DMS](CHAP_SupportScripts.md). # Script di supporto diagnostico per database compatibili con MySQL Di seguito, puoi trovare gli script di supporto diagnostico disponibili per analizzare un database locale o compatibile con Amazon RDS for MySQL nella tua configurazione di migrazione. AWS DMS Questi script funzionano con un endpoint di origine o di destinazione Gli script sono tutti scritti per essere eseguiti sulla linea di comando MySQL SQL. Per informazioni sull'installazione del client MySQL, consulta [Installing MySQL Shell](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-install.html) nella documentazione di MySQL. Per informazioni sull'utilizzo del client di MySQL, consulta [Using MySQL Shell Commands](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-configuring.html) nella documentazione di MySQL. Prima di eseguire uno script, assicurati che l'account utente in uso disponga delle autorizzazioni necessarie per accedere al database compatibile con MySQL. Utilizza la procedura seguente per creare un account utente e fornire le autorizzazioni minime necessarie per eseguire lo script. **Per configurare un account utente con le autorizzazioni minime per eseguire gli script** 1. Crea l'utente per eseguire gli script. ``` create user 'username'@'hostname' identified by password; ``` 1. Assegna il comando `select` ai database per analizzarli. ``` grant select on database-name.* to username; grant replication client on *.* to username; ``` 1. ``` grant execute on procedure mysql.rds_show_configuration to username; ``` Negli argomenti seguenti viene descritto come scaricare, rivedere ed eseguire ogni script di supporto disponibile per un database compatibile con MySQL. Descrivono inoltre come rivedere e caricare l'output dello script nel caso AWS Support. **Topics** + [Script awsdms\$1support\$1collector\$1MySQL.sql](#CHAP_SupportScripts.MySQL.Awsdms_Support_Collector_MySQL_Script) ## Script awsdms\$1support\$1collector\$1MySQL.sql Scarica lo script [https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_MySQL.sql](https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_MySQL.sql). Questo script raccoglie informazioni sulla configurazione del database compatibile con MySQL. Ricordati di controllare il checksum dello script e, se il checksum esegue la verifica, esamina il codice SQL contenuto nello script per commentare le parti che non desideri eseguire. Una volta che l'integrità e il contenuto sono validi, puoi eseguire lo script. Esegui lo script dopo la connessione all'ambiente del database tramite la linea di comando. **Per eseguire lo script e caricare i risultati nel caso di supporto** 1. Connettiti al database utilizzando il comando `mysql` seguente. ``` mysql -p -h hostname -P port -u username database-name ``` 1. Esegui lo script utilizzando il comando mysql `source` seguente. ``` source awsdms_support_collector_MySQL.sql ``` Esamina il report generato e rimuovi tutte le informazioni che desideri condividere. Quando il contenuto è accettabile per la condivisione, carica il file nel tuo caso del Supporto AWS . Per ulteriori informazioni sul caricamento del file, consulta [Utilizzo degli script di supporto diagnostico in AWS DMS](CHAP_SupportScripts.md). **Nota** Se disponi già di un account utente con i privilegi richiesti descritti in[Script di supporto diagnostico per database compatibili con MySQL](#CHAP_SupportScripts.MySQL), puoi utilizzarlo per eseguire lo script. Ricordati di connetterti al database prima di eseguire lo script. Lo script genera l'output in formato testo. Tenendo presenti le best practice di sicurezza, se si crea un nuovo account utente solo per eseguire questo script di supporto diagnostico MySQL, si consiglia di eliminare questo account utente dopo il completamento dell'esecuzione dello script. # Script di supporto diagnostico PostgreSQL Di seguito, puoi trovare gli script di supporto diagnostico disponibili per analizzare qualsiasi RDBMS PostgreSQL (locale, Amazon RDS o Aurora PostgreSQL) nella tua configurazione di migrazione. AWS DMS Questi script funzionano con un endpoint di origine o di destinazione Gli script sono tutti scritti per essere eseguiti nell'utilità della linea di comando psql. Prima di eseguire questi script, assicurati che l'account utente in uso disponga delle seguenti autorizzazioni necessarie per accedere a qualsiasi RDBMS PostgreSQL: + PostgreSQL 10.x o versione successiva: un account utente con autorizzazione di esecuzione per la funzione `pg_catalog.pg_ls_waldir`. + PostgreSQL 9.x o versioni precedenti: un account utente con autorizzazioni predefinite. Si consiglia di utilizzare un account esistente con le autorizzazioni appropriate per eseguire questi script. Se devi creare un nuovo account utente o fornire le autorizzazioni a un account esistente per eseguire questi script, puoi usare i seguenti comandi SQL per qualsiasi RDBMS PostgreSQL basato sulla versione PostgreSQL. **Per fornire all'account le autorizzazioni per eseguire questi script per un database PostgreSQL 10.x o versioni successive** + Esegui una delle seguenti operazioni: + Per un nuovo account utente, esegui quanto segue. ``` CREATE USER script_user WITH PASSWORD 'password'; GRANT EXECUTE ON FUNCTION pg_catalog.pg_ls_waldir TO script_user; ``` + Per un account utente esistente, esegui quanto segue. ``` GRANT EXECUTE ON FUNCTION pg_catalog.pg_ls_waldir TO script_user; ``` **Per fornire all'account le autorizzazioni per eseguire questi script per un database PostgreSQL 9.x o versioni precedenti** + Esegui una delle seguenti operazioni: + Per un nuovo account utente, esegui il comando seguente con le autorizzazioni predefinite. ``` CREATE USER script_user WITH PASSWORD password; ``` + Per un account utente esistente, utilizza le autorizzazioni esistenti. **Nota** Questi script non supportano determinate funzionalità relative alla ricerca della dimensione del WAL per database PostgreSQL 9.x e versioni precedenti. Per ulteriori informazioni, contatta AWS Support. I seguenti argomenti descrivono come scaricare, rivedere ed eseguire ogni script di supporto disponibile per PostgreSQL. Descrivono inoltre come rivedere e caricare l'output dello script nel caso del Supporto AWS . **Topics** + [Script awsdms\$1support\$1collector\$1postgres.sql](#CHAP_SupportScripts.PostgreSQL.Awsdms_Support_Collector_PostgreSQL_Script) ## Script awsdms\$1support\$1collector\$1postgres.sql Scarica lo script [https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_postgres.sql](https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_postgres.sql). Questo script raccoglie informazioni sulla configurazione del database PostgreSQL. Ricordati di verificare il checksum dello script. Se il checksum lo verifica, esamina il codice SQL contenuto nello script per commentare il codice che desideri eseguire. Una volta che l'integrità e il contenuto sono validi, puoi eseguire lo script. **Nota** È possibile eseguire questo script con la versione 10 o successiva del client psql. È possibile utilizzare le seguenti procedure per eseguire lo script dall'ambiente di database o dalla linea di comando. In entrambi i casi, puoi caricare il file per il Supporto AWS in un secondo momento. **Per eseguire lo script e caricare i risultati nel caso di supporto** 1. Esegui una delle seguenti operazioni: + Esegui lo script dall'ambiente di database utilizzando la seguente linea di comando psql. ``` dbname=# \i awsdms_support_collector_postgres.sql ``` Alla successiva richiesta, immetti il nome di uno solo degli schemi che vuoi migrare. Alla successiva richiesta, immetti il nome dell'utente (`script_user`) che hai definito per la connessione al database. + Esegui lo script seguente direttamente dalla linea di comando. Questa opzione evita qualsiasi richiesta prima dell'esecuzione dello script. ``` psql -h database-hostname -p port -U script_user -d database-name -f awsdms_support_collector_postgres.sql ``` 1. Esamina il file HTML di output e rimuovi tutte le informazioni che non desideri condividere. Quando il file HTML è accettabile per la condivisione, caricalo nel tuo caso del Supporto AWS . Per ulteriori informazioni sul caricamento del file, consulta [Utilizzo degli script di supporto diagnostico in AWS DMS](CHAP_SupportScripts.md). # Utilizzo dell'AMI di supporto AWS DMS diagnostico Se si verifica un problema relativo alla rete quando si lavora con AWS DMS, il tecnico dell'assistenza potrebbe aver bisogno di ulteriori informazioni sulla configurazione di rete. Vogliamo assicurarci che AWS Support riceva quante più informazioni richieste possibile nel più breve tempo possibile. Pertanto, abbiamo sviluppato un'AMI Amazon EC2 preconfigurata con strumenti di diagnostica per AWS DMS testare il tuo ambiente di rete. I test diagnostici installati sull'Amazon Machine Image (AMI) sono: + Virtual Private Cloud (VPC) + Perdita di pacchetti di rete + Latenza di rete + Dimensione dell'unità di trasmissione massima (MTU) **Topics** + [Avvia una nuova AWS DMS istanza diagnostica Amazon EC2](#CHAP_SupportAmi_Launch) + [Creazione di un ruolo IAM](#CHAP_SupportAmi_Iam) + [Esecuzione dei test diagnostici](#CHAP_SupportAmi_Run) + [Fasi successive](#CHAP_SupportAmi_NextSteps) + [AMI IDs per regione](#CHAP_SupportAmi_AmiIDs) + [AWS Systems Patch Manager](#CHAP_PatchManager) **Nota** 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 ulteriori informazioni, consulta [Valutazione delle prestazioni di lettura dei log redo o di archiviazione di Oracle](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Oracle.ReadPerformUtil). ## Avvia una nuova AWS DMS istanza diagnostica Amazon EC2 In questa sezione viene avviata una nuova istanza Amazon EC2. Per ulteriori informazioni sull'avvio di un'istanza Amazon EC2, consulta [Tutorial: Nozioni di base sulle istanze Amazon EC2 Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) nella [Guida per l'utente di Amazon EC2 per istanze Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/). Avvia un'istanza Amazon EC2 con le seguenti impostazioni: + Per **Immagini di applicazioni e sistema operativo (Amazon Machine Image)** cerca l'AMI **DMS-DIAG-AMI**. Se hai effettuato l'accesso alla console, puoi cercare l'AMI con [questa query](https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#Images:visibility=public-images;search=:dms-diag-ami;v=3;). Per l'ID AMI dell'AMI di AWS diagnostica nella tua regione, consulta [AMI IDs per regione](#CHAP_SupportAmi_AmiIDs) quanto segue. + Per **Tipo di istanza** si consiglia di scegliere **t2.micro**. + Per **Impostazioni di rete** scegli lo stesso VPC utilizzato dall'istanza di replica. Una volta che l'istanza è attiva, connettiti all'istanza. Per ulteriori informazioni sulla connessione a un'istanza Amazon EC2 Linux, consulta [Connessione all'istanza di Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html). ## Creazione di un ruolo IAM Se desideri eseguire i test diagnostici sulla tua istanza di replica utilizzando le autorizzazioni minime richieste, crea un ruolo IAM che usi la seguente policy di autorizzazioni: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "dms:DescribeEndpoints", "dms:DescribeTableStatistics", "dms:DescribeReplicationInstances", "dms:DescribeReplicationTasks", "secretsmanager:GetSecretValue" ], "Resource": "*" } ] } ``` ------ Associa il ruolo a un nuovo utente IAM. Per informazioni sulla creazione dei ruoli IAM, delle policy e degli utenti, consulta le sezioni seguenti nella [Guida per l'utente di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/): + [Nozioni di base su IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html) + [Creazione di ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) + [Creazione di policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) ## Esecuzione dei test diagnostici Dopo aver creato un'istanza Amazon EC2 e aver stabilito la connessione, procedi come segue per eseguire i test diagnostici sull'istanza di replica. 1. Configura la AWS CLI: ``` $ aws configure ``` Fornisci le credenziali di accesso per l'account AWS utente che desideri utilizzare per eseguire i test diagnostici. Fornisci la regione per il VPC e l'istanza di replica. 1. Visualizza le AWS DMS attività disponibili nella tua regione. Sostituisci la regione di esempio con la tua regione. ``` $ dms-report -r us-east-1 -l ``` Questo comando mostra lo stato delle attività. ![\[Strumento di diagnostica che mostra l'elenco delle attività.\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-diagami1.png) 1. Visualizza gli endpoint e le impostazioni delle attività. Sostituisci ** con la tua attività Amazon Resource Name (ARN). ``` $ dms-report -t ``` Questo comando visualizza gli endpoint e le impostazioni dell'attività. ![\[Strumento di diagnostica che mostra l'elenco degli endpoint per l'attività.\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-diagami2.png) 1. Esegui i test diagnostici. Sostituisci ** con il tuo task ARN. ``` $ dms-report -t -n y ``` Questo comando visualizza i dati diagnostici relativi al VPC dell'istanza di replica, alla trasmissione di pacchetti di rete, alla latenza di rete e alla dimensione dell'unità di trasmissione massima (MTU) di rete. ![\[Strumento di diagnostica che mostra i dati di rete.\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-diagami3.png) ## Fasi successive Nelle seguenti sezioni sono riportate le informazioni sulla risoluzione dei problemi in base ai risultati dei test di diagnostica di rete: ### Test del VPC Questo test verifica che l'istanza Amazon EC2 di diagnostica si trovi nello stesso VPC dell'istanza di replica. Se l'istanza Amazon EC2 di diagnostica non si trova nello stesso VPC dell'istanza di replica, terminala e creala nuovamente nel VPC corretto. Non puoi modificare il VPC di un'istanza Amazon EC2 dopo averlo creato. ### Test di perdita di pacchetti di rete Questo test invia 10 pacchetti ai seguenti endpoint e verifica l'eventuale perdita di pacchetti: + Il servizio di metadati AWS DMS Amazon EC2 sulla porta 80 + L'endpoint di origine + L'endpoint di destinazione Tutti i pacchetti devono arrivare correttamente. In caso di perdita di pacchetti, rivolgiti a un tecnico della rete per determinare il problema e trovare una soluzione. ### Test di latenza di rete Questo test invia 10 pacchetti agli stessi endpoint del test precedente e verifica la latenza dei pacchetti. Tutti i pacchetti devono avere una latenza inferiore a 100 millisecondi. Se alcuni pacchetti hanno una latenza superiore a 100 millisecondi, contatta un tecnico della rete per determinare il problema e trovare una soluzione. ### Test di dimensione dell'unità di trasmissione massima (MTU) Questo test rileva la dimensione della MTU utilizzando lo strumento Traceroute sugli stessi endpoint del test precedente. Tutti i pacchetti del test devono avere la stessa dimensione della MTU. Se alcuni pacchetti hanno una dimensione della MTU diversa, contatta uno specialista di sistema per determinare il problema e trovare una soluzione. ## AMI IDs per regione Per visualizzare un elenco delle diagnostiche DMS AMIs disponibili nella tua AWS regione, esegui il seguente esempio di AWS CLI. ``` aws ec2 describe-images --owners 343299325021 --filters "Name=name, Values=DMS-DIAG*" --query "sort_by(Images, &CreationDate)[-1].[Name, ImageId, CreationDate]" --output text ``` Se l'output non mostra risultati, significa che l'AMI DMS Diagnostic non è disponibile nella tua AWS regione. La soluzione alternativa consiste nel seguire i passaggi seguenti per copiare l'AMI diagnostica da un'altra regione. Per ulteriori informazioni, consulta [Copiare un AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingAMIs.html). + Avvia un'istanza nella regione disponibile. + Crea l'immagine. L'immagine sarà di tua proprietà. + Copia l'AMI nella tua regione, ad esempio la regione del Medio Oriente (Emirati Arabi Uniti). + Avvia l'istanza nella tua regione locale. ## AWS Systems Patch Manager AWS Systems Patch Manager automatizza l'applicazione di patch per sistemi operativi e applicazioni sulle istanze EC2. **Per configurare il gestore delle patch, procedi nel seguente modo:** 1. Abilita Systems Manager: 1. Collega la policy `AmazonSSMManagedInstanceCore` IAM al ruolo della tua istanza EC2. 1. Assicurati che SSM Agent sia installato (impostazione predefinita per Amazon Linux 2, Ubuntu 20.04\$1 AMIs). 1. Crea una base di riferimento per le patch definendo le regole per critical/security gli aggiornamenti, incluse le pianificazioni per l'applicazione delle patch. 1. Pianifica gli aggiornamenti per l'applicazione delle patch in un momento definito utilizzando le finestre di manutenzione in SSM. 1. Verifica la conformità controllando lo stato delle patch e i report di conformità in Systems Manager.