我的C#客户端将大量数据插入SQL Server 2005数据库时遇到了一些性能瓶颈,我正在寻找加快这一过程的方法。
我已经在使用SqlClient.SqlBulkCopy(基于TDS)来加速数据传输,这有助于提供很多帮助,但我仍在寻找更多。
我有一个简单的表格,如下所示:
CREATE TABLE [BulkData](
[ContainerId] [int] NOT NULL,
[BinId] [smallint] NOT NULL,
[Sequence] [smallint] NOT NULL,
[ItemId] [int] NOT NULL,
[Left] [smallint] NOT NULL,
[Top] [smallint] NOT NULL,
[Right] [smallint] NOT NULL,
[Bottom] [smallint] NOT NULL,
CONSTRAINT [PKBulkData] PRIMARY KEY CLUSTERED
(
[ContainerIdId] ASC,
[BinId] ASC,
[Sequence] ASC
))
我在平均大约300行的数据块中插入数据,其中ContainerId和BinId在每个块中都是常量,而Sequence值是0-n,并且这些值是根据主键预先排序的。
%Disk时间性能计数器花费大量时间在100%,因此很明显磁盘IO是主要问题,但我得到的速度比原始文件副本低几个数量级。
如果我:
,它会有所帮助吗?- 根据我得到的答复,让我澄清一下:
Portman:我正在使用聚簇索引,因为当数据全部导入时,我将需要按顺序依次访问数据。导入数据时,我并不特别需要索引。在进行插入时是否有使用非聚簇PK索引的优势,而不是完全删除约束以进行导入?
Chopeen:数据是在许多其他机器上远程生成的(我的SQL服务器目前只能处理大约10个,但我希望能够添加更多)。在本地计算机上运行整个过程是不切实际的,因为它必须处理50倍的输入数据才能生成输出。
Jason:我在导入过程中没有对表进行任何并发查询,我会尝试删除主键,看看是否有帮助。
答案 0 :(得分:18)
您已经在使用SqlBulkCopy,这是一个良好的开端。
但是,仅使用SqlBulkCopy类并不一定意味着SQL将执行批量复制。特别是,SQL Server必须满足一些要求才能执行有效的批量插入。
进一步阅读:
出于好奇,为什么你的索引设置如此?似乎ContainerId / BinId / Sequence 很多更适合作为非聚集索引。您是否希望将此索引集群化?
答案 1 :(得分:18)
以下是在SQL Server中禁用/启用索引的方法:
--Disable Index ALTER INDEX [IX_Users_UserID] SalesDB.Users DISABLE
GO
--Enable Index ALTER INDEX [IX_Users_UserID] SalesDB.Users REBUILD
以下是一些可帮助您找到解决方案的资源:
Some bulk loading speed comparisons
Use SqlBulkCopy to Quickly Load Data from your Client to SQL Server
Optimizing Bulk Copy Performance
绝对关注NOCHECK和TABLOCK选项:
答案 2 :(得分:8)
我的猜测是,如果您将该索引更改为非群集,您将看到显着改善。这为您提供了两个选项:
任何一个都会加速你的插入而不会明显减慢你的读取速度。
以这种方式思考 - 现在,您正在告诉SQL进行批量插入,但是您要求SQL在每个表中重新排序整个表。使用非聚簇索引,您将按照它们进入的顺序添加记录,然后构建一个指示其所需顺序的单独索引。
答案 3 :(得分:4)
您是否尝试过使用交易?
根据您的描述,让服务器将100%的时间提交到磁盘,似乎您在原子SQL语句中发送每行数据,从而迫使服务器每一行提交(写入磁盘)。 / p>
如果您使用了交易,服务器只会在交易结束时提交一次。
有关进一步的帮助:您使用什么方法将数据插入服务器?使用DataAdapter更新DataTable,或使用字符串执行每个句子?
答案 4 :(得分:3)
BCP - 设置起来很痛苦,但是自从数据库出现以来它一直存在,而且非常快。
除非你按顺序插入数据,否则3部分索引会让事情变得迟钝。稍后应用它也会使事情变得缓慢,但将会迈出第二步。
Sql中的复合键总是很慢,键越大越慢。
答案 5 :(得分:3)
我不是一个聪明人,我对SqlClient.SqlBulkCopy方法没有太多经验,但这是我的2美分它的价值。我希望它可以帮助你和其他人(或者至少让人们说出我的无知;)。
除非数据库数据文件(mdf)位于与事务日志文件(ldf)不同的物理磁盘上,否则永远不会匹配原始文件复制速度。此外,任何聚簇索引都需要位于单独的物理磁盘上,以便进行更公平的比较。
您的原始副本未记录或维护选择字段(列)的排序顺序以用于索引目的。
我同意Portman关于创建非聚簇身份种子并将现有非聚簇索引更改为聚簇索引的信息。
至于您在客户端上使用的构造...(数据适配器,数据集,数据表等)。如果服务器上的磁盘io为100%,我认为花在分析客户端构造上的时间最好,因为它们似乎比服务器当前处理的速度快。
如果您按照波特曼关于最小日志记录的链接,我不会认为在交易中包围您的批量副本会有很大帮助,但我生命中多次出错;)
这对您现在不一定有帮助,但如果您弄清楚当前的问题,下一条评论可能有助于解决下一个瓶颈(网络吞吐量) - 特别是如果它是通过互联网...
Chopeen也问了一个有趣的问题。您是如何确定使用300记录计数块插入的? SQL Server有一个默认的数据包大小(我相信它是4096字节),我有必要派生你的记录大小,并确保你有效地利用客户端和服务器之间传输的数据包。 (注意,您可以在客户端代码上更改数据包大小,而不是服务器选项,这显然会改变所有服务器通信 - 可能不是一个好主意。)例如,如果您的记录大小导致300个记录批次需要4500字节,你将发送2个数据包,第二个数据包大多是浪费。如果批量记录计数是任意分配的,那么做一些快速简单的数学计算可能是有意义的。
从我所知道的(并记住数据类型大小),每个记录只有20个字节(如果int = 4个字节,smallint = 2个字节)。如果您使用300个记录计数批次,那么您尝试发送300 x 20 = 6,000个字节(加上我猜测连接的一点开销等)。您可能更有效率地以200个记录计数批次(200 x 20 = 4,000 +空间开销)= 1个数据包发送这些数据。然后,你的瓶颈似乎仍然是服务器的磁盘io。
我意识到你正在使用相同的硬件/配置将原始数据传输与SqlBulkCopy进行比较,但如果挑战是我的话,我也会去那里:
这篇文章可能不会对你有所帮助,因为它相当陈旧但我接下来会问你的磁盘的RAID配置是什么以及你使用的磁盘速度是多少?尝试将日志文件放在数据文件中使用RAID 10且RAID 5(理想情况为1)的驱动器上。这可以帮助减少大量主轴移动到磁盘上的不同扇区,并导致更多时间读/写而不是非生产性“移动”状态。如果您已经分离了数据和日志文件,那么您的索引是否与数据文件中的其他物理磁盘驱动器有关(您只能对聚簇索引执行此操作)。这样不仅可以通过数据插入同时更新日志信息,还可以同时进行索引插入(以及任何昂贵的索引页操作)。
答案 6 :(得分:1)
我认为这听起来可以使用SSIS packages来完成。它们与SQL 2000的DTS包类似。我已经用它们成功地转换了纯文本CSV文件,现有SQL表,甚至跨越多个工作表的6位数行的XLS文件。您可以使用C#将数据转换为可导入格式(CSV,XLS等),然后让SQL服务器运行计划的SSIS作业以导入数据。
创建一个SSIS包非常简单,SQL Server的企业管理器工具内置了一个向导(我认为标记为“导入数据”),在向导结束时,它提供了将其保存为SSIS包。还有更多信息on Technet。
答案 7 :(得分:0)
是的,您的想法会有所帮助 如果在装载时没有读取,则倾向于选项1 如果在处理过程中正在查询目的地表,请选择选项2。
@Andrew
题。你插入300块。你插入的总金额是多少? SQL服务器应该能够非常快速地处理300个普通的旧插件。