我们目前正在SQL Server 2000上运行数据库。数据库不断从平面文件导入数据以供以后查询。此过程由一系列SQL Server存储过程完成，并通过BCP从这些过程调用xp_cmdshell。脚本使用BCP将平面文件读入同一服务器上的辅助数据库中的持久表。然后脚本将从导入数据库表中提取数据并将其放入真实数据库中，该数据库被规范化并用于查询。
通常，此导入过程需要5-10分钟，具体取决于文件的大小。然而，在过去一周，它已经花了50-60分钟。我们已经尝试逐步完成这些程序。我们注意到，只要我们创建临时表，我们就无法从另一个查询窗口查询tempdb。但更重要的是，当我们截断第一个导入表时，可以逐步完成。我们允许truncate执行，然后当我们使用sp_lock检查数据库中的锁时，我们看到truncate采取的锁不会被释放。然后，我们允许xp_cmdshell调用BCP来执行它，它会坐在那里。我们看一下CPU和I / O，当程序卡住BCP时，看不到重要的活动。当我们尝试这个时，也没有其他已知的查询正在运行。请注意，文件本身很小;最多20行。
如果我们从单独的查询中运行带有bcp的{{1}}命令，它将正常工作，但如果我们执行了截断行但尚未执行xp_cmdshell行，则会锁定存储过程。
所以我们遇到的问题是为什么服务器进入这种死锁状态，而不太重要的是为什么truncate生成的锁不能释放？
答案 0 :(得分：0)
只有存在活动事务时，才会保留SQL Server中的锁定。您必须在调用外部BCP之前提交事务。否则你会遇到这个死锁。
顺便说一句，SQL Server无法检测到这种死锁，所以如果它发生了，你将永远陷入其中。