2012-12-05 45 views
5

tl; डॉ संस्करणएसएसआईएस क्लोजिंग कनेक्शन का प्रबंधन कैसे करता है? क्या मैं इसे मजबूर कर सकता हूं?

मैं त्रुटियों जब चलाने का एक कुछ रातों के बाद OLE DB (SNC10.0) कनेक्शन प्रबंधकों का उपयोग, कनेक्शन ठीक से बाहर समय नहीं हो सकता है? ADO.NET कनेक्शन प्रबंधक और स्रोतों पर स्विच करना इसे ठीक करना प्रतीत होता है, क्यों?

मैं सामान्य शीर्षक के लिए क्षमा चाहता हूं लेकिन एक पंक्ति में राज्य के लिए बहुत सारे विवरण हैं।

प्रौद्योगिकी:

सभी मामलों में डेटाबेस सर्वर, स्रोत और गंतव्य दोनों एसक्यूएल सर्वर 2008 R2 हैं

स्थापना:

मुझे लगता है कि चलाने SSIS पैकेज का एक सेट है रात के मध्य में एक के बाद एक। वर्तमान में उनमें से 7 हैं। वे सभी कार्यों का एक समान सेट करते हैं: वे पहले स्रोत स्रोत से कनेक्ट होते हैं और डेटा को एक स्टेजिंग डेटाबेस में कॉपी करते हैं। फिर वे स्टेजिंग डेटाबेस के भीतर विभिन्न परिवर्तन करते हैं। अंत में प्रक्रिया एक लक्षित डेटाबेस से जुड़ती है और इसे डेटा से भरती है।

मैंने ओएलई डीबी कनेक्शन (एसक्यूएल मूल क्लाइंट 10.0) के रूप में सभी कनेक्शन सेट अप किए हैं ताकि मैं उन्हें लुकअप घटकों और अन्य ओएलई-विशिष्ट घटकों के साथ उपयोग कर सकूं।

समस्या:

हम SSIS पैकेज की हमारी स्वचालित रन के साथ बार-बार समस्याओं का सामना कर रहा है। आम तौर पर मैं इसे अपने स्टेशन से मैन्युअल रूप से चलाने का परीक्षण करूंगा, यह ठीक चल जाएगा; तो हम एसएसआईएस पैकेज को SQL सर्वर में सहेज लेंगे और इसे शेड्यूल करेंगे और यह ठीक चल जाएगा। कुछ रातों बाद, हमें एक समस्या मिलेगी जैसे:

एसएसआईएस त्रुटि कोड DTS_E_OLEDBERROR। ओएलई डीबी त्रुटि उत्पन्न हुई। त्रुटि कोड: 0x80004005। एक ओएलई डीबी रिकॉर्ड उपलब्ध है। स्रोत: "SQL सर्वर के लिए माइक्रोसॉफ्ट ओएलई डीबी प्रदाता" Hresult: 0x80004005 विवरण: "टीडीएस स्ट्रीम में प्रोटोकॉल त्रुटि"।

या

SSIS त्रुटि कोड DTS_E_OLEDBERROR। ओएलई डीबी त्रुटि उत्पन्न हुई। त्रुटि कोड: 0x80004005। एक ओएलई डीबी रिकॉर्ड उपलब्ध है। स्रोत: "माइक्रोसॉफ्ट एसक्यूएल सर्वर मूल क्लाइंट 10.0" Hresult: 0x80004005 विवरण: "SQL सर्वर से अज्ञात टोकन प्राप्त हुआ"।

जब ऑनलाइन खोज की, कनेक्शन समस्याओं की ओर इन बिंदु के दोनों और विशेष रूप से नेटवर्क कनेक्टिविटी समस्याओं।

काम के आसपास:

मैंने पाया कि एक त्वरित, नहीं तो हमेशा सरल, इन मुद्दों का हल ADO नेट सूत्रों का कहना है बजाय OLE DB सूत्रों का कहना है के साथ स्रोत नोड्स को बदलने के लिए है। यह कुछ मामलों के लिए मेरे डेटा फ्लो कार्यों के भीतर स्वीकार्य है, लेकिन उन मामलों में जहां मुझे एक लुकअप घटक, या कुछ अन्य ऐसे टूल का उपयोग करने की आवश्यकता है जो केवल ओएलई स्रोतों के साथ काम करता है, यह एक अच्छा पर्याप्त समाधान नहीं है यदि मैं अभी भी सामना करूंगा ये मुद्दे।

प्रश्न:

मैं जानता हूँ कि ADO.NET और OLE DB कनेक्शन के बीच मतभेद की टन कर रहे हैं, लेकिन एक प्राथमिक बात मैंने देखा है कि OLE DB कनेक्शन प्रबंधक दो समय समाप्ति है, दोनों मूल्य के लिए चूक '0' का जो आमतौर पर अक्षम है (कोई टाइमआउट नहीं)। ADO.NET कनेक्शन मैनेजर में एक टाइमआउट है और यह '15' (15 सेकंड) के मान पर सेट है।

इन दो कनेक्शन प्रबंधक समय-बहिष्कार और कनेक्शन बंद करने को कैसे प्रबंधित करते हैं? ओएलई डीबी कनेक्शन मैनेजर टाइमआउट में 0 के मान के साथ, क्या वह कनेक्शन कभी भी बंद नहीं होगा जब तक कि SQL सर्वर पर कुछ नहीं किया जाता है? क्या यह मेरे मुद्दे का हिस्सा हो सकता है, ओएलई डीबी कनेक्शन खोलने वाले कई डेटा-प्रवाह कार्यों और फिर बंद नहीं किया जा सकता है? क्या इन कनेक्शनों को मजबूती से बंद करने के लिए मैं एसएसआईएस पैकेज में कुछ भी कर सकता हूं?

**** संपादित ****

यहाँ प्रश्न में डाटा प्रवाह कार्य का एक स्क्रीनशॉट है। मैं, मासूम की रक्षा करने के लिए नाम के कुछ बदल दिया आदि

enter image description here

कार्य के रूप में यहाँ चित्र पूरी तरह से ठीक चलेगा और समय की 100% काम करता है। यदि मैं एक ओएलई डीबी स्रोत में उस ADO.NET स्रोत को बदलता हूं तो मुझे पोस्ट में उल्लिखित त्रुटियां मिलती हैं। मेरे पास, कुछ अन्य मामलों में, स्रोत क्वेरी का विस्तार करके लुकअप को पार कर गया है और हटा दिया गया है। इस काम में मैंने नहीं किया है।

+0

हमें यहां विवरण पसंद हैं; पी बस मूल बातें प्राप्त करने के लिए: आपके सिस्टम पैच-वार कैसे कर रहे हैं? क्या आप मैन्युअल रूप से स्क्रिप्ट कार्य/घटक से ओएलई डीबी कनेक्शन बना रहे हैं? पैकेज मानना ​​असफल नहीं होता है, यह आमतौर पर कितना समय चलता है? क्या आप लेनदेन को संभालने के लिए एमएसडीटीसी का उपयोग कर रहे हैं? क्या यह लगातार एक विशिष्ट पैकेज पर असफल रहता है? एक विशिष्ट कार्य पर लगातार विफलता के बारे में कैसे? – billinkc

+0

प्रश्नों के लिए धन्यवाद। ठीक है, पैच-वार मैं सत्यापित करूंगा लेकिन मुझे विश्वास है कि वे अद्यतित हैं। मैं मैन्युअल रूप से नीचे फलक में ओएलई डीबी कनेक्शन मैनेजर बना रहा हूं, फिर डेटा प्रवाह कार्यों के अंदर ओएलई डीबी डेटा स्रोत घटक उदाहरण बना रहा हूं और उन्हें कनेक्शन प्रबंधक को इंगित कर रहा हूं। पैकेज जो एकमात्र विफल है वर्तमान में ~ 30 मिनट तक चलता है। मैं एमएसडीटीसी का उपयोग नहीं कर रहा हूं और वास्तव में कुछ भी लेनदेन नहीं कर रहा हूं; वर्तमान में हम विफलता पर बहाल करते हैं।यह लगातार एक विशेष डेटा-प्रवाह कार्य पर विफल रहता है, जो # पंक्तियों (~ 3 मिलियन पंक्तियों) –

+0

के परिप्रेक्ष्य से सबसे बड़ा है, ध्यान दें, पैकेज 30 मिनट तक चलता है, दो सर्वरों पर दो अलग-अलग डेटाबेस तक पहुंचता है, 7 के माध्यम से चलता है डेटा की विभिन्न 'इकाइयां', शीर्ष स्तर की वस्तुएं, यह केवल 300-500 पंक्तियों को स्थानांतरित कर रही है, और उसके बाद ग्राफ़ में सबसे अधिक ऑब्जेक्ट उपर्युक्त ~ 3 मिलियन पंक्ति तालिका है। –

उत्तर

2

हमने पाया कि हमारे सभी मुद्दों का स्रोत क्या था और कारणों का विवरण पर्यावरण के विवरण से मेल नहीं खाता था और हल करने के लिए पर्याप्त संकेत नहीं थे।

आखिर में सब कुछ उड़ा दिया और हमने पाया कि "नेटवर्क या सर्वर पर कुछ भी नहीं बदला है" मामला नहीं था।

हमारी नौकरियों के बीच में एक बैकअप होता था। वह बैकअप वॉल्यूम छाया प्रति का उपयोग कर रहा था और दोनों उत्पादन डेटाबेस के साथ-साथ tempdb का बैक अप ले रहा था। डिस्क आईओ मुद्दों/ताले की वजह से, अस्थायी परिवर्तनों के कारण tempdb आधा टेराबाइट हो गया था और फिर वह छाया-प्रतिलिपि बनाने का प्रयास कर रहा था।

tempdb पर बैकअप/छाया प्रतिलिपि बंद करना और उत्पादन डेटाबेस ने नौकरियों को तत्काल से गुज़रने का कारण बना दिया। 30 मिनट लगने वाली क्वेरी अब < 1 मिनट हैं।

मेरे साथ चिपके रहने और इसके माध्यम से सोचने के लिए धन्यवाद दोस्तों।