我们的SSIS包含一个结构化的一个Control包和许多从控件包调用的子包（大约30个）。 使用“执行包任务”调用子包。 每个子包有一个执行包任务。 每个执行包任务使用文件连接管理器指定子包dtsx文件的路径。 每个子包有一个文件连接管理器。 每个文件连接管理器都有一个为ConnectionString属性定义的表达式。 这个表达式如下所示：
@[Template::FolderPackages]+"MyPackage.dtsx"每个包的文件名都不同。 变量（FolderPackages）在SSIS包配置文件中指定。
运行时生成的错误是
加载包文件“MyPackage.dtsx”时出错0x80070002
系统找不到指定的文件。“失败的包不同于运行运行，有时根本没有包失败。这是在完全相同的环境/数据等运行时。
我在此错误期间运行FileMon并发现当错误发生时SSIS尝试从错误的位置读取dtsx文件，即从system32读取。 我检查过这与@ [Template :: FolderPackages]变量为空时会发生的情况相同，但是因为每个子包都使用了相同的变量并且对某些子包起作用但有时对其他人不起作用，我没有对这个事实的谴责。
有什么明显的，或者是时候向微软提出支持电话？
Our SSIS pacakges a structured as one Control package and many child packages (about 30) that are invoked from the control package. The child packages are invoked with Execute Package Task. There is one Execute Package Task per child package. Each Execute Package Task uses File Connection Manager to specify path to the child package dtsx file. There is one File Connection Manager per child package. Each File Connection Manager has an expression defined for ConnectionString property. This expression looks like this:
@[Template::FolderPackages]+"MyPackage.dtsx"The file name is different for each package. The variable (FolderPackages) is specified in the SSIS package configuration file.
The error that is generated during run time is
Error 0x80070002 while loading package file "MyPackage.dtsx"
The system cannot find the file specified." The package that fails is different from run to run and sometimes no packages fail at all. This is when run on exactly the same environment/data etc.
I ran FileMon during this error and found out that when the error happens SSIS tries to read the dtsx file from a wrong place, namely from system32. I checked that this is identical to what would happen if @[Template::FolderPackages] variable were empty, but because the very same variable is used for every child package and works for some but doesn't work sometimes for others, I have no expalnation to this fact.
Anything obvious, or time to raise a support call with Microsoft?
最满意答案
您是否直接在SSIS变量上使用表达式？ 每次变量被需要使用它的消费对象引用时，计算带有表达式的变量。 这就是竞争条件错误存在的地方，因为如果另一个线程已经在评估另一个变量，并且该变量的默认值被提供给使用者对象，则有时表达式不会被评估。
如果这符合您的设计，连接站点上的这两个错误将讨论问题和解决方法：
https://connect.microsoft.com/SQLServer/feedback/details/332372/ssis-variable-expressions-dont-always-evaluate
第二个在connect.microsoft.com/SQLServer/feedback/details/406534/ssis-2008-variable-expressions-dont-always-evaluate
变通方法的摘要是{ - 注意可以在您的SSIS控制流中运行的并行任务并利用这些表达式变量。 如果你有两个并排的任务，如果每个任务依赖于同一个变量，并且该变量有一个Expression来设置它的值，那么你可以点击它。 手动序列化此类任务，以便它们不会并行运行。 IE浏览器。 在控制流上添加一个绿色箭头，以便任务按顺序发生在Task1，Task2，Task3中，而不是并行路径上并排，而不是在没有路径的同一容器内。
您可以避免使用变量表达式：使用执行相同类型工作的自制脚本任务以所需顺序分配局部变量，以便不使用表达式（即可以达到此竞争条件的事物）来评估变量。 换句话说，在使用之前，在控制流中的某个时间点手动分配变量值。 在变量上使用表达式的关键是在使用时根据另一个值动态设置一个值，因此这会以手动方式实现类似的设计目标。
减少线程以最小化潜力：将数据流任务EngineThreads设置为1，将MaxConcurrentExecutables设置为1.这将有助于将程序包的执行一次分离到一个任务，但这会产生可能导致性能降低的副作用。
在设计中的不同范围级别的变量的不同副本上创建和设置值，以便它们在不同的并行执行范围内进行评估，并避免在并行线程上进行表达式求值。 Master :: Var1，Child1 :: Var1，Child2 :: Var1
}
The official answer to this issue is that it is a bug in SQL 2005 and 2008. Many tasks accessing the same variable cause a race condition, and some tasks get the default value for the expression instead of the evaluated value.
The workaround is to ensure that the default value (the value defined in the property sheet for whatever property you are having trouble with) should be the value that will work in your production environment.
This way, when the race condition happens in prod, SSIS will fall back to the package value, which will still work.
In dev? Well you're just going to have to deal with that manually until we get a bug fix from Microsoft.
更多推荐
发布评论