Kapan menggunakan CDC untuk melacak riwayat?

26

SQL Server Change Data Capture adalah fitur yang membaca data historis dari log transaksi SQL Server dan menyimpannya dalam tabel khusus.

Melalui penggunaan fungsi nilai tabel khusus (TVF) maka memungkinkan pengguna untuk menanyakan data ini, sehingga memungkinkan untuk mendapatkan semua perubahan pada tabel tertentu atau hanya perubahan bersih yang dihasilkan dari perubahan dalam waktu tertentu.

CDC memiliki kelebihan tertentu

Itu dapat dikonfigurasi untuk hanya melacak tabel atau kolom tertentu.
Ia mampu menangani perubahan model hingga tingkat tertentu.
Itu tidak mempengaruhi kinerja sebanyak pemicu karena bekerja dengan log transaksi.
Mudah diaktifkan / dinonaktifkan dan tidak memerlukan kolom tambahan pada tabel yang harus dilacak.

Ini juga memiliki beberapa kelemahan:

Jumlah data riwayat bisa menjadi sangat cepat.
Anda tidak dapat melacak siapa yang membuat perubahan (setidaknya tidak untuk dihapus).
Data histori memerlukan beberapa waktu untuk mengejar ketinggalan, karena didasarkan pada log transaksi.
Itu tergantung pada Agen SQL Server. Jika Agen tidak berjalan atau macet, tidak ada riwayat yang dilacak.

Saya telah membaca cukup banyak tentang CDC dan sementara saya tahu sekarang bagaimana menggunakannya, saya masih tidak yakin apakah itu alat yang tepat untuk saya.

Untuk tugas / skenario manakah CDC alat yang tepat? (mis. Mengizinkan pengguna mengembalikan objek data ke titik waktu tertentu? Audit? Menampilkan riwayat lengkap data?)
Kapan sebaiknya Anda tidak menggunakan CDC, tetapi menggunakan solusi berbasis pemicu khusus?
Apakah boleh menggunakan CDC dalam basis data operasional dan memanfaatkan data CDC dalam aplikasi operasional? (misalnya menunjukkannya kepada pengguna akhir) Atau apakah ini jelas merupakan penyalahgunaan fitur ini?

Saya biasanya mendengar bahwa CDC adalah alat audit, tetapi bukankah itu untuk apa SQL Server Audit ? Apakah keduanya alat yang berbeda untuk tugas yang sama? Atau bisakah CDC digunakan untuk hal lain?

Skenario saya saat ini adalah saya diminta untuk membangun kerangka kerja data yang andal yang seharusnya menjadi dasar untuk berbagai aplikasi di masa depan. Persyaratan yang tepat kabur, tetapi satu adalah bahwa ia harus dapat melacak riwayat data dan mengembalikan entri yang lebih lama bersama dengan semua data terkait dari tabel lain. Saya mengevaluasi CDC sekarang sebagai opsi, tetapi saya tidak yakin apakah ini cara yang harus ditempuh, karena saya tidak dapat menemukan kasus penggunaan yang direkomendasikan.

Sementara saya menghargai saran untuk skenario spesifik saya, jawaban harus memberikan saran umum tentang kapan atau kapan tidak menggunakan Ubah Data Capture.

sql-server change-data-capture data-versioning

— agung
sumber

1

Idealnya, "kerangka kerja" tidak akan membuat keputusan semacam ini; itu akan diserahkan kepada masing-masing proyek. Tetapi karena Anda diminta untuk melakukan ini, setidaknya saya akan membuat poin kepada siapa pun yang memberi Anda persyaratan ini: ada berbagai cara untuk mencapai ini, dan pilihan terbaik sangat tergantung pada penggunaan dan kebutuhan yang tepat. Tanyakan apakah mereka dapat memberi Anda klarifikasi yang dapat membantu Anda memutuskan (seperti apakah kinerja atau fleksibilitas lebih penting). Pilihan lain untuk dipertimbangkan adalah mengembangkan kedua opsi sebagai bagian dari "kerangka kerja" dan membiarkan proyek nyata memilih mana yang akan diaktifkan.

— jpmc26

@ jpmc26, kerangka kerja mungkin diperlukan untuk menghentikan setiap proyek yang menghabiskan waktu untuk memutuskan pertanyaan semacam ini.

— Ian Ringrose

@IanRingrose Maksud saya adalah bahwa mencoba membuat keputusan itu tanpa mempertimbangkan kebutuhan spesifik suatu proyek akan, dalam jangka panjang, menyebabkan lebih banyak masalah daripada menyelesaikannya (dan dengan demikian sebenarnya lebih mahal daripada menghabiskan waktu itu). Ini adalah keputusan yang tidak dapat dibuat secara efektif dalam kasus umum. Kekhasan proyek harus dipertimbangkan. Menggunakan keputusan menyeluruh, waktu akan dihabiskan menggunakan solusi yang dipilih dan membuat asumsi di sekitarnya hanya untuk asumsi-asumsi yang dilanggar ketika ditemukan itu bukan solusi yang tepat. Maka sistem perlu dirancang ulang.

— jpmc26

1

@ jpmc26 Saya mungkin benar-benar pergi dengan solusi yang Anda usulkan, kalau-kalau saya menemukan cara untuk melakukannya: Mengembangkan baik pelacakan sejarah berbasis-memicu dan berbasis CDC, switchable dan di belakang antarmuka umum. Aplikasi kemudian dapat memilih satu atau yang lain, tergantung pada persyaratannya, tetapi tidak perlu khawatir untuk mengimplementasikannya sendiri. Tentu saja saya masih ingin mendapatkan jawaban yang baik untuk pertanyaan saya di atas, karena jika CDC tidak cocok untuk tugas semacam ini (misalnya karena hanya ada gunanya untuk audit) saya mungkin menyelamatkan diri saya dari masalah dan selalu menggunakan pemicu .

— Magnattic

"Jika Agen tidak berjalan atau macet, tidak ada riwayat dilacak" - tetapi jika itu dimulai kembali, tidak ada perubahan yang akan hilang, kan?

— Andy Joiner

12

Pertama,

Perubahan pengambilan data hanya tersedia pada edisi SQL Server Enterprise, Developer, dan Evaluation.

Sehingga dapat memutuskan untuk Anda jika ada pelanggan Anda yang tidak memiliki edisi perusahaan, atau Anda belum tahu Anda akan menggunakan edisi perusahaan. (Karena spesifikasi mencakup "beberapa aplikasi masa depan" ini mungkin merupakan masalah nyata bagi Anda)

Tidak seperti pemicu, ini bukan waktu nyata, ini merupakan keuntungan dan juga kerugian. Menggunakan pemicu selalu memperlambat pembaruan.

Saya bekerja pada satu sistem ketika kami menggunakan pemicu (dihasilkan oleh CodeSmith), serta melacak semua perubahan pada catatan, kami juga menautkan perubahan bersama-sama ke tabel "riwayat" yang termasuk modul aplikasi yang membuat perubahan, dan item UI yang digunakan pengguna untuk melakukan perubahan.

Namun Anda mungkin sebaiknya menyelesaikan ini di tingkat aplikasi, dengan mengatakan menulis semua pembaruan ke antrian pesan yang kemudian diputar ulang untuk membuat database pada suatu titik waktu tertentu, lihat Pola Temporal di blog Martin Flowler untuk ikhtisar opsi yang bagus.

— Ian Ringrose
sumber

Tautan ini merupakan bacaan yang sangat menarik, terima kasih untuk itu. Namun, menyelesaikan masalah ini pada tingkat aplikasi bukan merupakan pilihan dalam kasus saya. Kerangka kerja yang saya bangun seharusnya melakukan sebagian besar pekerjaan, termasuk pelacakan riwayat, untuk aplikasi yang didasarkan padanya. Aplikasi kemudian bekerja dengan antarmuka umum untuk menyimpan / mengambil data, sehingga mereka tidak perlu peduli tentang bagaimana data disimpan. Saya sadar bahwa tugas ini jauh dari sepele.

— Magnattic

Juga, saya saat ini tidak mempertimbangkan Edisi Perusahaan atau tidak menjadi faktor penentu dalam kasus kami. Aplikasi masa depan yang saya bicarakan kemungkinan besar akan dibangun dan di-host oleh kami.

— Magnattic

@atticae, Kerangka kerja Anda tidak harus terbatas pada basis data, ia dapat menyertakan kode yang berjalan di luar basis data.

— Ian Ringrose

Ini tidak terbatas pada basis data saja. (Saya tidak akan menyebutnya kerangka dalam kasus ini.) Saya melihat apa yang Anda maksud sekarang dengan "level aplikasi" dan saat ini saya sebenarnya menggunakan variasi dari pola Properti Temporal yang dibicarakan oleh tautan Anda. Kerangka kerja yang saya bangun menyediakan antarmuka ini ke aplikasi yang menggunakannya. Namun, itu adalah bagian dari sisi antarmuka, dan tidak ada yang benar-benar menjawab pertanyaan saya yang diuraikan di atas.

— Magnattic

Sekali lagi terima kasih atas jawaban Anda. Ini mungkin faktor penentu bagi kebanyakan orang, jadi saya pikir ini adalah jawaban yang baik dan mungkin membantu pengunjung masa depan untuk memutuskan untuk tidak menggunakan CDC. Namun, saya merasa itu tidak benar-benar menjawab sebagian besar pertanyaan saya, jadi saya harus memberikan hadiah kepada stacylaray yang merupakan satu-satunya yang mencoba menjawab semua pertanyaan yang saya miliki. (Meskipun saya berharap untuk jawaban sedikit lebih rumit.)

— Magnattic

12

Berikut ini adalah seri 9 bagian yang ditulis dengan sangat baik yang mengulas berbagai cara audit perubahan data SQL Server. Bagian 3, 4 & 5 fokus pada CDC. Ada baiknya membaca semua artikel karena ini akan menjawab pertanyaan Anda, seperti skenario yang berbeda di mana fitur akan sesuai dan overhead. http://solutioncenter.apexsql.com/tag/methods-for-auditing-sql-server

— Brynn
sumber

1

Setelah membaca sekilas artikel itu, saya masih belum terlalu pintar. Karena sebagian besar artikel menjelaskan cara menggunakan CDC dan bagaimana membandingkannya dengan Ubah Pelacakan. Itu tidak benar-benar menjawab pertanyaan saya di atas.

— Magnattic

9

Untuk tugas / skenario manakah CDC alat yang tepat? (mis. Mengizinkan pengguna mengembalikan objek data ke titik waktu tertentu?

Mungkin itu tergantung.

Mengaudit?

Iya nih.

Menampilkan riwayat lengkap data?)

Iya nih.

Kapan sebaiknya Anda tidak menggunakan CDC, tetapi menggunakan solusi berbasis pemicu khusus?

Ketika data dalam tabel perubahan tidak memenuhi kebutuhan Anda.

Apakah boleh menggunakan CDC dalam basis data operasional dan memanfaatkan data CDC dalam aplikasi operasional? (misalnya menunjukkannya kepada pengguna akhir)

Iya nih.

Atau apakah ini jelas merupakan penyalahgunaan fitur ini?

Tidak, ini bukan penyalahgunaan fitur ini.

Saya biasanya mendengar bahwa CDC adalah alat audit, tetapi bukankah itu maksud dari SQL Server Audit?

Iya nih.

Apakah keduanya alat yang berbeda untuk tugas yang sama?

Tidak.

Atau bisakah CDC digunakan untuk hal lain?

CDC dapat digunakan untuk hal-hal lain.

Ada Ubah Pelacakan dan ada Ubah Data Capture. Keduanya memiliki akar dalam replikasi.

Change Tracking menyediakan cara untuk memberikan perubahan bersih ke sebuah tabel. Contoh penggunaan adalah sinkronisasi perangkat genggam.

CDC, di sisi lain, melacak setiap perubahan kecil, sejarah. Seseorang dapat menggunakan riwayat itu untuk memperbarui gudang data alih-alih menyalin secara massal dalam data, atau seseorang dapat menggunakan riwayat itu sebagai data itu sendiri dan menghasilkan laporan darinya. Tabel perubahan tidak disembunyikan juga tidak memiliki skema aneh atau sesuatu. Anda dapat menanyakannya dan menggunakan data sesuka Anda. Hanya perlu diingat ... ini bukan real time, seperti kata Ian. Data berasal dari log transaksi, jadi berhati-hatilah seperti Anda akan menggunakan replikasi, atau mirroring, atau pengiriman log. Pada umumnya, ini akan lebih cepat dari pemicu. Anda perlu menggunakan Isolasi Snapshot, yang memiliki overhead, dan Anda harus memikirkan Disaster Recovery.

— stacylaray
sumber

2

Titik koreksi. Pada suatu waktu, perubahan pengambilan data hanya tersedia dalam versi yang tercantum di atas. Namun, perubahan pengambilan data menjadi tersedia dalam edisi standar pada 2016 SP1. Jadi, banyak artikel yang ditulis sebelum SP1 2016 membuatnya terdengar seolah-olah CDC tidak terjangkau bagi kita yang menggunakan edisi Standar. Ini bukan lagi masalahnya. Dokumen Microsoft yang menguraikan ketersediaan CDC ada di tautan di bawah ini.

https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2016?view=sql-server-2017#DW

— Robert Sievers
sumber