事务进程ID与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品 问题及想法

 　　今天有个项目（SQL SERVER）出现上述死锁错误，经过查阅造成死锁的主要有两个原因：

 

1.两个表进行互锁： 进程A访问表A (锁)访问表B ，进程B访问表B(锁) 访问表A。

2.同表互锁：进程A读数据A(共享锁)，修改A (排它锁), 进程A读数据A(共享锁)，修改数据A（排它锁）。

 

　　本项目只有两个进程A,B ,大量访问表A 和表B，出现的次数也不是很频繁，所以在进程Ａ中所有访问表Ａ和表Ｂ中加了Ｎｏｌｏｃｋ，在进行读数据时并不锁表，测试还不会会出现上述死锁问题。

      此问题还在持续观察,先记个笔记.

 

NOLOCK的使用  ：

　　NOLOCK可以忽略锁，直接从数据库读取数据。这意味着可以避开锁，从而提高性能和扩展性。但同时也意味着代码出错的可能性存在。你可能会读取到运行事务正在处理的无须验证的未递交数据。 这种风险可以量化。
　　实际上，你可能发现你的大多数数据很少或者甚至不进行修改的，这样我们就不会因为这些数据被锁住而浪费大量的时间。   

ROWLOCK的使用

　　　ROWLOCK告诉  SQL    Server只使用行级锁。ROWLOCK语法可以使用在SELECT,  UPDATE和DELETE语句中。如果在UPDATE语句中有指定的主键，那么就总是会引发行级锁的。但是当SQL  Server对几个这种UPDATE进行批处理时，某些数据正好在同一个页面(page)，这种情况在当前情况下    是很有可能发生的，这就象在一个folder中，创建一个新文件需要较长的时间，而同时你又要去更新该folder中的某些文件。当页面锁引发后，事情就开始变得糟糕了。而如果在UPDATE或者DELETE 时，没有指定主键，数据库当然认为很多数据会收到影响，那样  就会直接引发页面锁，事情同样变得糟糕。
　　通过指定使用行级锁，这种情况可以得到避免。但是需要小心的是，如果你错误地使用在过多行上，数据库并不会聪明到自动将行级锁升级到页面锁，服务器也会因为行级锁的开销而消耗大量的内存和CPU，直至无法响应。尤其主要留意的是  企业管理器中"管理/当前活动"(Management /Current    Activity)这一项。该项会花较长的时间来载入锁的信息。这些信息是十分有用的，当你使用行级锁后，你如果在"锁/处理" (Locks/Processes)下看到几百个锁，一点都不奇怪，而恰恰应该庆幸锁超时和死锁的问题减少了。     
 

UPDLOCK　使用

 

　读取表时使用更新锁，而不使用共享锁，并将锁一直保留到语句或事务的结束。UPDLOCK 的优点是允许您读取数据（不阻塞其它事务）并在以后更新数据，同时确保自从上次读取数据后数据没有被更改。　　这是SqlServer2000中对更新锁的说明.　　 当我们用UPDLOCK来读取记录时可以对取到的记录加上更新锁，从而加上锁的记录在其它的线程中是不能更改的只能等本线程的事务结束后才能更改。