我正在从一个 FTP 站点获取一个制表符分隔文件并进行夜间下载。然后我使用我的数据集以它的形式上传它。我只是将它加载到数据集中并绑定它。它有效，但是...
我有 2 个这些文件，最初我有一个工作，只是通过手动将所有数据从文件中拉出，如 VB 6 来插入每一行。我假设 Visual Studio 2012 中的数据表或数据集的绑定将使用更好的算法，我也认为它可能更容易，更有效。至少相对容易。
我无权访问 SQL Server 的服务器文件系统，因为它是共享环境，并且无法批量复制到 SQL Server。由于我的文件大小，提供商的批量复制方法也不能像宣传的那样工作。显然，这会更有效率。我想这是我的蓝领方式。我每晚对 2 个提要中的大约 100k 行进行远程处理，每次都需要大约 45 分钟。
我遇到的问题是此绑定上的表已被锁定，因此在 45 分钟的更新期间无法进行任何查询或访问。同样，它确实有效。是否有参数或设置，我可以调用或设置以允许在此更新期间使用它。
UPDATESQL Server 中的一个总是需要一个排他锁 - 没有办法/没有技巧/没有解决这个问题。
但是这个排他锁只是在被更新的单行上——它会在事务完成后被释放。
但是：如果您在单个事务中更新超过 5000 行，SQL Server 会将行级排他锁升级为表级锁 - 实质上锁定整个表，直到事务完成。
我在这里看到两个选项：
如果你能接受这种方法，你可以在一个事务中将你的导入分成例如 2000 行的块；这样，您可以避免表级排他锁，并且您的系统在导入期间将保持更快的响应。不利的一面是：它可能需要更长的时间，并且您最终可能会导入一些行组，而其他行则失败 - 您不再为整个文件获得干净的“全有或全无”导入
您可以启用一些跟踪标志/开关来关闭此锁升级机制，因此您的 40000 行的整个导入将由行级锁处理。另一方面，这会给锁管理系统带来很大压力和额外工作，因此可能需要更多时间和/或更多 RAM 来处理所有这些独占锁，并且在导入期间运行的查询可能会减慢（如果 39999 个人必须检查排他锁）
100K rows really isn't that much for SQL Server to handle, unless you are doing this insert over a very slow network connection. This sounds more like a locking problem with a long-running transaction. I think you are only doing a single commit after all rows are inserted and causing a lot of blocking issues. If this is a table with a lot of reads on it, then you will have locking problems. See marc_s' post for info on lock escalation. You should modify your insert so that you are committing more often like every 100 rows. Play around with the value until you get an optimal number. You want to avoid long-running transactions.
Not sure which version of SQL Server you are running, but if it's 2005 or later you can enable snapshot isolation for the database and use that for this particular transaction. This will add a bit more pressure on the tempdb, but you get an MVCC style locking mechanism where readers don't block writers. See here for more details. http://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.80).aspx