Risoluzione dei problemi relativi all'endpoint Oracle - AWS Servizio di migrazione del Database
Lettura dell'origine sospesaElevata generazione di log redo

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 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 attività AWS DMS.

  • SORTERmessaggio: Ciò indica che DMS le transazioni vengono memorizzate nella cache dell'istanza di replica. Per ulteriori informazioni, consulta la sezione seguente: SORTERmessaggio nel registro delle attività.

  • Registri delle attività di debug: se DMS interrompe il processo di lettura, l'attività scrive ripetutamente il seguente messaggio nei registri 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 in precedenza.

  • Verifica se il log supplementare è configurato al momento. 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.

  • Verificate di utilizzare il file corretto API per leggere i redo log o i log archiviati. È 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.

  • 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, vedere. ArchivedLogsOnly

  • Se la tua fonte Oracle utilizza Automatic Storage Management (ASM), consulta Memorizzazione di REDO su Oracle ASM quando si utilizza Oracle come origine per AWS DMS per informazioni su come configurare correttamente il tuo Data Store. Potresti anche essere in grado di ottimizzare ulteriormente le prestazioni di lettura utilizzando l'attributo di connessione asmUsePLSQLArray aggiuntivo ()ECA. Per ulteriori informazioni sull'uso di asmUsePLSQLArray, consultare Impostazioni degli endpoint quando si utilizza Oracle come fonte per AWS DMS.