लामो 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';

इतिहासले हरेक चरणको नतिजा र समय देखाउँछ, जो एउटा सफलता-झन्डाभन्दा उपयोगी हुन्छ। डेटा बदल्ने कामका लागि एप्लिकेसनको आफ्नै प्रमाणिकरण पनि थप्नुहोस्: पङ्क्ति-गणना, चेकसम वा कामले लेखेको स्थिति-पङ्क्ति। दुई स्वतन्त्र रेकर्डले मात्र पुनःप्रयास सुरक्षित बनाउँछ, र रेकर्ड गरिएको काम इतिहास तीमध्ये पहिलो हो।

फेरि पेस गर्नुअघि मिलाउनुहोस्

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

स्थायी मालिक र जाँच्न सकिने नतिजा राख्नुहोस्, अनि छोटो पहुँच असफलता अनुमानको सट्टा असुविधा बन्छ। यही सम्पूर्ण डिजाइनको लक्ष्य हो: कामले त्यसलाई माग्ने जडानभन्दा लामो बाँच्नुपर्छ।