我运行了一个查询，将1800万条记录从一个表复制到另一个表。由于查询需要很长时间才能运行，因此我监视表计数以告知它何时完成。
我注意到它到达了数字之前应该已经达到了计数开始下降所以我检查了日志，它看起来像sql server基本上没有内存：
'SQL Server数据库引擎的实例此时无法获取LOCK资源。当活跃用户较少时，重新运行您的语句。请数据库管理员检查此实例的锁定和内存配置，或检查长时间运行的事务。“
实际插入仅在日志中出现错误之前运行了大约20分钟。 我大约2小时前从管理工作室取消了查询，从表数统计来看，这件事只完成了25％，这让我大约多了6个小时。我正在假设一些事情，因为所有的内存都用完了，现在它正在运行页面文件，这就是它需要这么长时间的原因。
我有什么办法可以加快速度吗？它基本上使数据库无法使用，因为每个人都得到'无法获取锁资源'错误。我自己可以很容易地删除插入的记录，如果我可以杀死进程ID并且自己“回滚”插入，我就会徘徊？
更新
这件事直到跑得非常慢。我发现的一件事是，以下查询给出的#lock似乎令人愤慨：8300万。下一个最高的是高达20。
SELECT request_session_id, COUNT (*) num_locks
FROM sys.dm_tran_locks
GROUP BY request_session_id
ORDER BY count (*) DESC
答案 0 :(得分：0)
取消后，您需要修改代码才能执行插入操作。首先，如果您在游标中一次处理一条记录（并且所有在同一事务中）将永远运行。如果您使用基于集合的插入，则可以解决您描述的问题。如果你可以使用可以很好地工作的批量插入或者你做的是组合逐行和基于集合的方法，即在循环中运行批量记录。 （我通常一次从2000开始，如果快速移动到更多记录。）只要确保测试你不是要重复插入同一批记录。
答案 1 :(得分：0)
对我有用的解决方案是重启服务器。我正在使用的数据库确实需要12个小时来恢复 - 但是重新启动会清除我们在访问其他数据库的应用程序时遇到的资源问题。下次我尝试这个时，我把它分成500K而不是一次全部1800万批次，一切正常。
答案 2 :(得分：0)
我认为不需要重新启动。重新启动SQL Server Service就足够了。我建议重新启动SQL server service。它会解决问题。
答案 3 :(得分：-1)
断开所有其他用户进程。您甚至可能必须将数据库更改为“仅管理员”以防止其他连接。确保没有其他处理正在阻止原始更新语句的处理。
这有望释放一些内存和/或阻止其他进程使用可用的小内存。
此命令将刷新缓存，这可能通过从内存中删除所有缓存数据来提供帮助。希望这将删除其他进程使用的数据，并为您当前的查询腾出更多空间。
dbcc dropcleanbuffers