SQL Server 2000 Truncate Deadlock

Question

We are currently running a database on SQL Server 2000. The database constantly imports data from flat files for later querying. This process is done by a series of SQL Server stored procedures and calling BCP from those procedures through xp_cmdshell. The scripts use BCP to read in the flat files into persistent tables in a secondary database on the same server. Then the scripts will pull the data from the import database tables and put it into the real database which is normalized and used for querying.

Normally this import process takes 5-10 minutes depending on the size of the files. However for the past week it has been taking 50-60 minutes. We have tried stepping through the procedures. We've noticed that as soon as we create a temporary table, that we are unable to query tempdb from another query window. But more importantly when can step through just fine up until we truncate the first import table. We allow the truncate to execute and then when we check for locks in the database using sp_lock, we see that the locks taken by truncate are not released. We then allow the xp_cmdshell call to BCP to execute and it will sit there. We look at CPU and I/O and see no significant activity when the procedure is stuck calling BCP. Also no other known queries are running when we try this. Note that the file itself is small; at most 20 lines.

If we run the bcp command with xp_cmdshell from a separate query it will work fine, but lock up if we have executed the truncate line but not yet the BCP line in the stored procedure.

So the questions we have are why is the server getting into this deadlock state and less importantly why would the locks made by truncate not release?

Answer 1

Locks in SQL Server are only held if there is an active transaction. You have to commit the transaction before you call the external BCP. Otherwise you will run into this Deadlock.

Incidentally this Deadlock cannot be detected by SQL Server, so if it happens, you will be stuck in it forever.