Pemecahan Masalah Oracle Endpoint - AWS Layanan Migrasi Database
Pembacaan sumber dijedaGenerasi redo tinggi

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pemecahan Masalah Oracle Endpoint

Bagian ini berisi skenario replikasi khusus untuk Oracle.

Pembacaan sumber dijeda

AWS DMS berhenti membaca dari sumber Oracle dalam skenario berikut. Perilaku ini adalah dengan desain. Anda dapat menyelidiki penyebabnya menggunakan log tugas. Cari pesan yang mirip dengan yang berikut ini di log tugas. Untuk informasi tentang bekerja dengan log tugas, lihatMelihat dan mengelola log AWS DMS tugas.

  • SORTERmessage: Ini menunjukkan bahwa DMS transaksi caching pada instance replikasi. Untuk informasi lebih lanjut, lihat SORTERpesan di log tugas berikut ini.

  • Log tugas debug: Jika DMS mengganggu proses baca, tugas Anda berulang kali menulis pesan berikut ke log tugas debug, tanpa mengubah bidang konteks atau stempel waktu:

    • Pembaca biner: 

      [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 mencatat pesan berikut untuk setiap pengulangan baru atau operasi log yang diarsipkan.

    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)

    Jika sumber memiliki pengulangan baru atau operasi log yang diarsipkan, dan AWS DMS tidak menulis pesan ini ke log, ini berarti bahwa tugas tersebut tidak memproses peristiwa.

Generasi redo tinggi

Jika tugas Anda memproses log redo atau diarsipkan, tetapi latensi sumber tetap tinggi, coba identifikasi tingkat pembuatan log ulang dan pola pembuatan. Jika Anda memiliki tingkat pembuatan redo log yang tinggi, ini meningkatkan latensi sumber, karena tugas Anda membaca semua log redo dan arsip untuk mengambil perubahan yang terkait dengan tabel yang direplikasi.

Untuk menentukan tingkat pembuatan ulang, gunakan kueri berikut.

  • Tingkat pembuatan ulang per hari:

    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;

  • Tingkat pembuatan ulang per jam:

    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 ;

Untuk memecahkan masalah latensi dalam skenario ini, periksa hal berikut:

  • Periksa bandwidth jaringan dan kinerja single-thread replikasi Anda untuk memastikan bahwa jaringan yang mendasari Anda dapat mendukung tingkat pembuatan ulang sumber. Untuk informasi tentang bagaimana bandwidth jaringan dapat mempengaruhi kinerja replikasi, lihat Kecepatan jaringan dan bandwidth sebelumnya.

  • Periksa apakah Anda mengatur pencatatan tambahan dengan benar. Hindari pencatatan tambahan pada sumber, seperti mengaktifkan logging pada semua kolom tabel. Untuk informasi tentang menyiapkan pencatatan tambahan, lihat. Mengatur supplemental logging

  • Verifikasi bahwa Anda menggunakan yang benar API untuk membaca redo atau log melengkung. Anda dapat menggunakan Oracle LogMiner atau AWS DMS Binary Reader. Saat LogMiner membaca log redo online dan file log redo yang diarsipkan, Binary Reader membaca dan mem-parsing file log redo mentah secara langsung. Akibatnya, Binary Reader lebih berkinerja. Kami menyarankan Anda menggunakan Binary Reader jika pembuatan redo log Anda lebih dari 10 GB/jam. Untuk informasi selengkapnya, lihat Menggunakan Oracle LogMiner atau AWS DMS Binary Reader untuk CDC.

  • Periksa apakah Anda menyetel ArchivedLogsOnly keY. Jika pengaturan titik akhir ini disetel, AWS DMS membaca dari log pengulangan yang diarsipkan. Ini meningkatkan latensi sumber, karena AWS DMS menunggu log pengulangan online diarsipkan sebelum membaca. Untuk informasi lebih lanjut, lihat ArchivedLogsOnly.

  • Jika sumber Oracle Anda menggunakan Manajemen Penyimpanan Otomatis (ASM), lihat Menyimpan REDO di Oracle ASM saat menggunakan Oracle sebagai sumber AWS DMS informasi tentang cara mengonfigurasi penyimpanan data dengan benar. Anda mungkin juga dapat mengoptimalkan kinerja membaca lebih lanjut dengan menggunakan koneksi asmUsePLSQLArray tambahan attrribute (). ECA Untuk informasi tentang penggunaanasmUsePLSQLArray, lihatPengaturan titik akhir saat menggunakan Oracle sebagai sumber AWS DMS.