重新部署SSIS包 - 緩存？

我們注意到最近有一個問題，重新部署的SSIS包有時似乎沒有包含最新的更改......當我使用記事本搜索dtsx時，我在代碼中看到修改後的腳本，所以更改肯定存在。重新部署SSIS包 - 緩存？

我的假設是，SSIS包的腳本組件最終被編譯到程序中的某個程序集中 - 這很可能是因爲我想如果沒有先編譯它，C＃代碼就無法運行。所以在理論上，如果這些程序集最終會被緩存，並且不會立即被覆蓋（出於某種原因），這可以解釋這個問題。

使我認爲我的理論是正確的唯一「證據」是如果我在某個點繼續運行包，它會突然轉向新的代碼。

但是，到目前爲止，我還沒有找到爲什麼以及如何發生這種情況，如果是......任何人都可以幫忙嗎？

UPDATE： MSDN說：「不像早期版本，你可以指出腳本是否被預編譯，所有的腳本在SQL Server 2008集成服務（SSIS）和更高版本預編譯的。」 - 如果按預編譯的，它們表示代替預編譯版本運行的實際程序包（我認爲這是因爲程序包本身似乎沒有編譯，因爲代碼在記事本中是可見的），所以必須有一種方法強制引擎覆蓋預編譯的程序集......但是如何？

UPDATE： 一個SSIS的四個核心部件是SQL ServerIntegration Services服務，這是一個Windows服務。顯然這個服務會緩存組件/任務元數據，以便SSIS運行時引擎可以輪詢緩存以查看安裝的內容，這可能有助於加快程序包加載時間。但是，如果程序包存儲在文件系統中（不在SQL集成服務中）並由代理程序作業執行，代理作業將使用64位版本的DTEXEC來執行程序包。我還沒有找到有證據表明任何緩存都會涉及到，但是在執行的驗證階段檢查一些參數肯定有選項，例如版本號 - 可能是有原因的。

來源

2012-07-05 G Berdal

只是說我們今天在這裏有完全相同的問題。重新啓動代理程序或SQLSISS都有幫助。 – 2013-05-31 13:24:28

訣竅是從涉及的表中添加和刪除列。顯然，這不是我們要走的路，我們肯定對這個問題的答案感興趣 – 2013-06-03 06:22:07

另外：我認爲緩存存儲在磁盤的某個位置，因爲它在服務器重啓後仍然存在 – 2013-06-03 06:25:45

您是否查看過sysssispackages，將msdb中包的版本內部版本號與Visual Studio/SSIS中的內部版本號進行比較？

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

（必要時，調整WHERE子句找到你的包。永遠不要「SELECT * FROM msdb.dbo.sysssispackages」，因爲它包含了一列包XML）

而且在Visual Studio中打開軟件包，然後右鍵單擊軟件包的背景，然後從上下文菜單中選擇「屬性」。看看字段VersionBuild。它應該與上面的SELECT匹配！

我知道這不是您的問題的實際解決方案，但它可能有助於找出問題的原因所在。如果該數字較舊，則意味着您的軟件包部署無效。

來源

2013-07-02 13:07:17 cmenke

+1好的建議。我們將嘗試重現問題，並檢查這是否可以幫助我們至少指出這是問題所在。顯然我們仍在尋找解決問題的實際解決方案。 – 2013-07-02 13:12:51

現在你可以發表評論;） – 2013-07-02 13:13:17

+ cmenke：你的查詢返回8行：SqlTraceCollect，SqlTraceUpload，TSQLQueryCollect，TSQLQueryUpload，PerfCountersCollect，PerfCountersUpload，QueryActivityCollect，QueryActivityUpload。顯然這些都不是我的問題。我們的部署過程如下：我們的msi包只是將dtsx複製到文件夾，更改配置文件（對於conn信息等）。然後我們的調度程序運行dtexec/F「％dtsfile％」/ Rep EPW/Conf％dtsconfig％>％logfile％我們是否需要執行其他操作？ – 2013-07-02 13:23:54

這並不能明確解決您的疑惑，但是如果您正在運行基於文件系統的軟件包，並且想要驗證正在運行的軟件包是您部署的軟件包，則有一種方法可以做到這一點。

建立你的包。
打開包裝上的屬性並記下「版本構建」屬性（或者，打開記事本中的.dtsx並找到DTS：VersionBuild屬性。）
部署您的包。
在您的SQL Agent作業步驟中，轉到Verification選項卡。
在「驗證包構建」輸入框中輸入版本構建。
執行作業步驟。

我不知道這是否會強制SSIS拋出它的緩存並獲得新部署的包，但我知道如果您手動修改.dtsx包的內部版本號，然後嘗試重新運行工作步驟失敗，因爲包構建與它所尋找的不匹配，所以它肯定會對該值進行運行時檢查。

來源

2013-07-02 15:05:27

我認爲步驟3和4不適用，因爲我們從文件系統運行。 – 2013-07-04 09:21:29

那麼，你仍然「部署」你的工作，你只是使用部署到文件系統。而且，對於子類型爲SSIS包的任何SQL代理作業，您仍然具有「驗證」選項卡。 – 2013-07-08 16:58:59

這聽起來有點熟悉我後面碰到的東西。不幸的是，我不記得當我碰到這個（所以我不能確定），但我相信我發現的修復是確保我明確地從腳本編輯器調用Build | Build st_5bd541c294054c25b9e7eb55b92bd0e2命令（VSTA）菜單，然後關閉窗口。（顯然，每個腳本的具體項目名稱不同，因爲它基於GUID;但是，在Build下只會有一個可能的子菜單。）

明確調用Build命令可確保二進制代碼腳本獲取ASCII編碼並保存在生成的.dtsx文件的XML中。我習慣了SSIS 2005，每當我關閉腳本編輯器時，都會隨時爲我構建。顯然，在編輯器關閉時，SSIS 2008並不總是構建腳本項目，這是奇怪的邊緣情況。

BTW，預編譯的二進制文件似乎是存儲在一個稱爲BinaryItem源XML的標記：

<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

這可能是值得檢查你的源代碼控制系統的歷史，看看是否是得到了一些更新那些棘手的錯誤。

警告：我還沒有找到關於此的官方Microsoft文檔。

來源

2013-07-02 21:14:02

我是否認爲這隻適用於C＃腳本項目？迄今爲止，我們還沒有真正使用過這些。 – 2013-07-04 08:59:51

我沒有檢查過，但我期望它對於C＃或VB.NET項目都是一樣的（我很確定這是一個SSIS 2008問題）。 – 2013-07-05 03:47:59

當我通過將.dtsx編輯爲XML來修改腳本組件時，遇到了這個問題。因爲它是通過XML而不是設計器編輯的，所以二進制文件從不重新編譯;這是一個「杜？！」時刻。正如你所說，修正是明確重新編譯每個編輯的腳本組件。 – uhleeka 2013-11-20 19:23:24

重新部署SSIS包 - 緩存？

回答

相關問題