SSIS查找组件违规行为

Question

我在数据流中看到了奇怪的行为和查找操作。如果我选择“完整缓存”模式，部分查找将失败，我无法解释原因。“无缓存”工作正常，“部分缓存”也是如此。在这一点上，如果“完全缓存”神秘失败，我无法信任它。

预期的结果如下-

1 808 larry curly moe

2 808 larry curly moe

3 314 foo bar baz

4 314 foo bar baz

5 314 foo bar baz

6 314 foo bar baz

整个缓存会产生这个结果-

1 808 larry curly moe

2 808 larry curly moe

3 314 foo bar baz

4 314 foo bar baz

5 314 null null null

6 314 null null null

“314”的例子是一个实际的结果。前两个记录查找正确，第二个记录查找失败。如果它们是缓存失败，则所有四行都会失败。

失败是可重复的-相同的项目失败在相同的顺序，每次运行。这个环境是一个孤立的测试环境，有三个固定的数据库，它们在运行过程中不会发生变化。选择部分缓存的速度明显较慢，这意味着有大量缓存丢失。没有一个表是特别大的，一千行左右。

到底怎么回事？我应该放弃使用完全缓存的希望吗？

Answer 1

我也见过这种行为。我的原因是服务器内存，我将在指南中解释这一点。这很讨厌，因为它是断断续续的。

对于部分缓存，缓存从空开始，然后查询，直到找到匹配。如果你有多场比赛，第一场就赢了。有了完整的缓存，如果你有多个匹配，我不确定哪个会赢。可能是缓存顺序中的第一个。

部分缓存具有丢失缓存的选项，该选项将记住哪些记录没有匹配项，并且不会再次查询它们。如果要插入正在查找的表，这将是一个问题。同样，对于完整的缓存，如果您的源包含重复项，则在插入第一个缓存后，第二个文件将不会得到匹配，这将是一个问题，如果您想要取消第一个文件之外的所有内容。

以下是我在使用查找时尝试遵循的一些指南：

1. 查找永远不会将缓存交换到磁盘。如果内存耗尽，任务就会失败。如果这是你的问题，得到更多的冲压或尝试部分。
2. 尽可能使用整数。如果字段是字符串，但可以强制转换为int，则执行该操作。这个移除大小写和空白都是一个问题。
3. 修剪绳子。空白会让你合身的。
4. 如果是字符串，则在比较前大写两边(查找区分大小写，如果大小写不匹配则会失败)。
5. 空永远不等于空。如果该列为空，则用“未知”If字符串替换两边，如果是整数，则替换为-999这样的无理数。
6. 如果列为空，则将两边替换为文本“空”。

这是一个痛苦的屁股，但这比凌晨3点接到电话要好，因为一级客户ETL失败了。