查看数据库里阻塞和死锁情况

/***********************************
 //删除 死锁 存储过程
***************************************/

if exists (select * from dbo.sysobjects
where id = object_id(N‘[dbo].[sp_who_lock]‘)
and OBJECTPROPERTY(id, N‘IsProcedure‘) = 1)
drop procedure [dbo].[sp_who_lock]
GO

/********************************************************
//  日期 :2015-03-20
//  说明 : 查看数据库里阻塞和死锁情况
********************************************************/

use master
go
create procedure sp_who_lock
as
begin
declare @spid int,@bl int,
@intTransactionCountOnEntry     int,
@intRowcount             int,
@intCountProperties         int,
@intCounter             int
create table #tmp_lock_who (
id int identity(1,1),
spid smallint,
bl smallint)
IF @@ERROR<>0 RETURN @@ERROR
insert into #tmp_lock_who(spid,bl) select  0 ,blocked
from (select * from sysprocesses where  blocked>0 ) a
where not exists(select * from (select * from sysprocesses
where  blocked>0 ) b
where a.blocked=spid)
union select spid,blocked from sysprocesses where  blocked>0
IF @@ERROR<>0 RETURN @@ERROR
-- 找到临时表的记录数
select     @intCountProperties = Count(*),@intCounter = 1
from #tmp_lock_who
IF @@ERROR<>0 RETURN @@ERROR
if    @intCountProperties=0
select ‘现在没有阻塞和死锁信息‘ as message
-- 循环开始
while @intCounter <= @intCountProperties
begin
-- 取第一条记录
select     @spid = spid,@bl = bl
from #tmp_lock_who where Id = @intCounter
begin
if @spid =0
select ‘引起数据库死锁的是: ‘+ CAST(@bl AS VARCHAR(10))
+ ‘进程号,其执行的SQL语法如下‘
else
select ‘进程号SPID:‘+ CAST(@spid AS VARCHAR(10))+ ‘被‘
+ ‘进程号SPID:‘+ CAST(@bl AS VARCHAR(10)) +‘阻塞,其当前进程执行的SQL语法如下‘
DBCC INPUTBUFFER (@bl )
end
-- 循环指针下移
set @intCounter = @intCounter + 1
end
drop table #tmp_lock_who
return 0
end
时间: 2024-07-30 00:25:32

查看数据库里阻塞和死锁情况的相关文章

数据库阻塞和死锁的区别

本文来自:http://blog.sina.com.cn/s/blog_6f33ee7901018nsd.html 数据库阻塞和死锁在程序开发过程经常出现,怎么样避免呢?下面通过Demo简单模拟下,数据库发生阻塞和死锁的现象:一.数据库阻塞:    数据库阻塞的现象:第一个连接占有资源没有释放,而第二个连接需要获取这个资源.如果第一个连接没有提交或者回滚, 第二个连接会一直等待下去,直到第一个连接释放该资源为止.对于阻塞,数据库无法处理,所以对数据库操作要及时地提交或 者回滚.Demo:--创建

查看数据库中那些表被锁了,那些阻塞了 并且如何杀死该进程

原文地址:http://topic.csdn.net/u/20100520/14/0570ec45-a1da-4067-8940-8f5eed42f4ab.html?32933 --检测死锁 --如果发生死锁了,我们怎么去检测具体发生死锁的是哪条SQL语句或存储过程? --这时我们可以使用以下存储过程来检测,就可以查出引起死锁的进程和SQL语句.SQL Server自带的系统存储过程sp_who和sp_lock也可以用来查找阻塞和死锁, 但没有这里介绍的方法好用. use mastergocre

SQL Server 查看数据库是否存在阻塞

1 CREATE procedure [dbo].[sp_who_lock] 2 as 3 begin 4 declare @spid int,@bl int, 5 @intTransactionCountOnEntry int, 6 @intRowcount int, 7 @intCountProperties int, 8 @intCounter int 9 create table #tmp_lock_who (id int identity(1,1),spid smallint,bl s

阻塞与死锁(二)——各种操作对锁的申请

原文:阻塞与死锁(二)--各种操作对锁的申请 如何监视锁的申请.持有和释放: 在着手分析.处理阻塞.死锁之前,首先要进行"监控"和"信息收集" 1.检查一个连接当前所持有的锁: 可以使用sp_lock来查看所有连接持有的锁的内容. 在2005以后引入的DMV,还能用过sys.dm_tran_locks来查看: SELECT request_session_id, resource_type , resource_associated_entity_id , requ

阻塞与死锁(三)——死锁的定位及解决方法

原文:阻塞与死锁(三)--死锁的定位及解决方法 死锁所在的资源和检测: 在SQL Server的两个或多个任务中,如果某个任务锁定了其他任务试图锁定的资源.会造成这些任务的永久阻塞,从而出现死锁. 下图为例: l  事务T1获得了行R1的共享锁. l  事务T2获得了行R2的共享锁. l  然后事务T1请求行R2的排它锁,但是T2完成并释放其对R2的共享锁之前被阻塞. l  T2请求行R1的排它锁,但是事务T1完成并释放其对R1持有的共享锁之前被阻塞. 现在T2与T1相互等待,导致了死锁.一般情

三种东西永远不要放到数据库里(转)

原始出处:http://simple-is-better.com/news/872 我已经在很多演讲里说过,改进你的系统的最好的方法是先避免做"蠢事".我并不是说你或你开发的东西"蠢",只是有些决定很容易被人们忽略掉其暗含的牵连,认识不到这样做对系统维护尤其是系统升级带来多大的麻烦.作为一个顾问,像这样的事情我到处都能见到,我还从来没有见过做出这样的决定的人有过好的结果的. 图片,文件,二进制数据 既然数据库支持BLOB类型的数据,把文件塞进BLOB字段里一定没有错

可重复读隔离级别里的可能死锁

在今天的文章里我想谈论下在可重复读隔离级别(Transaction Isolation Level Repeatable Read)里,当你运行事务时可能引起的2类死锁.当你使用可重复读(Repeatable Read)隔离级别设置你的事务,SQL Server对读取数据把持需要的共享锁(Shared Locks)直到事务的结束(COMMIT或ROLLBAK).然后当你尝试修改读取的数据(通过UPDATE语句),如果同样的事务多次并发运行,它会英气不同类型的死锁. 循环死锁(Cycle Dead

三种东西永远不要放到数据库里

图片,文件,二进制数据 既然数据库支持BLOB类型的数据,把文件塞进BLOB字段里一定没有错了!?错,不是这样的!别的先不提,在很多数据库语言里,处理大字段都不是很容易. 把文件存放在数据库里有很多问题: ●对数据库的读/写的速度永远都赶不上文件系统处理的速度 ●数据库备份变的巨大,越来越耗时间 ●对文件的访问需要穿越你的应用层和数据库层 这后两个是真正的杀手.把图片缩略图存到数据库里?很好,那你就不能使用nginx或其它类型的轻量级服务器来处理它们了. 给自己行个方便吧,在数据库里只简单的存放

阻塞与死锁(一)——基础知识

原文:阻塞与死锁(一)--基础知识 阻塞与死锁是除内存.CPU.IO外另一个影响性能的因素.对OLTP系统尤为严重 一般以下问题是死锁的征兆: 1.  并发用户少的时候,一切正常,但是随着用户数量增多,性能越来越慢. 2.  客户端经常收到以下错误: Error 1222:Lock request time out period exceeded.(已超过锁请求超时时段) Error 1205:Your transaction(process ID #XX) was deadlocked on{