0

我有超过百万条记录的表。

  1. 当我在 SSMS 中执行查询时，在任何时间点肯定需要大约 1:24 不到 2 分钟，并返回大约 600,000 条记录。
  2. SSIS 需要几个多小时，事实上我只能导出一次。

这是示例sql：

SELECT distinct 
A.Col1, A.Col2, A.Col3, A.Col4, A.Col5, A.Col6, A.Col7, B.Col3
FROM tblA  A
inner join tblB B on A.Col1 = B.col1 and 
A.Col2 = 'AB' AND A.Col3 Not In ('A','B','C') AND 
A.Col3 In ('FPC','FPE','PRN','SUB','RVW','FPO','FEV','PRM')

注意：select sql 查询中的所有列（以及 where 子句中提到的列）都存在索引。

在 SSIS 中，

  1. 我在控制流上有数据流任务。
  2. 带有 SQL 查询命令的 OleDB 源。
  3. OleDB 目标表。

什么可能导致 SSIS 延迟？

4

2 回答 2

1

根据我的经验，这可能是以下两种情况之一：

  1. 这可能是所谓的参数嗅探。这仅仅意味着有时它将一个糟糕的（慢速）查询计划绑定到查询+参数，并且由于缓存这个糟糕的计划可能会“卡住”并不断地重新用于特定的应用程序或用途。检测这种情况的方法是使用 SQL Profiler 捕获 SSIS 任务查询的查询计划，然后将其与快速执行的 SSMS 版本的查询计划进行比较。如果查询计划明显不同，那么您可能遇到了参数嗅探问题。

  2. 但是，对于 SSIS，有一个更常见的问题（在我的评论/问题和 Mike Honey 的回答中提到）：因为 SSIS 使用管道架构，所以您只需要链中的一个慢速组件来停止整个管道。组件速度慢的一个非常常见的原因是没有为数据流任务使用最佳任务设置。

使用“快速加载”是一种可能性，但是根据我的经验，还有另一种设置在网络上流水线时更常见，那就是“DefaultBufferMaxRows”。默认值是 10,000，我总是发现对于网络连接来说太高了，在这些情况下可能应该在 100 到 1000 之间。

这是控制流中目标 DFT（数据流任务）的属性，因此要更改它只需在控制流视图中选择该任务的图标。您应该在属性窗格中看到 DefaultBufferMaxRows（在“Misc”下）。您可能还想按比例降低“DefaultBufferSize”。

于 2013-02-26T15:36:04.650 回答
1

您的问题很可能与您的 OLE DB 目标和它可以接受行的速率有关。您可以通过测试已删除 OLE DB 目标的包副本来确认这一点。

假设是这种情况，最常见的原因是未在传递到 SQL Server 的 OLE DB 目标中使用“快速加载”选项。

于 2013-02-26T02:44:14.693 回答