G B*_*dal 13 ssis sql-server-2008-r2
我们注意到最近一个问题,有时重新部署SSIS包似乎不包括最新的更改......当我使用记事本搜索dtsx时,我在代码中看到修改后的脚本,所以肯定会有更改.
我的假设是SSIS包的脚本组件最终在这个过程的某个地方被编译成一个程序集 - 这很可能是因为我认为C#代码无法在没有首先编译它的情况下运行.因此,理论上如果这些程序集最终会被缓存而不是立即被覆盖(由于某种原因),这将解释这个问题.
让我觉得我的理论是正确的唯一"证据"是,如果我在某个时刻继续运行包,它会突然转向新代码.
然而,到目前为止,我还没有找到为什么以及如何发生这种情况,如果是......有人可以帮忙吗?
更新: MSDN说:"与早期版本不同,您可以指出脚本是否已预编译,所有脚本都在SQL Server 2008 Integration Services(SSIS)和更高版本中预编译." - 如果通过预编译它们意味着而不是实际的包运行预编译版本(我认为这是因为包本身似乎没有编译,因为代码在记事本中可见)必须有一种方法来强制引擎覆盖预编译的程序集......但是如何?
更新: SSIS的四个核心组件之一是SQL ServerIntegration Services服务,它是一个Windows服务.显然,此服务将缓存组件/任务元数据,以便SSIS运行时引擎可以轮询缓存以查看安装的内容,这可能有助于加快程序包加载时间.但是,如果包存储在文件系统中(而不是在SQL Integration Services中)并由代理作业执行,则代理作业将使用64位版本的DTEXEC来执行包.我还没有找到任何证据表明在那里会涉及任何缓存,但是在执行的验证阶段确定检查许多参数肯定有选项,例如版本号 - 可能是有原因的.
您是否查看过 sysssispackages 以将 msdb 中包的版本构建号与 Visual Studio / SSIS 中的构建号进行比较?
SELECT name, verbuild
FROM msdb.dbo.sysssispackages
WHERE name LIKE '%bla%'
Run Code Online (Sandbox Code Playgroud)
(根据需要调整 WHERE 子句以查找您的包。切勿“SELECT * FROM msdb.dbo.sysssispackages”,因为它在其中一列中包含包 XML。)
在 Visual Studio 中,打开包,然后右键单击包的背景,然后从上下文菜单中选择“属性” 。查看 VersionBuild 字段。它应该与上面的 SELECT 中的数字匹配!
我知道这并不是您问题的实际解决方案,但它可能有助于找到问题的原因所在。如果该数字较旧,则意味着您的包部署不起作用。
归档时间: |
|
查看次数: |
5852 次 |
最近记录: |