डीबी टेबल चेंज (एसक्यूएल 2005) की विंडोज़ सेवा (सी #) को कैसे सूचित करें?

Question

मेरे पास SQL2005 डेटाबेस में भारी लोड (कई प्रविष्टियां/अपडेट/हटाएं) वाली एक तालिका है। मैं यथासंभव वास्तविक समय के करीब इन सभी परिवर्तनों के लिए कुछ पोस्ट प्रोसेसिंग करना चाहता हूं (असीमित रूप से ताकि तालिका को किसी भी तरह से लॉक न करें)। मैंने कई संभावित समाधान देखे हैं, लेकिन ऐसा लगता है कि एक साफ समाधान जो सही महसूस करता है।

पोस्ट प्रोसेसिंग की तरह काफी भारी है, इसलिए विंडोज श्रोता सेवा वास्तव में कई मशीनों पर प्रसंस्करण को पारित करने जा रही है। हालांकि आवेदन का यह हिस्सा पहले से ही चल रहा है और चल रहा है, पूरी तरह से असीमित है, और मुझे इसके लिए सहायता की आवश्यकता नहीं है - मैं बस इसका उल्लेख करना चाहता था क्योंकि यह डिजाइन निर्णय को प्रभावित करता है कि हम केवल कुछ सीएलआर ऑब्जेक्ट को लोड नहीं कर पाएंगे प्रसंस्करण को पूरा करने के लिए डीबी।

तो, सरल समस्या बनी हुई है: तालिका में डेटा परिवर्तन, मैं रिमोट सर्वर पर सी # कोड में कुछ प्रोसेसिंग करना चाहता हूं।

वर्तमान में हम एक एसक्यूएल ट्रिगर का उपयोग करने के साथ आए हैं, जो एक एक्सई लॉच करने के लिए "xp_cmdshell" निष्पादित करता है जो विंडोज़ सेवा सुन रहा है। यह सिर्फ बुरा लगता है।

हालांकि, अन्य समाधान जो मैंने ऑनलाइन देखा है, बल्कि भी घुलनशील महसूस करते हैं। उदाहरण के लिए SQLCacheDependancy की स्थापना में सेवा ब्रोकर सेट करना भी शामिल है। एक और संभावित समाधान एक सीएलआर ट्रिगर का उपयोग करना है, जो एक webservice को कॉल कर सकता है, लेकिन इसके बारे में इतनी सारी चेतावनियां ऑनलाइन हैं कि इसके बारे में जाने का एक बुरा तरीका है, खासकर जब प्रदर्शन महत्वपूर्ण है।

आदर्श हम टेबल परिवर्तनों पर निर्भर नहीं होंगे बल्कि हमारे आवेदन के अंदर कॉल को अवरुद्ध करेंगे और वहां से सेवा को सूचित करेंगे, दुर्भाग्यवश हालांकि हमारे पास कुछ विरासत अनुप्रयोग भी डेटा में परिवर्तन कर रहे हैं, और तालिका की निगरानी करना है इस समय केवल केंद्रीकृत जगह।

किसी भी मदद की सराहना की जाएगी।

सारांश:

• वास्तविक समय में तालिका डेटा परिवर्तन करने के लिए प्रतिक्रिया करने के लिए की आवश्यकता
• प्रदर्शन महत्वपूर्ण है
• यातायात की उच्च मात्रा की उम्मीद है
• मतदान और अनुसूचित कार्यों के लिए एक विकल्प नहीं हैं (या वास्तविक समय)
• सेवा दलाल को कार्यान्वित करना बहुत बड़ा है (लेकिन केवल समाधान हो सकता है?)
• सीएलआर कोड अभी तक शासित नहीं है बाहर है, लेकिन जरूरत है सुझाव दिया
• श्रोता/मॉनिटर रिमोट मशीन (समान phyisical नेटवर्क होने की संभावना)

Answer 1

आप वास्तव में है कि कई मायनों एसक्यूएल 2005 में परिवर्तन आप पहले से ही उनमें से ज्यादातर सूचीबद्ध पता लगाने के लिए नहीं है।

क्वेरी नोटिफिकेशन। यह वह तकनीक है जो एसक्लड निर्भरता और इसके डेरिवेटिव को शक्ति देती है, आप The Mysterious Notification पर अधिक जानकारी पढ़ सकते हैं। लेकिन क्यूएन को परिणामों को अमान्य करने के लिए डिज़ाइन किया गया है, सक्रिय रूप से परिवर्तन सामग्री को सक्रिय रूप से सूचित नहीं किया गया है। आपको केवल यह पता चलेगा कि तालिका में बदलाव आया है, बिना किसी बदलाव के। एक व्यस्त प्रणाली पर यह काम नहीं करेगा, क्योंकि अधिसूचनाएं काफी अधिक आती हैं।

लॉग पढ़ने। यह लेनदेन संबंधी प्रतिकृति का उपयोग करता है और परिवर्तनों का पता लगाने के लिए कम से कम घुसपैठ का तरीका है। दुर्भाग्य से केवल आंतरिक घटकों के लिए उपलब्ध है। भले ही आप लॉग प्रारूप को समझने में कामयाब हों, समस्या यह है कि जब तक आप इसे पढ़ नहीं लेते, तब तक लॉग को 'उपयोग में' के रूप में चिह्नित करने के लिए आपको इंजन से समर्थन की आवश्यकता होती है, या इसे ओवरराइट किया जा सकता है। केवल लेनदेन प्रतिकृति इस तरह के विशेष अंकन कर सकते हैं।

डेटा तुलना। परिवर्तनों का पता लगाने के लिए टाइमस्टैम्प कॉलम पर निर्भर करें। खींचने के आधार पर भी काफी घुसपैठ कर रहा है और इसमें डिलीट का पता लगाने में समस्याएं हैं।

आवेदन परत। सिद्धांत में यह सबसे अच्छा विकल्प है, जब तक कि एप्लिकेशन के दायरे से बाहर डेटा में कोई परिवर्तन नहीं होता है, इस मामले में यह टूट जाता है। अभ्यास में हमेशा एप्लिकेशन के दायरे से बाहर होने वाले परिवर्तन होते हैं।

ट्रिगर्स। आखिरकार, यह एकमात्र व्यवहार्य विकल्प है। ट्रिगर्स के आधार पर सभी परिवर्तन तंत्र उसी तरह काम करते हैं, वे कतार पर नज़र रखने वाले घटक को परिवर्तन अधिसूचना कतारबद्ध करते हैं।

वहाँ हमेशा एक कसकर युग्मित, तुल्यकालिक अधिसूचना करने के लिए सुझाव दिए गए हैं (xp_cmdshell के माध्यम से, xp_olecreate, CLR, WCF के साथ सूचना देने, आपको इसे नाम) है, लेकिन इन सभी योजनाओं व्यवहार में विफल क्योंकि वे मौलिक रूप से दोषपूर्ण हैं:
- वे लेनदेन स्थिरता और रोलबैक के लिए खाता न करें
- वे उपलब्धता निर्भरताएं पेश करते हैं (ओएलटीपी सिस्टम तब तक नहीं बढ़ सकता जब तक अधिसूचित घटक ऑनलाइन न हो)
- वे बहुत ही निष्पादित करते हैं क्योंकि प्रत्येक डीएमएल ऑपरेशन को कुछ फॉर्म के आरपीसी कॉल को पूरा करने के लिए इंतजार करना पड़ता है

तो चलाता वास्तव में सक्रिय रूप से श्रोताओं को सूचित नहीं है, लेकिन पर ly नोटिफिकेशन तब कतार, वहाँ सूचनाएं कतार की निगरानी में एक समस्या है (जब मैं कहता हूँ 'कतार', मुझे लगता है कि एक कतार के रूप में कार्य किसी भी तालिका मतलब)। निगरानी का अर्थ कतार में नई प्रविष्टियों को खींचने का तात्पर्य है, जिसका अर्थ है परिवर्तनों के भार के साथ सही ढंग से चेक की आवृत्ति को संतुलित करना, और लोड स्पाइक्स पर प्रतिक्रिया देना। यह बिल्कुल छोटा नहीं है, वास्तव में बहुत मुश्किल है। हालांकि, वहाँ है, खींच के बिना ब्लॉक करने के लिए, अर्थ विज्ञान है कि एसक्यूएल सर्वर में एक बयान है जब तक परिवर्तन उपलब्ध हो जाते हैं: WAITFOR(RECEIVE)। इसका मतलब सेवा ब्रोकर है। आपने अपनी पोस्ट में कई बार एसएसबी का उल्लेख किया है, लेकिन आप सही हैं, इसलिए, बड़े अज्ञात की वजह से इसे तैनात करने से डरते हैं। लेकिन वास्तविकता यह है कि, आपके द्वारा वर्णित कार्य के लिए सबसे अच्छा फिट है।

आपको एक पूर्ण एसएसबी आर्किटेक्चर तैनात करने की आवश्यकता नहीं है, जहां दूरस्थ सेवा के लिए अधिसूचना वितरित की जाती है (जिसके लिए रिमोट एसक्यूएल इंस्टेंस की आवश्यकता होती है, यहां तक ​​कि एक एक्सप्रेस भी)। जब आपको अधिसूचना वितरित की जाती है (परिवर्तन के बाद) उस समय से परिवर्तन का पता चला है जब परिवर्तन का पता चला है (डीएमएल ट्रिगर) उस क्षण को खत्म करना है। इसके लिए आपको एक स्थानीय एसएसबी कतार और सेवा की आवश्यकता है। ट्रिगर में आप SEND स्थानीय सेवा में एक परिवर्तन अधिसूचना। बाद मूल DML लेन-देन करता है, सेवा प्रक्रिया activates और अधिसूचना बचाता है, उदाहरण के लिए CLR का उपयोग कर। आप Asynchronous T-SQL पर इस तरह के कुछ का उदाहरण देख सकते हैं।

आप उस पथ नीचे जाना अगर वहाँ कुछ चालें आप उच्च troughput प्राप्त करने के लिए जानने के लिए की आवश्यकता होगी रहे हैं और आप एसएसबी में संदेशों के आदेश दिए वितरण की अवधारणा understant चाहिए। Change Data Capture and Change Tracking: परिवर्तन, एसक्यूएल 2008 जाहिरा तौर पर नई विकल्प जोड़ता है पता लगाने के लिए

• Reusing Conversations
• Writing Service Broker Procedures
• SQL Connections 2007 Demo

साधन के बारे में: मैं reommend आप इन लिंक पढ़ें। मैं 'जाहिर तौर पर' जोर देता हूं, क्योंकि वे वास्तव में नई तकनीक नहीं हैं। सीडीसी लॉग रीडर का उपयोग करता है और मौजूदा लेनदेन प्रतिकृति तंत्र पर आधारित है। सीटी ट्रिगर्स का उपयोग करता है और मौजूदा मर्ज प्रतिकृति तंत्र के समान है। वे दोनों के लिए कभी-कभी सिस्टम से जुड़े हुए हैं जिन्हें सिंक करने की आवश्यकता है और इसलिए रीयल-टाइम परिवर्तन अधिसूचना के लिए अपरिवर्तनीय नहीं है। वे परिवर्तन तालिकाओं को पॉप्युलेट कर सकते हैं, लेकिन परिवर्तनों के लिए इन तालिकाओं की निगरानी करने के लिए आपको कार्य के साथ छोड़ दिया गया है, जो कि आपने कहां से शुरू किया था।

Answer 2

हो सकता है जब से तुम ने कहा कि कई आवेषण कि मेज, एक बैच प्रोसेसिंग कर सकते थे पर चल रहे perfomant जा करने के लिए बेहतर फिट

केवल एक निर्धारित नौकरी क्यों बनाई गई, जो ध्वज कॉलम द्वारा पहचाने गए नए डेटा को संभालती है, और बड़े हिस्से में डेटा संसाधित करती है?

Answer 3

यह कई तरीकों से किया जा सकता है। नीचे विधि सरल है क्योंकि आप सीएलआर ट्रिगर और sqlcmd विकल्पों का उपयोग नहीं करना चाहते हैं।

• सीएलआर ट्रिगर्स का उपयोग करने के बजाय आप सामान्य डालने ट्रिगर बना सकते हैं जो प्रत्येक डालने पर समर्पित ट्रैकिंग तालिका अपडेट करता है।

• और सक्रिय विंडो सेवा विकसित करें जो सक्रिय रूप से ट्रैकिंग तालिका पर चुनाव करे और डेटा में कोई बदलाव होने पर दूरस्थ सेवा अपडेट करें और ट्रैकिंग तालिका में स्थिति सेट करें (इसलिए इसे फिर से नहीं चुना जाएगा) ..

संपादित करें:

मुझे लगता है कि ADO.Net के लिए Microsoft सिंक सेवाओं आप के लिए काम कर सकते हैं। नीचे दिए गए लिंक देखें। यह आप

• How to: Use SQL Server Change Tracking - sql server 2008
• Use a Custom Change Tracking System - below sql server 2008

Answer 4

उपयोग डेटाबेस पर एक CLR आग में मदद मिल सकती ठेठ ट्रिगर। यह CLR केवल एक कार्यक्रम दूर Win32_Process कक्षा का उपयोग शुरू होगा:

http://motevich.blogspot.com/2007/11/execute-program-on-remote-computer.html

Answer 5

इसी तरह की परिस्थितियों में हम CLR ट्रिगर है कि कतार (MSMQ) को संदेश लिख रहा है प्रयोग कर रहे हैं। सी # में लिखी गई सेवा कतार की निगरानी कर रही है और पोस्ट प्रोसेसिंग कर रही है। हमारे मामले में यह सब एक ही सर्वर पर किया जाता है, लेकिन आप उन संदेशों को सीधे एक अलग मशीन पर रिमोट कतार में भेज सकते हैं, पूरी तरह से "स्थानीय श्रोता" को छोड़कर।

कोड ट्रिगर से कहा जाता है इस तरह दिखता है:

public static void SendMsmqMessage(string queueName, string data) 
{ 
    //Define the queue path based on the input parameter. 
    string QueuePath = String.Format(".\\private$\\{0}", queueName); 

    try 
    { 
     if (!MessageQueue.Exists(QueuePath)) 
      MessageQueue.Create(QueuePath); 

     //Open the queue with the Send access mode 
     MessageQueue MSMQueue = new MessageQueue(QueuePath, QueueAccessMode.Send); 

     //Define the queue message formatting and create message 
     BinaryMessageFormatter MessageFormatter = new BinaryMessageFormatter(); 
     Message MSMQMessage = new Message(data, MessageFormatter); 

     MSMQueue.Send(MSMQMessage); 
    } 
    catch (Exception x) 
    { 
     // async logging: gotta return from the trigger ASAP 
     System.Threading.ThreadPool.QueueUserWorkItem(new WaitCallback(LogException), x); 
    } 
}