View a markdown version of this page

Pemecahan Masalah Oracle Endpoint - AWS Layanan Migrasi Database
Pembacaan sumber dijedaGenerasi ulang 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 menjeda membaca dari sumber Oracle dalam skenario berikut. Perilaku ini adalah desain. Anda dapat menyelidiki penyebabnya menggunakan log tugas. Cari pesan yang mirip dengan berikut ini di log tugas. Untuk informasi tentang bekerja dengan log tugas, lihatMelihat dan mengelola AWS Log tugas DMS.

  • Pesan SORTER: Ini menunjukkan bahwa DMS melakukan cache transaksi pada instance replikasi. Untuk informasi lebih lanjut, lihat Pesan SORTER di log tugas berikut ini.

  • Debug log tugas: Jika DMS mengganggu proses baca, tugas Anda berulang kali menulis pesan berikut ke log tugas debug, tanpa perubahan pada 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 operasi log ulang atau diarsipkan baru.

    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 operasi log ulang atau diarsipkan baru, dan AWS DMS tidak menulis pesan ini ke log, ini berarti bahwa tugas tidak memproses peristiwa.

Generasi ulang tinggi

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

Untuk menentukan tingkat pembuatan ulang, gunakan kueri berikut.

  • Per-day tingkat generasi ulang:

    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;

  • Per-hour tingkat generasi ulang:

    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 utas tunggal replikasi Anda untuk memastikan bahwa jaringan yang mendasarinya dapat mendukung tingkat pembuatan ulang sumber. Untuk informasi tentang bagaimana bandwidth jaringan dapat memengaruhi kinerja replikasi, lihat Kecepatan jaringan dan bandwidth sebelumnya.

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

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

  • Periksa apakah Anda menyet ArchivedLogsOnly el keY. Jika pengaturan titik akhir ini disetel, AWS DMS baca dari log ulang yang diarsipkan. Ini meningkatkan latensi sumber, karena AWS DMS menunggu log ulang online diarsipkan sebelum membaca. Untuk informasi selengkapnya, lihat ArchivedLogsOnly.

  • Jika sumber Oracle menggunakan Automatic Storage Management (ASM), lihat Menyimpan REDO di Oracle ASM saat menggunakan Oracle sebagai sumber AWS DMS informasi tentang cara mengkonfigurasi penyimpanan data dengan benar. Anda mungkin juga dapat mengoptimalkan kinerja membaca lebih lanjut dengan menggunakan asmUsePLSQLArray extra connection attrribute (ECA). Untuk informasi tentang penggunaanasmUsePLSQLArray, lihatPengaturan titik akhir saat menggunakan Oracle sebagai sumber AWS DMS.