SQL 进程死锁

首先，需要把你的AutoCommit=TRUE，然后，这是一个编程习惯问题，在pb中，对于数据窗口的 *** 作，首先设置数据窗口的提交方式，我一直

采用 key columns,use

update，然后记得在每次连接完成后，记得及时释放，譬如，在retrieve完成后，记得及时利用resetupdate()清除数据状态，然后，

再每次数据库更新，也就是update()后，记得利用

ll_num1=update()

if ll_num=1 then

commit;

dw_freeresetupdate( )

else

rollback;

messagebox("提示!","数据保存失败! ")

end if

以上说法我不赞同：

1、首先AutoCommit=TRUE，以后执行delete，update，insert语句都相当执行了commit，如果是把几个SQL语句当作是一个完整的事务，要不整

体成功提交，要不rollback，这就写就不会得到正确的结果。

2、其次key columns,use update，要具体情况具体使用，这种形式的并发性最差，适合对数据的并发性要求不高的场合。

3、再次程序的死锁原因是多方面的，上述两个方面只是其中的原因罢了，具体情况具体分析，例如数据尽快提交、建立合理的索引、合理的SQ

L语句、避免交叉事务、对于数据量庞大的表，应及时转移到历史库，我想可以很大程度上避免死锁。

以上愚见，欢迎拍砖。

在MSSQL控制台中，管理－当前活动－锁／进程ID看看是那几个进程在死锁，然后在进程信息中将这些死锁的进程杀死／

对查询进行优化

也建议检查：外键建立索引，如果上索引，再调试下网络

对外键建索引可以缓解这个问题。

如在商品字典和销售明细表中，销售明细表中商品编号是外键，如果在销售明细表的商品编号上没有索引，update商品字典会造成销售明细表

整表锁表。

解决Sybase数据库死锁的方法

人民银行吉林市中心支行科技处 刘志明

在联机事务处理(OLTP)的数据库应用系统中，多用户、多任务的并发性是系统最重要的技术指标之一。为了提高并发性，目前大部分RDBMS都采

用加锁技术。然而由于现实环境的复杂性，使用加锁技术又不可避免地产生了死锁问题。因此如何合理有效地使用加锁技术，最小化死锁是开

发联机事务处理系统的关键。

死锁产生的原因

在联机事务处理系统中，造成死机主要有两方面原因。一方面，由于多用户、多任务的并发性和事务的完整性要求，当多个事务处理对多个资

源同时访问时，若双方已锁定一部分资源但也都需要对方已锁定的资源时，无法在有限的时间内完全获得所需的资源，就会处于无限的等待状

态，从而造成其对资源需求的死锁。

另一方面，数据库本身加锁机制的实现方法不同，各数据库系统也会产生其特殊的死锁情况。如在Sybase SQL Server 11中，最小锁为2K一页

的加锁方法，而非行级锁。如果某张表的记录数少且记录的长度较短(即记录密度高，如应用系统中的系统配置表或系统参数表就属于此类表)

，被访问的频率高，就容易在该页上产生死锁。

几种死锁情况及解决方法

清算应用系统中，容易发生死锁的几种情况如下:

● 不同的存储过程、触发器、动态SQL语句段按照不同的顺序同时访问多张表;

● 在交换期间添加记录频繁的表，但在该表上使用了非群集索引(non-clustered);

● 表中的记录少，且单条记录较短，被访问的频率较高；

● 整张表被访问的频率高(如代码对照表的查询等)。

以上死锁情况的对应处理方法如下：

● 在系统实现时应规定所有存储过程、触发器、动态SQL语句段中，对多张表的 *** 作总是使用同一顺序。如：有两个存储过程proc1、proc2，

都需要访问三张表zltab、z2tab和z3tab，如果proc1按照zltab、z2tab和z3tab的顺序进行访问，那么，proc2也应该按照以上顺序访问这三张

表。

● 对在交换期间添加记录频繁的表，使用群集索引(clustered)，以减少多个用户添加记录到该表的最后一页上，在表尾产生热点，造成死锁

。这类表多为往来账的流水表，其特点是在交换期间需要在表尾追加大量的记录，并且对已添加的记录不做或较少做删除 *** 作。

● 对单张表中记录数不太多，且在交换期间select或updata较频繁的表可使用设置每页最大行的办法，减少数据在表中存放的密度，模拟行级

锁，减少在该表上死锁情况的发生。这类表多为信息繁杂且记录条数少的表。

如：系统配置表或系统参数表。在定义该表时添加如下语句：

with max_rows_per_page=1

● 在存储过程、触发器、动态SQL语句段中，若对某些整张表select *** 作较频繁，则可能在该表上与其他访问该表的用户产生死锁。对于检查

账号是否存在，但被检查的字段在检查期间不会被更新等非关键语句，可以采用在select命令中使用at isolation read uncommitted子句的方

法解决。该方法实际上降低了select语句对整张表的锁级别，提高了其他用户对该表 *** 作的并发性。在系统高负荷运行时，该方法的效果尤为

显著。

例如：

selectfrom titles at isolation read uncommitted

● 对流水号一类的顺序数生成器字段，可以先执行updata流水号字段+1，然后再执行select获取流水号的方法进行 *** 作。

小结

笔者对同城清算系统进行压力测试时，分别对采用上述优化方法和不采用优化方法的两套系统进行测试。在其他条件相同的情况下，相同业务

笔数、相同时间内，死锁发生的情况如下：

采用优化方法的系统: 0次/万笔业务;

不采用优化方法的系统：50～200次/万笔业务。

所以，使用上述优化方法后，特别是在系统高负荷运行时效果尤为显著。总之，在设计、开发数据库应用系统，尤其是OLTP系统时，应该根据

应用系统的具体情况，依据上述原则对系统分别优化，为开发一套高效、可靠的应用系统打下良好的基础。

经验：

1：前台问题：检视代码查看事物是否被提交或回滚。

2：后台问题：有时候由于处理的问题复杂度高。数据库日志空间已满或不够

导致事物未能提交。UNIX下的SYBAE就是典型的一例。解决办法各数据库厂商有更详细的说明。

虽然我从9转到10遇到了好多问题，也浪费了好几天的时间，但到了现在，我真觉得10比9好。

10没有了MSSQL专用接口，用的是OLEDB接口，用这个接口一定要注意一个问题是表死锁的事!

网上讲的连接方式都是天下一大抄。

用OLEDB要加上 SQLCALock = "RC"，

不然连查询也会死锁。

另个一个就是10写的软件不再乱码了，我在繁体写的软件在简体下运行不乱码，反之也可以。

第三就是编译速度明显快很多。

第四就是编译的时候有了XP样式皮肤，感觉漂亮多了。

编程要是要养成好习惯，在sql语句insert和update之后，要及时commit，数据窗口update()后也要及时commit;

阻塞是因为多个进程对同一一个资源的访问冲突，当一个进程排它访问一个资源时（从进入事务到事务结束为止），当有其他进程需要访问同

样的资源时，即造成阻塞（根据锁的级别和粒度设置）；

在实际应用中阻塞可能因为事务没有提交或者网络速度太慢或者大容量的数据查询等都可能会造成阻塞。

阻塞可以通过sp_who 系统存储过程进行查看，执行sp_who 后查看所有blk不等于

0的进程ID（SPID），直到找到SPID在blk列出现，但当前spid 的blk列 =0 即它就是阻塞的源头。

最简单的办法可用 kill spid(源头进程的SPID值)，同时结合sp_lock过程可查看到当前进程的加锁情况（如锁的类型被锁的对象）

最后最重要的是要根据 在查询到源头后，使用 DBCC INPUTBUFFER (spid)查看最后一次提交的内容，即可找到因为事务没有提交造成的阻塞（

一般不能使用 AutoCommit=True，因为大部分MIS程序需要使用批提交，来保证数据的完成性）

>

微软自SQL 2008以后提供了一个图形化的活动监视器来帮助DBA观察"当前的"阻塞现象 详情请参考 (点击打开链接) DBA需要关注如下的信息列去

会话 ID：　是建立连接时分配给每个用户连接的唯一整数 (int)。

等待时间(毫秒):此任务等待资源所用的时间（毫秒）。如果任务没有等待，则等待时间为 0。

等待类型：最近或当前等待类型的名称。

等待资源：所需资源的名称。

阻塞者：如果有阻塞会话，则为正阻塞任务的会话的 ID。

头阻塞程序：如果有阻塞会话，则标识导致第一个阻塞条件的会话。

值为 1 表示其他会话的头阻塞程序。

以上就是关于SQL 进程死锁全部的内容，包括:SQL 进程死锁、如何查看oracle数据库中哪些session异常阻塞了系统、关于组态王查询SQL Server数据库数据的问题等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！