Kami mulai berbicara tentang masalah Replikasi Transaksional SQL Server sebelumnya. Sekarang, kita akan melanjutkan dengan beberapa demo langsung untuk memahami masalah kinerja Replikasi yang sering dihadapi dan cara memecahkannya dengan benar.
Kami telah membahas masalah seperti masalah Konfigurasi, masalah Izin, masalah Konektivitas, dan masalah Integritas Data bersama dengan pemecahan masalah dan memperbaikinya. Sekarang, kita akan fokus pada berbagai masalah Kinerja dan masalah Korupsi yang berdampak pada Replikasi SQL Server.
Karena masalah Korupsi adalah topik yang sangat besar, kami akan membahas bagaimana dampaknya hanya dalam artikel ini dan tidak akan membahas secara rinci. Saya telah memilih beberapa skenario yang dapat termasuk dalam masalah Kinerja dan Korupsi berdasarkan pengalaman saya:
- Masalah Kinerja
- Transaksi Aktif yang berjalan lama di database Publisher
- Operasi INSERT/UPDATE/DELETE Massal pada Artikel
- Perubahan data yang besar dalam satu Transaksi
- Pemblokiran dalam database distribusi
- Masalah terkait korupsi
- Korupsi Basis Data Penerbit
- Korupsi Basis Data Distribusi
- Korupsi Basis Data Pelanggan
- Korupsi Basis Data MSDB
Masalah Kinerja
Replikasi Transaksional SQL Server adalah arsitektur rumit yang melibatkan beberapa parameter seperti database Publisher, database Distributor (distribusi), database Subscriber, dan beberapa Agen Replikasi yang dijalankan sebagai pekerjaan SQL Server Agent.
Seperti yang telah kita bahas semua item ini secara rinci di artikel kami sebelumnya, kami mengetahui pentingnya masing-masing item untuk fungsi Replikasi. Apa pun yang memengaruhi komponen ini dapat memengaruhi kinerja Replikasi SQL Server.
Misalnya, instans database Publisher memegang database penting dengan banyak transaksi per detik. Namun, sumber daya Server memiliki hambatan seperti penggunaan CPU yang konsisten di atas 90% atau penggunaan Memori di atas 90%. Pasti akan berdampak pada kinerja Pekerjaan Agen Pembaca Log yang membaca data perubahan dari log Transaksional database Publisher.
Demikian pula, skenario semacam itu di seluruh instans basis data Distributor atau Pelanggan dapat memengaruhi Agen Snapshot atau Agen Distribusi. Jadi, sebagai DBA, Anda perlu memastikan bahwa sumber daya server seperti CPU, Memori Fisik, dan bandwidth Jaringan dikonfigurasi secara efisien untuk instans database Publisher, Distributor, dan Subscriber.
Dengan asumsi bahwa server database Publisher, Subscriber, dan Distributor dikonfigurasi dengan benar, kami masih dapat mengalami masalah kinerja Replikasi saat menghadapi skenario di bawah ini.
Transaksi Aktif yang berjalan lama di Basis Data Penerbit
Seperti namanya, transaksi Long-Running Active menunjukkan bahwa ada panggilan Aplikasi atau operasi pengguna dalam lingkup transaksi yang dieksekusi untuk waktu yang lama.
Menemukan Transaksi Aktif yang Berjalan Lama berarti bahwa transaksi tersebut belum dilakukan dan dapat dibatalkan atau dilakukan oleh aplikasi. Ini akan mencegah agar Log Transaksi tidak terpotong, sehingga ukuran file Log Transaksi terus meningkat.
Agen Pembaca Log memindai semua catatan berkomitmen yang ditandai untuk replikasi dari Log Transaksional dalam urutan serial berdasarkan Nomor Urutan Log (LSN), melewatkan semua perubahan lain yang terjadi untuk artikel yang tidak direplikasi. Jika perintah transaksi Aktif yang Berjalan Lama belum dilakukan, maka Replikasi akan melewatkan pengiriman perintah tersebut dan mengirim semua transaksi komitmen lainnya ke database distribusi. Setelah transaksi Aktif yang Berjalan Lama dilakukan, catatan akan dikirim ke database distribusi dan sampai saat itu bagian yang tidak aktif dari file Log Transaksi dari DB Penerbit tidak akan dihapus sehingga menyebabkan File Log Transaksi ukuran database Penerbit meningkat.
Kita dapat menguji skenario Long-Running Active Transaction dengan melakukan langkah-langkah di bawah ini:
Secara default, Agen Distribusi membersihkan semua perubahan yang dilakukan ke database Pelanggan, menyimpan catatan terakhir untuk memantau perubahan baru berdasarkan Nomor Urutan Log (LSN).
Kami dapat menjalankan kueri di bawah ini untuk memeriksa status catatan yang tersedia di MSRepl_Commands tabel atau menggunakan sp_browsereplcmds prosedur dalam database distribusi:
exec sp_browsereplcmds
GO
SELECT * FROM MSrepl_commands
Sekarang, buka jendela kueri baru dan jalankan skrip di bawah ini untuk membuat transaksi aktif yang berjalan lama di AdventureWorks basis data. Perhatikan bahwa skrip di bawah ini tidak menyertakan perintah ROLLBACK atau COMMIT TRANSACTION. Oleh karena itu, kami menyarankan untuk tidak menjalankan perintah semacam ini pada basis data Produksi.
BEGIN TRANSACTION
SET IDENTITY_INSERT Person.ContactType ON;
insert into person.ContactType (ContactTypeId, Name, ModifiedDate) values ( 22, 'Test New Position', GETDATE());
SET IDENTITY_INSERT Person.ContactType OFF;
Kami dapat memverifikasi bahwa catatan baru ini belum direplikasi ke database Pelanggan. Untuk itu, kita akan melakukan pernyataan SELECT pada Person.ContactType tabel di database Pelanggan:
Mari kita verifikasi apakah perintah INSERT di atas telah dibaca oleh Agen Pembaca Log dan ditulis ke dalam database Distribusi.
Jalankan skrip dari bagian Langkah 1 lagi. Hasil masih menunjukkan status lama yang sama, mengonfirmasi bahwa catatan tidak dibaca dari log Transaksi dari database Publisher.
Sekarang buka Kueri Baru jendela dan jalankan skrip UPDATE di bawah ini untuk melihat apakah Agen Pembaca Log dapat melewati transaksi aktif yang berjalan lama dan membaca perubahan yang dilakukan oleh pernyataan UPDATE ini.
UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate = GETDATE()
Periksa database Distribusi apakah Agen Pembaca Log dapat menangkap perubahan ini. Jalankan skrip sebagai bagian dari Langkah 1:
Karena pernyataan UPDATE di atas dilakukan dalam database Publisher, Agen Pembaca Log dapat memindai perubahan ini dan memasukkannya ke dalam database Distribusi. Selanjutnya, itu menerapkan perubahan ini ke database Pelanggan seperti yang ditunjukkan di bawah ini:
MASUKKAN di Person.ContactType akan direplikasi ke database Pelanggan hanya setelah transaksi INSERT dilakukan di database Publisher. Sebelum berkomitmen, kami dapat dengan cepat memeriksa cara mengidentifikasi transaksi Aktif yang Berjalan Lama, memahaminya, dan menanganinya secara efisien.
Identifikasi Transaksi Aktif yang Berjalan Lama
Untuk memeriksa Transaksi Aktif yang Berjalan Lama di database mana pun, buka Jendela Kueri baru dan terhubung ke database masing-masing yang perlu kita periksa. Jalankan DBCC OPENTRAN console command – ini adalah Perintah Database Console untuk melihat transaksi yang terbuka di database pada saat eksekusi.
USE AdventureWorks
GO
DBCC OPENTRAN
Sekarang kita tahu bahwa ada SPID (ID proses server ) 69 berjalan untuk waktu yang lama. Mari kita verifikasi perintah mana yang dieksekusi pada transaksi tersebut menggunakan DBCC INPUTBUFFER console command (Perintah Konsol Basis Data yang digunakan untuk mengidentifikasi perintah atau operasi yang terjadi pada ID proses Server yang dipilih).
Agar mudah dibaca, saya menyalin EventInfo nilai bidang dan memformatnya untuk menampilkan perintah yang telah kita jalankan sebelumnya.
Jika tidak ada transaksi Long-Running Active pada database yang dipilih, kita akan mendapatkan pesan di bawah ini:
Mirip dengan DBCC OPENTRAN perintah konsol, kita dapat PILIH dari DMV bernama sys.dm_tran_database_transactions untuk mendapatkan hasil yang lebih detail (lihat artikel MSDN untuk data lebih lanjut).
Sekarang, kita tahu bagaimana mengidentifikasi transaksi yang berjalan lama. Kami dapat melakukan transaksi dan melihat bagaimana pernyataan INSERT direplikasi.
Buka jendela tempat kami memasukkan catatan ke Person.ContactType tabel dalam Lingkup Transaksi dan jalankan TRANSAKSI COMMIT seperti yang ditunjukkan di bawah ini:
Eksekusi COMMIT TRANSACTION melakukan record ke dalam database Publisher. Oleh karena itu, itu harus terlihat di database Distribusi dan database Pelanggan:
Jika Anda perhatikan, catatan lama dari database Distribusi dibersihkan oleh pekerjaan Pembersihan Agen Distribusi. Rekor baru untuk INSERT di Person.ContactType tabel terlihat di MSRepl_cmds tabel.
Dari pengujian kami, kami telah mempelajari hal-hal berikut:
- Tugas Agen Pembaca Log dari Replikasi Transaksional SQL Server akan memindai catatan yang Dikomit hanya dari Log Transaksi dari database Penerbit dan INSERT ke dalam database Pelanggan.
- Urutan data yang diubah pada database Publisher yang dikirim ke Pelanggan akan didasarkan pada status dan waktu Committed pada database Publisher meskipun data yang direplikasi akan memiliki waktu yang sama dengan database Publisher.
- Mengidentifikasi Transaksi Aktif yang Berjalan Lama dapat membantu dalam menyelesaikan pertumbuhan File Log Transaksional dari Penerbit atau Distributor atau Pelanggan atau basis data apa pun.
Operasi SQL INSERT/UPDATE/DELETE Massal pada Artikel
Dengan data besar yang berada di database Publisher, kita sering kali berakhir dengan persyaratan untuk INSERT atau UPDATE atau DELETE record besar ke tabel Replicated.
Jika operasi INSERT, atau UPDATE, atau DELETE dilakukan dalam satu Transaksi, pasti akan berakhir di Replikasi yang macet untuk waktu yang lama.
Katakanlah kita perlu INSERT 10 Juta record ke dalam tabel yang direplikasi. Memasukkan rekaman tersebut dalam satu bidikan akan menyebabkan masalah Performa.
INSERT INTO REplicated_table
SELECT * FROM Source_table
Sebagai gantinya, kami dapat MEMASUKKAN catatan dalam kumpulan 0,1 atau 0,5 Juta catatan dalam WHILE lingkaran atau loop KURSOR , dan itu akan memastikan replikasi lebih cepat. Kami mungkin tidak menerima masalah besar untuk pernyataan INSERT kecuali jika tabel yang terlibat memiliki banyak indeks. Namun, ini akan memiliki kinerja yang sangat baik untuk pernyataan UPDATE atau DELETE.
Asumsikan kami telah menambahkan kolom baru ke tabel Replika yang memiliki sekitar 10 Juta catatan. Kami ingin memperbarui kolom baru ini dengan nilai default.
Idealnya, perintah di bawah ini akan berfungsi dengan baik untuk MEMPERBARUI semua 10 Juta catatan dengan nilai default sebagai Abc :
-- UPDATE 10 Million records on Replicated Table with some DEFAULT values
UPDATE Replicated_table
SET new_column = 'Abc'
Namun, untuk menghindari dampak pada Replikasi, kita harus menjalankan operasi UPDATE di atas dalam kumpulan 0,1 atau 0,5 Juta catatan untuk menghindari masalah kinerja.
-- UPDATE in batches to avoid performance impacts on Replication
WHILE 1 = 1
BEGIN
UPDATE TOP(100000) Replicated_Table
SET new_Column = 'Abc'
WHERE new_column is NULL
IF @@ROWCOUNT = 0
BREAK
END
Demikian pula, jika kita perlu MENGHAPUS sekitar 10 Juta record dari tabel yang direplikasi, kita dapat melakukannya dalam batch:
-- DELETE 10 Million records on Replicated Table with some DEFAULT values
DELETE FROM Replicated_table
-- UPDATE in batches to avoid performance impacts on Replication
WHILE 1 = 1
BEGIN
DELETE TOP(100000) Replicated_Table
IF @@ROWCOUNT = 0
BREAK
END
Menangani BULK INSERT, atau UPDATE, atau DELETE secara efisien dapat membantu menyelesaikan masalah Replikasi.
Kiat Pro :Untuk MEMASUKKAN data yang sangat besar ke dalam tabel yang Direplikasi di database Publisher, gunakan wizard IMPOR/EKSPOR di SSMS, karena akan menyisipkan catatan dalam kumpulan 10.000 atau berdasarkan ukuran catatan yang lebih cepat dihitung oleh SQL Server.
Perubahan Data Besar dalam Satu Transaksi
Untuk menjaga integritas data dari perspektif aplikasi atau pengembangan, banyak aplikasi memiliki transaksi eksplisit yang ditentukan untuk operasi kritis. Namun, jika banyak operasi (INSERT, UPDATE, atau DELETE) dilakukan dalam satu lingkup Transaksi, Agen Pembaca Log pertama-tama akan menunggu transaksi selesai, seperti yang telah kita lihat sebelumnya.
Setelah transaksi dilakukan oleh aplikasi, Agen Pembaca Log perlu memindai perubahan data besar yang dilakukan pada log transaksi database Publisher. Selama pemindaian itu, kita dapat melihat peringatan atau pesan informasi di Agen Pembaca Log seperti
Agen Pembaca Log sedang memindai log transaksi untuk perintah yang akan direplikasi. Kira-kira xxxxxx log record telah dipindai dalam pass # xxxx yang ditandai untuk replikasi, waktu yang telah berlalu xxxxxxxxx (ms)
Sebelum mengidentifikasi solusi untuk skenario ini, kita perlu memahami bagaimana Agen Pembaca Log memindai catatan dari Log Transaksional dan memasukkan catatan ke dalam database Distribusi MSrepl_transactions dan MSrepl_cmds tabel.
SQL Server secara internal memiliki Nomor Urutan Log (LSN) di dalam Log Transaksional. Agen Pembaca Log memanfaatkan nilai LSN untuk memindai perubahan yang ditandai untuk Replikasi SQL Server secara berurutan.
Agen Pembaca Log mengeksekusi sp_replcmds prosedur tersimpan yang diperluas untuk mengambil perintah yang ditandai untuk Replikasi dari basis data Log Transaksi Penerbit.
Sp_replcmds menerima parameter input bernama @maxtrans untuk mengambil jumlah maksimum transaksi. Nilai defaultnya adalah 1 yang berarti akan memindai berapa pun jumlah transaksi yang tersedia dari log untuk dikirim ke database distribusi. Jika ada 10 operasi INSERT yang dilakukan melalui satu Transaksi dan dilakukan di database Publisher, satu batch mungkin berisi 1 Transaksi dengan 10 perintah.
Jika banyak transaksi dengan perintah yang lebih rendah diidentifikasi, Agen Pembaca Log akan menggabungkan beberapa transaksi atau XACT nomor urut ke Batch Replikasi tunggal. Tapi disimpan sebagai XACT different yang berbeda Urutan nomor di MSRepl_transactions meja. Perintah individu milik transaksi itu akan ditangkap di MSRepl_commands tabel.
Untuk memverifikasi hal-hal yang telah kita diskusikan di atas, saya memperbarui Tanggal Modifikasi kolom dbo.AWBuildVersion tabel untuk tanggal hari ini dan lihat apa yang terjadi:
UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate = GETDATE()
Sebelum menjalankan UPDATE, kami memverifikasi catatan yang ada di MSrepl_commands dan MSrepl_transactions tabel:
Sekarang, jalankan skrip UPDATE di atas dan verifikasi catatan yang ada di 2 tabel tersebut:
Rekor baru dengan waktu UPDATE dimasukkan ke dalam MSrepl_transactions meja dengan waktu_masuk . terdekat . Memeriksa perintah pada xact_seqno . ini akan menampilkan daftar perintah yang dikelompokkan secara logis menggunakan sp_browsereplcmds prosedur.
Di Replication Monitor, kita dapat melihat satu pernyataan UPDATE yang ditangkap di bawah 1 Transaksi dengan 1 perintah dari Penerbit ke Distributor.
Dan kita dapat melihat perintah yang sama dikirimkan dari Distributor ke Pelanggan dalam perbedaan sepersekian detik. Ini menunjukkan bahwa Replikasi terjadi dengan benar.
Sekarang, jika ada sejumlah besar transaksi digabungkan dalam satu xact_seqno , kita dapat melihat pesan seperti 10 transaksi dengan 5000 perintah terkirim .
Mari kita periksa ini dengan menjalankan UPDATE pada 2 tabel berbeda secara bersamaan:
Kita dapat melihat dua catatan transaksi di MSrepl_transactions tabel yang cocok dengan dua operasi UPDATE dan kemudian no. catatan dalam tabel yang cocok dengan no. catatan diperbarui.
Hasil dari MSrepl_transactions tabel:
Hasil dari MSrepl_commands tabel:
Namun, kami telah memperhatikan bahwa 2 transaksi ini secara logis dikelompokkan oleh Agen Pembaca Log dan digabungkan dalam satu batch sebagai 2 transaksi dengan 109225 perintah.
Tapi sebelum itu, kita mungkin melihat pesan seperti Mengirimkan transaksi yang direplikasi, xact count:1, command count 46601 .
Ini akan terjadi hingga Agen Pembaca Log memindai set lengkap perubahan dan mengidentifikasi bahwa 2 transaksi UPDATE telah dibaca sepenuhnya dari Log Transaksi.
Setelah perintah dibaca sepenuhnya dari Log Transaksi, kita melihat bahwa 2 transaksi dengan 109225 perintah dikirimkan oleh agen Pembaca Log:
Karena agen Distribusi sedang menunggu transaksi besar untuk direplikasi, kami mungkin melihat pesan seperti Mengirimkan transaksi Replika menunjukkan bahwa ada transaksi besar yang direplikasi, dan kami harus menunggu hingga transaksi tersebut direplikasi sepenuhnya.
Setelah direplikasi, kita juga dapat melihat pesan di bawah ini di Agen Distribusi:
Beberapa cara sangat membantu untuk menyelesaikan masalah ini.
Cara 1:BUAT Prosedur Tersimpan SQL Baru
Anda perlu membuat prosedur tersimpan baru dan merangkum logika aplikasi ke dalamnya di bawah cakupan Transaksi.
Setelah dibuat, tambahkan artikel Prosedur Tersimpan itu ke Replikasi dan ubah properti artikel Replikasikan ke Eksekusi Prosedur Tersimpan pilihan.
Ini akan membantu mengeksekusi artikel Prosedur Tersimpan di Pelanggan alih-alih mereplikasi semua perubahan data individual yang terjadi.
Mari kita tinjau bagaimana Eksekusi Prosedur Tersimpan opsi untuk Replika mengurangi beban pada Replikasi. Untuk melakukan itu, kita dapat membuat Test Stored Procedure seperti yang ditunjukkan di bawah ini:
CREATE procedure test_proc
AS
BEGIN
UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate = GETDATE()
UPDATE TOP(10) Production.TransactionHistoryArchive
SET ModifiedDate = GETDATE()
UPDATE TOP(10) Person.Person
SET ModifiedDate = GETDATE()
END
Prosedur di atas akan MEMPERBARUI satu catatan di AWBuildVersion tabel dan 10 catatan masing-masing di Production.TransactionHistoryArchive dan Person.Person tabel dengan total hingga 21 perubahan catatan.
Setelah membuat prosedur baru ini di Publisher dan Subscriber, tambahkan ke Replication. Untuk itu, klik kanan pada Publikasi dan pilih artikel prosedur untuk Replikasi dengan hanya definisi Prosedur Tersimpan default pilihan.
Setelah selesai, kami dapat memverifikasi catatan yang tersedia di MSrepl_transactions dan MSrepl_commands tabel.
Sekarang, mari kita jalankan prosedur di database Publisher untuk melihat berapa banyak record yang dilacak.
Berikut ini dapat kita lihat pada tabel Distribusi MSrepl_transactions dan MSrepl_commands :
Tiga xact_seqno dibuat untuk tiga operasi UPDATE di MSrepl_transactions tabel, dan 21 perintah dimasukkan ke MSrepl_commands tabel.
Buka Replication Monitor dan lihat apakah mereka dikirim sebagai 3 kumpulan Replikasi yang berbeda atau satu kumpulan dengan 3 transaksi secara bersamaan.
Kita dapat melihat bahwa tiga xact_seqno dikonsolidasikan sebagai kumpulan Replikasi tunggal. Oleh karena itu, kita dapat melihat bahwa 3 transaksi dengan 21 perintah berhasil terkirim.
Mari kita hapus prosedur dari Replikasi dan tambahkan kembali dengan Eksekusi Prosedur Tersimpan kedua pilihan. Sekarang, jalankan prosedur dan lihat bagaimana catatan direplikasi.
Memeriksa catatan dari tabel Distribusi menunjukkan detail di bawah ini:
Sekarang, jalankan prosedur pada database Publisher dan lihat berapa banyak catatan yang masuk ke tabel Distribusi. Eksekusi prosedur memperbarui 21 catatan (1 catatan, 10 catatan, dan 10 catatan) seperti sebelumnya.
Memverifikasi tabel Distribusi menunjukkan data di bawah ini:
Mari kita lihat sp_browsereplcmds untuk melihat perintah sebenarnya yang diterima:
Perintahnya adalah “{call “dbo”.”test_proc” }” yang akan dieksekusi di database Pelanggan.
Di Replication Monitor, kita dapat melihat bahwa hanya 1 transaksi dengan 1 perintah yang dikirimkan melalui Replication:
Dalam kasus pengujian kami, kami telah menggunakan prosedur dengan hanya 21 perubahan data. Namun, jika kita melakukannya untuk prosedur rumit yang melibatkan jutaan perubahan, maka Prosedur Tersimpan mendekati dengan Eksekusi Prosedur Tersimpan pilihan akan efisien dalam mengurangi beban Replikasi.
Kita perlu memvalidasi pendekatan ini dengan memeriksa apakah prosedur memiliki logika untuk memperbarui hanya kumpulan rekaman yang sama di database Publisher dan Subscriber. Jika tidak, ini akan menimbulkan masalah inkonsistensi data di seluruh Penerbit dan Pelanggan.
Cara 2:Mengonfigurasi MaxCmdsInTran, ReadBatchSize, dan Parameter Agen Pembaca Log ReadBatchThreshold
MaxCmdsInTran – menunjukkan jumlah maksimum Perintah yang dapat dikelompokkan secara logis dalam suatu Transaksi saat membaca data dari Log Transaksi dari basis data Penerbit dan ditulis ke basis data Distribusi.
Dalam pengujian kami sebelumnya, kami memperhatikan bahwa sekitar 109225 perintah terakumulasi dalam satu urutan tepat Replikasi, menghasilkan sedikit kelambatan atau latensi. Jika kita menyetel MaxCmdsInTran parameter ke 10000, satu urutan yang tepat nomor akan dibagi menjadi 11 urutan xact yang menghasilkan pengiriman perintah yang lebih cepat dari Penerbit ke Distributor . Meskipun opsi ini membantu mengurangi pertentangan database Distribusi dan mereplikasi data lebih cepat dari Publisher ke database Pelanggan, berhati-hatilah saat menggunakan opsi ini. Ini mungkin berakhir dengan mengirimkan data ke database Pelanggan dan mengaksesnya dari tabel database Pelanggan sebelum akhir lingkup transaksi awal.
ReadBatchSize – Parameter ini mungkin tidak membantu untuk satu skenario transaksi besar. Namun, ini membantu ketika ada banyak transaksi kecil yang terjadi di database Publisher.
Jika jumlah perintah per transaksi lebih sedikit, Agen Pembaca Log akan menggabungkan beberapa perubahan ke lingkup transaksi perintah Replikasi tunggal. Ukuran Batch Baca menunjukkan berapa banyak Transaksi yang dapat dibaca di Log Transaksi sebelum mengirim perubahan ke database Distribusi. Nilainya bisa antara 500 dan 10.000.
BatchBatchThreshold – menunjukkan jumlah perintah yang harus dibaca dari log transaksi database Penerbit sebelum dikirim ke Pelanggan dengan nilai default 0 untuk memindai file log lengkap. Namun, kita dapat mengurangi nilai ini untuk mengirim data lebih cepat dengan membatasinya menjadi 10.000 atau 100.000 perintah seperti itu.
Cara 3:Mengonfigurasi Nilai Terbaik untuk Parameter SubscriptionStreams
Aliran Langganan – menunjukkan jumlah koneksi yang dapat dijalankan oleh agen Distribusi secara paralel untuk mengambil data dari database Distribusi dan menyebarkannya ke database Pelanggan. Nilai default adalah 1 yang menyarankan hanya satu aliran atau koneksi dari distribusi ke database pelanggan. Nilainya bisa antara 1 hingga 64. Jika lebih banyak aliran Langganan ditambahkan, itu mungkin berakhir pada kemacetan CXPACKET (dengan kata lain, paralelisme). Oleh karena itu, Anda harus berhati-hati saat mengonfigurasi opsi ini di Produksi.
Untuk meringkas, coba hindari INSERT, UPDATE, atau DELETE yang besar dalam satu transaksi. Jika tidak mungkin untuk menghilangkan operasi ini, opsi terbaik adalah menguji cara di atas dan memilih salah satu yang paling sesuai dengan kondisi spesifik Anda.
Pemblokiran dalam Basis Data Distribusi
Basis data distribusi adalah inti dari Replikasi Transaksional SQL Server dan jika tidak dikelola dengan baik, akan ada banyak masalah kinerja.
Untuk meringkas semua praktik yang direkomendasikan untuk konfigurasi database distribusi, kita perlu memastikan konfigurasi di bawah ini dilakukan dengan benar:
- File data dari database distribusi harus ditempatkan pada drive IOPS tinggi. Jika database Publisher akan memiliki banyak perubahan data, kita perlu memastikan bahwa database distribusi ditempatkan pada drive dengan IOPS tinggi. Ini akan terus menerima data dari agen Pembaca Log, mengirim data ke database Pelanggan melalui agen Distribusi. Semua data yang direplikasi akan dihapus dari database distribusi setiap 10 menit melalui tugas pembersihan Distribusi.
- Konfigurasikan ukuran File Awal dan properti Pertumbuhan Otomatis dari database Distribusi dengan nilai yang disarankan berdasarkan tingkat aktivitas database Publisher. Jika tidak, ini akan menyebabkan fragmentasi data dan file log yang menyebabkan masalah kinerja.
- Sertakan database distribusi dalam pekerjaan Pemeliharaan Indeks reguler yang dikonfigurasi di Server tempat database distribusi berada.
- Sertakan database distribusi dalam jadwal tugas pencadangan lengkap untuk memecahkan masalah tertentu.
- Pastikan bahwa Pembersihan Distribusi:distribusi pekerjaan berjalan setiap 10 menit sesuai jadwal default. Jika tidak, ukuran database distribusi terus meningkat dan menyebabkan masalah kinerja.
Seperti yang telah kita perhatikan sejauh ini, dalam database distribusi, tabel kunci yang terlibat adalah MSrepl_transactions dan MSrepl_commands . Catatan disisipkan di sana oleh tugas Agen Pembaca Log, dipilih oleh tugas Agen Distribusi, diterapkan di database Pelanggan, lalu dihapus atau dibersihkan oleh tugas agen Pembersih Distribusi.
Jika database distribusi tidak dikonfigurasi dengan benar, kita dapat mengalami pemblokiran sesi di 2 tabel ini, yang akan mengakibatkan masalah kinerja Replikasi SQL Server.
Kami dapat menjalankan kueri di bawah ini di seluruh basis data untuk melihat sesi pemblokiran yang tersedia dalam contoh SQL Server saat ini:
SELECT *
FROM sys.sysprocesses
where blocked > 0
order by waittime desc
Jika kueri di atas mengembalikan hasil apa pun, kami dapat mengidentifikasi perintah pada sesi yang diblokir tersebut dengan menjalankan DBCC INPUTBUFFER(spid) perintah konsol dan ambil tindakan yang sesuai.
Masalah Terkait Korupsi
Basis data SQL Server menggunakan algoritme atau logikanya untuk menyimpan data ke dalam tabel dan menyimpannya dalam luasan atau halaman. Korupsi Basis Data adalah proses di mana keadaan fisik file/ekstensi/halaman terkait basis data berubah dari keadaan normal menjadi tidak stabil atau tidak dapat diambil sehingga pengambilan data menjadi lebih sulit atau tidak mungkin.
Semua Database SQL Server rentan terhadap Korupsi Database. Penyebabnya bisa:
- Kegagalan perangkat keras seperti masalah Disk, Penyimpanan, atau Pengontrol;
- Kegagalan OS Server seperti masalah patching;
- Kegagalan daya yang mengakibatkan server mati secara tiba-tiba atau matinya database secara tidak benar.
Jika kami dapat memulihkan atau memperbaiki database tanpa kehilangan data, Replikasi SQL Server tidak akan terpengaruh. Namun, jika ada kehilangan data saat memulihkan atau memperbaiki database yang rusak, kami akan mulai menerima banyak masalah integritas data yang telah kami diskusikan di artikel sebelumnya.
Korupsi dapat terjadi pada berbagai komponen, seperti:
- Data Penerbit/file log rusak
- Data Pelanggan/file log rusak
- Data Database Distribusi/File Log rusak
- Data Database Msdb/File Log rusak
If we receive a lot of data integrity issues after fixing up Corruption issues, it is recommended to remove the Replication completely, fix all Corruption issues in the Publisher, Subscriber, or Distributor database and then reconfigure Replication to fix it. Otherwise, data integrity issues will persist and lead to data inconsistency across the Publisher and Subscriber. The time required to fix the Data integrity issues in case of Corrupted databases will be much more compared to configuring Replication from scratch. Hence identify the level of Corruption encountered and take optimal decisions to resolve the Replication issues faster.
Wondering why msdb database corruption can harm Replication? Since msdb database hold all details related to SQL Server Agent Jobs including Replication Agent jobs, any corruption on msdb database will harm Replication. To recover quickly from msdb database corruptions, it is recommended to restore msdb database from the last Full Backup of msdb database. This also signifies the importance of taking Full Backups of all system databases including msdb database.
Kesimpulan
Thanks for successfully going through the final power-packed article about the Performance issues in the SQL Server Transactional Replication. If you have gone through all articles carefully, you should be able to troubleshoot almost any Transactional Replication-based issues and fix them out efficiently.
If you need any further guidance or have any Transactional Replication-related issues in your environment, you can reach out to me for consultation. And if I missed anything essential in this article, you are welcome to point to that in the Comments section.
