我们将数据从源系统引入我们的数据仓库。
他们正在将一些列从nvarchar(255)更改为nvarchar(max)。看看他们的数据,似乎95%的数据低于255个字符,99%(可能是100%)低于4000个字符。我们不得不更改我们的SSIS包元数据以使用NTEXT引入这些列(它们在4个表中转换8列)。
我不熟悉SSIS如何处理nvarchar(max)(在SQL Server中)/ NTEXT(在SSIS中)以及将会有什么性能影响(如果有的话)。 SSIS是否以不同的方式处理这些数据类型并且可能更慢?
我们基本上直接读取并转储到我们的暂存环境中,然后从那里继续。我知道SQL方面的限制,但不知道SSIS阶段的限制。
SQL Server 2012 / SSIS 2012
答案 0 :(得分:4)
在他们手上发生灾难之前,立即停止源系统的所有者。另见
这些文章和答案涵盖了一些这会对您的数据库造成伤害的原因。
我们来谈谈SSIS和数据流任务。数据流任务适用于缓冲区的概念。缓冲区是N行数据适合的预先大小的内存单元。这是SSIS对数据类型如此苛刻的一个根本原因,并且总是在检查它们。我们可以在内存中容纳1000个@ 100字节的缓冲区。但是,然后你去加倍源中所有列的大小,突然间,一次只有500个适合的行适合内存。这可能会减慢总吞吐量。
二进制/大对象数据/流数据不同。 SSIS不知道/不能知道该数据是否适合内存。你可能会躲过一颗子弹而且执行引擎能够将你的字符串放在缓冲区中,虽然你可能会有一些减速,但它可能并不明显。 但是,如果引擎确定真的是LOB数据怎么办?那你就驼背了。由于SSIS会在BLOBTempStoragePath
location以及可能BufferTempStoragePath
中创建所有这些可爱的小文件,因此您可以慢慢观看您的表现。而不是在缓冲区中使用数据(memory = fast),而是在缓冲区中将指针指向磁盘上的物理路径(disk = slow)。
你可以为它付出很多的性能损失。想一想。您从dbo.BadDecision
中提取所有数据以用于ETL过程。该数据可能不会全部存储在缓冲区缓存中,因此SQL Server或您使用的任何主机数据库都必须从磁盘读取所有数据。磁盘很慢。也许您通过网络将其流式传输到ETL服务器。那些胖类型无法放入内存中,因此它们会被写回磁盘,甚至可能不是快速磁盘,因为您没有设置缓冲路径。假设您没有填满C:并使服务器崩溃,那么您需要付费将刚从磁盘读取的数据写入单个小文件,同时数据通过管道传输。那批记录现在已准备好写入目标表 - 猜猜是什么?我们需要从这些文件中读取数据以实际存储它。当然,目标系统然后将该数据重写到磁盘。
听起来很有趣,不是吗?
所以打架,用你拥有的一切来对抗它。这是一个糟糕的,懒惰的决定,会让公司,而不仅仅是你和你的团队,在屁股上大打折扣。
不清楚引擎溢出到磁盘上LOB的确切机制。 John Welch撰写的文章澄清:LOBs in the SSIS Dataflow
由于这些数据类型有可能容纳如此多的数据,因此SSIS处理它们的方式与标准数据类型略有不同。它们与缓冲区中的常规数据分开分配。当存在内存压力时,SSIS将缓冲区假脱机到磁盘。 LOB数据的潜在大小使得它很可能被假脱机,这可能是一个非常重要的性能瓶颈。