Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah latensi target
Bagian ini berisi skenario yang dapat berkontribusi pada latensi target.
**Topics**
+ [Masalah pengindeksan](#CHAP_Troubleshooting_Latency_Target_Indexing)
+ [Pesan SORTER di log tugas](#CHAP_Troubleshooting_Latency_Target_Sorter)
+ [Penguncian database](#CHAP_Troubleshooting_Latency_Target_Locking)
+ [Pencarian LOB lambat](#CHAP_Troubleshooting_Latency_Target_LOB)
+ [Multi-AZ, pencatatan audit dan pencadangan](#CHAP_Troubleshooting_Latency_Target_MultiAZ)
## Masalah pengindeksan
Selama fase CDC, mer AWS DMS eplikasi perubahan pada sumber dengan menjalankan pernyataan DML (masukkan, perbarui, dan hapus) pada target. Untuk migrasi heterogen menggunakan DMS, perbedaan dalam pengoptimalan indeks pada sumber dan target dapat menyebabkan penulisan ke target memakan waktu lebih lama. Hal ini mengakibatkan masalah latensi dan kinerja target.
Untuk memecahkan masalah pengindeksan, lakukan hal berikut. Prosedur untuk langkah-langkah ini bervariasi untuk mesin database yang berbeda.
+ Pantau waktu kueri untuk database target Anda. Membandingkan waktu eksekusi query pada target dan sumber dapat menunjukkan indeks mana yang perlu dioptimalkan.
+ Aktifkan logging untuk kueri yang berjalan lambat.
Untuk memperbaiki masalah pengindeksan untuk replikasi yang berjalan lama, lakukan hal berikut:
+ Setel indeks pada basis data sumber dan target Anda sehingga waktu eksekusi kueri serupa pada sumber dan target.
+ Bandingkan indeks sekunder yang digunakan dalam kueri DML untuk sumber dan target. Pastikan kinerja DML pada target sebanding dengan atau lebih baik dari kinerja DML sumber.
Perhatikan bahwa prosedur untuk mengoptimalkan indeks khusus untuk mesin database Anda. Tidak ada fitur DMS untuk menyetel indeks sumber dan target.
## Pesan SORTER di log tugas
Jika titik akhir target tidak dapat mengikuti volume perubahan yang dit AWS DMS ulisnya, tugas menyimpan perubahan pada instance replikasi. Jika cache tumbuh lebih besar dari ambang internal, tugas berhenti membaca perubahan lebih lanjut dari sumbernya. DMS melakukan ini untuk mencegah instans replikasi kehabisan penyimpanan, atau tugas macet saat membaca sejumlah besar peristiwa yang tertunda.
Untuk memecahkan masalah ini, periksa CloudWatch log untuk pesan yang mirip dengan salah satu dari berikut ini:
```
[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)
```
Jika log berisi pesan yang mirip dengan pesan pertama, nonaktifkan pencatatan jejak untuk tugas tersebut, dan tingkatkan penyimpanan instans replikasi. Untuk informasi tentang meningkatkan penyimpanan instans replikasi, lihat[Mengubah instans replikasi](CHAP_ReplicationInstance.Modifying.md).
Jika log Anda berisi pesan yang mirip dengan pesan kedua, lakukan hal berikut:
+ Pindahkan tabel dengan banyak transaksi atau operasi DML yang berjalan lama ke tugas terpisah, jika tabel tersebut tidak memiliki dependensi pada tabel lain dalam tugas.
+ Tingkatkan `MemoryKeepTime` pengaturan `MemoryLimitTotal` dan untuk menahan transaksi untuk durasi yang lebih lama dalam memori. Ini tidak akan membantu jika latensi dipertahankan, tetapi dapat membantu menjaga latensi tetap rendah selama ledakan volume transaksional yang singkat. Untuk informasi tentang pengaturan tugas ini, lihat[Mengubah pengaturan penyetelan pemrosesan](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
+ Evaluasi apakah Anda dapat menggunakan batch apply untuk transaksi Anda dengan menyetel `BatchApplyEnabled` ke`true`. Untuk informasi tentang `BatchApplyEnabled` pengaturan, lihat[Menargetkan pengaturan tugas metadata](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md).
## Penguncian database
Jika aplikasi mengakses database yang AWS DMS digunakan sebagai target replikasi, aplikasi dapat mengunci tabel yang DMS coba akses. Ini menciptakan pertentangan kunci. Karena DMS menulis perubahan pada database target dalam urutan yang terjadi pada sumber, penundaan menulis ke satu tabel karena pertentangan kunci membuat penundaan untuk menulis ke semua tabel.
Untuk memecahkan masalah ini, kueri database target untuk memeriksa apakah kontradiksi kunci memblokir transaksi penulisan DMS. Jika database target memblokir transaksi penulisan DMS, lakukan satu atau beberapa hal berikut:
+ Restrukturisasi kueri Anda untuk melakukan perubahan lebih sering.
+ Ubah pengaturan batas waktu penguncian Anda.
+ Partisi tabel Anda untuk meminimalkan perselisihan kunci.
Perhatikan bahwa prosedur untuk mengoptimalkan kontensi kunci khusus untuk mesin database Anda. Tidak ada fitur DMS untuk penyetelan pertentangan kunci.
## Pencarian LOB lambat
Saat AWS DMS mereplikasi kolom objek besar (LOB), ia melakukan pencarian pada sumber tepat sebelum menulis perubahan ke target. Pencarian ini biasanya tidak menyebabkan latensi pada target, tetapi jika database sumber menunda pencarian karena penguncian, latensi target dapat melonjak.
Masalah ini biasanya sulit untuk didiagnosis. Untuk memecahkan masalah ini, aktifkan debugging terperinci pada log tugas, dan bandingkan stempel waktu panggilan pencarian DMS LOB. Untuk informasi tentang mengaktifkan debugging terperinci, lihat[Melihat dan mengelola AWS Log tugas DMS](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs).
Untuk memperbaiki masalah ini, coba yang berikut ini:
+ Meningkatkan kinerja kueri SELECT pada database sumber.
+ Setel pengaturan DMS LOB. Untuk informasi tentang menyetel pengaturan LOB, lihat[Melakukan migrasi objek biner large (LOB)](CHAP_BestPractices.md#CHAP_BestPractices.LOBS).
## Multi-AZ, pencatatan audit dan pencadangan
Untuk target Amazon RDS, latensi target dapat meningkat selama berikut:
+ Pencadangan
+ Setelah mengaktifkan beberapa zona ketersediaan (Multi-AZ)
+ Setelah mengaktifkan logging database, seperti audit atau log kueri lambat.
Masalah-masalah ini biasanya sulit untuk didiagnosis. Untuk memecahkan masalah ini, pantau latensi untuk lonjakan periodik selama jendela pemeliharaan Amazon RDS atau periode beban database yang berat.
Untuk memperbaiki masalah ini, coba yang berikut ini:
+ Jika memungkinkan, selama migrasi jangka pendek, nonaktifkan Multi-AZ, backup, atau logging.
+ Jadwalkan ulang jendela pemeliharaan Anda untuk periode aktivitas rendah.