Bagikan melalui

Replikasi, pelacakan perubahan, & ubah tangkapan data - Grup ketersediaan AlwaysOn

  • Artikel

Berlaku untuk: SQL Server

Replikasi SQL Server, penangkapan data perubahan (CDC), dan pelacakan perubahan (CT) didukung pada grup ketersediaan AlwaysOn. Grup ketersediaan AlwaysOn membantu menyediakan ketersediaan tinggi dan kemampuan pemulihan database lainnya.

Gambaran umum replikasi dengan grup ketersediaan

Pengalihan Penerbit

Saat database yang diterbitkan mengetahui grup ketersediaan AlwaysOn, distributor yang menyediakan akses agen ke database penerbitan dikonfigurasi dengan entri redirected_publishers. Entri ini mengalihkan pasangan penerbit/database yang awalnya dikonfigurasi, menggunakan nama pendengar grup ketersediaan untuk menyambungkan ke penerbit dan menerbitkan database. Koneksi yang dibuat melalui nama pendengar grup ketersediaan akan gagal pada failover. Ketika agen replikasi dimulai ulang setelah failover, koneksi akan secara otomatis dialihkan ke primer baru.

Dalam grup ketersediaan, database sekunder tidak bisa menjadi penerbit. Penerbitan ulang hanya didukung ketika replikasi transaksional dikombinasikan dengan grup ketersediaan AlwaysOn.

Jika database yang diterbitkan adalah anggota grup ketersediaan dan penerbit dialihkan, database tersebut harus dialihkan ke nama pendengar grup ketersediaan yang terkait dengan grup ketersediaan. Ini mungkin tidak dialihkan ke simpul eksplisit.

Catatan

Setelah failover ke replika sekunder, Monitor Replikasi tidak dapat menyesuaikan nama instans penerbitan SQL Server dan akan terus menampilkan informasi replikasi dengan nama instans utama asli SQL Server. Setelah failover, token pelacak tidak dapat dimasukkan dengan menggunakan Monitor Replikasi, namun token pelacak yang dimasukkan pada penerbit baru dengan menggunakan Transact-SQL, terlihat di Monitor Replikasi.

Perubahan umum pada agen replikasi untuk mendukung grup ketersediaan

Tiga agen replikasi dimodifikasi untuk mendukung grup ketersediaan AlwaysOn. Agen Pembaca Log, Rekam Jepret, dan Gabungkan dimodifikasi untuk mengkueri database distribusi untuk penerbit yang dialihkan dan untuk menggunakan nama pendengar grup ketersediaan yang dikembalikan, jika penerbit yang dialihkan dideklarasikan, untuk menyambungkan ke penerbit database.

Secara default, ketika agen meminta distributor untuk menentukan apakah penerbit asli telah dialihkan, kesesuaian target atau pengalihan saat ini akan diverifikasi sebelum mengembalikan host yang dialihkan ke agen. Perilaku ini direkomendasikan. Namun, jika startup agen sering terjadi overhead yang terkait dengan prosedur tersimpan validasi dapat dianggap terlalu mahal. Sakelar baris perintah baru, BypassPublisherValidation, telah ditambahkan ke agen Pembaca log, Rekam Jepret, dan Gabungkan. Ketika sakelar digunakan, penerbit yang dialihkan dikembalikan segera ke agen dan eksekusi prosedur tersimpan validasi dilewati.

Kegagalan yang dikembalikan dari prosedur tersimpan validasi dicatat dalam log riwayat agen. Kesalahan dengan tingkat keparahan yang lebih besar dari atau sama dengan 16 akan menyebabkan agen berakhir. Beberapa kemampuan coba lagi telah dibangun ke agen untuk menangani pemutusan sambungan yang diharapkan dari database yang diterbitkan ketika gagal ke primer baru.

Modifikasi Agen Pembaca Log

Agen pembaca Log memiliki perubahan berikut.

  • Konsistensi Database yang Direplikasi

    Ketika database yang diterbitkan adalah anggota grup ketersediaan, secara default pembaca log tidak akan memproses rekaman log yang belum diperkeras di semua replika sekunder grup ketersediaan. Ini memastikan bahwa pada failover, semua baris yang direplikasi ke pelanggan juga ada di primer baru.

    Ketika penerbit hanya memiliki dua replika ketersediaan (satu primer dan satu sekunder) dan failover terjadi, replika utama asli tetap turun karena pembaca log tidak bergerak maju sampai semua database sekunder dibawa kembali online atau sampai replika sekunder yang gagal dihapus dari grup ketersediaan. Pembaca log, yang sekarang berjalan terhadap database sekunder, tidak akan melanjutkan ke depan karena Always On tidak dapat mengeraskan perubahan apa pun pada database sekunder apa pun. Untuk memungkinkan pembaca log melanjutkan lebih lanjut dan masih memiliki kapasitas pemulihan bencana, hapus replika utama asli dari grup ketersediaan menggunakan ALTER AVAILABITY GROUP <group_name> REMOVE REPLICA. Kemudian tambahkan replika sekunder baru ke grup ketersediaan.

  • Bendera pelacakan 1448

    Bendera pelacakan 1448 memungkinkan pembaca log replikasi untuk maju meskipun replika sekunder asinkron belum mengakui penerimaan perubahan. Bahkan dengan bendera pelacakan ini diaktifkan, pembaca log selalu menunggu replika sekunder sinkron (Mereka bisa menjadi mode penerapan asinkron seperti yang didokumenkan di sini, sehingga pembaca log dapat bergerak maju.). Pembaca log tidak akan melampaui ack min dari replika sekunder sinkron. Bendera pelacakan ini berlaku untuk instans SQL Server, tidak hanya untuk grup ketersediaan, database ketersediaan, atau instans pembaca log. Bendera pelacakan ini segera berlaku tanpa menghidupkan ulang. Ini dapat diaktifkan sebelumnya atau ketika replika sekunder asinkron gagal.

Prosedur tersimpan yang mendukung grup ketersediaan

  • sp_redirect_publisher

    Prosedur tersimpan sp_redirect_publisher digunakan untuk menentukan penerbit yang dialihkan untuk pasangan penerbit/database yang sudah ada. Jika database penerbit termasuk dalam grup ketersediaan, penerbit yang dialihkan adalah nama pendengar grup ketersediaan.

  • sp_get_redirected_publisher

    Prosedur tersimpan sp_get_redirected_publisher digunakan oleh agen replikasi untuk mengkueri distributor untuk menentukan apakah pasangan penerbit/database memiliki penerbit yang dialihkan yang ditentukan. Prosedur tersimpan ini melayani dua tujuan. Pertama, ini memungkinkan agen untuk menentukan apakah penerbit asli telah dialihkan. Kedua, ini juga dapat memulai prosedur tersimpan validasi yang berjalan di distributor (sp_validate_redirected_publisher) yang memverifikasi kesesuaian simpul target pengalihan untuk berfungsi sebagai penerbit untuk database bernama.

    Untuk menjalankan prosedur tersimpan ini, pemanggil harus menjadi anggota peran server sysadmin , peran database db_owner untuk database distribusi, atau anggota Daftar Akses Publikasi untuk publikasi yang ditentukan yang terkait dengan database penerbit.

  • sp_validate_redirected_publisher

    Prosedur tersimpan ini mencoba memvalidasi bahwa penerbit saat ini mampu menghosting database yang diterbitkan. Ini dapat dipanggil kapan saja untuk memverifikasi bahwa host saat ini untuk database yang diterbitkan mampu mendukung replikasi.

  • sp_validate_replicate_hosts_as_publishers

    Meskipun berguna bagi agen untuk memastikan bahwa primer saat ini dapat berfungsi sebagai penerbit replikasi untuk database penerbit, kemampuan validasi yang lebih umum diperlukan untuk menetapkan validitas seluruh topologi replikasi pada database ketersediaan AlwaysOn. Prosedur tersimpan sp_validate_replica_hosts_as_publishers dirancang untuk memenuhi kebutuhan ini.

    Prosedur tersimpan ini selalu dijalankan secara manual. Pemanggil harus sysadmin di distributor, dbowner database distribusi, atau anggota Daftar Akses Publikasi publikasi database penerbit. Selain itu, login penelepon harus merupakan login yang valid untuk semua host replika ketersediaan, dan telah memilih hak istimewa pada database ketersediaan yang terkait dengan database penerbit.

Ubah Pengambilan Data

Database yang diaktifkan untuk mengubah penangkapan data (CDC) dapat menggunakan grup ketersediaan AlwaysOn untuk memastikan tidak hanya database tetap tersedia jika terjadi kegagalan, tetapi perubahan pada tabel database terus dipantau dan disimpan dalam tabel perubahan CDC. Urutan di mana grup ketersediaan CDC dan AlwaysOn dikonfigurasi tidak penting. Database yang diaktifkan CDC dapat ditambahkan ke grup ketersediaan AlwaysOn, dan database yang merupakan anggota grup ketersediaan AlwaysOn dapat diaktifkan untuk CDC. Namun, dalam kedua kasus, konfigurasi CDC selalu dilakukan pada replika utama saat ini atau yang dimaksudkan. CDC menggunakan agen pembaca log dan memiliki batasan yang sama seperti yang dijelaskan di bagian Modifikasi Agen Pembaca Log sebelumnya dalam topik ini.

  • Memanen Perubahan untuk Mengubah Pengambilan Data Tanpa Replikasi

    Jika CDC diaktifkan untuk database, tetapi replikasi tidak, proses pengambilan yang digunakan untuk memanen perubahan dari log dan menyimpannya dalam tabel perubahan CDC berjalan di host CDC sebagai pekerjaan Agen SQL sendiri.

    Untuk melanjutkan panen perubahan setelah failover, prosedur tersimpan sp_cdc_add_job harus dijalankan di primer baru untuk membuat pekerjaan penangkapan lokal.

    Contoh berikut membuat pekerjaan pengambilan.

    EXEC sys.sp_cdc_add_job @job_type = 'capture';

  • Memanen Perubahan untuk Mengubah Pengambilan Data Dengan Replikasi

    Jika CDC dan replikasi diaktifkan untuk database, pembaca log menangani populasi tabel perubahan CDC. Dalam hal ini, teknik yang digunakan oleh replikasi untuk menggunakan grup ketersediaan AlwaysOn akan memastikan bahwa perubahan terus dipanen dari log dan disimpan dalam tabel perubahan CDC setelah failover. Tidak ada lagi yang perlu dilakukan untuk CDC dalam konfigurasi ini untuk memastikan bahwa tabel perubahan diisi.

  • Ubah Pembersihan Penangkapan Data

    Untuk memastikan bahwa pembersihan yang sesuai terjadi di database utama baru, pekerjaan pembersihan lokal harus selalu dibuat. Contoh berikut membuat pekerjaan pembersihan.

    EXEC sys.sp_cdc_add_job @job_type = 'cleanup';

    Catatan

    Anda harus membuat pekerjaan di replika utama baru setelah failover. Pekerjaan CDC yang berjalan di database utama lama harus dinonaktifkan ketika database lokal menjadi database sekunder. Posting ini jika replika menjadi primer lagi, Anda perlu mengaktifkan kembali pekerjaan CDC pada replika. Untuk menonaktifkan dan mengaktifkan pekerjaan, gunakan opsi @enabled sp_update_job (Transact-SQL). Untuk informasi selengkapnya tentang membuat pekerjaan CDC, lihat sys.sp_cdc_add_job (Transact-SQL).

  • Menambahkan Peran CDC ke Replika Database Utama AlwaysOn

    Saat tabel diaktifkan untuk CDC, dimungkinkan untuk mengaitkan peran database dengan instans pengambilan. Jika peran ditentukan, pengguna yang ingin menggunakan fungsi bernilai tabel CDC untuk mengakses perubahan untuk tabel tidak hanya boleh memilih akses ke kolom tabel yang dilacak, tetapi juga harus menjadi anggota peran bernama. Jika peran yang ditentukan belum ada, peran akan dibuat. Saat peran database secara otomatis ditambahkan ke database utama AlwaysOn, peran juga disebarluaskan ke database sekunder dari grup ketersediaan.

  • Aplikasi Klien Yang Mengakses DATA Perubahan CDC dan AlwaysOn

    Aplikasi klien yang menggunakan fungsi bernilai tabel (TVF) atau server tertaut untuk mengakses data tabel perubahan juga memerlukan kemampuan untuk menemukan host CDC yang sesuai setelah failover. Nama pendengar grup ketersediaan adalah mekanisme yang disediakan oleh grup ketersediaan AlwaysOn untuk secara transparan memungkinkan koneksi ditargetkan ulang ke host yang berbeda. Setelah nama pendengar grup ketersediaan dikaitkan dengan grup ketersediaan, nama pendengar grup ketersediaan tersedia untuk digunakan dalam string koneksi TCP. Dua skenario koneksi yang berbeda didukung melalui nama pendengar grup ketersediaan.

    • Satu memastikan bahwa permintaan koneksi selalu diarahkan ke replika utama saat ini.

    • Satu memastikan bahwa permintaan koneksi diarahkan ke replika sekunder baca-saja.

    Jika digunakan untuk menemukan replika sekunder baca-saja, daftar perutean baca-saja juga harus ditentukan untuk grup ketersediaan. Untuk informasi selengkapnya tentang perutean akses ke sekunder yang dapat dibaca, lihat Untuk Mengonfigurasi Replika Ketersediaan untuk Perutean Baca-Saja.

    Catatan

    Ada beberapa penundaan penyebaran yang terkait dengan pembuatan nama pendengar grup ketersediaan dan penggunaannya oleh aplikasi klien untuk mengakses replika database grup ketersediaan.

    Gunakan kueri berikut untuk menentukan apakah nama pendengar grup ketersediaan telah ditentukan untuk grup ketersediaan yang menghosting database CDC. Kueri akan mengembalikan nama pendengar grup ketersediaan jika telah dibuat.

    SELECT dns_name   
FROM sys.availability_group_listeners AS l  
INNER JOIN sys.availability_databases_cluster AS d  
    ON l.group_id = d.group_id  
WHERE d.database_name = N'MyCDCDB';

  • Mengalihkan Beban Kueri ke Replika Sekunder yang Dapat Dibaca

    Meskipun dalam banyak kasus aplikasi klien akan selalu ingin terhubung ke replika utama saat ini, itu bukan satu-satunya cara untuk menggunakan grup ketersediaan AlwaysOn. Jika grup ketersediaan dikonfigurasi untuk mendukung replika sekunder yang dapat dibaca, data perubahan juga dapat dikumpulkan dari simpul sekunder.

    Saat grup ketersediaan dikonfigurasi, atribut ALLOW_CONNECTIONS yang terkait dengan SECONDARY_ROLE digunakan untuk menentukan jenis akses sekunder yang didukung. Jika dikonfigurasi sebagai SEMUA, semua koneksi ke sekunder akan diizinkan, tetapi hanya yang memerlukan akses baca-saja yang akan berhasil. Jika dikonfigurasi sebagai READ_ONLY, perlu untuk menentukan niat baca saja saat membuat koneksi ke database sekunder agar koneksi berhasil. Untuk informasi selengkapnya, lihat Mengonfigurasi Akses Baca-Saja pada Replika Ketersediaan (SQL Server).

    Kueri berikut dapat digunakan untuk menentukan apakah niat baca-saja diperlukan untuk menyambungkan ke replika sekunder yang dapat dibaca.

    SELECT g.name AS AG, replica_server_name, secondary_role_allow_connections_desc  
FROM sys.availability_replicas AS r  
JOIN sys.availability_groups AS g  
    ON r.group_id = g.group_id  
WHERE g.name = N'MY_AG_NAME';

    Baik nama pendengar grup ketersediaan atau nama node eksplisit dapat digunakan untuk menemukan replika sekunder. Jika nama pendengar grup ketersediaan digunakan, akses akan diarahkan ke replika sekunder yang sesuai.

    Ketika sp_addlinkedserver digunakan untuk membuat server tertaut untuk mengakses sekunder, parameter @datasrc digunakan untuk nama pendengar grup ketersediaan atau nama server eksplisit, dan parameter @provstr digunakan untuk menentukan niat baca-saja.

    EXEC sp_addlinkedserver   
@server = N'linked_svr',   
@srvproduct=N'SqlServer',  
@provider=N'MSOLEDBSQL',   
@datasrc=N'AG_Listener_Name',   
@provstr=N'ApplicationIntent=ReadOnly',   
@catalog=N'MY_DB_NAME';

  • Akses Klien ke CDC Mengubah Data dan Login Domain

    Secara umum, Anda harus menggunakan login domain untuk akses klien guna mengubah data yang berada di database yang merupakan anggota grup ketersediaan AlwaysOn. Untuk memastikan akses berkelanjutan untuk mengubah data setelah failover, pengguna domain akan memerlukan hak istimewa akses pada semua host yang mendukung replika grup ketersediaan. Jika pengguna database ditambahkan ke database di replika utama, dan pengguna dikaitkan dengan login domain, pengguna database disebarkan ke database sekunder dan terus dikaitkan dengan login domain yang ditentukan. Jika pengguna database baru dikaitkan dengan login autentikasi SQL Server, pengguna di database sekunder akan disebarluaskan tanpa login. Meskipun login autentikasi SQL Server terkait dapat digunakan untuk mengakses data perubahan di primer tempat pengguna database awalnya ditentukan, simpul tersebut adalah satu-satunya di mana akses akan dimungkinkan. Login autentikasi SQL Server tidak akan dapat mengakses data dari database sekunder apa pun, atau dari database utama baru selain database asli tempat pengguna database ditentukan.

  • Menonaktifkan Ubah Pengambilan Data
    Jika Anda perlu menonaktifkan Change Data Capture (CDC) pada database yang merupakan bagian dari grup ketersediaan AlwaysOn dan Anda berada di SQL Server 2016 SP2 atau yang lebih baru , Anda tidak perlu melakukan langkah tambahan apa pun untuk pemotongan log otomatis. Jika Anda menggunakan versi yang lebih lama dari SQL Server 2016 SP2 dan menonaktifkan CDC pada database yang merupakan bagian dari grup ketersediaan, maka Anda harus menerapkan salah satu langkah berikut untuk mencegah pemblokiran pemotongan log setelah CDC dinonaktifkan:

    • Mulai ulang layanan SQL Server pada setiap instans replika sekunder.
    • Hapus database dari semua instans replika sekunder dari grup ketersediaan lalu tambahkan kembali ke setiap instans replika grup ketersediaan menggunakan seeding otomatis atau manual.

Pelacakan Perubahan

Database yang diaktifkan untuk pelacakan perubahan (CT) dapat menjadi bagian dari grup ketersediaan AlwaysOn. Tidak diperlukan konfigurasi lagi. Mengubah aplikasi klien pelacakan yang menggunakan fungsi bernilai tabel CDC (TVF) untuk mengakses data perubahan akan membutuhkan kemampuan untuk menemukan replika utama setelah failover. Jika aplikasi klien terhubung melalui nama pendengar grup ketersediaan, permintaan koneksi akan selalu diarahkan dengan tepat ke replika utama saat ini.

Catatan

Data pelacakan perubahan harus selalu diperoleh dari replika utama. Upaya untuk mengakses data perubahan dari replika sekunder akan mengakibatkan kesalahan berikut:

Msg 22117, Level 16, State 1, Line1

Untuk database yang merupakan anggota replika sekunder (yaitu, untuk database sekunder), pelacakan perubahan tidak didukung. Sebagai alternatif untuk menjalankan kueri pelacakan perubahan pada replika utama, Anda dapat membuat rekam jepret database database AG dari replika sekunder lalu menggunakannya untuk mengkueri data perubahan. Rekam jepret database adalah tampilan statis baca-saja dari database SQL Server (database sumber), jadi mengubah data pelacakan dalam rekam jepret database akan menjadi waktu ketika rekam jepret diambil pada database AG dari replika sekunder.

Catatan

Ketika failover terjadi pada database dengan Pelacakan Perubahan diaktifkan, waktu pemulihan pada replika utama baru mungkin memakan waktu lebih lama dari biasanya karena Pelacakan Perubahan memerlukan mulai ulang database penuh.

Prasyarat, Pembatasan, dan Pertimbangan untuk Menggunakan Replikasi

Bagian ini menjelaskan pertimbangan untuk menyebarkan replikasi dengan grup ketersediaan AlwaysOn, termasuk prasyarat, pembatasan, dan rekomendasi.

Prasyarat

  • Saat menggunakan replikasi transaksional dan database penerbitan berada dalam grup ketersediaan, penerbit dan distributor harus menjalankan setidaknya SQL Server 2012 (11.x). Pelanggan dapat menggunakan tingkat SQL Server yang lebih rendah.

  • Saat menggunakan replikasi penggabungan dan database penerbitan berada dalam grup ketersediaan:

    • Langganan push: Penerbit dan distributor harus menjalankan setidaknya SQL Server 2012 (11.x).

    • Langganan penarikan: Database penerbit, distributor, dan pelanggan harus berada di setidaknya SQL Server 2012 (11.x). Ini karena agen penggabungan pada pelanggan harus memahami bagaimana grup ketersediaan dapat gagal ke sekundernya.

  • Instans Publisher memenuhi semua prasyarat yang diperlukan untuk berpartisipasi dalam grup ketersediaan AlwaysOn. Untuk informasi selengkapnya, lihat Prasyarat, Pembatasan, dan Rekomendasi untuk Grup Ketersediaan AlwaysOn (SQL Server).

Batasan

Kombinasi replikasi yang didukung pada grup ketersediaan AlwaysOn:

Replikasi Publisher Distributor1 Pelanggan
Transaksional Ya

Catatan: Tidak termasuk dukungan untuk replikasi transaksional dua arah dan timbal balik.		 Ya Ya
Peer-to-peer2 Ya Ya3 Ya
Gabungkan Ya No Tidak
Snapshot Ya No Ya
Langganan yang Dapat Diperbarui - Untuk Replikasi Transaksional Tidak No Tidak

1 Database Distributor tidak didukung untuk digunakan dengan pencerminan database.

2 Memerlukan SQL Server 2019 CU 13 atau yang lebih baru.

3 Memerlukan SQL Server 2019 CU 17 atau yang lebih baru.

Pertimbangan

  • Database distribusi tidak didukung untuk digunakan dengan pencerminan database tetapi didukung dengan grup ketersediaan AlwaysOn tunduk pada batasan tertentu, lihat Mengonfigurasi Grup Ketersediaan Distribusi. Konfigurasi replikasi digabungkan ke instans SQL Server tempat Distributor dikonfigurasi; oleh karena itu database distribusi tidak dapat dicerminkan atau direplikasi. Dimungkinkan juga untuk memberikan ketersediaan tinggi untuk Distributor menggunakan kluster failover SQL Server. Untuk informasi selengkapnya, lihat Instans Kluster Failover AlwaysOn (SQL Server).

  • Failover pelanggan ke database sekunder, meskipun didukung, adalah prosedur manual untuk pelanggan replikasi penggabungan. Prosedur ini pada dasarnya identik dengan metode yang digunakan untuk melakukan failover pada database pelanggan cermin. Pelanggan replikasi transaksional tidak memerlukan penanganan khusus saat berpartisipasi dalam grup ketersediaan AlwaysOn. Pelanggan harus menjalankan SQL Server 2012 (11.x) atau yang lebih baru untuk berpartisipasi dalam grup ketersediaan. Untuk informasi selengkapnya, lihat Pelanggan Replikasi dan Grup Ketersediaan AlwaysOn (SQL Server)

  • Metadata dan objek yang ada di luar database tidak disebarluaskan ke replika sekunder, termasuk login, pekerjaan, server tertaut. Jika Anda memerlukan metadata dan objek di database utama baru setelah failover, Anda harus menyalinnya secara manual. Untuk informasi selengkapnya, lihat Manajemen Login dan Pekerjaan untuk Database Grup Ketersediaan (SQL Server).

Grup Ketersediaan Terdistribusi

Penerbit, atau database distribusi dalam Grup Ketersediaan tidak dapat dikonfigurasi sebagai bagian dari Grup Ketersediaan Terdistribusi. Database penerbit dalam Grup Ketersediaan dan database distribusi dalam Grup Ketersediaan memerlukan titik akhir pendengar untuk konfigurasi dan penggunaan yang tepat. Namun, tidak dimungkinkan untuk mengonfigurasi titik akhir pendengar untuk grup Ketersediaan Terdistribusi.

Tugas Terkait

Replikasi

Mengubah pengambilan data

Pelacakan perubahan

Lihat Juga

Pelanggan Replikasi dan Grup Ketersediaan AlwaysOn (SQL Server)
Prasyarat, Pembatasan, dan Rekomendasi untuk Grup Ketersediaan AlwaysOn (SQL Server)
Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server)
Grup Ketersediaan AlwaysOn: Interoperabilitas (SQL Server)
Instans Kluster Failover AlwaysOn (SQL Server)
Tentang Mengubah Penangkapan Data (SQL Server)
Tentang Pelacakan Perubahan (SQL Server)
Replikasi SQL Server
Lacak Perubahan Data (SQL Server)
sys.sp_cdc_add_job (T-SQL)