Meningkatkan Performa Replikasi Umum

Artikel
04/26/2023

Berlaku untuk:SQL Server Azure SQL Managed Instance

Anda dapat meningkatkan performa umum untuk semua jenis replikasi di aplikasi Anda dan di jaringan Anda dengan menggunakan panduan yang dijelaskan dalam topik ini.

Server dan Jaringan

Atur jumlah memori minimum dan maksimum yang dialokasikan ke Microsoft SQL Server Database Engine.

Secara default, Mesin Database mengubah persyaratan memorinya secara dinamis berdasarkan sumber daya sistem yang tersedia. Untuk menghindari ketersediaan memori yang rendah selama aktivitas replikasi, gunakan opsi memori server min untuk mengatur memori minimum yang tersedia. Untuk menghindari halaman sistem operasi ke disk untuk memori, Anda juga dapat mengatur jumlah memori maksimum dengan opsi memori server maks. Untuk informasi selengkapnya, lihat Opsi Konfigurasi Server Memori Server.
Pastikan alokasi file data database dan file log yang tepat. Gunakan drive disk terpisah untuk log transaksi untuk semua database yang terlibat dalam replikasi.

Anda dapat mengurangi waktu yang diperlukan untuk menulis transaksi dengan menyimpan file log pada drive disk yang berbeda dari yang digunakan untuk menyimpan database. Anda dapat mencerminkan drive tersebut, menggunakan Array Redundan Dari Disk Murah (RAID)-1, jika Anda memerlukan toleransi kesalahan. Gunakan RAID 0 atau 0+1 (tergantung pada kebutuhan Anda akan toleransi kesalahan) untuk file database lainnya. Ini adalah praktik yang baik terlepas dari apakah replikasi sedang digunakan atau tidak.
Pertimbangkan untuk menambahkan memori ke server yang digunakan dalam replikasi, terutama Distributor.
Gunakan komputer multiproscessor.

Agen replikasi dapat memanfaatkan prosesor tambahan di server. Jika Anda berjalan pada penggunaan CPU tinggi, pertimbangkan untuk menginstal CPU yang lebih cepat atau beberapa CPU.
Gunakan jaringan cepat.

Jaringan dapat menjadi hambatan performa yang signifikan, terutama untuk replikasi transaksional. Penyebaran perubahan pada Pelanggan dapat ditingkatkan secara signifikan dengan menggunakan jaringan cepat 100 megabit per detik (Mbps) atau lebih cepat. Jika jaringan lambat, tentukan pengaturan jaringan dan parameter agen yang sesuai.

Desain Database

Ikuti praktik terbaik untuk desain database.

Database yang direplikasi umumnya mendapat manfaat dari pengoptimalan performa yang sama dengan database yang tidak direplikasi. Namun, indeks harus digunakan dengan hati-hati di Pelanggan: kolom kunci utama di Pelanggan harus diindeks, tetapi indeks tambahan dapat memengaruhi kinerja sisipkan, perbarui, dan hapus.
Pertimbangkan untuk mengatur opsi database READ_COMMITTED_SNAPSHOT.

Untuk membantu mengurangi pertikaian antara aktivitas pengguna dan aktivitas agen replikasi, atur opsi ini untuk database publikasi dan langganan:
```
ALTER DATABASE AdventureWorks  
SET READ_COMMITTED_SNAPSHOT ON  
```
Untuk informasi selengkapnya, lihat MENGUBAH DATABASE (Transact-SQL).
Berhati-hatilah dengan logika aplikasi dalam pemicu.

Logika bisnis dalam pemicu yang ditentukan pengguna di Pelanggan dapat memperlambat replikasi perubahan pada Pelanggan:
- Untuk replikasi transaksional, mungkin lebih efisien untuk menyertakan logika ini dalam prosedur tersimpan kustom yang digunakan untuk menerapkan perintah yang direplikasi. Untuk informasi selengkapnya, lihat Menentukan Bagaimana Perubahan Disebarkan untuk Artikel Transaksional.
- Untuk replikasi penggabungan, bisa lebih efisien untuk menggunakan penangan logika bisnis. Untuk informasi selengkapnya, lihat Menjalankan Logika Bisnis Selama Sinkronisasi Penggabungan.
Jika Anda menggunakan pemicu untuk mempertahankan integritas referensial dalam tabel yang diterbitkan untuk replikasi penggabungan, tentukan urutan pemrosesan tabel untuk mengurangi jumlah percobaan ulang yang diperlukan untuk Agen Penggabungan. Untuk informasi selengkapnya, lihat Menentukan opsi replikasi penggabungan.
Batasi penggunaan jenis data Objek Besar (LOB).

LOB memerlukan lebih banyak ruang penyimpanan dan pemrosesan daripada jenis data kolom lainnya. Jangan sertakan kolom ini dalam artikel kecuali diperlukan untuk aplikasi Anda. Teks jenis data, ntext, dan gambar tidak digunakan lagi. Jika Anda menyertakan LOB, kami sarankan Anda menggunakan jenis data varchar(max), nvarchar(max), varbinary(max), masing-masing.

Untuk replikasi transaksional, pertimbangkan untuk menggunakan profil Agen Distribusi yang disebut Profil Distribusi untuk streaming OLEDB. Untuk informasi selengkapnya, lihat Profil Agen Replikasi.

Desain Publikasi

Terbitkan hanya data yang diperlukan.

Karena replikasi mudah disiapkan, ada kecenderungan untuk menerbitkan lebih banyak data daripada yang sebenarnya diperlukan. Ini dapat menggunakan sumber daya tambahan dalam database distribusi dan file rekam jepret, dan dapat menurunkan throughput untuk data yang diperlukan. Hindari menerbitkan tabel yang tidak perlu dan pertimbangkan untuk memperbarui publikasi lebih jarang.
Meminimalkan konflik melalui desain publikasi dan perilaku aplikasi.

Jenis replikasi berikut memungkinkan data diubah di Pelanggan: replikasi penggabungan, replikasi transaksional dengan langganan yang dapat diperbarui, dan replikasi transaksional peer-to-peer. Replikasi penggabungan dan replikasi transaksional dengan langganan yang dapat diperbarui mendukung konflik data jika baris tertentu diperbarui pada lebih dari satu simpul antara sinkronisasi. Replikasi peer-to-peer tidak mendukung konflik data; perubahan data harus dipartisi. Terlepas dari jenis replikasi yang digunakan, kami sarankan Anda mengubah partisi jika memungkinkan, karena ini mengurangi pemrosesan yang diperlukan untuk deteksi dan resolusi konflik.

Perubahan dapat dipartisi dengan menerbitkan subset data ke setiap Pelanggan atau dengan memiliki perubahan langsung aplikasi untuk baris tertentu ke simpul tertentu:
- Replikasi penggabungan mendukung penerbitan subset data menggunakan filter berparameter dengan satu publikasi. Untuk informasi selengkapnya, lihat Filter Baris Berparameter.
- Replikasi transaksional mendukung penerbitan subset data menggunakan filter statis dengan beberapa publikasi. Untuk informasi selengkapnya, lihat Memfilter Data yang Diterbitkan.
Gunakan filter baris secara yudisius.

Saat publikasi transaksi menyertakan satu atau beberapa artikel yang menggunakan filter baris, Agen Pembaca Log harus menerapkan filter ke setiap baris yang dipengaruhi oleh pembaruan ke tabel saat memindai log transaksi. Oleh karena itu, throughput Agen Pembaca Log terpengaruh.

Demikian pula, replikasi penggabungan harus mengevaluasi baris yang diubah atau dihapus untuk menentukan Pelanggan mana yang harus menerima baris tersebut. Saat filter baris digunakan untuk mengurangi data yang diperlukan pada Pelanggan, pemrosesan ini lebih kompleks dan bisa lebih lambat daripada saat Anda menerbitkan semua baris dalam tabel. Pertimbangkan dengan cermat tradeoff antara pengurangan persyaratan penyimpanan di setiap Pelanggan dan kebutuhan untuk mencapai throughput maksimum. Untuk informasi selengkapnya tentang pemfilteran, lihat Memfilter Data yang Diterbitkan.

Pertimbangan Langganan

Gunakan langganan penarikan saat ada sejumlah besar Pelanggan.

Agen Distribusi dan Agen Penggabungan berjalan di Distributor untuk langganan push, dan di Pelanggan untuk menarik langganan. Menggunakan langganan pull dapat meningkatkan performa dengan memindahkan pemrosesan agen dari Distributor ke Pelanggan. Untuk informasi selengkapnya, lihat Berlangganan Publikasi.
Pertimbangkan untuk menginisialisasi ulang langganan jika Pelanggan terlalu jauh di belakang.

Ketika sejumlah besar perubahan perlu dikirim ke Pelanggan, menginisialisasinya kembali dengan rekam jepret baru mungkin lebih cepat daripada menggunakan replikasi untuk memindahkan perubahan individual. Untuk informasi selengkapnya, lihat Menginisialisasi ulang Langganan.

Untuk replikasi transaksional, Monitor Replikasi menampilkan informasi pada tab Perintah yang Tidak Didistribusikan tentang: jumlah transaksi dalam database distribusi yang belum didistribusikan ke Pelanggan; dan perkiraan waktu untuk mendistribusikan transaksi ini. Untuk informasi selengkapnya, lihat Menampilkan informasi dan melakukan tugas menggunakan Monitor Replikasi.

Pertimbangan Rekam Jepret

Jalankan Agen Rekam Jepret hanya jika perlu dan pada waktu sibuk.

Agen Rekam Jepret menyalin data secara massal dari tabel yang diterbitkan di Publisher ke file di folder rekam jepret di Distributor. Menghasilkan rekam jepret dapat menjadi proses intensif sumber daya dan paling baik dijadwalkan selama waktu di luar puncak.
Gunakan rekam jepret mode asli kecuali rekam jepret mode karakter diperlukan.

Gunakan rekam jepret mode asli default untuk semua Pelanggan kecuali Pelanggan dan Pelanggan non-SQL Server yang menjalankan SQL Server Compact, yang memerlukan rekam jepret mode karakter.
Gunakan satu folder rekam jepret untuk publikasi.

Saat menentukan properti publikasi yang terkait dengan lokasi rekam jepret, Anda dapat memilih untuk membuat file rekam jepret ke folder rekam jepret default, ke folder rekam jepret alternatif, atau ke keduanya. Menghasilkan file rekam jepret di kedua lokasi memerlukan ruang disk tambahan dan lebih banyak pemrosesan saat Agen Rekam Jepret berjalan.
Tempatkan folder rekam jepret pada drive lokal ke Distributor yang tidak digunakan untuk menyimpan database atau file log.

Agen Rekam Jepret melakukan penulisan data berurutan ke folder rekam jepret. Menempatkan folder rekam jepret pada drive terpisah dari database atau file log apa pun mengurangi ketidakcocokan di antara disk dan membantu proses rekam jepret selesai lebih cepat.
Saat Anda membuat database langganan di Pelanggan, pertimbangkan untuk menentukan model pemulihan yang sederhana atau dicatat secara massal. Ini memungkinkan pengelogan minimal sisipan massal yang dilakukan selama aplikasi rekam jepret di Pelanggan. Setelah rekam jepret diterapkan ke database langganan, Anda dapat mengubah ke model pemulihan yang berbeda jika perlu (database yang direplikasi dapat menggunakan salah satu model pemulihan). Untuk informasi selengkapnya tentang memilih model pemulihan, lihat Gambaran Umum Pemulihan dan Pemulihan (SQL Server).
Pertimbangkan untuk menggunakan folder rekam jepret alternatif dan rekam jepret terkompresi pada media yang dapat dilepas untuk jaringan bandwidth rendah.

Mengompresi file rekam jepret di folder rekam jepret alternatif dapat mengurangi persyaratan penyimpanan disk rekam jepret dan mempermudah transfer file rekam jepret pada media yang dapat dilepas.

Rekam jepret terkompresi dapat, dalam beberapa kasus, meningkatkan performa mentransfer file rekam jepret di seluruh jaringan. Namun, mengompresi rekam jepret memerlukan pemrosesan tambahan oleh Agen Rekam Jepret saat membuat file rekam jepret, dan oleh Agen Distribusi atau Agen Penggabungan saat menerapkan file rekam jepret. Ini dapat memperlambat pembuatan rekam jepret dan meningkatkan waktu yang diperlukan untuk menerapkan rekam jepret dalam beberapa kasus. Selain itu, rekam jepret terkompresi tidak dapat dilanjutkan jika kegagalan jaringan terjadi; oleh karena itu mereka tidak cocok untuk jaringan yang tidak dapat diandalkan. Pertimbangkan tradeoff ini dengan hati-hati saat menggunakan rekam jepret terkompresi di seluruh jaringan. Untuk informasi selengkapnya, lihat Mengubah opsi rekam jepret.
Pertimbangkan untuk menginisialisasi langganan secara manual.

Dalam beberapa skenario, seperti yang melibatkan himpunan data awal besar, lebih baik menginisialisasi langganan menggunakan metode selain rekam jepret. Untuk informasi selengkapnya, lihat Menginisialisasi Langganan Transaksi tanpa Rekam Jepret.

Parameter Agen

Kurangi tingkat verbose agen replikasi kecuali selama pengujian awal, pemantauan, atau penelusuran kesalahan.

Kurangi parameter –HistoryVerboseLevel dan parameter –OutputVerboseLevel dari Agen Distribusi atau Agen Penggabungan. Ini mengurangi jumlah baris baru yang dimasukkan untuk melacak riwayat dan output agen. Sebaliknya, pesan riwayat sebelumnya dengan status yang sama diperbarui ke informasi riwayat baru. Tingkatkan tingkat verbose untuk pengujian, pemantauan, dan penelusuran kesalahan sehingga Anda memiliki informasi sebanyak mungkin tentang aktivitas agen.
Gunakan parameter –MaxBCPThreads dari Agen Rekam Jepret, Agen Penggabungan, dan Agen Distribusi (jumlah utas yang ditentukan tidak boleh melebihi jumlah prosesor di komputer). Parameter ini menentukan jumlah operasi penyalinan massal yang dapat dilakukan secara paralel saat rekam jepret dibuat dan diterapkan.
Gunakan parameter –UseInprocLoader dari Agen Distribusi dan Agen Penggabungan (parameter ini tidak dapat digunakan jika tabel yang diterbitkan menyertakan kolom XML). Parameter ini menyebabkan agen menggunakan perintah INSERT MASSAL saat rekam jepret diterapkan.

Parameter agen dapat ditentukan dalam profil agen dan pada baris perintah. Untuk informasi selengkapnya, lihat:

Bekerja dengan Profil Agen Replikasi
Lihat dan Ubah Parameter Prompt Perintah Agen Replikasi (SQL Server Management Studio)
Konsep Executable Agen Replikasi.

Share via