Tag: bulkinsert tvp

bcp / BULK INSERT与表值参数的性能

我将不得不使用SQL Server的BULK INSERT命令重写一些相当老的代码，因为架构已经改变了，而且我想到了也许我应该考虑用TVP切换到存储过程，但是我想知道它可能对性能有什么影响。 一些背景信息可能有助于解释为什么我问这个问题： 数据实际上是通过Web服务进入的。 Web服务将文本文件写入数据库服务器上的共享文件夹，然后执行BULK INSERT 。 这个过程最初是在SQL Server 2000上实现的，当时真的没有别的办法，只能在服务器上夹几百个INSERT语句，这实际上是原来的过程，并且是性能灾难。 数据被批量插入到永久登台表中，然后被合并到一个更大的表中（之后，它从登台表中被删除）。 要插入的数据量是“大”，但不是“巨大” – 通常是几百行，在极less数情况下可能是5-10k行。 因此，我的直觉是BULK INSERT是一个非日志操作，不会有太大的区别（当然，我不确定，因此是个问题）。 插入实际上是一个更大的stream水线批处理的一部分，需要连续发生多次; 因此性能至关重要。 我想用TVP取代BULK INSERT的原因是： 通过NetBIOS编写文本文件可能已经花费了一些时间，从架构的angular度来看这是相当可怕的。 我相信舞台表可以（也应该）被淘汰。 主要原因是插入的数据需要在插入的同时用于其他更新，并且从大量生产表尝试更新比使用几乎空的暂存更昂贵表。 有了TVP，参数基本上就是临时表，我可以在主插入之前/之后做任何事情。 我几乎可以避免使用重复检查，清除代码以及所有与批量插入相关的开销。 如果服务器同时获取这些事务中的一些（我们试图避免它，但是它发生），则无需担心登台表或tempdb上的锁争用。 很明显，在将任何东西投入生产之前，我会先简单介绍一下，但是我认为在我花费所有时间之前先问问一下是个好主意，看看有没有人有严格的警告要求使用TVP来达到这个目的。 所以 – 对于那些对SQL Server 2008来说足够安逸的人来说，已经尝试过或者至less调查过这个，那么判断是什么？ 对于插入数百行到数千行，频繁发生的事情，TVP是否切断了芥末？ 与散装刀片相比，性能是否有显着差异？ 更新：现在减less了92％的问号！ （又名：testing结果） 现在最终的结果是在36阶段的部署过程之后进行生产。 两种解决scheme都经过了广泛的testing 翻出共享文件夹代码并直接使用SqlBulkCopy类; 使用TVP切换到存储过程。 为了让读者能够了解究竟是什么被testing的，为了消除对这些数据的可靠性的任何怀疑，下面是对这个导入过程实际上做了什么的更详细的解释： 从一个通常约20-50个数据点的时间数据序列开始（尽pipe有时可能多达几百个）; 做一大堆疯狂的处理，大部分独立于数据库。 这个过程是并行的，所以（1）中的大约8-10个序列正在被同时处理。 每个并行进程生成3个附加序列。 把所有3个序列和原始序列合并成一个批次。 将所有8-10个已完成的加工任务的批次合并为一个大的超批次。 使用BULK INSERT策略（见下一步）或TVP策略（跳到步骤8）导入它。 使用SqlBulkCopy类将整个超批量转储到4个永久登台表中。 运行一个存储过程（a）在其中两个表上执行一系列聚合步骤，包括几个JOIN条件，然后（b）使用聚合数据和非聚合数据在6个生产表上执行MERGE 。 （成品） 要么 […]