RE:事务（进程 ID 63）与另一个进程已被死锁在 lock 资源上，且该事务已被选作死锁牺牲品。请重新运行该事务。

MSSQL 2000 SERVER 事务并发时常出现该错误

事务（进程 ID  63）与另一个进程已被死锁在  lock 资源上，且该事务已被选作死锁牺牲品。请重新运行该事务。

求解决方法...

14 个解决方案

#1

监听，找到冲突源，详细操作和解决办法参见 http://www.cnblogs.com/happyhippy/archive/2008/11/14/1333922.html 

#2

查看两个进程执行的代码,解决资源访问的顺序问题即可.

#3

引用 2 楼  的回复:

查看两个进程执行的代码,解决资源访问的顺序问题即可.

#4

是多用户同时写一个表.

你的意思指执行事务采用队列?

如果采用队列来执行,效率方面?

#5

这种情况主要是DBMS自动帮你解决死锁的危险。但是有些死锁是不会自动帮你解决的，会让你手动kill掉进程才能解决。你可以用sp_who 64看看这个语句是干什么，然后查一下是那个操作和这个冲突了，导致死锁，一般情况是由于两个操作，一个先对某个或多个表进行非查询操作，把表进行排它锁，导致第二个操作，主要是查询，也就是你那个进程为64的操作，需要等待。而上一个操作有可能又引用了spid为64的里面某些资源。造成了循环等待，最后造成死锁。
一般处理流程就是要看看非64的那个操作是否有合理的事务流程。这种原因一定是语句没写好，流程没处理好所导致的。
另外，非查询的操作一定会锁表，这是合理的动作，所以不能避免，只能看看如何把这个操作过程缩短或者把资源通过另外一些方式引用。比如先进入临时表，然后再操作。

#6

在处理数据时,有一条语句是先查询该表是否存在该项数据.存在则修改,不存在则insert

应该是这句引起的.

#7

出现了死锁,了解63号被中断的进程当时在做什么,看看有没有可以优化的地方....

#8

找出根源是关键，一定要找出根源啊，这样你才能顺利解决问题。

#9

单用户使用没问题.干脆使用列队来处理事务.

#10

发现死锁时,后面所有的事务都不能被处理....

#11

引用 10 楼  的回复:

发现死锁时,后面所有的事务都不能被处理....

用PROFILER跟踪LOCK。查出是哪些东西造成死锁的

#12

就是多用户同时执行那一条SQL事务语句时

#13

profiler跟踪...

EventClass           LoginName     ClentProcessID  SPID          StartTime
Lock:Timeout       sa       2364          70           2012-05-02 14:46:26.407

#14

学习了  不错         现在 系统有个大问题  需要解决