我有一个使用BULK INSERT将两个CSV文件推入SQL表的进程，所以我可以将它们的数据与另一个表相关联。 来自CSV文件的数据将生成大约100,000行的表格。 当进程完成时，这些表被截断。 整个过程运行在为此创build的数据库上（没有其他活动）。
在一分钟内运行一段时间后，整个服务器变得非常慢。 它看起来像这个活动正在采取一些资源，而不是释放它。 即使批量插入和连接在一起，每次只需要约5秒钟。
您在实例上执行的每个操作都会消耗资源并在某种程度上影响性能。 有些事情比别人更明显。
你的数据库有哪些恢复模式？ 您正在将数据添加到另一个数据库中的表？
仅仅提供你所提供的信息很难说底层的问题。 你必须在你的服务器上做一些监控，看看究竟是什么原因。 你的服务器可能会排队IO请求，你可能会增长你的传输日志文件，并在那里等待，你可能会推动内存约束，索引可能是重build，各种事情。
使用BULK INSERT本身并不意味着你会得到最less的日志。 您应该小心并仔细阅读获取最less日志logging的先决条件。
参考： http : //msdn.microsoft.com/en-us/library/ms190422.aspx
Ref： http : //sankarreddy.com/2011/03/interrogating-prerequisites-for-minimal-logging-in-bulk-import-part-1/
另外，请检查盒子上的存储器设置，并确保已经设置了最大内存。 你看过页面文件的用法吗？ 如果页面文件使用量过多，则可能还需要减less最大内存设置。 还有什么东西在盒子上运行？
处理这个问题的正确方法是使用WAIT STATISTICS信息，并在服务器运行缓慢时追踪一些信息。 当服务器运行缓慢，你需要检查CPU的使用情况，IO使用情况等… @SQLSoldier有一个很酷的脚本，以确定高瞬态CPU峰值的根本原因。
Ref： http : //www.sqlsoldier.com/wp/sqlserver/catchingtransientcpuspikesusingsqltrace
这是一个起点，还有其他的事情可以做，但需要更多的信息。
这在很大程度上取决于服务器的硬件和configuration，但是，单一数据库上的繁重活动可能会在整个服务器上造成性能问题。 最合理的情况是，繁重的活动消耗了几乎所有的服务器内存，并将所有其他内容从系统（或SQL Server）caching中推出; 所以，即使完成了，所有的东西都必须从磁盘重新读取。