SSIS 在更新期间挂起，有 300 万行

Question

我正在为仓库实施一种新方法。新方法包括在源表和目标表之间执行增量加载（插入、更新或删除）。

所有表都运行良好，除了 1 个表，其 Source 的行数超过 300 万行，如下图所示，它刚刚开始运行，但从未完成。 可能我没有以正确的方式进行更新，或者有其他方法可以做到这一点。

以下是我的 SSIS 包的一些图片：

突出显示的对象是它挂起的地方。 这是我调用来更新表的存储过程：

ALTER PROCEDURE [dbo].[UpdateDim_A] 
      @ID INT,
      @FileDataID INT
     ,@CategoryID SMALLINT
     ,@FirstName VARCHAR(50)
     ,@LastName VARCHAR(50)
     ,@Company VARCHAR(100)
     ,@Email VARCHAR(250) AS BEGIN
SET NOCOUNT ON;


BEGIN TRAN 
 UPDATE DIM_A 
    SET                  
        [FileDataID] = @FileDataID,
        [CategoryID] = @CategoryID,
        [FirstName]  = @FirstName,
        [LastName]   = @LastName,
        [Company]    = @Company,
        [Email]      = @Email

    WHERE PartyID=@ID

    COMMIT TRAN;  END

注意： 我已经尝试过删除约束和索引并将数据库的恢复模式更改为简单。

任何帮助将不胜感激。

---

应用@Prabhat G 提供的解决方案后，这是我的包的样子，运行时间为 39 秒（平均）！！！

在 Dim_A 数据流内部

Answer 1

遵循这 2 个性能增强器，您将避免瓶颈。

1. 删除sort 转换。在您的源代码中，在获取数据时使用order by sql。 原因是，sort 在排序之前占用了内存中的所有记录。你不希望这样，无论是增量负载还是全负载。

2. 在更新的最后一步，引入另一个 Staging Table 而不是 update records oledb command，它将是 Dim 表的副本。一旦所有匹配的记录都插入到这个新的临时表中，退出数据流任务并创建EXECUTE SQL TASK，它将根据连接 ID/条件简单地更新 Dim 表。

原因是，oledb 命令逐行命中。始终喜欢使用Execute SQL Task 作为批处理更新。

---

编辑： 根据 cmets，要仅更新 Execute SQL Task 中更改的行，请在 where 子句中添加条件：

eg:

UPDATE x
SET
   x.attribute_A = y.attribute_A
  ,x.attribute_B = y.attribute_B
FROM
DimA x
 inner join stg_DimA y
ON x.Id = y.Id
WHERE
(x.Attribute_A <> y.Attribute_A
OR x.Attribute_B <> y.Attribute_B)

Answer 2

所以您的问题实际上非常简单，您使用的方法是为返回的每一行执行该存储过程。如果您有 9961 行（如图所示）要更新，它将在 9961 单独的时间运行该语句。如果您要查看 SQL Server 上运行的活动查​​询，您可能会看到该过程一遍又一遍地执行。

您应该做的就是将数据转储到临时表中，然后在您的包中进一步使用执行 SQL 任务来运行标准 SQL 更新。这将运行得更快。

Answer 3

问题是您正试图在数据流中执行存储过程。正确的 SqlCommand 将是一个显式的 UPDATE 查询，然后将 SSIS 中的列映射到您正在更新的表上的列。

UPDATE DIM_A 
SET FileDataID = ?
    ,CategoryID = ?
    ,FirstName = ?
    ,LastName = ?
    ,Company = ?
    ,Email = ?
WHERE PartyID = ?

注意：@Id 需要作为列包含在数据流中。

正如 Zane 正确指出的那样，您应该考虑的最后一件事是：您应该只更新已更改的行。因此，在您的数据流中，您应该添加一个条件拆分转换，以检查新源行中的任何列是否与现有表行不同。只有不同的行应该发送到 OLE DB 命令 - 其余的可以忽略。