sql server 表快速加载不是答案

【问题标题】：sql server table fast load isn'tsql server 表快速加载不是
【发布时间】：2009-05-13 21:26:55
【问题描述】：

我继承了一个 SSIS 包，它将 500K 行（大约 30 列）加载到临时表中。

它现在已经烹饪了大约 120 分钟，但还没有完成 --- 这表明它的运行速度低于每秒 70 行。我知道每个人的环境都不同，但我认为这与“典型”相差几个数量级。

奇怪的是，暂存表在 INT（身份）列上有一个 PK 约束——现在我认为它可能会妨碍加载性能。暂存表上没有其他约束、索引或触发器。

有什么建议吗？

---- 附加信息 ------
源是一个制表符分隔的文件，它连接到两个单独的数据流组件，这些组件将一些静态数据（运行日期和批次 ID）添加到流中，然后连接到 OLE DB 目标适配器

访问模式是使用 FastLoad 的 OpenRowset

FastLoadOptions 是 TABLOCK,CHECK_CONSTRAINTS

最大插入提交大小：0

【问题讨论】：

你能举个例子说明数据是什么样子和表结构吗？
即使有 PK 约束，它的性能也应该比这好很多。你能看到 SSMS 中的任何锁吗？您是否尝试过使用 nolock/read uncommitted 查询暂存表以查看是否添加了任何内容？

【解决方案1】：

我不确定回答自己问题的礼仪 - 如果这更适合发表评论，请提前道歉。

问题在于文本文件中输入列的数据类型：它们都被声明为“文本流 [DT_TEXT]”，当我将其更改为“字符串 [DT_STR]”时，在 58 秒内加载了 200 万行，即现在处于“典型”领域——我不确定当以这种方式声明列时文本文件源在做什么，但现在它已经落后了！

【讨论】：

【解决方案2】：

我会说存在某种问题，我从一个包含 2000 万条记录和更多列以及一个标识字段的文件中批量插入一个暂存表，而 SSIS 应该比 SQL 更快Server 2000 批量插入。

您检查过阻塞问题吗？

【讨论】：

【解决方案3】：

如果它在一个大事务中运行，那可能会解释一些事情。确保不时完成提交。

您可能还想检查处理器负载、内存和 IO 以排除资源问题。

【讨论】：

【解决方案4】：

这很难说。

我有复杂的 ETL，我会检查数据流中允许的最大线程数，看看是否可以并行运行。

不过听起来好像很简单的转移。

对于 500,000 行，批处理是一种选择，但我认为这几行没有必要。

PK 身份应该不是问题。您在目标上是否有任何复杂的约束或持久的计算列？

这是拉动还是推动慢速网络链接？它是从复杂的 SP 或视图中拉出还是推入？数据源是什么？

【讨论】：