Apa itu change data capture (CDC)?

  • Artikel
  • 18 menit untuk membaca

Berlaku untuk:yes SQL Server (semua versi yang didukung) YesAzure SQL Database YesAzure SQL Managed Instance

Dalam artikel ini, pelajari tentang mengubah pengambilan data (CDC), yang merekam aktivitas pada database saat tabel dan baris telah dimodifikasi. Tangkapan data perubahan umumnya tersedia dalam Azure SQL Database, SQL Server, dan Azure SQL Managed Instance.

Gambaran Umum

Mengubah pengambilan data (CDC) menggunakan agen SQL Server untuk merekam aktivitas sisipkan, perbarui, dan hapus yang berlaku untuk tabel. Ini membuat detail perubahan tersedia dalam format relasional yang mudah dikonsumsi. Informasi kolom dan metadata yang diperlukan untuk menerapkan perubahan ke lingkungan target diambil untuk baris yang dimodifikasi dan disimpan dalam tabel perubahan yang mencerminkan struktur kolom tabel sumber yang dilacak. Fungsi bernilai tabel disediakan untuk memungkinkan akses sistematis ke data perubahan oleh konsumen.

Contoh yang baik dari konsumen data yang ditargetkan teknologi ini adalah aplikasi ekstraksi, transformasi, dan pemuatan (ETL). Aplikasi ETL secara bertahap memuat data perubahan dari tabel sumber SQL Server ke gudang data atau data mart. Meskipun representasi tabel sumber dalam gudang data harus mencerminkan perubahan dalam tabel sumber, teknologi end-to-end yang menyegarkan replika sumber tidak sesuai. Sebagai gantinya, Anda memerlukan aliran data perubahan yang andal yang terstruktur sehingga konsumen dapat menerapkannya ke representasi target data yang berbeda. SQL Server mengubah tangkapan data menyediakan teknologi ini.

Azure SQL Database CDC &

Pada Azure SQL Database, penjadwal pengambilan data perubahan menggantikan Agen SQL Server yang memanggil prosedur yang disimpan guna memulai pengambilan dan penghapusan berkala dari tabel pengambilan data perubahan. Penjadwal menjalankan pengambilan dan pembersihan secara otomatis dalam SQL Database, tanpa dependensi eksternal untuk keandalan atau performa. Pengguna masih memiliki opsi untuk menjalankan pengambilan dan penghapusan secara manual sesuai permintaan.

Untuk mempelajari cara Mengubah Pengambilan Data, Anda juga dapat merujuk ke episode Data Yang Diekspos ini.

Pertimbangan performa

Dampak performa dari mengaktifkan perubahan pengambilan data pada Azure SQL Database mirip dengan dampak performa mengaktifkan CDC untuk SQL Server atau Azure SQL Managed Instance. Di bawah ini adalah beberapa aspek yang memengaruhi dampak performa mengaktifkan CDC:

  • Jumlah tabel yang diaktifkan CDC terlacak
  • Frekuensi perubahan dalam tabel terlacak
  • Ruang yang tersedia dalam database sumber, karena artefak CDC (misalnya tabel CT, cdc_jobs dll.) disimpan dalam database yang sama
  • Apakah database tunggal atau terkumpul. Untuk database dalam kumpulan elastis, selain mempertimbangkan jumlah tabel yang mengaktifkan CDC, perhatikan jumlah database tempat tabel tersebut berada. Database dalam kumpulan berbagi sumber daya di antaranya (seperti ruang disk), sehingga mengaktifkan CDC pada beberapa database menjalankan risiko mencapai ukuran maksimum ukuran disk kumpulan elastis. Pantau sumber daya seperti CPU, memori, dan throughput log.

Untuk memberikan panduan pengoptimalan performa yang lebih spesifik kepada pelanggan, detail lebih lanjut diperlukan pada beban kerja setiap pelanggan. Namun, di bawah ini adalah beberapa panduan umum tambahan, berdasarkan pengujian performa yang dijalankan pada beban kerja TPCC:

  • Pertimbangkan untuk meningkatkan jumlah vCore atau beralih ke tingkat database yang lebih tinggi (misalnya Hyperscale) untuk memastikan tingkat performa yang sama seperti sebelum CDC diaktifkan pada Azure SQL Database Anda.

  • Pantau pemanfaatan ruang dengan cermat dan uji beban kerja Anda secara menyeluruh sebelum mengaktifkan CDC pada database dalam produksi.

  • Memantau laju pembuatan log. Untuk mempelajari lebih lanjut di sini.

  • Pemindaian/pembersihan adalah bagian dari beban kerja pengguna (sumber daya pengguna digunakan). Dampak performa dapat bersifat substansial karena seluruh baris ditambahkan untuk mengubah tabel dan untuk operasi pembaruan pra-gambar juga disertakan.

  • Kumpulan Elastis - Jumlah database yang diaktifkan CDC tidak boleh melebihi jumlah vCore kumpulan, untuk menghindari peningkatan latensi. Pelajari selengkapnya tentang manajemen sumber daya di Kumpulan Elastis yang padat di sini.

  • Pembersihan - berdasarkan beban kerja pelanggan, mungkin disarankan untuk menjaga periode retensi lebih kecil dari default 3 hari, untuk memastikan bahwa pembersihan mengejar semua perubahan dalam tabel perubahan. Secara umum, ada baiknya untuk menjaga retensi tetap rendah dan melacak ukuran database.

  • Tidak ada Perjanjian Tingkat Layanan (SLA) yang disediakan ketika perubahan akan diisi ke tabel perubahan. Latensi sub-detik juga tidak didukung.

Aliran data

Ilustrasi berikut menunjukkan aliran data utama untuk mengubah pengambilan data.

Change data capture data flow

Sumber data perubahan untuk tangkapan data perubahan adalah log transaksi SQL Server. Saat sisipan, pembaruan, dan penghapusan diterapkan ke tabel sumber terlacak, entri yang menjelaskan perubahan tersebut ditambahkan ke log. Log berfungsi sebagai input untuk proses pengambilan. Ini membaca log dan menambahkan informasi tentang perubahan pada tabel perubahan terkait tabel yang dilacak. Fungsi disediakan untuk menghitung perubahan yang muncul di tabel perubahan pada rentang tertentu, menampilkan informasi dalam bentuk tataan hasil yang difilter. Tataan hasil yang difilter biasanya digunakan oleh proses aplikasi untuk memperbarui representasi sumber di beberapa lingkungan eksternal.

Mengambil instans

Sebelum perubahan pada setiap tabel individual dalam database dapat dilacak, ubah pengambilan data harus diaktifkan secara eksplisit untuk database. Ini dilakukan dengan menggunakan prosedur tersimpan sys.sp_cdc_enable_db. Saat database diaktifkan, tabel sumber dapat diidentifikasi sebagai tabel terlacak dengan menggunakan prosedur tersimpan sys.sp_cdc_enable_table. Saat tabel diaktifkan untuk mengubah pengambilan data, instans pengambilan terkait dibuat untuk mendukung penyebaran data perubahan dalam tabel sumber. Instans pengambilan terdiri dari tabel perubahan dan hingga dua fungsi kueri. Metadata yang menjelaskan detail konfigurasi instans pengambilan dipertahankan dalam tabel metadata tangkapan data perubahan cdc.change_tables, cdc.index_columns, dan cdc.captured_columns. Informasi ini dapat diambil dengan menggunakan prosedur tersimpan sys.sp_cdc_help_change_data_capture.

Semua objek yang terkait dengan instans pengambilan dibuat dalam skema pengambilan data perubahan database yang diaktifkan. Persyaratan untuk nama instans pengambilan adalah nama objek yang valid, dan unik di seluruh instans pengambilan database. Secara default, namanya adalah <nama>skema name_table dari tabel sumber. Tabel perubahan terkait dinamai dengan menambahkan _CT ke nama instans tangkapan. Fungsi yang digunakan untuk mengkueri semua perubahan dinamai dengan menambahkan fn_cdc_get_all_changes_ ke nama instans pengambilan. Jika instans pengambilan dikonfigurasi untuk mendukung perubahan bersih, fungsi kueri net_changes juga dibuat dan dinamai dengan menambahkan fn_cdc_get_net_changes_ ke nama instans pengambilan.

Ubah tabel

Lima kolom pertama dari tabel perubahan tangkapan data perubahan adalah kolom metadata. Ini memberikan informasi tambahan yang relevan dengan perubahan yang direkam. Kolom yang tersisa mencerminkan kolom yang diambil yang diidentifikasi dari tabel sumber dalam nama dan, biasanya, dalam jenis. Kolom ini menyimpan data kolom yang diambil yang dikumpulkan dari tabel sumber.

Setiap operasi sisipkan atau hapus yang diterapkan ke tabel sumber muncul sebagai baris tunggal dalam tabel perubahan. Kolom data dari baris yang dihasilkan dari operasi penyisipan berisi nilai kolom setelah penyisipan. Kolom data dari baris yang dihasilkan dari operasi penghapusan berisi nilai kolom sebelum penghapusan. Operasi pembaruan memerlukan entri satu baris untuk mengidentifikasi nilai kolom sebelum pembaruan, dan entri baris kedua untuk mengidentifikasi nilai kolom setelah pembaruan.

Setiap baris dalam tabel perubahan juga berisi metadata tambahan untuk memungkinkan interpretasi aktivitas perubahan. Kolom __$start_lsn mengidentifikasi nomor urutan log penerapan (LSN) yang ditetapkan untuk perubahan. LSN penerapan mengidentifikasi perubahan yang dilakukan dalam transaksi yang sama, dan memerintahkan transaksi tersebut. Kolom __$seqval dapat digunakan untuk memesan lebih banyak perubahan yang terjadi dalam transaksi yang sama. Kolom __$operation mencatat operasi yang terkait dengan perubahan: 1 = penghapusan, 2 = penyisipan, 3 = pembaruan (sebelum gambar), dan 4 = pembaruan (setelah gambar). Kolom __$update_mask adalah masker bit variabel dengan satu bit yang ditentukan untuk setiap kolom yang diambil. Untuk entri sisipkan dan hapus, masker pembaruan akan selalu mengatur semua bit. Namun, memperbarui baris hanya akan memiliki bit yang sesuai dengan kolom yang diubah.

Interval validitas

Interval validitas tangkapan data perubahan untuk database adalah waktu di mana data perubahan tersedia untuk instans pengambilan. Interval validitas dimulai ketika instans pengambilan pertama dibuat untuk tabel database, dan berlanjut ke waktu saat ini.

Database

Data yang disimpan dalam tabel perubahan akan tumbuh tidak terkendali jika Anda tidak memangkas data secara berkala dan sistematis. Proses pembersihan penangkapan data perubahan bertanggung jawab untuk memberlakukan kebijakan pembersihan berbasis retensi. Pertama, ini memindahkan titik akhir rendah dari interval validitas untuk memenuhi pembatasan waktu. Kemudian, ini menghapus entri tabel perubahan yang kedaluwarsa. Secara default, tiga hari data dipertahankan.

Di ujung atas, saat proses penangkapan menerapkan setiap batch data perubahan baru, entri baru ditambahkan ke cdc.lsn_time_mapping untuk setiap transaksi yang memiliki entri tabel perubahan. Dalam tabel pemetaan, Nomor Urutan Log (LSN) penerapan dan waktu penerapan transaksi (kolom start_lsn dan tran_end_time, masing-masing) dipertahankan. Nilai LSN maksimum yang ditemukan di cdc.lsn_time_mapping mewakili tanda air tinggi dari jendela validitas database. Waktu penerapan yang sesuai digunakan sebagai dasar dari mana pembersihan berbasis retensi menghitung tanda air rendah baru.

Karena proses pengambilan mengekstrak data perubahan dari log transaksi, ada latensi bawaan antara waktu perubahan dilakukan pada tabel sumber dan waktu perubahan muncul dalam tabel perubahan terkait. Meskipun latensi ini biasanya kecil, namun penting untuk diingat bahwa perubahan data tidak tersedia sampai proses penangkapan telah memproses entri log terkait.

Mengambil instans

Meskipun umum untuk interval validitas database dan interval validitas instans pengambilan individu bertepatan, ini tidak selalu benar. Interval validitas instans pengambilan dimulai ketika proses pengambilan mengenali instans pengambilan dan mulai mencatat perubahan terkait pada tabel perubahannya. Akibatnya, jika instans pengambilan dibuat pada waktu yang berbeda, masing-masing pada awalnya akan memiliki titik akhir rendah yang berbeda. Kolom start_lsn dari kumpulan hasil yang dikembalikan oleh sys.sp_cdc_help_change_data_capture menunjukkan titik akhir rendah saat ini untuk setiap instans pengambilan yang ditentukan. Ketika proses pembersihan membersihkan entri tabel perubahan, proses ini menyesuaikan nilai start_lsn untuk semua instans tangkapan untuk mencerminkan tanda air rendah baru untuk data perubahan yang tersedia. Hanya instans tangkapan yang memiliki nilai start_lsn yang saat ini kurang dari tanda air rendah baru yang disesuaikan. Seiring waktu, jika tidak ada instans pengambilan baru yang dibuat, interval validitas untuk semua instans individu akan cenderung bertepatan dengan interval validitas database.

Interval validitas penting bagi konsumen data perubahan karena interval ekstraksi untuk permintaan harus sepenuhnya dicakup oleh interval validitas tangkapan data perubahan saat ini untuk instans pengambilan. Jika titik akhir rendah interval ekstraksi berada di sebelah kiri titik akhir rendah interval validitas, mungkin ada data perubahan yang hilang karena pembersihan agresif. Jika titik akhir tinggi interval ekstraksi berada di sebelah kanan titik akhir tinggi interval validitas, proses penangkapan belum diproses melalui periode waktu yang diwakili oleh interval ekstraksi, dan data perubahan juga dapat hilang.

Fungsi sys.fn_cdc_get_min_lsn digunakan untuk mengambil LSN minimum saat ini untuk instans pengambilan, sementara sys.fn_cdc_get_max_lsn digunakan untuk mengambil nilai LSN maksimum saat ini. Saat mengkueri data perubahan, jika rentang LSN yang ditentukan tidak terletak di dalam dua nilai LSN ini, fungsi kueri penangkapan data perubahan akan gagal.

Menangani perubahan pada tabel sumber

Untuk mengakomodasi perubahan kolom dalam tabel sumber yang sedang dilacak adalah masalah yang sulit bagi konsumen hilir. Meskipun mengaktifkan pengambilan data perubahan pada tabel sumber tidak mencegah perubahan DDL seperti itu terjadi, tangkapan data perubahan membantu mengurangi efek pada konsumen dengan memungkinkan kumpulan hasil yang dikirimkan yang dikembalikan melalui API untuk tetap tidak berubah bahkan saat struktur kolom tabel sumber yang mendasar berubah. Struktur kolom tetap ini juga tercermin dalam tabel perubahan yang mendasar yang diakses fungsi kueri yang ditentukan.

Untuk mengakomodasi tabel perubahan struktur kolom tetap, proses pengambilan yang bertanggung jawab untuk mengisi tabel perubahan akan mengabaikan kolom baru yang tidak diidentifikasi untuk diambil ketika tabel sumber diaktifkan untuk mengubah pengambilan data. Jika kolom terlacak dihilangkan, nilai null akan disediakan untuk kolom dalam entri perubahan berikutnya. Namun, jika kolom yang ada mengalami perubahan dalam jenis datanya, perubahan disebarluaskan ke tabel perubahan untuk memastikan bahwa mekanisme penangkapan tidak menyebabkan kehilangan data ke kolom terlacak. Proses pengambilan juga memposting setiap perubahan yang terdeteksi pada struktur kolom tabel terlacak ke tabel cdc.ddl_history. Konsumen yang ingin diberi tahu tentang penyesuaian yang mungkin harus dilakukan dalam aplikasi hilir, gunakan prosedur tersimpan sys.sp_cdc_get_ddl_history.

Biasanya, instans pengambilan saat ini akan terus mempertahankan bentuknya ketika perubahan DDL diterapkan ke tabel sumber terkait. Namun, dimungkinkan untuk membuat instans pengambilan kedua untuk tabel yang mencerminkan struktur kolom baru. Ini memungkinkan proses pengambilan untuk membuat perubahan pada tabel sumber yang sama menjadi dua tabel perubahan berbeda yang memiliki dua struktur kolom yang berbeda. Dengan demikian, sementara satu tabel perubahan dapat terus memberi umpan program operasional saat ini, yang kedua dapat mendorong lingkungan pengembangan yang mencoba menggabungkan data kolom baru. Mengizinkan mekanisme penangkapan untuk mengisi kedua tabel perubahan bersamaan berarti bahwa transisi dari satu ke tabel lainnya dapat dicapai tanpa kehilangan data perubahan. Ini dapat terjadi kapan saja dua garis waktu pengambilan data perubahan tumpang tindih. Ketika transisi terpengaruh, instans pengambilan usang dapat dihapus.

Catatan

Jumlah maksimum instans pengambilan yang dapat dikaitkan secara bersamaan dengan satu tabel sumber adalah dua.

Hubungan dengan agen pembaca log

Logika untuk proses pengambilan data perubahan disematkan dalam prosedur tersimpan sp_replcmds, fungsi server internal yang dibangun sebagai bagian dari sqlservr.exe dan juga digunakan oleh replikasi transaksional untuk memanen perubahan dari log transaksi. Dalam SQL Server dan Azure SQL Managed Instance, saat mengubah tangkapan data saja diaktifkan untuk database, Anda membuat perubahan tangkapan data SQL Server Agent mengambil pekerjaan sebagai kendaraan untuk memanggil sp_replcmds. Ketika replikasi juga ada, logreader transaksional saja digunakan untuk memenuhi kebutuhan data perubahan untuk kedua konsumen ini. Strategi ini secara signifikan mengurangi ketidakcocokan log ketika replikasi dan mengubah tangkapan data diaktifkan untuk database yang sama.

Peralihan antara kedua mode operasional ini untuk menangkap data perubahan terjadi secara otomatis setiap kali ada perubahan status replikasi database yang diaktifkan tangkapan data perubahan.

Catatan

Dalam SQL Server dan Azure SQL Managed Instance, kedua instans logika penangkapan mengharuskan SQL Server Agent berjalan agar proses dijalankan.

Tugas utama proses pengambilan adalah memindai data kolom log dan tulis serta informasi terkait transaksi ke tabel perubahan tangkapan data perubahan. Untuk memastikan batas yang konsisten secara transaksional di semua tabel perubahan tangkapan data perubahan yang diisinya, proses pengambilan terbuka dan melakukan transaksinya sendiri pada setiap siklus pemindaian. Ini mendeteksi kapan tabel baru diaktifkan untuk mengubah pengambilan data, dan secara otomatis menyertakannya dalam kumpulan tabel yang secara aktif dipantau untuk entri perubahan di log. Demikian pula, menonaktifkan tangkapan data perubahan juga akan terdeteksi, menyebabkan tabel sumber dihapus dari kumpulan tabel yang dipantau secara aktif untuk data perubahan. Saat pemrosesan untuk bagian log selesai, proses pengambilan memberi sinyal logika pemotongan log server, yang menggunakan informasi ini untuk mengidentifikasi entri log yang memenuhi syarat untuk pemotongan.

Catatan

Ketika database diaktifkan untuk mengubah pengambilan data, bahkan jika mode pemulihan diatur ke pemulihan sederhana, titik pemotongan log tidak akan maju sampai semua perubahan yang ditandai untuk tangkapan telah dikumpulkan oleh proses pengambilan. Jika proses pengambilan tidak berjalan dan ada perubahan yang akan dikumpulkan, menjalankan CHECKPOINT tidak akan memotong log.

Proses pengambilan juga digunakan untuk mempertahankan riwayat pada perubahan DDL pada tabel terlacak. Pernyataan DDL yang terkait dengan tangkapan data perubahan membuat entri ke log transaksi database setiap kali database atau tabel yang mendukung pengambilan data perubahan dihilangkan atau kolom tabel yang mendukung tangkapan data perubahan ditambahkan, dimodifikasi, atau dihilangkan. Entri log ini diproses oleh proses pengambilan, yang kemudian memposting peristiwa DDL terkait ke tabel cdc.ddl_history. Anda dapat memperoleh informasi tentang peristiwa DDL yang memengaruhi tabel terlacak dengan menggunakan prosedur tersimpan sys.sp_cdc_get_ddl_history.

Pekerjaan agen

Dua pekerjaan SQL Server Agent biasanya dikaitkan dengan database yang diaktifkan tangkapan data perubahan: yang digunakan untuk mengisi tabel perubahan database, dan yang bertanggung jawab untuk pembersihan tabel perubahan. Kedua pekerjaan terdiri dari satu langkah yang menjalankan perintah Transact-SQL. Perintah Transact-SQL yang dipanggil adalah prosedur tersimpan yang ditentukan tangkapan data perubahan yang mengimplementasikan logika pekerjaan. Pekerjaan dibuat saat tabel pertama database diaktifkan untuk mengubah pengambilan data. Pekerjaan Pembersihan selalu dibuat. Pekerjaan pengambilan hanya akan dibuat jika tidak ada publikasi transaksi yang ditentukan untuk database. Pekerjaan pengambilan juga dibuat ketika tangkapan data perubahan dan replikasi transaksional diaktifkan untuk database, dan pekerjaan pembaca log transaksional dihapus karena database tidak lagi menentukan publikasi.

Pekerjaan penangkapan dan pembersihan dibuat dengan menggunakan parameter default. Pekerjaan penangkapan segera dimulai. Ini berjalan terus menerus, memproses maksimum 1000 transaksi per siklus pemindaian dengan menunggu 5 detik antar siklus. Pekerjaan pembersihan berjalan setiap hari pada pukul 2 pagi. Ini mempertahankan entri tabel perubahan selama 4320 menit atau 3 hari, menghapus maksimum 5000 entri dengan satu pernyataan penghapusan.

Pekerjaan agen penangkapan data perubahan dihapus saat tangkapan data perubahan dinonaktifkan untuk database. Pekerjaan pengambilan juga dapat dihapus ketika publikasi pertama ditambahkan ke database, dan mengubah pengambilan data dan replikasi transaksional diaktifkan.

Secara internal, mengubah pekerjaan agen penangkapan data dibuat dan dihilangkan dengan menggunakan prosedur tersimpan sys.sp_cdc_add_job dan sys.sp_cdc_drop_job. Prosedur tersimpan ini juga diekspos sehingga administrator dapat mengontrol pembuatan dan penghapusan pekerjaan ini.

Administrator tidak memiliki kontrol eksplisit atas konfigurasi default pekerjaan agen penangkapan data perubahan. Prosedur tersimpan sys.sp_cdc_change_job disediakan untuk memungkinkan parameter konfigurasi default dimodifikasi. Selain itu, prosedur tersimpan sys.sp_cdc_help_jobs memungkinkan parameter konfigurasi saat ini untuk dilihat. Pekerjaan penangkapan dan pekerjaan pembersihan mengekstrak parameter konfigurasi dari tabel msdb.dbo.cdc_jobs saat startup. Setiap perubahan yang dilakukan pada nilai-nilai ini dengan menggunakan sys.sp_cdc_change_job tidak akan berlaku sampai pekerjaan dihentikan dan dimulai ulang.

Dua prosedur tersimpan tambahan disediakan untuk memungkinkan pekerjaan agen penangkapan data perubahan dimulai dan dihentikan: sys.sp_cdc_start_job dan sys.sp_cdc_stop_job.

Catatan

Memulai dan menghentikan pekerjaan pengambilan tidak mengakibatkan hilangnya data perubahan. Ini hanya mencegah proses penangkapan secara aktif memindai log untuk entri perubahan untuk disimpan dalam tabel perubahan. Strategi yang wajar untuk mencegah pemindaian log menambahkan beban selama periode permintaan puncak adalah menghentikan pekerjaan penangkapan dan memulai ulang ketika permintaan berkurang.

Kedua pekerjaan SQL Server Agent dirancang agar cukup fleksibel dan cukup dapat dikonfigurasi untuk memenuhi kebutuhan dasar lingkungan penangkapan data perubahan. Namun, dalam kedua kasus, prosedur tersimpan yang mendasar yang menyediakan fungsionalitas inti telah diekspos sehingga penyesuaian lebih lanjut dimungkinkan.

Mengubah tangkapan data tidak dapat berfungsi dengan baik ketika layanan Mesin Database atau layanan SQL Server Agent berjalan di bawah akun NETWORK SERVICE. Ini dapat mengakibatkan kesalahan 22832.

Catatan

Dalam Azure SQL Database, Pekerjaan Agen digantikan oleh penjadwal yang menjalankan pengambilan dan pembersihan secara otomatis.

Pembersihan CDC di Azure SQL Database

Pada Azure SQL Database, penjadwal pengambilan data perubahan menggantikan Agen SQL Server yang memanggil prosedur yang disimpan guna memulai pengambilan dan penghapusan berkala dari tabel pengambilan data perubahan. Penjadwal menjalankan pengambilan dan pembersihan secara otomatis dalam SQL Database, tanpa dependensi eksternal untuk keandalan atau performa. Pengguna masih memiliki opsi untuk menjalankan pengambilan dan pembersihan secara manual sesuai permintaan menggunakan prosedur sp_cdc_scan dan sp_cdc_cleanup_change_tables .

Azure SQL Database menyertakan dua tampilan manajemen dinamis untuk membantu Anda memantau perubahan pengambilan data: sys.dm_cdc_log_scan_sessions dan sys.dm_cdc_errors.

Perbedaan kolabasi

Penting untuk mengetahui situasi di mana Anda memiliki kolase yang berbeda antara database dan kolom tabel yang dikonfigurasi untuk mengubah tangkapan data. CDC menggunakan penyimpanan sementara untuk mengisi tabel samping. Jika tabel memiliki kolom CHAR atau VARCHAR dengan kolase yang berbeda dari kolase database dan jika kolom tersebut menyimpan karakter non-ASCII (seperti karakter DBCS byte ganda), CDC mungkin tidak dapat mempertahankan data yang diubah konsisten dengan data dalam tabel dasar. Hal ini disebabkan oleh fakta bahwa variabel penyimpanan sementara tidak dapat memiliki kolase yang terkait dengannya.

Harap pertimbangkan salah satu pendekatan berikut untuk memastikan perubahan data yang diambil konsisten dengan tabel dasar:

  • Gunakan jenis data NCHAR atau NVARCHAR untuk kolom yang berisi data non-ASCII.

  • Atau, Gunakan kolatasi yang sama untuk kolom dan untuk database.

Misalnya, jika Anda memiliki satu database yang menggunakan kolab SQL_Latin1_General_CP1_CI_AS, pertimbangkan tabel berikut:

CREATE TABLE T1( 
     C1 INT PRIMARY KEY, 
     C2 VARCHAR(10) collate Chinese_PRC_CI_AI)

CDC mungkin gagal mengambil data biner untuk kolom C2, karena kolabnya berbeda (Chinese_PRC_CI_AI). Gunakan NVARCHAR untuk menghindari masalah ini:

CREATE TABLE T1( 
     C1 INT PRIMARY KEY, 
     C2 NVARCHAR(10) collate Chinese_PRC_CI_AI --Unicode data type, CDC works well with this data type
     )

Izin yang diperlukan

Izin adminsis diperlukan untuk mengaktifkan pengambilan data perubahan untuk SQL Server atau Azure SQL Managed Instance. Peran db_owner diperlukan untuk mengaktifkan perubahan pengambilan data untuk Azure SQL Database.

Batasan

Ubah pengambilan data memiliki batasan berikut:

Linux
CDC sekarang didukung untuk SQL Server 2017 di Linux yang dimulai dengan CU18, dan SQL Server 2019 di Linux.

Panduan Indeks Penyimpan Kolom
Mengubah pengambilan data tidak dapat diaktifkan pada tabel dengan indeks penyimpan kolom berkluster. Dimulai dengan SQL Server 2016, dapat diaktifkan pada tabel dengan indeks penyimpan kolom yang tidak berkluster.

Pengalihan partisi dengan variabel
Menggunakan variabel dengan pengalihan partisi pada database atau tabel dengan change data capture (CDC) tidak didukung untuk pernyataan tersebut ALTER TABLE ... SWITCH TO ... PARTITION ... . Lihat batasan pengalihan partisi untuk mempelajari selengkapnya.

Ketersediaan CDC di Database Azure SQL
CDC hanya dapat diaktifkan pada tingkat database S3 ke atas. Sub-core (Dasar, S0, S1, S2) Azure SQL Database tidak didukung untuk CDC.

Dbcopy dari tingkat database di atas S3 yang mengaktifkan CDC ke SLO sub-inti saat ini mempertahankan artefak CDC, tetapi artefak CDC dapat dihapus di masa mendatang.

Kustomisasi Pengambilan dan Pembersihan pada Database Azure SQL
Mengonfigurasi frekuensi pengambilan dan proses pembersihan untuk CDC di Database Azure SQL tidak dimungkinkan. Pengambilan dan pembersihan dijalankan secara otomatis oleh penjadwal.

Kolom komputasi
CDC tidak mendukung nilai untuk kolom komputasi meskipun kolom komputasi didefinisikan sebagai bertahan. Kolom komputasi yang disertakan dalam instans pengambilan selalu memiliki nilai NULL. Perilaku ini dimaksudkan, dan bukan bug.

Pemulihan titik waktu (PitR)
Jika Anda mengaktifkan CDC pada database Anda sebagai pengguna Microsoft Azure Active Directory (Azure AD), tidak dimungkinkan untuk Pemulihan titik waktu (PITR) ke SLO sub-inti. Disarankan agar Anda memulihkan database ke yang sama dengan sumber atau SLO yang lebih tinggi, lalu menonaktifkan CDC jika perlu.

Microsoft Azure Active Directory (Azure AD)
Jika Anda membuat database di Azure SQL Database sebagai pengguna Microsoft Azure Active Directory (Azure AD) dan mengaktifkan change data capture (CDC) di dalamnya, pengguna SQL (misalnya, bahkan peran sysadmin) tidak akan dapat menonaktifkan/membuat perubahan pada artefak CDC. Namun, pengguna Azure AD lainnya akan dapat mengaktifkan atau menonaktifkan CDC di database yang sama.

Demikian pula, jika Anda membuat Azure SQL Database sebagai pengguna SQL, mengaktifkan/menonaktifkan pengambilan data perubahan karena pengguna Azure AD tidak akan berfungsi.

Pemotongan log agresif
Saat mengaktifkan change data capture (CDC) pada Azure SQL Database Anda, perlu diketahui bahwa pemotongan log agresif dinonaktifkan (pemindaian CDC menggunakan log transaksi database).

Mengaktifkan change data capture (CDC) pada database menonaktifkan perilaku pemotongan log yang agresif. Transaksi aktif akan terus menahan pemotongan log transaksi sampai transaksi dilakukan dan pemindaian CDC mengejar ketinggalan, atau pembatalan transaksi. Ini dapat mengakibatkan log transaksi penuh dan database masuk ke mode baca-saja.

CDC gagal setelah MENGUBAH KOLOM ke VARCHAR dan VARBINARY
Saat tipe data kolom pada tabel berkemampuan CDC diubah dari TEXT ke VARCHAR atau IMAGE ke VARBINARY dan baris yang sudah ada diperbarui ke nilai di luar baris. Setelah pembaruan, pemindaian CDC akan mengakibatkan kesalahan.

Mengaktifkan CDC gagal pada Azure SQL DB yang dipulihkan yang dibuat dengan Microsoft Azure Active Directory (Azure AD)
Mengaktifkan CDC akan gagal jika Anda membuat database di Azure SQL Database sebagai pengguna Microsoft Azure Active Directory (Azure AD) dan tidak mengaktifkan CDC, lalu memulihkan database dan mengaktifkan CDC pada database yang dipulihkan.

Untuk mengatasi masalah ini, ikuti langkah-langkah ini:

  • Masuk sebagai admin Azure AD server
  • Jalankan perintah ALTER AUTHORIZATION pada database:
ALTER AUTHORIZATION ON DATABASE::[<restored_db_name>] TO [<azuread_admin_login_name>];

EXEC sys.sp_cdc_enable_db

Lihat juga

Lacak Perubahan Data (SQL Server)
Mengaktifkan dan Menonaktifkan perubahan pengambilan data (SQL Server)
Bekerja dengan Ubah Data (SQL Server)
Mengelola dan Memantau perubahan pengambilan data (SQL Server)
Tabel Temporal