आपके पास वास्तव में SQL 2005 में परिवर्तनों का पता लगाने के इतने तरीके नहीं हैं। आप उनमें से अधिकांश को पहले ही सूचीबद्ध कर चुके हैं।
क्वेरी सूचनाएं . यह वह तकनीक है जो एसक्लड निर्भरता और उसके डेरिवेटिव को शक्ति प्रदान करती है, आप रहस्यमय सूचना . लेकिन QN को अमान्य . के लिए डिज़ाइन किया गया है परिणाम, परिवर्तन सामग्री को सक्रिय रूप से सूचित करने के लिए नहीं। आप केवल यह जानेंगे कि तालिका में परिवर्तन हुए हैं, बिना यह जाने कि क्या बदल गया है। व्यस्त सिस्टम पर यह काम नहीं करेगा, क्योंकि सूचनाएं काफी हद तक लगातार आती रहेंगी।
लॉग रीडिंग . यह वह है जो लेनदेन संबंधी प्रतिकृति का उपयोग करता है और परिवर्तनों का पता लगाने का सबसे कम दखल देने वाला तरीका है। दुर्भाग्य से केवल आंतरिक घटकों के लिए उपलब्ध है। यहां तक कि अगर आप लॉग प्रारूप को समझने का प्रबंधन करते हैं, तो समस्या यह है कि जब तक आप इसे पढ़ नहीं लेते, तब तक आपको लॉग को 'उपयोग में' के रूप में चिह्नित करने के लिए इंजन से समर्थन की आवश्यकता होती है, या इसे अधिलेखित किया जा सकता है। इस प्रकार की विशेष मार्किंग केवल लेन-देन की प्रतिकृति ही कर सकती है।
डेटा तुलना . परिवर्तनों का पता लगाने के लिए टाइमस्टैम्प कॉलम पर भरोसा करें। यह पुल आधारित भी है, काफी दखल देने वाला है और इसमें हटाए जाने का पता लगाने में समस्या होती है।
अनुप्रयोग परत . सिद्धांत रूप में यह सबसे अच्छा विकल्प है, जब तक कि अनुप्रयोग के दायरे से बाहर डेटा में होने वाले परिवर्तन नहीं होते हैं, जिस स्थिति में यह टूट जाता है। व्यवहार में हमेशा . होते हैं अनुप्रयोग के दायरे से बाहर होने वाले परिवर्तन।
ट्रिगर . आखिरकार, यह एकमात्र व्यवहार्य विकल्प है। ट्रिगर्स पर आधारित सभी परिवर्तन तंत्र उसी तरह काम करते हैं, वे परिवर्तन अधिसूचना को एक घटक के लिए कतारबद्ध करते हैं जो कतार की निगरानी करता है।
कसकर युग्मित, तुल्यकालिक अधिसूचना (xp_cmdshell, xp_olecreate, CLR के माध्यम से, WCF के साथ सूचित करें, आप इसे नाम दें) करने के लिए हमेशा सुझाव दिए जाते हैं, लेकिन ये सभी योजनाएं व्यवहार में विफल हो जाती हैं क्योंकि वे मौलिक रूप से त्रुटिपूर्ण हैं:
- वे नहीं करते हैं लेन-देन की स्थिरता और रोलबैक के लिए खाता
- वे उपलब्धता निर्भरता का परिचय देते हैं (जब तक अधिसूचित घटक ऑनलाइन नहीं होता है तब तक OLTP सिस्टम आगे नहीं बढ़ सकता है)
- वे बहुत खराब प्रदर्शन करते हैं क्योंकि प्रत्येक DML ऑपरेशन को किसी न किसी रूप में RPC कॉल की प्रतीक्षा करनी पड़ती है। पूरा करने के लिए
यदि ट्रिगर वास्तव में श्रोताओं को सक्रिय रूप से सूचित नहीं करते हैं, लेकिन केवल सूचनाओं को कतारबद्ध करते हैं, तो अधिसूचना कतार की निगरानी में एक समस्या है (जब मैं 'कतार' कहता हूं, मेरा मतलब है कि कोई तालिका जो कतार के रूप में कार्य करती है)। निगरानी का तात्पर्य कतार में नई प्रविष्टियों के लिए खींचना है, जिसका अर्थ है कि परिवर्तनों के भार के साथ चेक की आवृत्ति को सही ढंग से संतुलित करना, और स्पाइक्स को लोड करने के लिए प्रतिक्रिया करना। यह बिल्कुल भी तुच्छ नहीं है, वास्तव में बहुत कठिन है। हालांकि, SQL सर्वर में एक स्टेटमेंट है जिसमें सिमेंटिक्स को बिना खींचे ब्लॉक करना है, जब तक कि बदलाव उपलब्ध नहीं हो जाते:वेटफोर(रिसीव) . यानी सर्विस ब्रोकर। आपने अपनी पोस्ट में कई बार एसएसबी का उल्लेख किया है, लेकिन आप सही हैं, बड़े अज्ञात के कारण इसे तैनात करने से डरते हैं। लेकिन वास्तविकता यह है कि, आपके द्वारा वर्णित कार्य के लिए अब तक यह सबसे उपयुक्त है।
आपको एक पूर्ण एसएसबी आर्किटेक्चर को तैनात करने की आवश्यकता नहीं है, जहां अधिसूचना दूरस्थ सेवा के लिए सभी तरह से वितरित की जाती है (जिसके लिए रिमोट एसक्यूएल इंस्टेंस की आवश्यकता होती है, यहां तक कि एक एक्सप्रेस भी)। आपको केवल सहयोगी होने की आवश्यकता है, उस क्षण को अलग करना है जब परिवर्तन का पता चलता है (डीएमएल ट्रिगर) उस क्षण से जब अधिसूचना वितरित की जाती है (परिवर्तन के बाद)। इसके लिए आपको केवल एक स्थानीय एसएसबी कतार और सेवा की आवश्यकता है। ट्रिगर में आप भेजें स्थानीय सेवा में परिवर्तन अधिसूचना। मूल डीएमएल लेनदेन के बाद, सेवा प्रक्रिया सक्रिय हो जाती है। और उदाहरण के लिए सीएलआर का उपयोग करके अधिसूचना वितरित करता है। आप कुछ इसी तरह का उदाहरण Asynchronous T-SQL<पर देख सकते हैं। /ए> ।
यदि आप उस रास्ते पर जाते हैं तो कुछ तरकीबें हैं जिन्हें आपको उच्च ट्रफपुट प्राप्त करने के लिए सीखने की आवश्यकता होगी और आपको एसएसबी में संदेशों के आदेशित वितरण की अवधारणा को समझना होगा। मेरा सुझाव है कि आप इन लिंक्स को पढ़ें:
परिवर्तनों का पता लगाने के साधनों के बारे में, SQL 2008 जाहिरा तौर पर नए विकल्प जोड़ता है:डेटा कैप्चर बदलें और ट्रैकिंग बदलें . मैं 'स्पष्ट रूप से' पर जोर देता हूं, क्योंकि वे वास्तव में नई प्रौद्योगिकियां नहीं हैं। सीडीसी लॉग रीडर का उपयोग करता है और मौजूदा ट्रांजेक्शनल प्रतिकृति तंत्र पर आधारित है। CT ट्रिगर का उपयोग करता है और मौजूदा मर्ज प्रतिकृति तंत्र के समान है। वे दोनों कभी-कभी जुड़े . के लिए अभिप्रेत हैं सिस्टम जिन्हें सिंक करने की आवश्यकता है और इसलिए रीयल-टाइम परिवर्तन अधिसूचना के लिए उपयुक्त नहीं हैं। वे परिवर्तन तालिकाओं को पॉप्युलेट कर सकते हैं, लेकिन आपके पास परिवर्तनों के लिए इन तालिकाओं की निगरानी करने का कार्य बचा है, जो ठीक वहीं से है जहां से आपने प्रारंभ किया था।
