SSIS C＃腳本任務約250MB內存使用失敗

我有一個SSIS包，只是運行一個SSIS腳本任務（不是我）寫的。然後，該腳本動態創建包並以線程方式運行它們，管理活動的線程數。這是使用SQL Agent啓動的。這是從Attunity Source獲取11g Oracle數據庫的數據。SSIS C＃腳本任務約250MB內存使用失敗

當我看到taskmanager中的進程時，我看到DTexec.exe緩慢消耗越來越多的內存。當它達到250MB左右時會失敗。它每次都會返回不同的錯誤，有時它甚至會顯示爲來自SQL代理的取消請求。

我減少了最大內存給操作系統更多，沒有工作。

它不應該是一個memToLeave問題，因爲它是64位。我試過運行命令行，什麼都沒有。

Windows Server 2003的 SQL 2008R2

我有這這麼大的麻煩，並嘗試了所有我能在網上找到。有人有主意嗎？我確信我在這裏留下了一些東西，所以請問，我會爲你找到答案。

2012-04-17 Grinder

你有我的哀悼。我認爲主數據包的原因只是讓他們能夠比生產數據庫管理員更容易地安裝到生產環境中？當你說你從命令行運行它時，什麼都沒有。這是否意味着沒有錯誤或者根本不運行？ – billinkc 2012-04-17 20:51:14

它表現出與運行代理程序相同的行爲。它緩慢地填滿（RAM）然後死掉（250MB）而不會留下SSISlog消息，並且通常沒有窗口事件，SQLDumper似乎無能爲力。 – Grinder 2012-04-17 21:42:09

所以，我明白了。

編寫C＃的方式沒有明確銷燬正在創建的線程的機制，但之前從來沒有問題的原因是腳本任務在SSIS包內創建了一個DLL。默認情況下，我的環境具有32位運行時，並且按照這種方式構建。如果SSIS包內置32位模式，它具有256MB的硬RAM限制，64位沒有這樣的限制。那麼我需要做什麼？

在Visual Studio ON THE SERVER ITSELF中打開包，然後保存它。這迫使它在64位模式下重新編譯（如果它是該服務器上的默認運行時間）。

2012-04-18 15:14:22 Grinder

出於好奇，如果你只是使用64位dtexec來運行軟件包，它是否仍然表現出相同的行爲？ – billinkc 2012-04-19 14:29:07

是的。它確實表現出這種相同的行爲，死於256MB，而且由於64位在錯誤日誌記錄方面並不是最詳細的，所以在無數其他因素中，這使得它成爲一場完美風暴，因此很難排除故障。 – Grinder 2012-04-20 11:25:22

回答