SQL Server 2000截断死锁

Question

我们当前在SQL Server 2000上运行数据库。数据库不断地从平面文件中导入数据以供以后查询。此过程由一系列SQL Server存储过程完成，并通过xp_cmdshell从这些过程调用BCP。这些脚本使用BCP将平面文件读入同一台服务器上的辅助数据库中的持久表。然后，脚本将从导入的数据库表中提取数据，并将其放入真正的数据库中，该数据库经过标准化并用于查询。

通常，此导入过程需要5-10分钟，具体取决于文件的大小。然而，在过去的一周里，它花费了50-60分钟。我们已经尝试一步一步地完成了程序。我们已经注意到，一旦我们创建了一个临时表，我们就无法从另一个查询窗口查询tempdb。但更重要的是，在我们截断第一个导入表之前，何时可以很好地逐步执行。我们允许truncate执行，然后当我们使用sp_lock检查数据库中的锁时，我们看到truncate获得的锁没有被释放。然后，我们允许执行对BCP的xp_cmdshell调用，它就会停在那里。我们查看CPU和I/O，当过程停留在调用BCP时，看不到任何重要的活动。此外，当我们尝试此操作时，也没有其他已知查询正在运行。请注意，该文件本身很小；最多只有20行。

如果我们从一个单独的查询中使用xp_cmdshell运行bcp命令，它将工作得很好，但是如果我们已经在存储过程中执行了截断行，但还没有执行BCP行，那么就会锁定。

所以我们的问题是，为什么服务器会进入这种死锁状态，以及不太重要的是，为什么truncate产生的锁不会释放？

Answer 1

仅当存在活动事务时，才会持有SQL Server中的锁。您必须在调用外部BCP之前提交事务。否则，您将陷入这种死锁。

顺便说一句，SQL Server无法检测到这种死锁，因此，如果发生这种情况，您将永远被困在其中。