我们正在将数据从源系统引入我们的数据仓库。
他们正在将某些列从 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
在他们手头发生灾难之前立即停止源系统的所有者。也可以看看
这些文章和答案涵盖了这会损害您的数据库的一些原因。
让我们来谈谈 SSIS 和数据流任务。数据流任务基于缓冲区的概念。缓冲区是 N 行数据将放入的预先大小的内存单元。这是 SSIS 对数据类型如此挑剔并始终检查它们的根本原因之一。我们可以将 1000 @ 100 字节缓冲区放入内存。但是随后您将源中所有列的大小加倍，突然间，一次只有 500 行适合内存。这可能会减慢总吞吐量。
二进制/大对象数据/流数据是不同的。SSIS 不/不能知道该数据是否适合内存。您可能会躲避子弹，并且执行引擎将能够将您的字符串放入缓冲区中，虽然您可能会放慢速度，但可能不会很明显。但是，如果引擎确定这确实是 LOB 数据呢？那你就驼背了。当 SSIS 在您BLOBTempStoragePath 所在的位置创建所有这些可爱的小文件时，您可能会看到您的性能缓慢到爬行BufferTempStoragePath。不是在缓冲区中有数据（内存 = 快），而是在缓冲区中有一个指向磁盘上物理路径的指针（磁盘 = 慢）。
你会为此付出很多的性能损失。想想看。你把所有的数据从dbo.BadDecision用于您的 ETL 过程。该数据可能并非全部在缓冲区缓存中，因此 SQL Server 或您使用的任何主机数据库都必须从磁盘读取所有数据。磁盘很慢。也许您通过网络将其流式传输到 ETL 服务器。这些胖类型无法放入内存中，因此它们会被写回磁盘，甚至可能不是快速磁盘，因为您没有设置缓冲区路径。假设您没有填满 C: 并使服务器崩溃，您需要付费将刚刚从磁盘读取的数据写入单独的小文件，同时数据在管道中移动。那批记录现在已准备好写入目标表 - 你猜怎么着？我们需要从这些文件中读取该数据以实际存储它。当然，目标系统然后将该数据重写到磁盘。
听起来很有趣，不是吗？
所以战斗吧，用你所拥有的一切来战斗吧。这是一个糟糕的、懒惰的决定，它会严重打击公司，而不仅仅是你和你的团队。
不清楚引擎溢出到磁盘以获取 LOB 的确切机制。John Welch 的文章阐明了：SSIS 数据流中的 LOB
因为这些数据类型有可能容纳如此多的数据，所以 SSIS 处理它们的方式与标准数据类型略有不同。它们与缓冲区中的常规数据分开分配。当存在内存压力时，SSIS 将缓冲区假脱机到磁盘。LOB 数据的潜在大小使其很可能被假脱机，这可能是一个非常主要的性能瓶颈。