लंबा SQL कार्य: VPN टूटने पर भी उसे चलता रखें

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

कनेक्शन त्रुटि आपको क्या नहीं बताती

क्लाइंट-साइड त्रुटि क्लाइंट का वर्णन करती है। यह बताती है कि सॉकेट बंद हो गया, यह नहीं कि सर्वर ने लेनदेन के साथ क्या किया। स्टेटमेंट अभी भी चल रहा हो सकता है, लिंक मरने से ठीक पहले कमिट हो गया हो सकता है, या उसका सत्र साफ़ होने पर रोलबैक हो गया हो सकता है। तीनों आपके लैपटॉप पर एक ही संदेश देते हैं।

केवल सर्वर की स्थिति ही इसे तय कर सकती है। कुछ भी तय करने से पहले वहाँ देखें।

काम सर्वर-साइड मालिक को सौंपें

जिस काम को किसी इंसान की निगरानी नहीं चाहिए, उसमें डेटाबेस होस्ट को निष्पादन का मालिक बनने दें। SQL Server Agent माँग पर या समय-सारणी के अनुसार कार्य चलाता है और हर रन दर्ज करता है, इसलिए कार्य का जीवनचक्र आपके VPN सत्र से स्वतंत्र है। कार्य की पहचान को ठीक वही अनुमतियाँ चाहिए जो कार्य माँगता है, किसी एडमिनिस्ट्रेटर का पूरा इंटरैक्टिव संदर्भ नहीं। तब लैपटॉप काम शुरू करता है और परिणाम पढ़ता है, उसे ज़िंदा रखने वाली प्रक्रिया बनने के बजाय।

EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';

Agent की उपलब्धता इस पर निर्भर है कि आपने कौन-सा संस्करण और सेवा तैनात की है। यह मानने के बजाय कि यह हर जगह मौजूद है, वह तंत्र इस्तेमाल करें जो आपका प्लेटफ़ॉर्म वास्तव में देता है।

डेटाबेस के पास का जंप होस्ट रास्ता छोटा करता है और रखने योग्य है, पर यह स्वामित्व का सवाल नहीं बदलता। नेटवर्क खत्म होने पर सत्र फिर भी खत्म होता है। इसका उपयोग निरीक्षण के लिए करें, काम को ज़िंदा रखने वाली चीज़ के रूप में नहीं।

ऐसा रिकॉर्ड छोड़ें जिसे अगला सत्र पढ़ सके

किसी कार्य का नाम या पहचानकर्ता, लक्ष्य डेटाबेस और वह परिणाम दर्ज करें जिसकी आप अपेक्षा करते हैं। वही रिकॉर्ड किसी दूसरे सत्र, या किसी दूसरे व्यक्ति को, उस सवाल का जवाब देने देता है जो त्रुटि नहीं दे सकी। इसके बिना अद्यतन की एक धुँधली याद बचती है और जाँचने का कोई रास्ता नहीं।

EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';

इतिहास प्रत्येक चरण का परिणाम और समय दिखाता है, जो एक सफलता-ध्वज से अधिक उपयोगी है। डेटा बदलने वाले कार्यों के लिए एप्लिकेशन का अपना सत्यापन भी जोड़ें: पंक्ति-गणना, चेकसम या कार्य द्वारा लिखी गई स्थिति-पंक्ति। दो स्वतंत्र रिकॉर्ड ही पुनः प्रयास को सुरक्षित बनाते हैं, और इनमें से पहला दर्ज किया गया कार्य इतिहास है।

फिर से भेजने से पहले मिलान करें

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

स्थायी मालिक और जाँचने योग्य परिणाम बनाए रखें, और एक संक्षिप्त पहुँच विफलता अनुमान के बजाय असुविधा बन जाती है। पूरे डिज़ाइन का लक्ष्य यही है: काम को उस कनेक्शन से अधिक जीना चाहिए जिसने उसकी माँग की।