说三道四技术文摘-感悟人生的经典句子
说三道四 > 文档快照

sql阻塞相关的问题,我需要真正的高手,100分悬赏,长期有效。

编辑:说三道四文库 发布时间:2018-04-20 07:14
HTML文档下载 WORD文档下载 PDF文档下载
首先谢过进来的高手!
此问题,本人研究长达半年已久,尚未找出真正原因。
问题现象很简单,就是当两个spid同时访问某一资源时,会出现锁定进而发生阻塞。

先说下,我这里的程序环境。
SQL服务器是IBM品牌机,Win2000sp4,sql2000企业版,系统里没装其它软件。
只有一个用户数据库,数据文件有4G左右,日志文件有3G.
客户端情况:使用人数在50人左右,客户端软件是用PB开发的,这50人并非会同时访问数据库,但一运行这个客户端软件都会连接数据库。

发生阻塞的过程基本上是这样的:
A用户提交了某一个查询,比如查询了a表,返回结果正常,A用户进入等待状态,当然,它依然保持对服务器的连接。
B用户提交另一查询(有时候可能是update),也涉及到了a表,这时就有可能出问题了。B用户的这个SPID就会陷入等待状态,很多时候这种等待是无期限的,不知道这是不是所谓的死锁。当然,客户机的反应就是应用程序出现假死状态。

查阅微软官网,找到了这方面的文章,编号为224453和271509
(不知道什么原因,224453这篇文章现在没中文简体的了,但可以找到繁体的,强烈BS微软一下。)
http://support.microsoft.com/kb/224453/
http://support.microsoft.com/kb/162361/

按照224453中的指示,查询master.sysprocesses,确实能找到阻塞的SPID,KILL掉,一切都正常了。
现在的问题的,它为什么会发生阻塞呢?据同事介绍,之前还好好的,这期间软硬件都没改变过。
所以还得深入研究,说实在的,微软写的那些东西真的太专业且太啰嗦了,按他的指示,查这个表执行那个存储过程,经常是折腾了我半天搞出来的结果我又看得似懂非懂,哎,这也只能怪小弟我学艺不精,所以在此跪求进来的大虾们不吝赐教。
现列出一些我发现的问题点。
(1) 无论是否出现阻塞,服务器的CPU使用率都不高,基本上10%不到。
(2) 一个值得研究的现象:比如spid56被spid90阻塞,可是sysprocesses表中,spid90这个连接lastbatch的时间有可能是距离阻塞几个小时之前。也就是说,spid90这个连接上次执行操作已经过了几个小时了,但它还对某一数据保持锁定。当然,这种情况不是绝对的,通过我的观察,有的时候,这样的阻塞会自行解除。
(3)以下是在有阻塞时执行sp_blocker_pss80存储过程的结果:
等答案吧
UP..........
http://topic.csdn.net/u/20080721/20/15a60db6-34b5-4ea1-b392-11c42270aaab.html?19834
死锁啦..学习中....
该不会是查询设置了可重复读以后就没关闭连接吧,能看客户端的代码吗?
客户端 代码编写的事务处理有没有影响到啊
返回结果正常,为何A用户进入等待状态而不释放掉。
帮顶.
7楼,这个问题我也想不通,所以奇怪就在这里呀。但问题是,同样的程序,以前它好好的呢!
要说客户端程序有问题吧,我也怀疑过,但我没办法看到代码,所以也没证据。

不过,PB写的应用程序,它要连接SQL,肯定使用ODBC,也就是说,站在SQL Server的角色上去看,所以来自客户端的查询请求都是标准化的了。那么和PB代码关系也就不怎么大了,当然,公平是要看它的连接那一块是怎么做的。我不怎么懂PB,所以也无从下手。

另外,我通过SQL事件探查器,追踪了一段时间所有来自客户端的命令,发现都很正常呀,没什么特别的。那些客户端程序提交的SELECT语句都不复杂。
有可能是客户端代码问题,比如客户端开启了一个序列化级别的事务,且没有及时终止该事务 
这肯定是死锁,客户端语句是肯定有问题,会不会是几个客户端SQL同时查询时太大太长。就会出现这种情况。
从 lz 提供的信息分析,spid 56 的 select 语句在请求行 s 锁时,被 spid 90 在该行上保持的 x 锁阻塞。而 spid 90 一直没有完成事务,释放此 x 锁,从而造成了阻塞。具体原因可能与 spid 90 在请求 networkio 上的等待有关。

具体分析需要通过“事件跟踪器”跟踪一下 spid 90 所执行的 sql 语句,看看是什么语句在请求 networkio,这个 networkio 又与什么网络问题相关(可能要分析程序代码)。
该回复于2010-07-28 10:55:59被版主删除
帮顶,估计为客户端问题?以前没有发生是否是因为当时数据量小所以没有问题,现在数据量大了而几个客户端同时查询就太大太长了。

DBCC INPUTBUFFER(SPID)
看看那个SQL语句还是SP出问题了!
多谢12楼!
networkio这个你看一下1楼我的帖图,绿圈那里,是否不正常?

多谢15楼!
DBCC INPUTBUFFER(SPID)这个结果,我在1楼有帖出来的(最下面两行)。
帮顶。
或者你没事运行个cut 死锁的sp……
自己顶起来!
同样的程序,以前它好好的

是SQL的环境改变了? 还是客户端有修改过?

看起来很像是PB端没有AutoCommit的结果
更新时加上更新锁试试

这期间软硬件都没改变过。


千万不要信这个,呵呵。

帮顶。
看一下,想一下
楼主,你的问题我提两个解决参考方案:
1、首先查找你系统的开发程序bug(指的是PB)。这个访问压力不该出现这种情况,高概率是程序问题。 
    一些操作DB的方法程序bug,如连接DB方法,声明成静态方法,那么多用户调用时,就不会创建新对象,会出现程序层面的排队。 我在上万并发的情况,遇到过此类现象。  
    此外还有数据事务(程序+Sql两点都要查)也很有可能导致。
    此外还有外键关联……   

2、如果实在找不到原因,结合数据完整性要求, 可以把数据操作语句改为 select * from table with(nolock) 。加上后面这个修饰符,往往银行业务对数据即时性要求高,不适合这样写。

最后祝你,好运,找到原因,记得分享经验。
跟踪一下,看A/B都执行了哪些SQL指令。。。。SQL 2000不会有此低级错误。。。
我认为有两种可能
一,有人更改过select语句并在select时给表加了锁,可能为了防止数据不统一。select如果加了锁再select没有执行完之前,其它的任何语句都是等待状态。
二。你的代码编写不合理,系统压力过大,有些界面假死需要处理成线程,这样即便短暂等待也不会出现界面假死
正在受到相同问题的困扰
强顶此贴!本人也正受此困惑,而且情形一模一样!
查询了一些资料,归纳一下有以下几种可能:

1、应用程序中SQL语句更新后未及时提交或回滚,未在提交前处理了其他事务或有响应窗口消息需要用户确认的话,则此表一直处于锁定状态;

2、多表间提交顺序不一致,如X用户提交按顺序提交a、b两表,Y用户按b,a顺序提交,造成死锁

3、不知道病毒会不会造成这种状态,因为我的系统在有些客户那里就没有发生

4、客户端系统最好不要用同一版本Ghost
备案号:鲁ICP备13029499号-2 说三道四 www.s3d4.cn 说三道四技术文摘