लांब 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';

इतिहास प्रत्येक टप्प्याचा निकाल आणि वेळ दाखवतो, जो एका यश-ध्वजापेक्षा उपयुक्त आहे. डेटा बदलणाऱ्या कामांसाठी अॅप्लिकेशनची स्वतःची पडताळणीही जोडा: ओळींची संख्या, चेकसम किंवा कामाने लिहिलेली स्थिती-ओळ. दोन स्वतंत्र नोंदीच पुनःप्रयत्न सुरक्षित करतात, आणि नोंदवलेला कामाचा इतिहास त्यातील पहिला आहे.

पुन्हा पाठवण्यापूर्वी जुळवा

निरीक्षण कनेक्शन गायब झाल्यावर, दुसरी सुरू करण्यापूर्वी विद्यमान फेरी शोधा. तिच्या टप्प्यांचे निकाल वाचा आणि काम कमिट झाले, अंशतः पूर्ण झाले, की कधीच सुरू झाले नाही हे ठरवा. तेव्हाच वर्कफ्लोने परिभाषित केलेला पुनःप्रयत्न नियम लागू करा, कारण डोळे बंद करून पुन्हा पाठवल्यास लोड दुप्पट होऊ शकतो किंवा दुसऱ्यांदा अर्ध्यावर अपयशी होऊ शकतो.

टिकाऊ मालक आणि तपासण्यायोग्य निकाल टिकवा, मग छोटी प्रवेश अडचण अंदाजाऐवजी गैरसोय बनते. हेच संपूर्ण रचनेचे ध्येय आहे: कामाने त्याची मागणी करणाऱ्या कनेक्शनपेक्षा जास्त जगले पाहिजे.