मुझे अक्सर "समस्याएं" दिखाई देती हैं जिनमें SQL सर्वर के लिए "गंदा काम" करने की आवश्यकताएं शामिल होती हैं जैसे:
- मेरे ट्रिगर में मुझे नेटवर्क पर/से फ़ाइल कॉपी करने की आवश्यकता है
- मेरी संग्रहीत कार्यविधि को फ़ाइल को FTP करने की आवश्यकता है
- बैकअप समाप्त होने के बाद मुझे इसे ज़िप करने, प्रतिलिपि बनाने और फिर इसे संग्रहीत करने के लिए SQL सर्वर की आवश्यकता है
- जब कोई ग्राहक जोड़ा जाता है, तो मैं एक नया डेटाबेस बनाना चाहता हूं, और सक्रिय निर्देशिका में बहुत सी चीजें करना चाहता हूं
- मेरे SQL सर्वर एजेंट कार्य को फ़ाइलों के लिए एक निर्देशिका को स्कैन करने की आवश्यकता होती है, और जब यह नई मिलती है तो बल्क इंसर्ट करता है
यह एक विस्तृत सूची नहीं है; मैं शायद एक पेज भर सकता था। मुद्दा यह है कि SQL सर्वर के भीतर से इन कार्यों को करने से महत्वपूर्ण बाधाएं आती हैं:
सुरक्षा
आमतौर पर, किसी भी चीज़ के लिए जहाँ आपको लगता है कि SQL सर्वर को फ़ाइल सिस्टम या अन्य OS-स्तरीय पहुँच की आवश्यकता है, आप या तो (a) SQL सर्वर सेवा खाते (और/या SQL एजेंट/प्रॉक्सी खातों) को स्पष्ट कार्टे ब्लैंच अधिकार देने जा रहे हैं, या (बी) SQL सर्वर सेवा खातों को मौजूदा डोमेन खाते के रूप में चलाने के लिए सेट करें जिसमें पहले से ही वे सभी अधिकार हैं। यह "आसान" समाधान है - अब, व्यक्तिगत रूप से इस फ़ोल्डर और उस शेयर और इस अन्य संसाधन तक पहुंच प्रदान करने के बजाय, आप केवल अपने हाथ मिटा दें क्योंकि वे पहले से ही डोमेन व्यवस्थापक हैं। इसके बाद आप सर्वर-स्तरीय सेटिंग्स को सक्षम करते हैं जो डिफ़ॉल्ट रूप से अक्षम होती हैं लेकिन उपरोक्त कार्यों में से एक या अधिक कार्यों को पूरा करने के आपके रास्ते में खड़ी होती हैं (उदा. xp_cmdshell )।
मुझे नहीं लगता कि मुझे इन कार्यों का प्रतिनिधित्व करने वाले जोखिम के स्तर की व्याख्या करनी होगी। या किस तरह की समस्याएं हो सकती हैं यदि यह एक वास्तविक कर्मचारी खाता है, और वह कर्मचारी चला जाता है - या यह निर्धारित करता है कि उनके जाने से पहले वह असंतुष्ट है। ओह। मैंने ऐसे कई मामले देखे हैं जहां सभी SQL सर्वर के लिए एक सामान्य खाते का उपयोग किया जाता है। लगता है कि क्या होता है यदि आपको एक डोमेन खाते के लिए पासवर्ड बदलने की आवश्यकता होती है जो सक्रिय रूप से दर्जनों या सैकड़ों SQL सर्वर उदाहरणों द्वारा उपयोग किया जा रहा है? कोई फर्क नहीं पड़ता कि यह कितनी बार होगा यदि आप उस उपयोगकर्ता को पासवर्ड रीसेट नीतियों से बाहर नहीं करते हैं?
प्रदर्शन
सुरक्षा मुद्दों के अलावा, डेटाबेस सर्वर के बाहर जाने से देरी हो सकती है जबकि SQL सर्वर किसी बाहरी प्रक्रिया पर निर्भर करता है, जिस पर इसका कोई नियंत्रण नहीं है। क्या डेटाबेस लेनदेन को वास्तव में किसी फ़ाइल को संपीड़ित और कॉपी करने के लिए, या एक FTP हस्तांतरण के पूरा होने के लिए, या आपके बैकअप डोमेन नियंत्रक को प्रतिक्रिया देने के लिए प्रतीक्षा करने की आवश्यकता है? यह कंपाउंड कैसे होता है जब कई उपयोगकर्ता समान कार्य कर रहे हैं, सभी एक ही बैंडविड्थ और/या डिस्क हेड के लिए प्रतिस्पर्धा कर रहे हैं? आपको यह भी विचार करना चाहिए कि एक बार SQL सर्वर ने कुछ बैच फ़ाइल को कुछ करने के लिए कहा है, तो युक्त लेनदेन वापस ले लिया गया है, आप बाहरी क्रिया को वापस नहीं ले सकते हैं।
जवाब
खैर, आमतौर पर - और हमेशा अपवाद होते हैं - इसका उत्तर इन कार्यों के लिए बाहरी प्रक्रियाओं का उपयोग करना है जो वास्तव में SQL सर्वर के लिए बाहरी हैं। PowerShell का उपयोग करें, C# का उपयोग करें, बैच फ़ाइलों का उपयोग करें; बिल्ली, वीबीस्क्रिप्ट का प्रयोग करें। इस बारे में सोचें कि इनमें से कौन से कार्यों को वास्तव में *तुरंत* संभालने की आवश्यकता है और जबकि लेन-देन अभी भी सक्रिय है - मुझे संदेह है कि कई नहीं हैं। इनके लिए एक कतार तालिका बनाएं, और लेन-देन के अंदर कतार तालिका में लिखें (यदि लेनदेन सफल नहीं होता है तो इसे वापस ले लिया जाएगा)। फिर, एक पृष्ठभूमि कार्य या स्क्रिप्ट है जो कतार तालिका से पंक्तियों का उपभोग करता है, संबंधित कार्य करता है, और प्रत्येक पंक्ति को पूर्ण के रूप में हटा देता है या चिह्नित करता है। जोड़ा गया बोनस:यहां SQL सर्वर एजेंट की आवश्यकता नहीं है, इसलिए आप किसी भी एंटरप्राइज़ शेड्यूलर का उपयोग कर सकते हैं, और कार्यप्रणाली अभी भी SQL सर्वर एक्सप्रेस के साथ काम करती है।
