Sqlserver
 sql >> Teknologi Basis Data >  >> RDS >> Sqlserver

Pemecahan Masalah Replikasi Transaksional SQL Server

Replikasi Transaksional SQL Server adalah salah satu teknik Replikasi paling umum yang digunakan untuk menyalin atau mendistribusikan data ke berbagai tujuan.

Pada artikel sebelumnya, kita telah membahas Replikasi SQL Server, cara kerjanya secara internal, dan cara mengkonfigurasi Replikasi melalui Wisaya Replikasi atau pendekatan T-SQL. Sekarang, kami fokus pada masalah Replikasi SQL dan memecahkan masalah dengan benar.

Masalah Replikasi SQL

Mayoritas pelanggan yang menggunakan Replikasi Transaksional SQL Server terutama berfokus pada pencapaian data hampir waktu nyata yang tersedia di instans database Pelanggan. Oleh karena itu, DBA yang mengelola Replikasi harus menyadari berbagai kemungkinan masalah terkait Replikasi SQL yang mungkin muncul. Selain itu, DBA harus dapat menyelesaikan masalah ini dalam waktu singkat.

Kami dapat mengkategorikan semua masalah Replikasi SQL ke dalam kategori di bawah ini (berdasarkan pengalaman saya):

Masalah Konfigurasi

  • Ukuran Replikasi Teks Maksimum
  • Layanan Agen Server SQL tidak disetel untuk memulai mode Otomatis
  • Instance Replikasi yang Tidak Terpantau masuk ke status Langganan yang tidak diinisialisasi
  • Masalah umum dalam SQL Server

Masalah Izin

  • Masalah Izin Pekerjaan Agen Server SQL
  • Kredensial pekerjaan Agen Snapshot tidak dapat mengakses jalur Folder Snapshot
  • Kredensial pekerjaan Agen Pembaca Log tidak dapat terhubung ke database Penerbit/distribusi
  • Kredensial pekerjaan Agen Distribusi tidak dapat terhubung ke database distribusi/Pelanggan

Masalah Konektivitas

  • Server penerbit tidak ditemukan atau tidak dapat diakses
  • Server distribusi tidak ditemukan atau tidak dapat diakses
  • Server pelanggan tidak ditemukan atau tidak dapat diakses

Masalah Integritas Data

  • Kesalahan pelanggaran Kunci Utama atau Kunci Unik
  • Galat Baris Tidak Ditemukan
  • Kunci Asing atau kesalahan pelanggaran batasan lainnya

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

  • Database penerbit rusak
  • File Log Transaksi Penerbit rusak
  • Korupsi basis data distribusi
  • Database pelanggan rusak

Persiapan Lingkungan DEMO

Sebelum masuk ke detail tentang masalah Replikasi SQL, kita perlu mempersiapkan lingkungan kita untuk demo. Seperti yang telah dibahas di artikel saya sebelumnya, setiap perubahan data yang terjadi pada database Subscriber di Replikasi Transaksional tidak akan terlihat langsung ke database Publisher. Jadi, kami akan membuat modifikasi tertentu langsung di database Pelanggan untuk tujuan pembelajaran.

Harap berhati-hati dan jangan ubah apa pun di basis data Produksi. Ini akan berdampak pada integritas Data database Pelanggan. Saya akan mengambil skrip cadangan untuk setiap perubahan yang dilakukan dan akan menggunakan skrip tersebut untuk memperbaiki masalah Replikasi SQL.

Ubah 1 – Memasukkan Catatan ke dalam Tabel Person.ContactType

Sebelum memasukkan catatan ke dalam Person.ContacType tabel, mari kita lihat struktur tabel itu, beberapa batasan default, dan properti tambahan yang disunting dalam skrip di bawah ini:

CREATE TABLE [Person].[ContactType](
	[ContactTypeID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
	[Name] [dbo].[Name] NOT NULL,
	[ModifiedDate] [datetime] NOT NULL,
 CONSTRAINT [PK_ContactType_ContactTypeID] PRIMARY KEY CLUSTERED 
(
	[ContactTypeID] ASC
) ON [PRIMARY]
) ON [PRIMARY]
GO

Saya telah memilih tabel ini karena memiliki lebih sedikit kolom. Lebih nyaman untuk tujuan pengujian. Sekarang, mari kita periksa apa yang kita dapatkan tentang strukturnya:

  • ContactTypeId didefinisikan sebagai KOLOM IDENTITAS – ini akan menghasilkan nilai kunci utama secara otomatis dan BUKAN UNTUK REPLIKASI.
  • TIDAK UNTUK REPLICASI adalah properti khusus yang dapat digunakan pada berbagai jenis Objek seperti Tabel, Batasan seperti Batasan Kunci Asing, Batasan Periksa, Pemicu, dan kolom Identitas pada Penerbit atau Pelanggan saat menggunakan salah satu metodologi Replikasi saja. Ini memungkinkan DBA merencanakan atau mengimplementasikan Replikasi untuk memastikan bahwa fungsi tertentu berperilaku berbeda di Penerbit/Pelanggan saat menggunakan Replikasi.
  • Dalam kasus kami, kami menginstruksikan SQL Server untuk menggunakan nilai IDENTITY yang dihasilkan hanya pada database Publisher. Properti IDENTITY tidak boleh digunakan pada Person.ContactType tabel di database Pelanggan. Demikian pula, kita dapat memodifikasi Batasan atau Pemicu untuk membuatnya berperilaku berbeda saat Replikasi dikonfigurasi menggunakan opsi ini.
  • 2 kolom NOT NULL lainnya tersedia di tabel.
  • Tabel memiliki kunci utama yang ditentukan pada ContactTypeId . Sekedar mengingatkan, Primary key merupakan syarat wajib untuk Replication. Tanpanya di atas meja, kami tidak akan dapat mereplikasi artikel tabel.

Sekarang, mari MASUKKAN catatan sampel ke Orang .Jenis Kontak tabel di AdventureWorks_REPL basis data:

INSERT langsung di atas tabel akan gagal di database Pelanggan karena Properti Identitas dinonaktifkan hanya untuk Replikasi dengan opsi NOT FOR REPLICATION. Setiap kali kita melakukan operasi INSERT secara manual, kita masih perlu menggunakan opsi SET IDENTITY_INSERT seperti ini:

 SET IDENTITY_INSERT AdventureWorks_REPL.Person.ContactType ON;

 INSERT INTO AdventureWorks_REPL.Person.ContactType(ContactTypeID, Name, ModifiedDate)
 VALUES (21, 'Test Position', GETDATE())
SET IDENTITY_INSERT AdventureWorks_REPL.Person.ContactType OFF;

Setelah menambahkan opsi SET IDENTITY_INSERT, kita dapat berhasil INSERT record ke Person.ContactType tabel.

Mengeksekusi SELECT pada tabel menunjukkan record yang baru dimasukkan:

Kami telah menambahkan catatan baru hanya ke database Pelanggan yang tidak tersedia di database Publisher di Person.ContactType tabel.

Menjalankan SELECT pada tabel yang sama dari database Publisher tidak memperlihatkan catatan apa pun. Dengan demikian, setiap perubahan yang dilakukan pada basis data Pelanggan tidak direplikasi ke basis data Penerbit.

Ubah 2 – Menghapus 2 Catatan dari Tabel Person.ContactType

Kami tetap menggunakan Person.ContactType yang kami kenal meja. Sebelum menghapus record dari database Subscriber, kita harus memverifikasi apakah record tersebut ada di kedua Publisher dan Subscriber. Lihat di bawah:

Sekarang, kita dapat menghapus 2 ContactTypeId ini menggunakan pernyataan berikut:

DELETE FROM AdventureWorks_REPL.Person.ContactType
WHERE ContactTypeID IN (19,20)

Skrip di atas memungkinkan kita menghapus 2 catatan dari Person.ContactType tabel di database Pelanggan:

Kami memiliki referensi kunci Asing yang mencegah penghapusan 2 catatan ini dari Person.ContactType meja. Kami dapat menangani skenario ini dengan menonaktifkan batasan kunci Asing pada tabel anak untuk sementara. Scriptnya di bawah ini:

ALTER TABLE [Person].[BusinessEntityContact] NOCHECK CONSTRAINT [FK_BusinessEntityContact_ContactType_ContactTypeID];

Setelah kunci Asing dinonaktifkan, kami dapat menghapus catatan dengan sukses dari Person.ContactType tabel:

Ini juga telah memodifikasi batasan Referensi Kunci Asing di 2 tabel. Kami dapat mencoba mensimulasikan masalah Replikasi SQL berdasarkan skenario ini.

Dalam skenario kami saat ini, kami tahu bahwa Person.ContactType tabel tidak memiliki data yang disinkronkan di seluruh Penerbit dan Pelanggan.

Percayalah, di beberapa lingkungan Produksi, pengembang atau DBA melakukan beberapa perbaikan data pada basis data Pelanggan. seperti semua perubahan yang kami lakukan sebelumnya menyebabkan masalah integritas data di seluruh basis data Penerbit dan Pelanggan di tabel yang sama. Sebagai DBA, saya memerlukan mekanisme yang lebih sederhana untuk memverifikasi perbedaan semacam ini. Jika tidak, itu akan membuat hidup DBA menyedihkan.

Inilah solusi dari Microsoft yang memungkinkan kami untuk memverifikasi perbedaan data di seluruh tabel di Penerbit dan Pelanggan. Ya, Anda menebaknya dengan benar. Ini adalah utilitas TableDiff yang telah kita bahas di artikel sebelumnya.

Utilitas TableDiff

Utilitas TableDiff terutama digunakan di lingkungan Replikasi. Kami juga dapat menggunakannya untuk kasus lain di mana kami perlu membandingkan 2 tabel SQL Server untuk non-konvergensi. Kita dapat membandingkannya dan mengidentifikasi perbedaan antara 2 tabel ini. Kemudian utilitas membantu menyinkronkan Tujuan meja ke Sumber meja dengan membuat skrip INSERT/UPDATE/DELETE yang diperlukan.

TableDiff adalah program mandiri tablediff.exe yang diinstal secara default di C:\Program Files\Microsoft SQL Server\130\COM setelah kami menginstal Komponen Replikasi. Harap dicatat bahwa jalur default dapat bervariasi sesuai dengan parameter penginstalan SQL Server. Angka 130 di jalur menunjukkan versi SQL Server (SQL Server 2016). Oleh karena itu, ini akan bervariasi untuk setiap versi instalasi SQL Server yang berbeda.

Anda dapat mengakses utilitas TableDiff melalui Command Prompt atau hanya dari file batch. Utilitas tidak memiliki Wizard atau GUI mewah untuk digunakan. Sintaks rinci utilitas TableDiff ada di artikel MSDN. Artikel kami saat ini hanya berfokus pada beberapa opsi yang diperlukan.

Untuk Membandingkan 2 tabel menggunakan utilitas TableDiff, kita perlu memberikan detail wajib untuk tabel Sumber dan Tujuan, seperti Nama Server Sumber, Nama Database Sumber, Nama Skema Sumber, Nama Tabel Sumber, Nama Server Tujuan, Nama Database Tujuan, Tujuan Nama Skema, dan Nama Tabel Tujuan.

Mari kita coba menguji TableDiff dengan Person.ContactType tabel yang memiliki perbedaan antara Penerbit dan Pelanggan.

Buka Command prompt dan navigasikan ke jalur utilitas TableDiff (jika jalur tersebut tidak ditambahkan ke variabel Lingkungan).

Untuk melihat daftar semua parameter yang tersedia, ketik perintah “tablediff-?” untuk membuat daftar semua opsi dan parameter yang tersedia. Hasilnya di bawah ini:

Mari kita periksa Orangnya.ContactType tabel di seluruh database Penerbit dan Pelanggan kami dengan menjalankan perintah di bawah ini:

tablediff -sourceserver RRJ -sourcedatabase AdventureWorks -sourceschema Person -sourcetable ContactType -destinationserver RRJ -destinationdatabase AdventureWorks_REPL -destinationschema Person -destinationtable ContactType

Perhatikan bahwa saya belum memberikan pengguna sumber , sandi sumber , pengguna tujuan , dan sandi tujuan karena login Windows saya memiliki akses ke tabel. Jika Anda ingin menggunakan Kredensial SQL alih-alih Otentikasi Windows, parameter di atas wajib untuk mengakses tabel untuk perbandingan . Jika tidak, Anda akan menerima kesalahan.

Hasil eksekusi perintah yang benar:

Ini menunjukkan bahwa kita memiliki 3 perbedaan. Satu adalah catatan baru di database Tujuan, dan dua catatan tidak tersedia di database Tujuan.

Sekarang, mari kita lihat sekilas Lain-lain pilihan yang tersedia untuk utilitas TableDiff.

  • -et – mencatat ringkasan hasil ke tabel tujuan
  • -dt – menjatuhkan tabel tujuan hasil jika sudah ada
  • -f – menghasilkan skrip DML T-SQL dengan pernyataan INSERT/UPDATE/DELETE untuk membawa tabel Tujuan ke konvergensi dengan tabel Sumber.
  • -o – nama file keluaran jika opsi -f digunakan untuk menghasilkan file konvergensi.

Kami akan membuat file konvergensi dengan -f dan -o opsi untuk perintah kami sebelumnya:

tablediff -sourceserver RRJ -sourcedatabase AdventureWorks -sourceschema Person -sourcetable ContactType -destinationserver RRJ -destinationdatabase AdventureWorks_REPL -destinationschema Person -destinationtable ContactType -f -o C:\PersonContactType.sql

File konvergensi berhasil dibuat:

Seperti yang Anda lihat, pembuatan file baru di folder root drive C:tidak diizinkan karena alasan keamanan. Oleh karena itu, ini menunjukkan pesan kesalahan dan membuat file output DIFFIX.*.sql file di folder utilitas TableDiff. Saat kita membuka file tersebut, kita dapat melihat detail di bawah ini:

Skrip INSERT dibuat untuk 2 catatan yang dihapus, dan skrip DELETE dibuat untuk catatan yang baru dimasukkan ke dalam database Pelanggan. Alat ini juga memperhatikan penggunaan opsi IDENTITY_INSERT seperti yang diperlukan untuk Tujuan meja. Oleh karena itu, alat ini akan sangat berguna setiap kali DBA perlu menyinkronkan dua tabel.

Dalam kasus kami, saya tidak akan menjalankan skrip, karena kami membutuhkan varians ini untuk mensimulasikan masalah Replikasi SQL kami.

Keuntungan Utilitas TableDiff

  • TableDiff adalah utilitas gratis yang hadir sebagai bagian dari instalasi komponen SQL Server Replication yang akan digunakan untuk perbandingan atau konvergensi tabel.
  • Skrip pembuatan konvergensi dapat dibuat tanpa intervensi manual.

Batasan Utilitas TableDiff

  • Utilitas TableDiff hanya dapat dijalankan dari command prompt atau file batch.
  • Dari command prompt, Anda hanya dapat melakukan satu perbandingan tabel pada satu waktu, kecuali Anda memiliki beberapa command prompt yang dibuka secara paralel untuk membandingkan beberapa tabel.
  • Tabel Sumber yang perlu Anda bandingkan menggunakan utilitas TableDiff memerlukan Kunci Utama atau kolom Identitas yang ditentukan, atau kolom ROWGUID yang tersedia untuk melakukan perbandingan baris demi baris. Jika -ketat digunakan, tabel Tujuan juga memerlukan kunci Utama, atau kolom Identitas, atau kolom ROWGUID yang tersedia.
  • Jika tabel Sumber atau tujuan berisi sql_variant kolom tipe data, Anda tidak dapat menggunakan utilitas TableDiff untuk membandingkannya.
  • Masalah kinerja dapat diketahui saat menjalankan utilitas TableDiff pada tabel yang berisi catatan besar, karena akan melakukan perbandingan baris demi baris pada tabel ini.
  • Skrip konvergensi yang dibuat oleh utilitas TableDiff tidak menyertakan kolom tipe data karakter BLOB, seperti varchar(max) , nvarchar(maks) , varbinary(maks) , teks , nteks , atau gambar kolom, dan xml atau stempel waktu kolom. Oleh karena itu, Anda memerlukan pendekatan alternatif untuk menangani tabel dengan kolom tipe data ini.

Namun, bahkan dengan keterbatasan ini, utilitas TableDiff dapat digunakan di semua tabel SQL Server untuk verifikasi data cepat atau pemeriksaan konvergensi. Namun, Anda juga dapat membeli alat pihak ketiga yang bagus.

Sekarang, mari kita pertimbangkan berbagai masalah Replikasi SQL secara mendetail.

Masalah Konfigurasi

Dari pengalaman saya, saya telah mengkategorikan opsi Konfigurasi Replikasi yang sering terlewatkan yang dapat menyebabkan masalah Replikasi SQL yang kritis sebagai Konfigurasi masalah. Beberapa di antaranya ada di bawah ini.

Ukuran Replikasi Teks Maks

Ukuran Repl Teks Maks mengacu pada Ukuran Replikasi Teks Maksimum dalam byte . Ini berlaku untuk semua tipe data seperti char(max), nvarchar(max), varbinary(max), teks, ntext, varbinary, xml, dan gambar .

SQL Server memiliki opsi default untuk membatasi panjang kolom tipe data string maksimum (dalam byte) untuk direplikasi sebagai 65536 byte.

Kita perlu mengevaluasi Ukuran Repl Teks Maks dengan hati-hati setiap kali Replikasi dikonfigurasi untuk database. Untuk itu, kita harus memeriksa semua kolom tipe data di atas dan mengidentifikasi kemungkinan byte maksimum yang akan ditransfer melalui Replikasi.

Mengubah nilai ke -1 menunjukkan bahwa tidak ada batasan. Namun, kami menyarankan Anda mengevaluasi panjang string maksimum dan mengonfigurasi nilai tersebut.

Kita dapat mengonfigurasi Max Text Repl Size menggunakan SSMS atau T-SQL.

Di SSMS, klik kanan pada nama Server> Properti > Lanjutan :

Cukup klik 65536 untuk memodifikasinya. Untuk pengujian, saya telah mengubah 65536 menjadi 1000000 dan mengeklik OK :

Untuk mengonfigurasi opsi Ukuran Repl Teks Maks melalui T-SQL, buka jendela kueri baru dan jalankan skrip di bawah ini terhadap database master:

EXEC sys.sp_configure N'max text repl size (B)', N'-1'
GO
RECONFIGURE WITH OVERRIDE
GO

Kueri ini akan memungkinkan Replikasi untuk tidak membatasi ukuran kolom tipe data di atas.

Untuk memverifikasi, kita dapat melakukan SELECT pada sys.configurations DMV dan periksa value_in_use kolom seperti di bawah ini:

Layanan Agen Server SQL Tidak Disetel untuk Memulai Mode Otomatis

Replikasi bergantung pada Agen Replikasi yang dijalankan sebagai pekerjaan Agen Server SQL. Oleh karena itu, masalah apa pun dengan beberapa Layanan Agen Server SQL akan berdampak langsung pada fungsionalitas Replikasi.

Kita perlu memastikan bahwa Mode Mulai SQL Server dan Layanan Agen Server SQL diatur ke Otomatis. Jika diatur ke Manual, kita harus mengonfigurasi beberapa peringatan. Mereka akan memberi tahu DBA atau Admin Server untuk memulai Layanan Agen Server SQL saat Server memulai ulang yang direncanakan atau tidak.

Jika tidak dilakukan, Replikasi mungkin tidak berjalan untuk waktu yang lama, yang juga mempengaruhi pekerjaan Agen Server SQL lainnya.

Instance Replikasi yang Tidak Terpantau Masuk ke Status Langganan yang Tidak Diinisialisasi

Mirip dengan memantau Layanan Agen Server SQL, mengonfigurasi Layanan Surat Basis Data dalam setiap contoh SQL Server memainkan peran penting dalam memperingatkan DBA atau orang yang dikonfigurasi pada waktu yang tepat. Untuk kegagalan atau masalah pekerjaan apa pun, pekerjaan Agen Server SQL seperti Agen Pembaca Log atau Agen Distribusi dapat dikonfigurasi untuk mengirim peringatan ke DBA atau anggota tim masing-masing melalui email. Kegagalan eksekusi pekerjaan Agen Replikasi dapat menyebabkan skenario di bawah ini:

Non-eksekusi Tugas Agen Pembaca Log . File Log Transaksi dari database Publisher hanya akan digunakan kembali setelah perintah ditandai untuk Replikasi dibaca oleh Agen Pembaca Log dan berhasil dikirim ke database distribusi. Jika tidak, log_reuse_wait_desc kolom sys.databases akan menampilkan nilai sebagai Replikasi, yang menunjukkan bahwa log database tidak dapat digunakan kembali hingga berhasil mentransfer perubahan ke database distribusi. Oleh karena itu, non-eksekusi agen Pembaca Log akan terus meningkatkan ukuran file Log Transaksional dari database Publisher, dan kami akan mengalami masalah kinerja selama Full Backup, atau masalah ruang disk pada instans database Publisher.

Non-eksekusi Pekerjaan Agen Distribusi. Pekerjaan Agen Distribusi membaca data dari database distribusi dan mengirimkannya ke database Pelanggan. Kemudian menandai catatan tersebut untuk dihapus dalam database distribusi. Jika pekerjaan Agen Distribusi tidak dijalankan, itu akan meningkatkan ukuran database distribusi yang menyebabkan masalah kinerja pada kinerja Replikasi secara keseluruhan. Secara default, database distribusi dikonfigurasi untuk menyimpan rekaman hingga maksimum 0-72 jam seperti yang diperlihatkan dalam properti Retensi Transaksi di bawah ini. Jika Replikasi gagal selama lebih dari 72 jam, langganan terkait akan ditandai sebagai belum diinisialisasi, yang memaksa kami untuk mengonfigurasi ulang Langganan atau membuat cuplikan baru agar Replikasi berfungsi kembali.

Non-eksekusi pembersihan Distribusi:tugas distribusi . Pekerjaan pembersihan Distribusi bertanggung jawab untuk menghapus semua rekaman yang direplikasi dari database distribusi untuk menjaga agar ukuran database distribusi tetap terkendali. Non-eksekusi pekerjaan ini menyebabkan peningkatan ukuran database distribusi yang mengakibatkan masalah kinerja Replikasi.

Untuk memastikan bahwa kami tidak menemukan salah satu dari masalah yang tidak terpantau ini, Database Mail harus dikonfigurasi untuk melaporkan semua kegagalan pekerjaan atau mencoba kembali ke masing-masing anggota tim untuk tindakan cepat.

Masalah Umum dalam SQL Server

Versi SQL Server tertentu telah mengetahui masalah replikasi di versi RTM atau versi sebelumnya. Masalah ini telah diperbaiki di Paket Layanan atau paket CU berikutnya. Oleh karena itu, disarankan untuk menerapkan paket Layanan atau paket CU terbaru setelah tersedia untuk semua SQL Server setelah mengujinya di lingkungan QA. Meskipun ini adalah rekomendasi umum untuk server yang menjalankan SQL Server, ini juga berlaku untuk Replikasi.

Masalah Izin

Dalam lingkungan dengan Replikasi Transaksional SQL Server yang dikonfigurasi, kami dapat sering mengamati masalah Izin. Kami mungkin menghadapinya selama waktu konfigurasi Replikasi atau aktivitas Pemeliharaan apa pun pada Penerbit, atau Distributor, atau instans basis data Pelanggan. Ini menghasilkan kredensial atau izin yang hilang. Sekarang mari kita amati beberapa masalah izin yang sering terjadi terkait dengan Replikasi.

Masalah Izin Pekerjaan Agen Server SQL

Semua agen Replikasi menggunakan pekerjaan Agen Server SQL. Setiap pekerjaan Agen Server SQL yang terkait dengan Snapshot atau Agen Pembaca Log, atau Distribusi dijalankan di bawah beberapa kredensial Windows atau Login SQL seperti yang ditunjukkan di bawah ini:

Untuk memulai pekerjaan Agen Server SQL, Anda harus memiliki SQLAgentOperatorRole untuk memulai semua pekerjaan atau SQLAgentUserRole atau SQLAgentReaderRole untuk memulai pekerjaan yang Anda miliki. Jika ada pekerjaan yang tidak dapat dimulai dengan benar, periksa apakah pemilik pekerjaan memiliki hak yang diperlukan untuk melaksanakan pekerjaan tersebut.

Kredensial Pekerjaan Agen Snapshot Tidak Dapat Mengakses Jalur Folder Snapshot

Dalam artikel kami sebelumnya, kami melihat bahwa eksekusi agen Snapshot akan membuat snapshot artikel di jalur folder lokal atau bersama untuk disebarkan ke database Pelanggan melalui agen Distribusi. Lokasi jalur Snapshot dapat diidentifikasi di bawah Properti Publikasi > Snapshot :

Jika agen Snapshot tidak memiliki akses ke lokasi file Snapshot ini, kami mungkin menerima kesalahan:

Akses ke jalur 'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\repldata\unc\XXXX\YYYYMMDDHHMISS\' ditolak.

Untuk mengatasi masalah ini, lebih baik berikan akses lengkap ke jalur folder C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\repldata\unc\ untuk akun tempat Agen Snapshot dijalankan. Dalam konfigurasi kami, kami menggunakan akun Agen Server SQL, dan Layanan Agen Server SQL berjalan di bawah akun RRJ\RRJ.

Kredensial Tugas Agen Pembaca Log Tidak Dapat Terhubung ke Basis Data Penerbit/Distribusi

Agen Pembaca Log terhubung ke database Publisher untuk menjalankan sp_replcmds prosedur untuk memindai transaksi yang ditandai untuk Replikasi dari log Transaksi dari database Publisher.

Jika pemilik database database Publisher tidak disetel dengan benar, kami mungkin menerima kesalahan berikut:

Proses tidak dapat mengeksekusi 'sp_replcmds' di 'RRJ.

Atau

Tidak dapat dijalankan sebagai prinsipal database karena prinsip "dbo" tidak ada, jenis prinsipal ini tidak dapat ditiru, atau Anda tidak memiliki izin.

Untuk mengatasi masalah ini, pastikan bahwa properti pemilik database dari database Publisher diatur ke sa atau akun lain yang valid (lihat di bawah).

Klik kanan pada Penerbit basis data (AdventureWorks )> Properti > File . Pastikan bahwa Pemilik bidang disetel ke sa atau info masuk yang valid dan tidak kosong .

Jika ada masalah izin yang terjadi saat kami terhubung ke Publisher atau database distribusi, periksa kredensial yang digunakan untuk Agen Pembaca Log dan beri mereka izin untuk mengakses database tersebut.

Kredensial Pekerjaan Agen Distribusi Tidak Dapat Terhubung ke Database Distribusi/Pelanggan

Agen Distribusi mungkin memiliki masalah izin jika akun tidak diizinkan untuk mengakses database distribusi atau menyambung ke database Pelanggan. Dalam hal ini, kita mungkin mendapatkan kesalahan berikut:

Tidak dapat memulai eksekusi langkah 2 (alasan:Kesalahan mengautentikasi proxy RRJ\RRJ, kesalahan sistem:Nama pengguna atau sandi salah.)

Proses tidak dapat terhubung ke Subscriber ‘RRJ.

Login gagal untuk pengguna 'RRJ\RRJ'.

Untuk mengatasinya, periksa akun yang digunakan di Properti Langganan dan pastikan akun tersebut memiliki izin yang diperlukan untuk terhubung ke database Distribusi atau Pelanggan.

Masalah Konektivitas

Kami biasanya mengonfigurasi Replikasi Transaksional di seluruh server dalam jaringan yang sama atau di seluruh lokasi yang terdistribusi secara geografis. Jika basis data distribusi terletak di server khusus selain dari Penerbit atau Pelanggan, basis data tersebut menjadi rentan terhadap kehilangan paket jaringan – masalah konektivitas.

Dalam kasus masalah seperti itu, agen Replikasi (Pembaca Log atau Agen Distribusi) dapat melaporkan kesalahan di bawah ini:

Server penerbit tidak ditemukan atau tidak dapat diakses

Server distribusi tidak ditemukan atau tidak dapat diakses

Server pelanggan tidak ditemukan atau tidak dapat diakses

Untuk memecahkan masalah ini, kami mungkin mencoba menghubungkan ke Publisher, Distributor, atau database Pelanggan di SSMS untuk memeriksa apakah kami dapat terhubung ke instance SQL Server ini tanpa masalah atau tidak.

Jika masalah konektivitas sering terjadi, kami dapat mencoba melakukan ping ke server secara terus menerus untuk mengidentifikasi paket yang hilang. Selain itu, kami harus bekerja dengan anggota tim yang diperlukan untuk menyelesaikan masalah tersebut dan mengaktifkan server agar Replikasi dapat melanjutkan transfer data.

Masalah Integritas Data

Karena Replikasi Transaksional adalah mekanisme satu arah, setiap perubahan data yang terjadi pada Pelanggan (secara manual atau dari aplikasi) tidak akan tercermin pada Penerbit. Hal ini dapat menyebabkan perbedaan data di seluruh Penerbit dan Pelanggan.

Mari kita tinjau masalah yang terkait dengan Integritas Data dan lihat cara mengatasinya. Perhatikan bahwa kami telah memasukkan catatan ke dalam Person.ContactType tabel dan menghapus 2 catatan dari Person.ContactType tabel di database Pelanggan. Kami akan menggunakan 3 catatan ini untuk menemukan kesalahan.

Kesalahan Pelanggaran Kunci Utama atau Kunci Unik

Saya akan menguji catatan INSERT pada Person.ContactType meja. Mari masukkan catatan itu ke dalam database Publisher dan lihat apa yang terjadi:

Luncurkan Replication Monitor untuk melihat bagaimana kelanjutannya. Kami mendapatkan kesalahan:

Memperluas Penerbit dan Publikasi , kami mendapatkan detail berikut:

Jika kami telah mengonfigurasi Peringatan Replikasi dan menetapkan orang masing-masing untuk menerima peringatan email mereka, kami akan menerima pemberitahuan email yang sesuai dengan pesan kesalahan:Tidak dapat menyisipkan baris kunci duplikat di objek 'Person.ContactType' dengan indeks unik 'AK_ContactType_Name ' . Nilai kunci duplikat adalah (Tes Posisi). (Sumber:MSSQLServer, Nomor kesalahan:2601)

Untuk mengatasi masalah terkait Pelanggaran kunci unik atau masalah Kunci utama, kami memiliki beberapa opsi:

  • Analisis mengapa kesalahan ini terjadi, bagaimana catatan tersedia di database Pelanggan, dan siapa yang memasukkannya untuk alasan apa. Identifikasi apakah perlu atau tidak.
  • Tambahkan kesalahan lompat parameter ke profil Agen Distribusi untuk melewati Nomor Kesalahan 2601 atau Nomor Kesalahan 2627 jika terjadi pelanggaran Kunci Utama.

Dalam kasus kami, kami sengaja memasukkan data untuk menerima kesalahan ini. Untuk menangani masalah ini, hapus rekaman yang disisipkan secara manual untuk melanjutkan replikasi perubahan yang diterima dari Penerbit.

DELETE from Person.ContactType
where ContactTypeID = 21

Untuk mempelajari opsi lain dan untuk membandingkan perbedaan antara kedua pendekatan ini, saya melewatkan opsi pertama (yang efisien dan disarankan) dan melanjutkan ke opsi kedua dengan menambahkan -skiperrors parameter ke tugas Agen Distribusi.

Kita dapat menerapkannya dengan mengedit Tugas Agen Distribusi > Langkah > klik 2 Langkah Pekerjaan bernama Jalankan Agen > klik Edit untuk melihat perintah yang tersedia:

Sekarang, tambahkan -SkipErrors 2601 kata kunci di akhir (2601 adalah nomor kesalahan – kita dapat melewati nomor kesalahan yang diterima sebagai bagian dari Replikasi) dan klik OK .

To make sure that the Distribution job is aware of this configuration change, we need to restart the Distribution agent job. For that, stop it and start again from Step 1 as shown below:

The Replication Monitor displays that one of the error records is skipped from the Replication, that started working fine.

Since the Replication issue is resolved successfully, we’d recommend removing the -SkipErrors parameter from the Distribution Agent job. Then, restart the job to get the changes reflected.

Thus, we’ve fixed the replication issue, but let’s compare the data across the same Person.ContactType in the Publisher and Subscriber databases. The results show the data variance, or the data integrity issue :

ModifiedDate is different across the Publisher and Subscriber databases. It happens because the data in the Subscriber database was inserted earlier (when we were preparing the test data), and the data in the Publisher database has just been inserted.

If we deleted the record from the Subscriber database, the record from the Publisher would have been inserted to match the data across the Publisher and the Subscriber databases.

Most of the newbie DBAs simply add the -SkipErrors option to get the replication working immediately without detailed investigations of the issue. Hence, it is recommended not to use the -SkipErrors option as a primary solution without proper examination of the problem. The Person.ContactType table had only 3 columns. Assume that the table has over 20 columns. Then, we have just screwed up the Data integrity of this table with that -SkipErrors perintah.

We used this approach just to illustrate the usage of that option. The best way is to examine and clarify the reason for variance and then perform the appropriate DELETE statements on the Subscriber database to maintain the Data Integrity across the Publisher and Subscriber databases.

Row Not Found Errors

Let’s try to perform an UPDATE on one of the records that were deleted from the Subscriber database:

Let’s check the Replication Monitor to see the performance. We have the following error:

The row was not found at the Subscriber when applying the replicated UPDATE command for Table ‘[Person].[ContactType]’ with Primary Key(s):[ContactTypeID] =19 (Source:MSSQLServer, Error number:20598).

There are two ways to resolve this error. First, we can use -SkipErrors for Error Number 20598 . Or, we can INSERT the record with ContactTypeID =19 (shown in the error message) to get the data changes reflected.

If we skip this error, we’ll lose the record with ContactTypeId =19 from the Subscriber database permanently. It can cause data inconsistency issues. Hence, we aren’t going to use the -SkipErrors pilihan. Instead, we’ll apply the INSERT approach.

The Replication resumes correctly by sending the UPDATE to the Subscriber database.

It is the same when we try to delete the ContactTypeId =20 from the Publisher database and see the error popping up in the Replication Monitor.

The Replication Monitor shows us a message similar to the one we already noticed:

The row was not found at the Subscriber when applying the replicated DELETE command for Table ‘[Person].[ContactType]’ with Primary Key(s):[ContactTypeID] =20 (Source:MSSQLServer, Error number:20598)

Similar to the previous error, we need to identify the missing record and insert it back to the Subscriber database for the DELETE statement to get replicated properly. For DELETE scenario, using -SkipErrors doesn’t have any issues but can’t be considered as a safe option, as both missing UPDATE or missing DELETE record are captured with the same error number 20598 and adding -SkipErrors 20598 will skip applying all records from the Subscriber database.

We can also get more details about the problematic command by using the sp_browsereplcmds stored procedure which we have discussed earlier as well. Let’s try to use sp_browsereplcmds stored procedure for the previous error we have received out as shown below.

exec sp_browsereplcmds @xact_seqno_start = '0x000000A500001160000600000000'
			, @xact_seqno_end = '0x000000A500001160000600000000'
			, @publisher_database_id = 1
			, @command_id = 1

@xact_seqno_start and @xact_seqno_end will be the same value. We can fetch that value from the Transaction Sequence number in the Replication Monitor along with Command ID.

@publisher_database_id can be fetched from the id column of the distribution..MSPublisher_databases DMV.

select * from MSpublisher_databases

Foreign Key or Other Constraint Violation Errors

The error messages related to Foreign keys or any other data issues are slightly different. Microsoft has made these error messages detailed and self-explanatory for anyone to understand what the issue is about.

To identify the exact command that was executed on the Publisher and resolve it efficiently, we can use the sp_browsereplcmds procedure explained above and identify the root cause of the issue.

Once the commands are identified as INSERT/UPDATE/DELETE which caused the errors, we can take corresponding actions to resolve the problems correctly which is more efficient compared to simply adding -SkipErrors approach. Once corrective measures are taken, Replication will start resuming fine immediately.

Word of Caution Using -SkipErrors Option

Those who are comfortable using -SkipErrors option to resolve error quickly should remember that -SkipErrors option is added at the Distribution agent level and applies to all Published articles in that Publication. Command -SkipErrors will result in skipping any number of commands related to that particular error across all published articles any number of times resulting in discrepancies we have seen in demo resulting in data discrepancies across Publisher and Subscriber without knowing how many tables are having discrepancies and would require efforts to compare the tables and fix it out.

Kesimpulan

Thanks for going through another robust article. I hope it was helpful for you to understand the SQL Server Transactional Replication issues and methods of troubleshooting them. In our next article, we’ll continue the discussion about the SQL Transaction Replication issues, examine other types, such as Corruption-related issues, and learn the best methods of handling them.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. MASUKKAN MASSAL dengan kolom identitas (kenaikan otomatis)

  2. Gunakan OBJECTPROPERTY() untuk Menentukan Apakah Objek adalah Tampilan di SQL Server

  3. Apa cara terbaik untuk memilih nilai minimum dari beberapa kolom?

  4. CROSS JOIN vs INNER JOIN dalam SQL

  5. Bagaimana cara memperbarui Kolom Identitas di SQL Server?