2012-04-17 46 views
3

我有一个SSIS包,只是运行一个SSIS脚本任务(不是我)写的。然后,该脚本动态创建包并以线程方式运行它们,管理活动的线程数。这是使用SQL Agent启动的。这是从Attunity Source获取11g Oracle数据库的数据。SSIS C#脚本任务约250MB内存使用失败

当我看到taskmanager中的进程时,我看到DTexec.exe缓慢消耗越来越多的内存。当它达到250MB左右时会失败。它每次都会返回不同的错误,有时它甚至会显示为来自SQL代理的取消请求。

我减少了最大内存给操作系统更多,没有工作。

它不应该是一个memToLeave问题,因为它是64位。 我试过运行命令行,什么都没有。

Windows Server 2003的 SQL 2008R2

我有这这么大的麻烦,并尝试了所有我能在网上找到。有人有主意吗?我确信我在这里留下了一些东西,所以请问,我会为你找到答案。

+0

你有我的哀悼。我认为主数据包的原因只是让他们能够比生产数据库管理员更容易地安装到生产环境中?当你说你从命令行运行它时,什么都没有。这是否意味着没有错误或者根本不运行? – billinkc 2012-04-17 20:51:14

+0

它表现出与运行代理程序相同的行为。它缓慢地填满(RAM)然后死掉(250MB)而不会留下SSISlog消息,并且通常没有窗口事件,SQLDumper似乎无能为力。 – Grinder 2012-04-17 21:42:09

回答

2

所以,我明白了。

编写C#的方式没有明确销毁正在创建的线程的机制,但之前从来没有问题的原因是脚本任务在SSIS包内创建了一个DLL。默认情况下,我的环境具有32位运行时,并且按照这种方式构建。如果SSIS包内置32位模式,它具有256MB的硬RAM限制,64位没有这样的限制。那么我需要做什么?

在Visual Studio ON THE SERVER ITSELF中打开包,然后保存它。这迫使它在64位模式下重新编译(如果它是该服务器上的默认运行时间)。

+0

出于好奇,如果你只是使用64位dtexec来运行软件包,它是否仍然表现出相同的行为? – billinkc 2012-04-19 14:29:07

+1

是的。它确实表现出这种相同的行为,死于256MB,而且由于64位在错误日志记录方面并不是最详细的,所以在无数其他因素中,这使得它成为一场完美风暴,因此很难排除故障。 – Grinder 2012-04-20 11:25:22