स्रोत LOB कॉलम के साथ काम करते समय "पंक्ति द्वारा पंक्ति" लाने की विधि से बचें

Question

मेरे पास एक विरासत PostgreSQL डेटाबेस स्रोत (ODBC) है जिसे मैं SSIS का उपयोग करके नए SQL सर्वर स्कीमा में स्थानांतरित करने का प्रयास कर रहा हूं। मुझे एक चेतावनी मिल रही है:

'पंक्ति द्वारा पंक्ति' लाने की विधि लागू की जाती है क्योंकि तालिका में LOB कॉलम (s) होता है। स्तंभ सामग्री LOB है

बात यह है कि किसी भी कॉलम को वास्तव में एलओबी होने की आवश्यकता नहीं है। कुछ ऐसे हैं जो TEXT प्रकार हैं, लेकिन एक varchar (अधिकतम) के भीतर आसानी से फिट हो सकते हैं। हालांकि, अजनबी भी, अधिकांश पहले से ही varchars हैं, लेकिन ऐसा लगता है कि varchar (128) पर कुछ भी व्यवहार किया जा रहा है जैसे कि यह एक LOB था (अग्रिम गुणों में, डेटा प्रकार DT_NTEXT है)।

मैंने इवेंट को मैन्युअल SQL कमांड करने की कोशिश की, जहाँ मैंने स्पष्ट रूप से प्रत्येक स्ट्रिंग प्रकार को चयनित स्टेटमेंट में एक उपयुक्त लंबाई के varchar में डाला, और वे अभी भी ODBC स्रोत में DT_NTEXT के रूप में सेट किए जा रहे हैं।

मैं एक डीबीए नहीं हूं, इसलिए यह पूरी तरह से संभव है कि मैं वास्तव में बेवकूफ कुछ कर रहा हूं। मैं यह सुनिश्चित करने के लिए सबसे अच्छा तरीका जानना चाहूंगा कि प्रकार varchars के रूप में समाप्त होते हैं इसलिए मैं बैच ला सकता हूं। कोई विचार?

यदि यह मायने रखता है, तो मैं विज़ुअल स्टूडियो 2013 के अंदर SSIS-BI 2014 का उपयोग कर रहा हूं।

Comments

जब आप स्पष्ट रूप से उन्हें स्रोत प्रणाली में एक गैर-अधिकतम आकार में डालते हैं, तो क्या यह मौजूदा डेटा प्रवाह में था या आपने इसके लिए एक नया या कम से कम एक नया स्रोत घटक बनाया था? जब आप समान कॉलम नाम और सिर्फ स्किनियर प्रकार के साथ एक क्वेरी प्रदान करते हैं, तो कुछ बार जो बदलाव के रूप में पंजीकृत नहीं होता है, इसलिए संपादक मेटाडेटा संग्रह प्रक्रिया (जो महंगी हो सकती है) को बंद नहीं करता है। इसके अलावा, एक varchar (अधिकतम) एक SSIS डेटा प्रवाह के लिए एक LOB के रूप में माना जा रहा है और इससे agilebi.com/jwelch/2010/05/11/…

— बिलिन्क

ODBC डेटा स्रोत घटक में, आपके पास तालिका का चयन करने या क्वेरी का उपयोग करने का विकल्प होता है। यह वह जगह है जहां मैं कास्टिंग कर रहा हूं: एक कस्टम क्वेरी में। मैंने varchar(max)यह कहते हुए केवल आशुलिपि का उल्लेख किया है कि कॉलम डेटा अधिकतम varchar आकार के भीतर फिट हो सकता है, जो कि लगभग 4000 है, SSIS के उद्देश्यों के लिए, मुझे लगता है। मैं वास्तव में कुछ भी नहीं कर रहा हूँ varchar(max); हालाँकि, मैंने कुछ कॉलम डाले varchar(4000), बस सुरक्षित रहने के लिए।

— क्रिस प्रैट

Answer 1

मैंने NTchar के रूप में 128 से बड़े varchar के लिए डेटा रूपांतरण का उपयोग किया था, लेकिन अंततः मेरे लिए जो त्रुटि थी उसे हटा दिया गया है, यह बाहरी डेटा को गलत पर सेट करना है।

Answer 2

जाहिरा तौर पर यह सिर्फ SSIS को NTEXT के रूप में 128 से बड़े किसी भी varchar का इलाज करता है। यकीन नहीं है कि क्यों। हालाँकि, मैं ODBC स्रोत के उन्नत गुणों में जा सकता हूँ और वापस DT_WSTR जैसी चीज़ों को बदल सकता हूँ। जो अधिकांश भाग के लिए काम करता है।

हालाँकि, मैंने यह निर्धारित किया था कि कुछ टेबल जो मैं वास्तव में काम कर रहा हूँ, उनमें से कुछ को अपने अगले कॉलम में 4000 बाइट्स से ऊपर ले जा रहे हैं, इसलिए मुझे दुर्भाग्य से ट्रेंकुलेशन को रोकने के लिए DT_NTEXT के रूप में उन कॉलम्स को छोड़ना होगा (SSIS) आप 4000 से अधिक बाइट्स के साथ एक DT_WSTR प्रकार सेट करते हैं)। मुझे लगता है कि इन उदाहरणों में, मैं केवल पंक्ति-दर-पंक्ति भ्रूण के साथ फंस गया हूं, लेकिन कम से कम मैं कुछ तालिकाओं को ठीक करने में सक्षम था।

Answer 3

इस समाधान ने मेरे लिए काम किया:

मैंने डेटा स्रोत संपत्ति में अधिकतम वर्चर पैरामीटर को बदलकर त्रुटि को हटा दिया। कनेक्शन प्रबंधक पर जाएं। कनेक्शन स्ट्रिंग के बगल में बिल्ड विकल्प चुनें। अधिक विकल्प तक पहुंचने के लिए कनेक्शन बटन पर क्लिक करें। मैक्स वर्चर का मान बदलें।

Answer 4

मेरे मामले में स्रोत फिल्म निर्माता ODBC है जो लंबे पाठ को LOB डेटाटाइप के रूप में मानता है। पंक्ति द्वारा रो के लिए प्रदर्शन में अत्यधिक कमी के कारण मेरा पैकेज लंबे समय तक लटका रहता था, क्योंकि यह विधि एलओबी कॉलम (s) है, क्योंकि इसे लागू किया गया है। इस प्रकार, तैनात होने के दौरान यह लंबे समय के बाद टाइमआउट करता था और अंततः विफल हो जाता था।

मैं वास्तविक समाधान साझा कर रहा हूं जो मेरे लिए एक आकर्षण की तरह काम करता है। 30k LOB प्रकार के डेटा पुल पर एक दिन का समय मेरे लिए लगभग 10 मिनट लगा ::

DefaultBufferMaxRows को 1 से कम करें और DefaultBufferSize को अधिकतम यानी 100 एमबी तक बढ़ाएं। फिर 'टेक्स्ट को लॉन्ग वर्चर' के विकल्प की जाँच करके स्रोत ODBC DSN को बदलें। और स्रोत से लक्ष्य के रूप में डेटाटिप्स को मैप करें (स्रोत में उन्नत संपादक में किसी भी बदलाव के बिना)।