Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Pemecahan Masalah Titik Akhir SQL Server
Bagian ini berisi skenario replikasi khusus untuk SQL Server. Untuk menentukan perubahan apa yang akan direplikasi dari SQL server AWS DMS membaca log transaksi, dan menjalankan pemindaian berkala pada database sumber. Latensi replikasi biasanya dihasilkan dari SQL Server yang membatasi pemindaian ini karena kendala sumber daya. Ini juga dapat dihasilkan dari peningkatan signifikan dalam jumlah peristiwa yang ditulis ke log transaksi dalam waktu singkat.
Topik
Pembangunan kembali indeks
Ketika SQL Server membangun kembali indeks besar, ia menggunakan satu transaksi. Ini menghasilkan banyak peristiwa, dan dapat menggunakan sejumlah besar ruang log jika SQL Server membangun kembali beberapa indeks sekaligus. Ketika ini terjadi, Anda dapat mengharapkan lonjakan replikasi singkat. Jika sumber SQL Server Anda mengalami lonjakan log yang berkelanjutan, periksa hal berikut:
Pertama, periksa periode waktu lonjakan latensi menggunakan
CDCLatencySourceCloudWatch metrikCDCLatencySourcedan, atau dengan memeriksa pesan Pemantauan Throughput di log tugas. Untuk informasi tentang CloudWatch metrik untuk AWS DMS, lihatMetrik tugas replikasi.Periksa apakah ukuran log transaksi aktif atau cadangan log meningkat selama lonjakan latensi. Periksa juga apakah pekerjaan pemeliharaan atau pembangunan kembali berjalan selama waktu itu. Untuk informasi tentang memeriksa ukuran log transaksi, lihat Mem antau penggunaan ruang log
dalam dokumentasi teknis SQL Server . Pastikan rencana pemeliharaan Anda mengikuti praktik terbaik SQL server. Untuk informasi tentang praktik terbaik pemeliharaan server SQL, lihat Strateg i pemeliharaan
indeks dalam dokumentasi teknis SQL Server .
Untuk memperbaiki masalah latensi selama pembuatan ulang indeks, coba yang berikut ini:
Gunakan model
BULK_LOGGEDpemulihan untuk pembuatan ulang offline untuk mengurangi kejadian yang harus diproses tugas.Jika memungkinkan, hentikan tugas selama pembangunan kembali indeks. Atau, cobalah menjadwalkan pembangunan kembali indeks selama jam non-sibuk untuk mengurangi dampak lonjakan latensi.
Cobalah untuk mengidentifikasi hambatan sumber daya yang memperlambat pembacaan DMS, seperti latensi disk atau I/O throughput, dan atasi mereka.
Transaksi besar
Transaksi dengan banyak peristiwa, atau transaksi yang berjalan lama, menyebabkan log transaksi tumbuh. Hal ini menyebabkan pembacaan DMS memakan waktu lebih lama, mengakibatkan latensi. Ini mirip dengan efek pembangunan kembali indeks terhadap kinerja replikasi.
Anda mungkin mengalami kesulitan mengidentifikasi masalah ini jika Anda tidak terbiasa dengan beban kerja khas pada database sumber. Untuk memecahkan masalah ini, lakukan hal berikut:
Pertama, identifikasi waktu latensi melonjak menggunakan
WriteThroughputCloudWatch metrikReadThroughputdan, atau dengan memeriksa pesan Pemantauan Throughput di log tugas.Periksa apakah ada kueri yang berjalan lama pada database sumber selama lonjakan latensi. Untuk informasi tentang kueri yang berjalan lama, lihat Memec ahkan masalah kueri yang berjalan lambat di SQL Server
dalam dokumentasi teknis SQL Server. Periksa apakah ukuran log transaksi aktif atau cadangan log telah meningkat. Untuk informasi selengkapnya, lihat Memantau penggunaan ruang log
dalam dokumentasi teknis SQL Server .
Untuk memperbaiki masalah ini, lakukan salah satu hal berikut:
Perbaikan terbaik adalah merestrukturisasi transaksi Anda di sisi aplikasi sehingga selesai dengan cepat.
Jika Anda tidak dapat merestrukturisasi transaksi Anda, solusi jangka pendek adalah memeriksa kemacetan sumber daya seperti menunggu disk atau pertikaian CPU. Jika Anda menemukan hambatan di database sumber Anda, Anda dapat mengurangi latensi dengan meningkatkan sumber daya disk, CPU, dan memori untuk database sumber. Ini mengurangi perselisihan untuk sumber daya sistem, memungkinkan kueri DMS selesai lebih cepat.
Interval MS-CDC polling yang salah konfigurasi untuk Amazon RDS SQL Server
Pengaturan interval polling yang salah dikonfigurasi pada instans Amazon RDS dapat menyebabkan log transaksi bertambah. Ini karena replikasi mencegah pemotongan log. Sementara tugas yang sedang berjalan mungkin terus direplikasi dengan latensi minimal, menghentikan dan melanjutkan tugas, atau memulai CDC-only tugas, dapat menyebabkan kegagalan tugas. Ini karena batas waktu saat memindai log transaksi besar.
Untuk memecahkan masalah interval polling yang salah konfigurasi, lakukan hal berikut:
Periksa apakah ukuran log transaksi aktif meningkat, dan apakah penggunaan log mendekati 100 persen. Untuk informasi selengkapnya, lihat Memantau penggunaan ruang log
dalam dokumentasi teknis SQL Server . Periksa apakah pemotongan log tertunda dengan a
log_reuse_wait_desc valueof.REPLICATIONUntuk informasi selengkapnya, lihat Log Transaksi (SQL Server)dalam dokumentasi teknis SQL Server .
Jika Anda menemukan masalah dengan salah satu item dalam daftar sebelumnya, setel interval MS-CDC polling. Untuk informasi tentang menyetel interval polling, lihatPengaturan yang disarankan saat menggunakan RDS untuk SQL Server sebagai sumber AWS DMS.
Beberapa tugas CDC mereplikasi dari database sumber yang sama
Selama fase beban penuh, sebaiknya pisahkan tabel di seluruh tugas untuk meningkatkan kinerja, memisahkan tabel dependen secara logis, dan mengurangi dampak kegagalan tugas. Namun, selama fase CDC, kami merekomendasikan konsolidasi tugas untuk meminimalkan pemindaian DMS. Selama fase CDC, setiap tugas DMS memindai log transaksi untuk peristiwa baru beberapa kali dalam satu menit. Karena setiap tugas berjalan secara independen, setiap tugas memindai setiap log transaksi secara individual. Hal ini meningkatkan penggunaan disk dan CPU pada database SQL Server sumber. Akibatnya, sejumlah besar tugas yang berjalan secara paralel dapat menyebabkan SQL Server membatasi pembacaan DMS, yang menyebabkan peningkatan latensi.
Anda mungkin mengalami kesulitan mengidentifikasi masalah ini jika beberapa tugas dimulai secara bertahap. Gejala yang paling umum dari masalah ini adalah sebagian besar pemindaian tugas mulai memakan waktu lebih lama. Hal ini menyebabkan latensi yang lebih tinggi untuk pemindaian ini. SQL Server memprioritaskan beberapa pemindaian tugas, sehingga beberapa tugas menunjukkan latensi normal. Untuk memecahkan masalah ini, periksa CDCLatencySource metrik untuk semua tugas Anda. Jika beberapa tugas mengalami peningkatanCDCLatencySource, sementara beberapa tugas memiliki tingkat rendahCDCLatencySource, kemungkinan SQL Server membatasi pembacaan DMS Anda untuk beberapa tugas Anda.
Jika SQL Server membatasi pembacaan tugas Anda selama CDC, konsolidasikan tugas Anda untuk meminimalkan jumlah pemindaian DMS. Jumlah maksimum tugas yang dapat terhubung ke database sumber Anda tanpa membuat pertentangan tergantung pada faktor-faktor seperti kapasitas database sumber, tingkat pertumbuhan log transaksi, atau jumlah tabel. Untuk menentukan jumlah tugas yang ideal untuk skenario replikasi Anda, uji replikasi di lingkungan pengujian yang mirip dengan lingkungan produksi Anda.
Pemrosesan cadangan log transaksi untuk RDS untuk SQL Server
AWS DMS 3.5.3 dan di atas mendukung replikasi dari RDS untuk cadangan log SQL Server. Mereplikasi peristiwa dari log cadangan pada instans RDS lebih lambat daripada mereplikasi peristiwa dari log transaksi aktif. Ini karena DMS meminta akses ke cadangan secara serial untuk memastikan bahwa ia mempertahankan urutan transaksi, dan untuk meminimalkan risiko pengisian penyimpanan instans Amazon RDS. Selain itu, di akhir Amazon RDS, waktu yang dibutuhkan untuk membuat cadangan tersedia untuk DMS bervariasi tergantung pada ukuran cadangan log, dan beban pada RDS untuk instance SQL Server.
Karena kendala ini, kami sarankan Anda menyetel ECA ActivateSafeguard ketrue. Ini memastikan bahwa transaksi tidak dicadangkan saat tugas DMS membaca dari log transaksi aktif. Pengaturan ini juga mencegah transaksi pengarsipan Amazon RDS di log aktif saat DMS membaca transaksi dari cadangan, sehingga menghilangkan kemungkinan DMS tidak dapat mengejar log aktif. Perhatikan bahwa ini dapat menyebabkan ukuran log aktif bertambah saat tugas mengejar ketinggalan. Pastikan instans Anda memiliki penyimpanan yang cukup agar instans tidak kehabisan ruang.
Untuk CDC-only tugas yang direplikasi dari sumber RDS untuk SQL Server, gunakan penggunaan posisi awal CDC asli dibandingkan waktu mulai CDC asli jika memungkinkan. Ini karena DMS bergantung pada tabel sistem untuk mengidentifikasi titik awal untuk posisi awal asli, daripada memindai cadangan log individual saat Anda menentukan waktu mulai asli.
