एसएसआईएस पैकेज को पुन: नियोजित करना - कैश?

Question

हमने हाल ही में एक मुद्दा देखा है कि एसएसआईएस पैकेजों को फिर से तैनात किए गए नवीनतम परिवर्तनों में शामिल नहीं लगता है ... जब मैं नोटपैड का उपयोग करके डीटीएसएक्स खोजता हूं तो मुझे कोड में संशोधित स्क्रिप्ट दिखाई देती है ताकि परिवर्तन निश्चित रूप से वहां हों।

मेरी धारणा थी कि एसएसआईएस पैकेज के स्क्रिप्ट घटक अंततः प्रक्रिया में कहीं भी एक असेंबली में संकलित किए जाते हैं - यह काफी संभावना है क्योंकि मुझे लगता है कि सी # कोड पहले संकलित किए बिना कुछ नहीं चला सकता है। तो सिद्धांत रूप में यदि इन विधानसभाओं को तब कैश किया जा रहा है और तत्काल ओवरराइट नहीं किया गया है (किसी कारण से) जो इस मुद्दे को समझाएगा।

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

हालांकि, अब तक मुझे नहीं मिला है कि यह क्यों और कैसे हो रहा है, यदि है ... क्या कोई मदद कर सकता है?

अद्यतन: MSDN कहते हैं: "पहले के संस्करणों जहां से संकेत मिलता है कर सकता था कि स्क्रिप्ट precompiled रहे थे विपरीत, सभी स्क्रिप्ट एसक्यूएल सर्वर 2008 एकीकरण सेवाओं (SSIS) और बाद के संस्करणों में precompiled कर रहे हैं।" - द्वारा प्री-संकलित का मतलब है कि वास्तविक पैकेज की बजाय एक पूर्व-संकलित संस्करण चलता है (मुझे ऐसा लगता है क्योंकि कोड को नोटपैड में कोड दिखाई देने के बाद संकलित नहीं लगता है) वहां एक तरीका होना चाहिए पूर्व-संकलित असेंबली को ओवरराइट करने के लिए इंजन को मजबूर करें ... लेकिन कैसे?

अद्यतन: लघु उद्योगों के चार मुख्य घटक में से एक एसक्यूएल ServerIntegration सेवाएं सेवा है, जो एक खिड़कियों सेवा है। स्पष्ट रूप से यह सेवा घटक/कार्य मेटाडेटा को कैश करेगी ताकि एसएसआईएस रनटाइम इंजन कैश को स्थापित कर सके, यह देखने के लिए कि कौन सा स्थापित है, जो पैकेज लोड समय को तेज करने में मदद कर सकता है। हालांकि, यदि पैकेज फ़ाइल सिस्टम (SQL एकीकरण सेवाओं में नहीं) में संग्रहीत हैं और एजेंट जॉब्स द्वारा निष्पादित किया गया है, तो एजेंट जॉब पैकेज को निष्पादित करने के लिए DTEXEC के 64 बिट संस्करण का उपयोग करेगा। मुझे अभी तक सबूत नहीं मिला है कि किसी भी कैशिंग में शामिल होगा, लेकिन निष्पादन के सत्यापन चरण में कई पैरामीटर जांचने के लिए निश्चित रूप से विकल्प हैं, जैसे कि संस्करण संख्या - एक कारण के लिए हो सकती है।

Answer 1

क्या आपने विजुअल स्टूडियो/एसएसआईएस में अपने बिल्ड नंबर पर एमएसडीबी में पैकेज के संस्करण निर्माण संख्या की तुलना करने के लिए sysssispackages को देखा है?

SELECT name, verbuild 
FROM msdb.dbo.sysssispackages 
WHERE name LIKE '%bla%' 

(अपने पैकेज को खोजने के लिए जहां-खंड के रूप में आवश्यक समायोजित करें। ऐसा नहीं कभी "msdb.dbo.sysssispackages से * का चयन करें" के रूप में यह स्तंभों में से एक में पैकेज XML है।)

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

मुझे पता है कि यह आपकी समस्या का वास्तविक समाधान नहीं है लेकिन यह समस्या का कारण कहां है इसका पता लगाने में मदद कर सकता है। यदि संख्या पुरानी है, तो इसका मतलब है कि आपका पैकेज परिनियोजन काम नहीं करता है।

Answer 2

यह आपके पास विशेष रूप से रहस्य को हल नहीं करता है, लेकिन यदि आप फ़ाइल सिस्टम-आधारित पैकेज चला रहे हैं और यह सत्यापित करना चाहते हैं कि चल रहा पैकेज वह पैकेज है जिसे आपने तैनात किया है, तो ऐसा करने का एक तरीका है।

1. अपना पैकेज बनाएं।
2. अपने पैकेज पर गुणों को खोलें और "संस्करण बिल्ड" संपत्ति को नोट करें (वैकल्पिक रूप से, नोटपैड में .dtsx खोलें और डीटीएस: संस्करणबिल्ड विशेषता खोजें।)
3. अपने पैकेज को तैनात करें।
4. अपने एसक्यूएल एजेंट नौकरी चरण में, सत्यापन टैब पर जाएं।
5. "पैकेज निर्माण सत्यापित करें" इनपुट बॉक्स में संस्करण बनाएं दर्ज करें।
6. नौकरी के चरण का निष्पादन करें।

मैं अगर यह अपने कैश बाहर फेंक और नव तैनात पैकेज प्राप्त करने के लिए लघु उद्योगों के लिए बाध्य करेगा पता नहीं है, लेकिन मुझे लगता है अगर आप हाथ से .dtsx पैकेज के बिल्ड नंबर संशोधित जानते हैं और फिर से करने की कोशिश फिर से रन जॉब चरण यह विफल रहता है क्योंकि पैकेज बिल्ड उस चीज़ से मेल नहीं खाता है जो यह खोज रहा है, इसलिए यह निश्चित रूप से उस मान का रन-टाइम चेक कर रहा है।

Answer 3

यह कुछ समय पहले चलने वाली चीज़ से कुछ हद तक परिचित लगता है। दुर्भाग्यवश, मुझे याद नहीं है जब मैं इसमें भाग गया (इसलिए मैं निश्चित रूप से जांच नहीं कर सकता), लेकिन मैं मानता हूं मुझे लगता है कि यह तय करना था कि मैंने स्क्रिप्ट संपादक से Build | Build st_5bd541c294054c25b9e7eb55b92bd0e2 कमांड को स्पष्ट रूप से बुलाया था (VSTA) मेनू विंडो बंद करने से पहले। (विशेष परियोजना के नाम प्रत्येक स्क्रिप्ट के लिए अलग होगा, जाहिर है, क्योंकि यह एक GUID पर आधारित है;। तथापि, वहाँ केवल Build के तहत एक संभव सबमेनू हो जाएगा)

स्पष्ट रूप से लागू Build आदेश सुनिश्चित करता है कि के लिए बाइनरी कोड स्क्रिप्ट को एएससीआईआई-एनकोडेड और परिणामी .dtsx फ़ाइल के एक्सएमएल में सहेजा जाता है। जब भी मैं स्क्रिप्ट संपादक बंद करता हूं तो मैं हमेशा एसएसआईएस 2005 में अपने लिए निर्माण कर रहा था। जाहिर है, विचित्र किनारे के मामले हैं जहां संपादक बंद होने पर एसएसआईएस 2008 हमेशा स्क्रिप्ट प्रोजेक्ट नहीं बनाते हैं।

Btw, precompiled binaries स्रोत XML के एक टैग BinaryItem कहा जाता है में संग्रहीत करने के लिए दिखाई देते हैं:

<DTS:Executable DTS:ExecutableType="Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask, Microsoft.SqlServer.ScriptTask, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" DTS:ThreadHint="0"> 
    <DTS:Property DTS:Name="ObjectName">SCR_StepOne</DTS:Property> 
    <DTS:ObjectData> 
     <ScriptProject Name="ST_5bd541c294054c25b9e7eb55b92bd0e2" VSTAMajorVersion="2" VSTAMinorVersion="1" Language="CSharp" EntryPoint="Main" ReadOnlyVariables="User::FileOneName,User::OutputFolder" ReadWriteVariables=""> 
     <BinaryItem Name="\bin\release\st_5bd541c294054c25b9e7eb55b92bd0e2.csproj.dll"> 
      TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
      AAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v 
      ZGUuDQ0KJAAAAAAAAABQRQAATAEDADuOb04AAAAAAAAAAOAAAiELAQgAABAAAAAIAAAAAAAAPi8A 
      AAAgAAAAQAAAAABAAAAgAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAMAQIUAABAA 

आप अपने स्रोत कोड नियंत्रण प्रणाली इतिहास की जाँच है कि अगर कुछ के लिए अद्यतन मिल रही थी, को देखने के लिए लायक हो सकता है उन खराब त्रुटियों में से।

चेतावनी: मुझे इस पर आधिकारिक माइक्रोसॉफ्ट दस्तावेज नहीं मिला है।