Sybase 数据库的死锁问题-2

   来源：

---

 

死锁DEADLOCK

简单地说，有两个用户进程，每个进程都在一个单独的页或表上有一个锁，而且每个进程都想在对方进程的页或表上请求不相容锁时就会发生“死锁”。在这种情况下，第一个进程在等待另一进程锁，但另一进程要等到第一个进程的对象释放时才会释放自己的锁。

SQL Server检查是否死锁，并终止事务中CPU积累最小的用户（即最后进入的用户）。SQL Server回滚该用户的事务，并用消息号1205通知有此死锁的应用程序，然后允许其他用户进程继续进行。

在多用户情形下，每个用户的应用程序都应检查每个修改数据的事务是否有1205号消息，以此确定是否有可能死锁。消息号1025表示该用户的事务因死锁而终止并被回滚。应用程序必须重新开始这个事务处理。

查找死锁原因

既然管理信息系统长时间死锁的原因是由于我们提交或者是提交不当，那么我们就可以通过修改程序防止出现死锁。定位死锁出错处主要经过以下三步：

(1)在死锁出现时，用SP_WHO,SP_LOCK获得进程与锁的活动情况。

(2)结合库表sysobjects和相应的员信息表查出被锁的库表与锁住别人的操作员。

(3)根据锁定的库表与操作员的岗位，可以估计出程序大约出错处。询问操作员在死锁时执行的具体操作即可完全定位出错处。最后查找程序并修改之。

用sp_who获取关于被阻碍进程的信息

系统过程sp_who给出系统进程的报告。如果用户的命令正被另一进程保持的锁阻碍，则：

◆status列显示“lock sleep”。

◆blk列显示保持该锁或这些锁的进程标识，即被谁锁定了。

◆loginame列显示登录操作员。结合相应的操作员信息表，便可知道操作员是谁。

Fid spid status loginame origname blk dbname cmd
0 1 lock sleep lm lm 18 QJYD SELECT
0 2 sleeping NULL NULL 0 master NETWORK HANDLER
0 3 sleeping NULL NULL 0 master NETWORK HANDLER
……

用sp_lock浏览锁

要得到关于当前SQL Server上保持的锁的报告，可用系统过程sp_lock [spid1[,spid2]]，spid1,spid2是表master.dbo.sysprocesses中的sql server进程id号，用sp_who可以得到锁定与被锁定的spid号：

◆locktype列显示加锁的类型和封锁的粒度，有些锁的后缀还带有blk表明锁的状态。前缀表明锁的类型：Sh—共享锁，Ex—排它锁或更新锁，中间表明锁死在表上（”table”或’intent’）还是在页上（page）. 后缀“blk”表明该进程正在障碍另一个需要请求锁的进程。一旦正在障碍的进程一结束，其他进程就向前移动。“demand”后缀表明当前共享锁一释放， 该进程就申请互斥锁。

◆table_id列显示表的id号，结合sysobjects即可查出被封锁的表名。

执行该进程后屏幕显示

Fid Spid locktype table_id page row dbname Class context
0 1 Sh_intent 678293476 0 0 QJYD Non Cursor LockFam dur
0 1 Sh_page 678293476 31764 0 QJYD Non Cursor Lock
0 18 Ex_intent 9767092 0 0 QJYD Non Cursor LockFam dur
……

定位出错处

根据sp_who与sp_lock命令的结果，结合sysobjects和相应的操作员信息表。得到操作员及其在死锁时所操作的库表，便大约可以知道应用程序。