sql2000阻塞问题？

[a2048]

数据库用sql2000 这几天管理系统前台查询经常出现打不开，好像就涉及到数据库的一张表，然后打开企业管理器发现有100多个阻塞，并发操作这个系统的也不到10人。奇怪的是就这几天开始，然后重启服务器后奇就好了，但过了几分钟后又不行了。查询不到数据的这张表里面也只有3万左右的数据，这个系统最近没有改过程序，数据每天也不多，服务器也是比较新的，用了1年。请问为什么会出现这个是什么问题？

[a2048]

引用 53 楼 DBA_Huangzj 的回复:

[quote=引用 52 楼 a2048 的回复:] [quote=引用 49 楼 DBA_Huangzj 的回复:] 按并发和数据量来说，这个配置倒不是很严重，但是比较常规的办法是把数据文件和日志文件分开物理磁盘，如果系统中大量使用临时对象比如临时表，并且操作的数据量比较大，那么tempdb初始化搞大一点，前期可以分4个数据文件，日志文件就不用了，然后也分开独立的盘。看你46楼的截图中3、4、5行，等待类型主要和这部分有关系，当然也和你的代码及处理的数据量、内存大小有关，等你发现有点卡或者有说阻塞的时候再截图看看吧。

今天下午运行到现在暂时没有什么问题。服务器上的sql进程有8个。 如果换成sql2005会好点吗？ 假如换成2005的话是不是就把MDF文件和LDF文件附件就可以了对吗？[/quote]换2005不能根本上解决问题，如果可以换还不如换2008，查问题比较容易，这点是可以的。如果你没有用什么旧语法，比如*=这样的，直接附加到2008就可以了，但是提醒一句，附加之后就不能再降回2000了，需要做一系列比较痛苦的处理，所以如果你真要这样做，完整备份不可少[/quote] 2008暂时不行，还要设计到jdk版本。你说的”比如*=这样的“里的*=是什么意思

[發糞塗牆]

等于新语法的left join

[a2048]

引用 55 楼 DBA_Huangzj 的回复:

等于新语法的left join

谢谢你的答复，虽然还没有解决这个问题，但收益很多。先结贴。

[發糞塗牆]

非SQL Server的问题我是处理不了了，如果是SQL SERVER问题，从配置到语句都应该注意，特别是代码优化，像之前你那几个SELECT，大数据量的时候效率低、资源消耗高，往往就容易导致阻塞

[a2048]

引用 57 楼 DBA_Huangzj 的回复:

非SQL Server的问题我是处理不了了，如果是SQL SERVER问题，从配置到语句都应该注意，特别是代码优化，像之前你那几个SELECT，大数据量的时候效率低、资源消耗高，往往就容易导致阻塞

版主再想问你一下关于前几天的这几句sql语句，后来我改成索引后应该效率会提高很多了对吗？ 还有a_name这个字段我加上索引后，还是模糊查询就像”a_name like '%上%' “这样，在执行计划里看也好像有点效果，这是为什么？你说 like '%%'是不走索引的。

[發糞塗牆]

有没有提高要现场测试才能回答，另外和你说过，有选择度这个因素，如果某一列的数据只有0和1，那么没必要建索引，建了sqlserver也不会用这个索引。 like '%%'是不走索引的 这句的意思是不进行索引查找，而是索引扫描。

[a2048]

引用 37 楼 DBA_Huangzj 的回复:

那你能预估别人都做了什么操作吗？

版主，我昨晚看服务器上的sql进程有38个，早上看sql进程数怎么还38，这个会不会影响阻塞的原因之一。

[發糞塗牆]

看状态，不要看进程，另外你说的进程是怎么查出来的？

[a2048]

引用 39 楼 DBA_Huangzj 的回复:

看状态，不要看进程，另外你说的进程是怎么查出来的？

我是从企业管理器--管理--当前活动--锁/进程id 里查看的。

[發糞塗牆]

select * from sys.sysprocesses 看看有没有88个？

[a2048]

引用 41 楼 DBA_Huangzj 的回复:

select * from sys.sysprocesses 看看有没有88个？

我上面说的看到的是38不是88 。select * from sys.sysprocesses我没有查看，现在我已经重启了也看不到了。 我现在还发现有这个错误提示“[Microsoft][SQLServer 2000 Driver for JDBC]Connection reset by peer: socket write error” 这个是不是并发的问题？

[發糞塗牆]

我知道你说38，但是50个是系统进程 Connection reset by peer: socket write error” 这个貌似有点问题了

[發糞塗牆]

经常出现的Connection reset by peer: 原因可能是多方面的，不过更常见的原因是： ①：服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉； ②：客户关掉了浏览器，而服务器还在给客户端发送数据； ③：浏览器端按了Stop tomcat我不懂，你先从sqlserver阻塞方面看看问题，select * from sys.sysprocesses where spid>50，如果不多的话就截图给我看看

[a2048]

引用 43 楼 DBA_Huangzj 的回复:

我知道你说38，但是50个是系统进程 Connection reset by peer: socket write error” 这个貌似有点问题了

版主那这个问题有什么解决方法？

[a2048]

引用 44 楼 DBA_Huangzj 的回复:

经常出现的Connection reset by peer: 原因可能是多方面的，不过更常见的原因是：
①：服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉；
②：客户关掉了浏览器，而服务器还在给客户端发送数据；
③：浏览器端按了Stop

tomcat我不懂，你先从sqlserver阻塞方面看看问题，select * from sys.sysprocesses where spid>50，如果不多的话就截图给我看看

截图：


这张图现在看上去还正常，因为在1个小时左右我重启过，现在是中午没有人在用。

[發糞塗牆]

等卡的时候你再查查截图吧。另外你的磁盘和数据库文件怎么配置的？比如有没有做RAID等？tempdb、数据文件和日志文件是否存在同一个盘？

[a2048]

引用 47 楼 DBA_Huangzj 的回复:

等卡的时候你再查查截图吧。另外你的磁盘和数据库文件怎么配置的？比如有没有做RAID等？tempdb、数据文件和日志文件是否存在同一个盘？

做RAID1，数据库文件盒日志文件都放在d盘里。你说的tempdb在c盘里，是安装时默认的。

[發糞塗牆]

按并发和数据量来说，这个配置倒不是很严重，但是比较常规的办法是把数据文件和日志文件分开物理磁盘，如果系统中大量使用临时对象比如临时表，并且操作的数据量比较大，那么tempdb初始化搞大一点，前期可以分4个数据文件，日志文件就不用了，然后也分开独立的盘。看你46楼的截图中3、4、5行，等待类型主要和这部分有关系，当然也和你的代码及处理的数据量、内存大小有关，等你发现有点卡或者有说阻塞的时候再截图看看吧。

[a2048]

引用 49 楼 DBA_Huangzj 的回复:

按并发和数据量来说，这个配置倒不是很严重，但是比较常规的办法是把数据文件和日志文件分开物理磁盘，如果系统中大量使用临时对象比如临时表，并且操作的数据量比较大，那么tempdb初始化搞大一点，前期可以分4个数据文件，日志文件就不用了，然后也分开独立的盘。看你46楼的截图中3、4、5行，等待类型主要和这部分有关系，当然也和你的代码及处理的数据量、内存大小有关，等你发现有点卡或者有说阻塞的时候再截图看看吧。

”那么tempdb初始化搞大一点，前期可以分4个数据文件“是什么意思？分4个数据文件怎么弄。

[發糞塗牆]

嗯，tempdb的数据文件分4个，日志文件不要动，不过如果你的tempdb使用不频繁就没所谓，另外如果空间足够的话，把tempdb设为大一点也行，这个可以不分文件