我正在为仓库实现一种新方法。新方法包括在源表和目标表之间执行增量加载(插入、更新或删除)。
所有表都运行良好,除了 1 个表,其中 Source 有超过 300 万行,如下图所示,它只是开始运行但从未结束。 可能我没有以正确的方式进行更新,或者有另一种方式进行更新。
突出显示的对象是它悬挂的地方。 这是我调用来更新表的存储过程:
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 秒(平均)!!!
最佳答案
遵循这 2 个性能增强器,您将避免瓶颈。
删除
排序
转换。在您的源代码中,获取数据时使用order by
sql。 原因是,sort
在排序前占用了内存中的所有记录。您不希望这样,无论是增量加载还是满载。在更新的最后一步,引入另一个 Staging Table 而不是
update records oledb 命令
,它将成为 Dim 表的副本。一旦所有匹配的记录都插入到这个新的暂存表中,退出数据流任务并创建EXECUTE SQL TASK
,它将根据连接 ID/条件简单地更新 Dim 表。
原因是,oledb 命令逐行命中。始终喜欢使用 Execute SQL Task
作为批处理进行更新。
编辑:
根据评论,要仅更新 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)
关于sql - SSIS 在更新期间挂起,有 300 万行,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53601501/