Internal Replikasi Transaksional SQL Server

Replikasi Transaksional SQL Server adalah salah satu teknik Replikasi yang paling umum digunakan untuk berbagi, menyalin, atau mendistribusikan data ke beberapa tujuan. Pada artikel ini, kita akan membahas Replikasi, Berbagai Jenis Replikasi, dan memberikan perhatian khusus pada pekerjaan Replikasi Transaksional.

Apa itu Replikasi Transaksional SQL?

Replikasi adalah teknologi SQL Server untuk Menyalin atau Mendistribusikan data dari satu database ke database lain dengan tetap menjaga konsistensi Data.

Replikasi dapat digunakan untuk mentransfer data dari satu database ke database lain

• pada instance yang sama atau instance lain di server yang sama;
• atau di seluruh Server di satu lokasi atau beberapa lokasi.

Pertama, kita harus mempelajari Arsitektur Replikasi dan memahami terminologi Replikasi.

Arsitektur &Terminologi Replikasi SQL Server

• Penerbit adalah contoh Database Sumber yang menerbitkan perubahan data yang dapat didistribusikan ke database lain. Data dari Penerbit Tunggal dapat dikirim ke Pelanggan Tunggal atau beberapa Pelanggan .
• Pelanggan adalah Instans Basis Data Tujuan tempat kami mendistribusikan perubahan data yang diambil dari Basis Data Penerbit. Pelanggan dapat berupa Instans Penerbit atau instans lain di Server Penerbit/ Server lain di lokasi yang sama/lokasi yang jauh. Sebelum perubahan data didistribusikan ke instance Database Pelanggan, data ini disimpan di Distributor .
• Distributor adalah Database yang menyimpan log perubahan yang diambil dari database Publisher. Ketika Server diaktifkan sebagai Distributor, itu akan membuat Database sistem bernama database distribusi .

Berdasarkan lokasi database distribusi, mereka dapat diklasifikasikan sebagai distributor lokal atau distributor jarak jauh.

– Distributor Lokal adalah database distribusi yang berada di instans database Publisher.
– Distributor Jarak Jauh adalah database distribusi yang berada di instans database Pelanggan atau di instans SQL Server lainnya selain dari instans database Publisher.

Faktor penentunya adalah di mana menempatkan database Distribusi pada instans Publisher (instance lain). itu tergantung pada sumber daya Server yang tersedia untuk menangani beban Distribusi Data.

Menurut cara bagaimana data akan dikirim dari database Distribusi ke instance Pelanggan, data tersebut dapat diklasifikasikan menjadi Push atau Tarik Langganan .

– Langganan Dorong berarti bahwa database Distribusi bertanggung jawab untuk mendorong data ke instans database Pelanggan.
– Tarik Langganan berarti instans database Pelanggan bertanggung jawab untuk menarik data yang tersedia dari database Distribusi dan menerapkannya ke database Pelanggan.

• Artikel adalah unit dasar Replikasi. Ini menunjukkan setiap perubahan data pada objek atau artikel database ini yang akan direplikasi dari Publisher ke Subscriber. Artikel dapat berupa Tabel, Tampilan, Tampilan Terindeks, Prosedur Tersimpan, atau Fungsi Buatan Pengguna.
• Publikasi adalah kumpulan dari satu atau lebih Artikel dari database di Publisher.
• Langganan mendefinisikan Publikasi apa yang akan diterima. Juga, ini menentukan dari Publikasi mana dan pada jadwal apa data direplikasi. Berlangganan dapat berupa Push atau Pull (dari Publikasi ke Langganan).
• Agen Replikasi adalah program mandiri yang bertanggung jawab untuk melacak perubahan dan mendistribusikan data di seluruh Penerbit ke Distributor dan Pelanggan. Semua Agen Replikasi dijalankan sebagai Pekerjaan di bawah Agen SQL Server. Dengan demikian, dapat dikelola melalui SSMS di bawah Pekerjaan Agen Server SQL atau Monitor Replikasi. Jenis Agen Replikasi berikut tersedia:
• Agen Snapshot – Digunakan oleh hampir semua jenis Replikasi. Agen Snapshot berjalan dari Server yang memegang database distribusi. Ini menyiapkan Skema dan data awal dari semua Artikel yang termasuk dalam Publikasi di Penerbit. Selain itu, ia membuat file Snapshot dalam folder snapshot dan mencatat detail Sinkronisasi dalam database Distribusi.
• Agen Pembaca Log – Digunakan oleh Replikasi Transaksional. Tujuannya adalah untuk membaca perubahan data artikel yang diaktifkan untuk Replikasi dari Log Transaksi Basis Data Penerbit dan disimpan ke Basis Data Distribusi. Agen Pembaca Log dijalankan dari Server Distributor.
• Agen Distribusi – Digunakan oleh Replikasi Transaksional dan Snapshot. Ini menerapkan file Snapshot awal dan transaksi tertunda tambahan atau yang tersedia dari database Distribusi ke database Pelanggan. Agen Distribusi berjalan dari Server Distributor untuk Langganan Push dan Server Pelanggan untuk Langganan Pull.
• Gabungkan Agen – Digunakan hanya dengan Merge Replication. Ini menerapkan file snapshot awal dan rekonsiliasi perubahan diferensial atau inkremental di seluruh Penerbit atau Pelanggan. Agen Penggabungan berjalan di Server Distributor untuk Replikasi Push dan dari Server Pelanggan untuk Langganan Tarik.
• Agen Pembaca Antrian – Agen Pembaca Antrian digunakan oleh Replikasi Transaksional dengan opsi pembaruan yang antri. Ini memindahkan perubahan dari Pelanggan ke Penerbit. Agen Pembaca Antrian dijalankan dari Server Distributor.
• Pekerjaan Pemeliharaan Replikasi – Seperti yang dijelaskan sebelumnya, semua Agen Replikasi adalah program mandiri yang disiapkan saat mengonfigurasi Replikasi. Mereka berjalan sebagai pekerjaan di bawah Pekerjaan Agen Server SQL. Beberapa pekerjaan penting yang perlu diperhatikan adalah Pembersihan Distribusi:Distribusi, Pembersihan Riwayat Agen:Distribusi, dan Pembersihan Langganan yang Kedaluwarsa.

Jenis Replikasi di SQL Server

Sekarang setelah kita mengetahui terminologinya, mari selami jenis-jenis Replikasi.

1. Replikasi Transaksional . Seperti namanya, setiap transaksi atau perubahan data dalam lingkup transaksi di Penerbit akan dikirim ke Pelanggan hampir secara real-time dengan penundaan kecil tergantung pada bandwidth jaringan dan sumber daya server. Replikasi Transaksional menggunakan Agen Pembaca Log untuk membaca perubahan data dari Log Transaksi dari database Publisher. Itu juga menggunakan Agen Distribusi untuk menerapkan perubahan pada Pelanggan. Kadang-kadang mungkin menggunakan Agen Snapshot untuk mengambil data Snapshot awal dari semua artikel yang direplikasi. Publikasi Replikasi Transaksional dapat termasuk dalam kategori di bawah ini:
   • Replikasi Transaksional Standar – Pelanggan adalah database read-only dari perspektif Replikasi Transaksional. Perubahan apa pun yang dilakukan oleh siapa pun di basis data Pelanggan tidak akan dilacak dan diperbarui ke Basis Data Penerbit. Replikasi Transaksional Standar sering disebut sebagai Replikasi Transaksional.
   • Replikasi Transaksional dengan Langganan yang Dapat Diperbarui merupakan Penyempurnaan Replikasi Transaksional Standar yang melacak perubahan data yang terjadi pada Langganan. Setiap kali perubahan data dimulai pada Langganan yang Dapat Diperbarui, perubahan tersebut pertama-tama akan disebarkan ke Penerbit dan kemudian ke Pelanggan lain.
   • Replikasi Peer-to-Peer merupakan Penyempurnaan dari Replikasi Transaksional Standar. Ini menyebarkan perubahan yang konsisten secara transaksional hampir secara real-time di beberapa instance server.
   • Replikasi Dua Arah adalah Peningkatan dari Replikasi Transaksional Standar yang memungkinkan dua server (dibatasi hanya 2 Server dan karenanya dinamai Bidirectional) untuk bertukar perubahan data satu sama lain dengan server mana pun yang bertindak sebagai Penerbit (untuk mengirim perubahan ke Server lain) atau sebagai Pelanggan (untuk menerima perubahan dari server lain).
2. Gabungkan Replikasi – Mendukung pengambilan perubahan data yang terjadi di Penerbit dan Pelanggan dan mendistribusikannya ke Server lain. Replikasi Gabung membutuhkan ROWGUID kolom pada Tabel Artikel yang terlibat dalam Merge Replication. Ini menggunakan Pemicu untuk menangkap perubahan data di seluruh Penerbit dan Pelanggan. Juga, ini memberikan perubahan di seluruh Server saat Penerbit dan Pelanggan terhubung ke jaringan. Gabungkan Replikasi menggunakan Agen Penggabungan untuk mereplikasi perubahan data di seluruh Penerbit dan Pelanggan.
3. Replikasi Snapshot – Seperti namanya, Replikasi Snapshot tidak bergantung pada Log Transaksional atau Pemicu untuk menangkap perubahan. Ini mengambil snapshot dari artikel yang terlibat dalam Publikasi dan menerapkannya ke Pelanggan dengan catatan yang tersedia pada saat snapshot. Replikasi Snapshot menggunakan Agen Snapshot untuk mengambil snapshot dari Penerbit dan menggunakan Agen Distribusi untuk menerapkan catatan ini ke Pelanggan.

Replikasi Transaksional SQL Server

Replikasi Transaksional biasanya lebih disukai dalam skenario di mana database OLTP Publisher memiliki aktivitas INSERT/UPDATE dan/atau DELETE Data yang berat.

Karena instance server Publisher memiliki DISK IO yang besar, membuat Laporan dapat menyebabkan pemblokiran yang parah. Itu juga dapat memengaruhi kinerja Server. Oleh karena itu, Server lain dengan data hampir real-time baik untuk membongkar persyaratan Pelaporan.

Salah satu persyaratan mendasar untuk Replikasi Transaksional adalah tabel yang direplikasi harus memiliki Kunci Utama yang tersedia.

Kami dapat meringkas bagaimana Replikasi Transaksional bekerja. Lihat diagram Arsitektur Replikasi Transaksional di bawah ini yang diambil dari dokumentasi resmi Microsoft.

Publikasi dibuat di database Penerbit yang terdiri dari daftar Artikel untuk direplikasi ke database Pelanggan.

Replikasi Transaksional biasanya akan diinisialisasi dari Penerbit ke Distributor melalui Agen Snapshot atau Cadangan Penuh. Agen Snapshot didukung melalui Wizard Konfigurasi Replikasi. Full Backup didukung melalui TSQL Statements untuk menginisialisasi Replikasi Transaksional.

Agen Pembaca Log memindai Log Transaksi dari database Penerbit untuk Artikel yang dilacak. Kemudian menyalin perubahan data dari Log Transaksi ke database Distribusi.

Basis data Distribusi dapat berupa Penerbit atau Pelanggan; itu juga bisa atau contoh SQL Server independen lainnya.

Perhatikan juga hal-hal berikut:

• Agen Pembaca Log berjalan terus menerus dari Server Distributor untuk memindai perintah baru yang ditandai untuk Replikasi. Namun, jika Anda tidak ingin terus berjalan dan ingin menjalankan sesuai jadwal, kami dapat mengubah Pekerjaan SQL Agen Pembaca Log yang akan dibuat.
• Agen Pembaca Log mengambil semua catatan yang ditandai untuk Replikasi dari kumpulan Log Masuk Transaksional dan mengirimkannya ke database Distribusi.
• Agen Pembaca Log hanya mengambil transaksi yang Dikomit dari Log Transaksional Basis Data Penerbit. Jadi, setiap kueri yang berjalan lama di database Publisher dapat secara langsung memengaruhi Replikasi saat menunggu transaksi aktif selesai.

Agen Distribusi mengambil semua perintah baru yang tidak terdistribusi dari database Distribusi dan menerapkannya ke database Langganan melalui Mekanisme Dorong atau Tarik. Seperti disebutkan sebelumnya, jika Distributor Berlangganan Push mengambil alih kepemilikan untuk menerapkan perubahan dari basis data Distribusi ke Pelanggan sedangkan dalam basis data Pelanggan Berlangganan Pull mengambil alih kepemilikan untuk mengambil perubahan dari basis data Distribusi ke Pelanggan.

Setelah catatan berhasil didistribusikan dari database Distribusi ke Pelanggan, catatan tersebut akan ditandai sebagai Didistribusikan dan ditandai untuk dihapus dari database Distribusi. Salah satu tugas Pemeliharaan Replikasi Utama bernama Pembersihan Distribusi:Tugas Distribusi dijalankan setiap 10 menit sekali untuk menghapus catatan terdistribusi dari database Distribusi untuk menjaga ukuran database Distribusi tetap terkendali.

Dengan penjelasan rinci tentang konsep Replikasi dan Replikasi Transaksional, kita dapat memahaminya dengan mengonfigurasi Replikasi untuk AdventureWorks database dan verifikasi Replikasi untuk setiap komponen yang dibahas secara teoritis.

Mengonfigurasi Replikasi Transaksional Langkah demi Langkah (melalui SSMS GUI)

Konfigurasi Replikasi Transaksional melibatkan 3 langkah utama:

1. Mengonfigurasi basis data Distribusi
2. Pembuatan Publikasi
3. Pembuatan Langganan

Sebelum mencoba mengonfigurasi Replikasi, pastikan Komponen Replikasi diinstal sebagai bagian dari penginstalan SQL Server atau gunakan media SQL Server untuk menginstal Komponen Replikasi, karena diperlukan untuk tugas tersebut.

Di SSMS, sambungkan ke Instans Database Penayang dan klik kanan pada Replikasi :

Distribusi tidak dikonfigurasi sekarang. Oleh karena itu, kami memiliki opsi Konfigurasi Distribusi. Kita dapat mengonfigurasi database Distribusi menggunakan wizard Konfigurasi Distribusi atau melalui wizard Pembuatan Publikasi.

Untuk mengkonfigurasi database Distribusi dan Publikasi, ikuti langkah-langkah di bawah ini:

Luaskan Replikasi dan klik kanan pada Publikasi Baru .

Wizard Publikasi Baru akan diluncurkan. Klik Berikutnya untuk melihat Distributor opsi konfigurasi.

Secara default, ia memilih server Publisher untuk menyimpan database distribusi. Jika Anda ingin menggunakan database distribusi jarak jauh, pilih opsi kedua. Klik Berikutnya .

Opsi selanjutnya adalah untuk mengonfigurasi Folder Snapshot . Ubah ke folder yang diperlukan. Jika tidak, itu akan dibuat di jalur folder penginstalan SQL Server secara default. Klik Berikutnya .

Pilih Database Publikasi (ini dia AdventureWorks ) dan klik Berikutnya .

Pilih Jenis Publikasi – Replikasi Transaksional . Klik Berikutnya .

Pilih Artikel untuk publikasi ini. Untuk tujuan pengujian, pilih semua Tabel dan Tampilan :

Sebelum mengklik Berikutnya , perluas tabel sekali lagi untuk memverifikasi beberapa masalah.

Beberapa tabel ditandai dengan ikon merah. Ketika kita mengklik tabel tersebut, kita melihat peringatan yang menunjukkan bahwa tabel tidak dapat direplikasi karena tidak memiliki Kunci Utama, salah satu persyaratan penting untuk Replikasi Transaksional. Nanti kita akan lebih detail. Sekarang, klik Berikutnya .

Laman dengan Masalah Artikel terkait dengan dependensi akan muncul. Klik Berikutnya .

Opsi selanjutnya adalah Filter Baris Tabel – karena kita sedang menguji replikasi dasar, kita dapat mengabaikannya. Klik Berikutnya .

Konfigurasikan Agen Snapshot – abaikan dan klik Berikutnya .

Agen Setelan – klik Setelan Keamanan untuk mengonfigurasi akun untuk menjalankan agen Snapshot dan Agen Pembaca Log di bawahnya.

Kemudian, ubah Proses Agen Snapshot untuk dijalankan di bawah Akun Layanan Agen Server SQL.

Setel Agen Pembaca Log ke Hubungkan ke Penerbit> Dengan meniru Akun Proses . Klik Oke .

Keamanan Agen akan diperbarui.

Jadi, kami telah mengonfigurasi Distributor dan semua elemen Publikasi seperti Artikel , Agen Snapshot , Agen Pembaca Log , dan Agen Sekuritas . Kami hampir menyelesaikan pembuatan Publikasi melalui Wizard.

Jika Anda perlu mempelajari lebih lanjut tentang skrip TSQL yang digunakan untuk membuat Publikasi, kita dapat memeriksa Menghasilkan file skrip untuk membuat Publikasi pilihan. Jika tidak, klik Berikutnya .

Karena saya memilih untuk menyimpan file, wizard mengizinkan saya untuk mengatur Jalur file skrip dan nama . Berikan detail ini dan klik Berikutnya .

Wizard akhirnya menanyakan Nama Publikasi , saya menamakannya AdventureWorks_pub dengan nama database dan kata kunci untuk menunjukkannya sebagai publikasi untuk memudahkan identifikasi.

Verifikasi semua data yang diberikan di Ringkasan halaman dan klik Selesai .

Wizard akan menampilkan kemajuan dalam Membuat Publikasi . Jika sudah selesai, kita akan melihat konfirmasinya. Klik Tutup .

Untuk memverifikasi keberhasilan pembuatan Distributor (Database distribusi), perluas database sistem:

Untuk memverifikasi keberhasilan pembuatan Publikasi , luaskan Publikasi Lokal :

Kami telah mengonfigurasi Database Distribusi dan membuat database Publikasi di database AdventureWorks berhasil. Sekarang kita dapat melanjutkan dengan Langganan kreasi

Klik kanan pada Publikasi yang baru kami baru saja membuat dan memilih Langganan Baru :

Wizard Langganan Baru akan muncul. Untuk memulai proses, klik Berikutnya .

Publikasi halaman meminta untuk memastikan bahwa Publikasi dan Penerbit database dipilih. Klik Berikutnya .

Setel Agen Distribusi ke Dorong atau Tarik Berlangganan. Kami akan menggunakan Server Penerbit sebagai Pelanggan, dan jenis itu tidak akan berdampak apa pun. Oleh karena itu, kami membiarkan default Push Berlangganan. Klik Berikutnya .

Pilih Pelanggan (basis data). Saya memilih AdventureWorks_REPL dipulihkan dari cadangan Database AdventureWorks yang sama. Klik Berikutnya .

Setel Keamanan Agen :

Karena saya akan melakukan semuanya dalam satu Server, saya menggunakan Akun layanan Agen .

Jendela berikutnya menampilkan Keamanan Agen Distribusi nilai yang sudah dikonfigurasi. Klik Berikutnya .

Jadwal Sinkronisasi - biarkan ke default. Klik Berikutnya .

Inisialisasi Langganan – biarkan dengan nilai default. Klik Berikutnya .

Setelah Anda memberikan semua detail yang diperlukan, Anda akan dapat menyelesaikan proses pembuatan Langganan. Periksa Buat file Skrip… opsi untuk mempelajari skrip nanti dan klik Berikutnya .

Berikan jalur untuk menyimpan file, klik Berikutnya .

Lihat ringkasan dan periksa semua nilai yang dikonfigurasi. Setelah diverifikasi, klik Selesai .

Pembuatan Langganan selesai. Klik Tutup .

Sekarang kita bisa melihat Langganan ditampilkan di bawah Publikasi our kami .

Konfigurasikan Agen Snapshot

Langkah kita selanjutnya adalah mengerjakan Snapshot Agen untuk mengirim data awal dari Penerbit kepada Pelanggan .

Sebelum melangkah ke dalamnya, kita perlu memperhatikan Monitor Replikasi . Alat penting ini tersedia di SSMS untuk melihat status Replikasi di berbagai level, Level Server, level Basis Data Penerbit, level Langganan, dan level Agen Replikasi.

Klik kanan pada Replikasi /Publikasi Lokal /Langganan Lokal /Publikasi atau Langganan kami buat untuk meluncurkan Monitor Replikasi seperti yang ditunjukkan di bawah ini:

Di Monitor Replikasi , luaskan Server Penerbit (RRJ)> Publikasi ([AdventureWorks]:AdventureWorks_pub) untuk menampilkan detail Langganan. Klik kanan pada Langganan dan pilih Lihat Detail .

Seperti yang bisa kita lihat, informasi tentang Snapshot Awal untuk publikasi kami AdventureWorks_pub belum tersedia. Kami harus menjalankan tugas agen Snapshot untuk mengirim data awal ke database Pelanggan .

Biarkan jendela ini tetap terbuka untuk melihat kemajuan Snapshot setelah memulai tugas Agen Snapshot .

Klik kanan pada Publikasi > Melihat Status Agen Snapshot :

Agen tidak pernah dijalankan pesan menyatakan bahwa kami tidak pernah mengeksekusi Agen Snapshot. Klik Mulai .

Saat Agen Snapshot dijalankan, Anda dapat melihat perkembangannya:

Ketika semua snapshot dibuat, itu akan menghasilkan pesan konfirmasi:

Kita dapat melihat file Snapshot yang baru dibuat di folder Snapshot yang telah kita sediakan pathnya sebelumnya.

Setelah semua snapshot diterapkan oleh Agen Distribusi ke basis data Pelanggan , itu akan menampilkan status di bawah ini di Monitor Replikasi yang terbuka jendela:

Selamat! Kami telah berhasil mengonfigurasi Replikasi Transaksional menggunakan Agen Snapshot.

Catatan :Jika kami memiliki Basis Data Penerbit yang besar, membuat snapshot mungkin membutuhkan banyak waktu. Oleh karena itu, disarankan untuk menggunakan cadangan penuh database Penerbit daripada menjalankan Agen Snapshot – kami akan membahas masalah ini di artikel berikutnya.

Memverifikasi Komponen Replikasi

Setiap Komponen Replikasi dapat diverifikasi oleh SSMS GUI dan kueri TSQL. Kami akan membahasnya di artikel selanjutnya, dan di sini kami akan segera menjelaskan cara melihat properti komponen di bawah ini.

Penerbit

Di SSMS, klik kanan Replikasi > Properti Penayang > Basis Data Publikasi :

Untuk melihat detail tentang Penerbit , jalankan kueri di bawah ini terhadap database distribusi.

USE distribution
GO
exec sp_helpdistpublisher
GO
select * from MSpublisher_databases
GO

Pelanggan

Info pelanggan dapat diperoleh dengan query di bawah ini di SSMS.

USE distribution
GO
exec sp_helpsubscriberinfo
GO
select * from MSsubscriber_info

Distributor

Di SSMS, klik kanan Replikasi > Distributor Properti :

Klik Penerbit untuk menampilkan daftar semua Penerbit menggunakan basis data Distribusi ini.

Di SSMS, kita bisa menjalankan query di bawah ini untuk mendapatkan detail yang sama.

USE distribution
GO
exec sp_helpdistributor
GO
exec sp_helpdistributiondb
GO	

Artikel

Klik kanan pada Publikasi > Properti Publikasi > Artikel . Anda akan melihat daftar semua Artikel yang tersedia. Properti artikel individual dapat dimodifikasi dengan mengklik Properti Artikel juga.

USE AdventureWorks
GO
-- To View all articles available under a Publication
exec sp_helparticle @publication = 'Adventureworks_pub'
GO
-- To View all article columns for a particular article available under a Publication
exec sp_helparticlecolumns @publication = 'Adventureworks_pub', @article = 'Address'
GO
USE distribution
GO
SELECT * from MSArticles

Publikasi

Klik kanan pada Publikasi > Properti :

Di SSMS, kita dapat menjalankan kueri di bawah ini untuk melihat Properti publikasi :

USE AdventureWorks
GO
exec sp_helppublication
GO
USE distribution
GO
SELECT * FROM MSPublications

Langganan

Klik kanan pada Langganan > Properti langganan :

Di SSMS, kita dapat menjalankan skrip di bawah ini untuk mendapatkan info Langganan:

USE AdventureWorks
GO
exec sp_helpsubscription
GO
USE distribution
GO
SELECT * FROM MSsubscriptions
GO

Agen Replikasi

Di bawah Tugas Agen Server SQL , kita dapat menemukan Pekerjaan specific tertentu dibuat untuk semua Agen Replikasi:

Di SSMS, kita dapat menjalankan kueri untuk mengetahui pekerjaan mana yang diperlukan Pekerjaan Agen Pembaca Log , Pekerjaan Agen Snapshot , dan Pekerjaan Agen Distribusi . Selain itu, kita dapat melihat tugas Pembersihan Agen Distribusi dan beberapa pekerjaan lain yang terkait dengan Replikasi dibuat saat kami mengatur Publikasi dan Langganan secara internal.

Cara Kerja Agen Pembaca Log

Agen Pembaca Log membaca semua data yang dikomit dari log transaksi basis data Penerbit dan memasukkannya ke basis data Distributor. Meskipun Microsoft tidak menyediakan cara resmi untuk membaca Log Transaksi, ada beberapa fungsi yang tidak didokumentasikan seperti fn_dblog() dan fn_dump_dblog() yang dapat membaca data dari File Log. Namun, fungsi ini tidak didokumentasikan dan tidak tercakup oleh dukungan Microsoft. Jadi, kami tidak akan menjelajahinya lebih jauh.

Bagaimana Agen Distribusi Mengirimkan Perubahan Data ke Basis Data Pelanggan

Setelah data ditulis ke database Distribusi, kita dapat membaca bagaimana data tersebut disimpan dalam tabel distribusi. Untuk itu, kami menerapkan sp_browsereplcmds prosedur – ia mengambil catatan di seluruh MSrepl_commands dan MSrepl_transactions tabel.

Untuk tujuan pembelajaran, mari kita ambil tabel dengan 3 kolom bernama Person.ContactType :

Langganan yang dibuat akan membuat 3 prosedur untuk setiap artikel yang merupakan bagian dari Publikasi di database Pelanggan dengan konvensi penamaan di bawah ini:

• dbo.sp_MSins_
• dbo.sp_MSupd_
• dbo.sp_MSdel_

Untuk artikel Tabel Person.ContactType, kita dapat melihat prosedur di bawah ini yang dibuat di database Pelanggan:

• dbo.sp_MSins_PersonContactType – MASUKKAN catatan baru yang diambil dari basis data Log Transaksi Penerbit dan kemudian disebarkan ke basis data distribusi.
• dbo.sp_MSupd_PersonContactType – PERBARUI perubahan yang diambil dari basis data Log Transaksi Penerbit dan kemudian disebarkan ke basis data distribusi.
• dbo.sp_MSdel_PersonContactType – HAPUS records captured from Transaction Logs of Publisher database and then propagated to the distribution database.

Script of the dbo.sp_MSins_PersonContactType Procedure

As you can see, it’s a straightforward INSERT statement that comes out of the distribution database:

ALTER procedure [dbo].[sp_MSins_PersonContactType]
    @c1 int,
    @c2 nvarchar(50),
    @c3 datetime
as
begin  
	insert into [Person].[ContactType] (
		[ContactTypeID],
		[Name],
		[ModifiedDate]
	) values (
		@c1,
		@c2,
		@c3	) 
end  
GO

Script of the dbo.sp_MSupd_PersonContactType Procedure

The script relies on the Primary Key values to identify the unique record for updating:

ALTER procedure [dbo].[sp_MSupd_PersonContactType]
		@c1 int = NULL,
		@c2 nvarchar(50) = NULL,
		@c3 datetime = NULL,
		@pkc1 int = NULL,
		@bitmap binary(1)
as
begin  
	declare @primarykey_text nvarchar(100) = ''
update [Person].[ContactType] set
		[Name] = case substring(@bitmap,1,1) & 2 when 2 then @c2 else [Name] end,
		[ModifiedDate] = case substring(@bitmap,1,1) & 4 when 4 then @c3 else [ModifiedDate] end
	where [ContactTypeID] = @pkc1
if @@rowcount = 0
    if @@microsoftversion>0x07320000
		Begin
			if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')
			Begin
				
				set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)
				exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @[email protected]_text, @param3=13233 
			End
			Else
				exec sp_MSreplraiserror @errorid=20598
		End
end 
GO

Script of the dbo.sp_MSdel_PersonContactType Procedure

This script relies on the Primary Key values to identify a unique record for deleting records from the Subscriber :

ALTER procedure [dbo].[sp_MSdel_PersonContactType]
		@pkc1 int
as
begin  
	declare @primarykey_text nvarchar(100) = ''
	delete [Person].[ContactType] 
	where [ContactTypeID] = @pkc1
if @@rowcount = 0
    if @@microsoftversion>0x07320000
		Begin
			if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')
			Begin
				
				set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)
				exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @[email protected]_text, @param3=13234 
			End
			Else
				exec sp_MSreplraiserror @errorid=20598
		End
end  
GO

This clearly explains why Transactional Replication enforces the Primary Key as a key requirement for tables to be added as part of Replication .

Now, let’s see the Transactional Replication in action. Let’s change some data in the Publisher database. For simplicity, I’ll take the same Person.ContactType tabel.

Executing the SELECT statement on the table yields 20 records:

Next, I INSERTed a sample record into the Person.ContactType tabel:

And, I UPDATE the newly inserted record:

DELETE the newly inserted record from the table:

We need to verify these transactions in Replication using sp_browsereplcmds

Changes from Person.ContactType were captured from the Transactional Logs of Publisher Database (AdventureWorks ) and sent to the Distribution database in the same order. Later, it was propagated to the Subscriber Database (AdventureWorks_REPL ).

Kesimpulan

Thanks for reading this long power-packed article! We have gone through a variety of topics, such as:

• Replication Architecture and Terminologies
• SQL Server Replication Types
• SQL Server Transactional Replication in Detail
• SQL Server Transactional Replication Configuration (Default approach)
• SQL Server Transactional Replication Verification
• SQL Server Transactional Replication in action

I hope that you’ve found lots of helpful information in this article. In subsequent parts, we’ll explore troubleshooting various issues that are frequently encountered in Replication, and learn how to handle them more efficiently.