Anda benar-benar tidak memiliki banyak cara untuk mendeteksi perubahan di SQL 2005. Anda sudah mendaftarkan sebagian besar dari mereka.
Pemberitahuan Kueri . Ini adalah teknologi yang mendukung SqlDependency dan turunannya, Anda dapat membaca detail selengkapnya di Pemberitahuan Misterius . Tapi QN dirancang untuk membatalkan hasil, bukan untuk secara proaktif memberitahukan perubahan konten. Anda hanya akan tahu bahwa tabel mengalami perubahan, tanpa mengetahui apa yang berubah. Pada sistem yang sibuk, ini tidak akan berfungsi, karena notifikasi akan datang terus menerus.
Pembacaan log . Inilah yang digunakan replikasi transaksional dan merupakan cara yang paling tidak mengganggu untuk mendeteksi perubahan. Sayangnya hanya tersedia untuk komponen internal. Bahkan jika Anda berhasil memahami format log, masalahnya adalah Anda memerlukan dukungan dari mesin untuk menandai log sebagai 'sedang digunakan' sampai Anda membacanya, atau mungkin akan ditimpa. Hanya replikasi transaksional yang dapat melakukan penandaan khusus semacam ini.
Perbandingan data . Andalkan kolom stempel waktu untuk mendeteksi perubahan. Juga berbasis pull, cukup mengganggu dan memiliki masalah dalam mendeteksi penghapusan.
Lapisan Aplikasi . Ini adalah opsi terbaik dalam teori, kecuali jika ada perubahan yang terjadi pada data di luar cakupan aplikasi, yang dalam hal ini akan hancur. Dalam praktiknya ada selalu perubahan yang terjadi di luar cakupan aplikasi.
Pemicu . Pada akhirnya, ini adalah satu-satunya pilihan yang layak. Semua mekanisme perubahan berdasarkan pemicu bekerja dengan cara yang sama, mereka mengantri pemberitahuan perubahan ke komponen yang memantau antrean.
Selalu ada saran untuk melakukan pemberitahuan sinkron yang digabungkan erat (melalui xp_cmdshell, xp_olecreate, CLR, beri tahu dengan WCF, sebut saja), tetapi semua skema ini gagal dalam praktiknya karena pada dasarnya cacat:
- mereka tidak memperhitungkan konsistensi transaksi dan rollback
- mereka memperkenalkan dependensi ketersediaan (sistem OLTP tidak dapat melanjutkan kecuali komponen yang diberi tahu sedang online)
- mereka berkinerja buruk karena setiap operasi DML harus menunggu panggilan RPC dalam beberapa bentuk untuk menyelesaikan
Jika pemicu sebenarnya tidak secara aktif memberi tahu pendengar, tetapi hanya mengantre notifikasi, ada masalah dalam memantau antrian notifikasi (ketika saya mengatakan 'antrian', maksud saya tabel apa pun yang bertindak sebagai antrian). Pemantauan menyiratkan menarik entri baru dalam antrian, yang berarti menyeimbangkan frekuensi pemeriksaan dengan benar dengan beban perubahan, dan bereaksi terhadap lonjakan beban. Ini sama sekali tidak sepele, sebenarnya sangat sulit. Namun, ada satu pernyataan di SQL server yang memiliki semantik untuk memblokir, tanpa menarik, hingga perubahan tersedia:MENUNGGU(TERIMA) . Itu berarti Pialang Layanan. Anda menyebutkan SSB beberapa kali di posting Anda, tetapi Anda, memang seharusnya begitu, takut menyebarkannya karena hal yang tidak diketahui. Namun kenyataannya, sejauh ini, tugas tersebut paling sesuai untuk tugas yang Anda jelaskan.
Anda tidak perlu menerapkan arsitektur SSB penuh, di mana pemberitahuan dikirimkan sepenuhnya ke layanan jarak jauh (yang akan memerlukan instance SQL jarak jauh, bahkan yang Express). Yang perlu Anda lakukan hanyalah memisahkan saat perubahan terdeteksi (pemicu DML) dari saat pemberitahuan dikirimkan (setelah perubahan dilakukan). Untuk ini yang Anda butuhkan hanyalah antrian dan layanan SSB lokal. Di pemicu, Anda KIRIM pemberitahuan perubahan ke layanan lokal. Setelah transaksi DML asli dilakukan, prosedur layanan mengaktifkan dan mengirimkan notifikasi, menggunakan CLR misalnya. Anda dapat melihat contoh sesuatu yang mirip dengan ini di Asynchronous T-SQL .
Jika Anda menempuh jalan itu, ada beberapa trik yang perlu Anda pelajari untuk mencapai hasil yang tinggi dan Anda harus memahami konsep pengiriman pesan yang teratur di SSB. Saya sarankan Anda membaca tautan ini:
Tentang cara mendeteksi perubahan, SQL 2008 tampaknya menambahkan opsi baru:Ubah Pengambilan Data dan Ubah Pelacakan . Saya menekankan 'tampaknya', karena itu bukan teknologi yang benar-benar baru. CDC menggunakan pembaca log dan didasarkan pada mekanisme replikasi Transaksional yang ada. CT menggunakan pemicu dan sangat mirip dengan mekanisme replikasi Gabung yang ada. Keduanya dimaksudkan untuk terhubung sesekali sistem yang perlu disinkronkan dan karenanya tidak sesuai untuk pemberitahuan perubahan waktu nyata. Mereka dapat mengisi tabel perubahan, tetapi Anda memiliki tugas untuk memantau tabel ini untuk perubahan, yang persis dari tempat Anda memulai.
