一个奇怪的阻塞问题

[ycg_893]

使用SQL 2005,程序一直没有任何问题,今天发生了阻塞,而且是连接地阻塞,一个张单据当处理完毕则将待办事项表标记为已处理,而在阻塞报表看到的就是这个语句阻塞,造成其他语句被阻塞,看程序代码以及SQL语句就是找不到任何可能的阻塞,最后没有办法了,就重启一下服务器,重启后居然变为正常了.之后就没有任何阻塞了.

但为什么重启后就好了呢?同样的地操作这张单据,却没有任何阻塞了.

[-晴天]

应该是你的数据库发生了死锁.
你要检查为什么会发生死锁,然后考虑以后如何避免出现死锁,一旦死锁后如何解锁.

[-晴天]

在事务日志中可以查到所发生的死锁.

[ycg_893]

因为一直使用一年多了,没有发生过今天这样的问题,今天发生后,一直在找原因,按执行这张单据的所有SQL代码找出来,实在找不出原因,到了最后实在没有办法了,就重启服务器,重启之后恢复如初,并已观察了3个小时了,同样的都在操作一样的工作,所以才觉得奇怪.

[dawugui]

[Quote=引用楼主 ycg_893 的回复:]
使用SQL 2005,程序一直没有任何问题,今天发生了阻塞,而且是连接地阻塞,一个张单据当处理完毕则将待办事项表标记为已处理,而在阻塞报表看到的就是这个语句阻塞,造成其他语句被阻塞,看程序代码以及SQL语句就是找不到任何可能的阻塞,最后没有办法了,就重启一下服务器,重启后居然变为正常了.之后就没有任何阻塞了.

但为什么重启后就好了呢?同样的地操作这张单据,却没有任何阻塞了.
[/Quote]

/*--处理死锁

 查看当前进程,或死锁进程,并能自动杀掉死进程

 因为是针对死的,所以如果有死锁进程,只能查看死锁进程
 当然,你可以通过参数控制,不管有没有死锁,都只查看死锁进程

--邹建 2004.4--*/

/*--调用示例

 exec p_lockinfo
--*/
create proc p_lockinfo
@kill_lock_spid bit=1,  --是否杀掉死锁的进程,1 杀掉, 0 仅显示
@show_spid_if_nolock bit=1 --如果没有死锁的进程,是否显示正常进程信息,1 显示,0 不显示
as
declare @count int,@s nvarchar(1000),@i int
select id=identity(int,1,1),标志,
 进程ID=spid,线程ID=kpid,块进程ID=blocked,数据库ID=dbid,
 数据库名=db_name(dbid),用户ID=uid,用户名=loginame,累计CPU时间=cpu,
 登陆时间=login_time,打开事务数=open_tran, 进程状态=status,
 工作站名=hostname,应用程序名=program_name,工作站进程ID=hostprocess,
 域名=nt_domain,网卡地址=net_address
into #t from(
 select 标志='死锁的进程',
  spid,kpid,a.blocked,dbid,uid,loginame,cpu,login_time,open_tran,
  status,hostname,program_name,hostprocess,nt_domain,net_address,
  s1=a.spid,s2=0
 from master..sysprocesses a join (
  select blocked from master..sysprocesses group by blocked
  )b on a.spid=b.blocked where a.blocked=0
 union all
 select '|_牺牲品_>',
  spid,kpid,blocked,dbid,uid,loginame,cpu,login_time,open_tran,
  status,hostname,program_name,hostprocess,nt_domain,net_address,
  s1=blocked,s2=1
 from master..sysprocesses a where blocked<>0
)a order by s1,s2

select @count=@@rowcount,@i=1

if @count=0 and @show_spid_if_nolock=1
begin
 insert #t
 select 标志='正常的进程',
  spid,kpid,blocked,dbid,db_name(dbid),uid,loginame,cpu,login_time,
  open_tran,status,hostname,program_name,hostprocess,nt_domain,net_address
 from master..sysprocesses
 set @count=@@rowcount
end

if @count>0
begin
 create table #t1(id int identity(1,1),a nvarchar(30),b Int,EventInfo nvarchar(255))
 if @kill_lock_spid=1
 begin
  declare @spid varchar(10),@标志 varchar(10)
  while @i<=@count
  begin
   select @spid=进程ID,@标志=标志 from #t where id=@i
   insert #t1 exec('dbcc inputbuffer('+@spid+')')
   if @标志='死锁的进程' exec('kill '+@spid)
   set @i=@i+1
  end
 end
 else
  while @i<=@count
  begin
   select @s='dbcc inputbuffer('+cast(进程ID as varchar)+')' from #t where id=@i
   insert #t1 exec(@s)
   set @i=@i+1
  end
 select a.*,进程的SQL语句=b.EventInfo
 from #t a join #t1 b on a.id=b.id
end
go

[--小F--]

[Quote=引用 3 楼 ycg_893 的回复:]
因为一直使用一年多了,没有发生过今天这样的问题,今天发生后,一直在找原因,按执行这张单据的所有SQL代码找出来,实在找不出原因,到了最后实在没有办法了,就重启服务器,重启之后恢复如初,并已观察了3个小时了,同样的都在操作一样的工作,所以才觉得奇怪.
[/Quote]
有没有去 尝试一下用SQL PROFILER去跟踪下。

[ycg_893]

由于这台服务器,具与GPS定位更新,短信收发等,都是由这个系统的一个服务来完成,随时执行的语句太多,实在没法跟踪,如果停用这个服务,工作流也会被停止,当然就不会发生这种情况了,因为这是由工作流执行的语句阻塞.

[ycg_893]

提交单据时,单据交给了工作流服务来完成.发现工作流在变更处理状态时,就阻塞了,与该表相关(连接到被锁的行,非锁的行不受影响)的后续语句就得等待了,但工作流并不影响其他类型的单据,即只是该行被锁.

[NBDBA]

阻塞了说明更新语句所在的事务效率不高，看看是否用到索引

[gogodiy]

弄个单元机，把数据库复制过去，然后跟踪，这样可以避免其他不需要的SQL语句的影响。

[ycg_893]

奇怪的是自从重启服务器后,直到今天都没有再发生这种情况.之前为什么会发生,用了一年多了,只发生过这一次.
不过这个系统用到分布式事务,包括文件事务(自己编写的,即文件删除\重命名\移动等支持回撤与提交),会不会不是分布式事务导致的呢?

[-晴天]

[Quote=引用 10 楼 ycg_893 的回复:]
奇怪的是自从重启服务器后,直到今天都没有再发生这种情况.之前为什么会发生,用了一年多了,只发生过这一次.
不过这个系统用到分布式事务,包括文件事务(自己编写的,即文件删除\重命名\移动等支持回撤与提交),会不会不是分布式事务导致的呢?
[/Quote]
不是没有可能.特别是当分布式事务出错时,可能会使锁无法解开.