求助sqlserver服务器压力问题 sqlserver数据库优化脚本服务器 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 从你的第一个图来看，很有意思。大部分的阻塞都是自己阻塞自己，另外，这些阻塞的情况都出现在，多线程的问题上。比如71阻塞了他自己，他对应了2个线程，也就是kpid是不同的，其他的91更夸张，这个至少说明了，这些会话在执行sql语句时，都采用了并行的执行计划。建议你查看一下，这些会话当前运行的是哪些语句：查看会话71的sql语句dbcc inputbuffer(71)然后看看这个语句的执行计划，运行一下，看看是否很慢 阳泉小当家，我现在sqlserver服务器恢复正常了，但是这是个很危险的前兆，4个月前就是这样，刚开始偶尔会卡，后面越来越频繁，直到最后卡的时间比正常时间多到不行，彻底没法用了，我们那个时候用的方法是，晚上下班后，重启web服务器，好像也关闭了数据库吧，忘了，因为用的是虚拟服务器，我们就申请了新增内存，后来就好了，现在又开始这样，且不管这是不是硬件跟不上，就是你所说的哪些问题，是什么原因呢，自己阻塞自己？一般不是都是A阻塞B吗，感觉现在又要做开发，又要当DBA尼玛部门就是将自己当全能用，其实这样也好，可以多学很多东西，但是目前就是出这样的问题，能给个诊断思路吗？ 2楼那哥们也说并发严重，究竟怎么样才会产生并发呢？你说的这种问题，目前如何快速解决？增加服务器内存可以吗？sql优化以后是要做的，但是太多了，现在是搞不完的，目前就是想要让它正常运行 关于自己阻塞自己的问题，我查了一下资料，是这样说的置于 CXPACKET和LATCH_EX 往意味着存在大量扫描，总是给人的感觉是你的数据库中存在大量的表扫描，因为这个原因造成缓存中的数据频繁的置换出内存，然后又是物理的IO应该是加大内存，或者是优化sql避免一些无所谓的读取操作 刚才参考了这个 http://www.cnblogs.com/lyhabc/articles/3236984.html看了你几个出现次数比较多的等待，下面可以参考，另外，症状和解决方案-LATCH_XX 这意味着 存在非页闩锁 使用sys.dm_os_latch_stats来分析哪一个闩锁等待时间过长 和其它同时发生的等待类型结合查看 比如说CXPACKET和LATCH_EX与ACCESS_METHODs_SCAN_RANGE_GENERATOR往 往意味着存在大量扫描 症状和解决方案-LCK_M_XX 解决方案基于最开始被阻塞进程的等待类型 一个查范围更新或扫描造成的锁升级 症状和解决方案- SOS_SCHEDULER_YIELD 这意味着 线程用完4毫秒的时间片，主动放弃CPU 存在自旋锁 不一定是CPU问题（CPU问题往往体现在长Runnable队列或大量signal wait） 通过执行计划查看是否存在大量扫描 查看等待类型 避免望文生义 更多分析 注意：该方式没有Resource_wait等待类型，因此一些查另外关于sqltrace的，参考这个另外你的服务器硬件配置还有数据库大小是什么样的？建议你查询一下执行次数最多的sql和最耗费IO的sql，看看执行计划是不是缺少索引之类的 这样的问题不是抱佛脚能解决的，如果临时查段资料就能解决，咱们专门玩DB的都该退出江湖了数据库肯定不是简单的Insert/Update/Delete/Select 出现这种问题的原因，有2种：1.硬件瓶颈。就想你说的，加了内存后，好像又恢复正常了，一段时间又不行了，难道是因为数据量新增的速度远快于，你所加的内存量吗？ 我觉得从长期来看，随着数据量的增加，确实会导致硬件的瓶颈，这个时候确实考虑要增加内存。但是我觉得你这个问题，不是增加内存这么简单的。2.需要优化sql语句。sql server说白了，就是执行各种sql语句的一个程序，如果执行这些语句很慢，那么大部分的原因应该是你的sqli写的有问题，或者说你没有建立合理的索引。所以，综合上面的2个，你现在要做的就是找到那些产生阻塞的sql语句，尝试优化这些语句。如果你优化不了，那么可以贴出来，让大家帮你看看，如何优化 关于自己阻塞自己的问题，我查了一下资料，是这样说的置于 CXPACKET和LATCH_EX 往意味着存在大量扫描，总是给人的感觉是你的数据库中存在大量的表扫描，因为这个原因造成缓存中的数据频繁的置换出内存，然后又是物理的IO应该是加大内存，或者是优化sql避免一些无所谓的读取操作对于你说的自我阻塞是否可以这样理解，因为外部读取sqlserver时，首先看的是缓冲池里面有没有这样的数据，有就直接取出来，没有的话，就会为其分配空间，然后先查询出来放到这块内存区域，但存和取是两个异步IO线程，彼此无法访问对方的资源，一定要等到先存完OK了，才能够读取吗？假如磁盘速度够快，那这种等待时间就会很小咯？也就数据库的机制就是这样的，看似一查询就出结果，其实底层内部是进行了这两个动作的吧？我们知道没有索引会查的很慢，索引的作用是更快速地检索，真正的内存读取还是靠磁盘速度吧？ 你说的大量扫描我知道存在，这个系统当初不是我开发的，他们用asp.net的gridview，但是并没有分页，一下子就会查出很多记录，其次我也看了代码，即使用了分页，但是他每一页看似显示的是那几条，不过每点击任何一页，他还是执行了全部查询，没有用分页存储过程，所以只是改了下显示，我真的是醉了，所以sql代码有问题我是知道的，不过现在如果去改，怕又会影响，并且有很多地方sql写的都不规范，一个人改真的会湿了真的很谢谢你，这么耐心的的给我找资料，跟我解释原因，多多少少我也了解了一些，我自己总结下（1，系统设计有些瑕疵，一些查询sql并没有优化，并且数据表的设计不规范，并无索引，这样容易导致造成全表扫描，和大量的查询，加上磁盘速度不够快，导致读写很慢，CXPACKET和LATCH_EX这种类型的wait_type对应的就是扫描过多吧。2，正因为大量查询，导致内存吃紧，这应该是属于代码问题引起的硬件吃不消假象吧，我看不到服务器的硬件配置，这好像是公司给我们部门的一个虚拟服务器吧，数据库大小如何去看呢？）曾经我们时出现过，但是通过增加内存就OK了，看来这次想要治标，就先申请扩张内存吧，不过治本任重道远 大哥我不是专业搞DB的，但是一个人扛这个部门的系统运转，虽然这个系统不是很难，但是目前要升级更新，和其他部门做数据共享，还要做开发，外国佬还要和你开开会啥的，感觉自己什么都要会，尼玛上不了网，网线坏了，电脑卡，Excel公式，都来问，有的明显找IT的就好了的 - -！DB这一块我确实只会写增删查改，存储过程，游标，函数，触发器，但是其他的东西几乎不知道。 数据库大小用存储过程看sp_spaceused你说用gridview自动分页（假分页），就是全部查出来在客户端分页那种了，那优化的余地就很小了，应该可以确认上面那些“等待”就是查询问题引起的了，另外加内存的问题，数据库查询机制，也是治标不治本你任意一个“查询”或者点击一下“下一页”都返回的结果集都比较大，这个一方面会造成大量的IO操作，另一方面，会挤压内存，就是每次每个查询结果集都很大，占用大量内存，注意这个是相互的，A查询返回大量结果集，B查询页返回大量结果集，相互抢占内存的使用，将其他查询缓存的数据写入磁盘，下次继续从磁盘读取，这个相互的你这个现在去改成分页读取数据的方式不太现实，光UI页面上的修改就够受了最现实的是在应用端，在查询时去做一些限制，比如一定要选择一个时间段等，不能不要任何条件随意查询，这样，尽可能地去减少每次查询返回的结果集我第一家公司也是这样的，用gridview假分页，但是因为限制了查询条件，比如默认给一个查询的起始时间等也没有太明显的问题，当然我也不是说这是个好办法，只是没办法的办法 另外，从你说的情况来看，我估计是企业内部用的管理系统我不认为是并发引起的，不太可能说同一时刻非常多的人去写数据，最多就是很多查询操作，产生大量的IO操作，因为并发引起的等待是pagelatch_XX你那个是pageIOlatch_XX，就是你第二个截图第8行的那个，这数据IO等待，置于为什么会产生IO等待，应该清楚了，每次查询都没有分页，直接扫描表所以这些“等待”事件，应该就是因为大量的IO引起的我也没啥经验，属于事后诸葛亮的类型，哈哈就好比病人说肚子疼，原因可能是多样的，到底是肠胃炎还是其他原因，医生也不好说，如果病人说中午吃了生冷的事物，那确定原因的可能性是不是大了很多 急求树形结构表的新增、删除 sql 求一SQL语句 日至总是1m 请问大师,sql能否高效率随机从数据库里面挑出10条数据? 三个表的连接,如何写SQL语句 如何只改变主码 把原来地记录在复制一遍？ 急！急！急！如何恢复丢失的数据库文件.MDF！！！ 怪!!是不是电信在搞鬼啊!!真不明白!!难道就只能连一次啊!!!!!! 重新启动也没有用!!! 谁用过LDAP数据库，有相关的资料吗？ 如何对SQL-Server加锁? sql有字段存在重复数据，只需查询一条数据出来 sql for xml query 求助3
关于自己阻塞自己的问题，我查了一下资料，是这样说的
置于 CXPACKET和LATCH_EX 往意味着存在大量扫描，总是给人的感觉是你的数据库中存在大量的表扫描，因为这个原因造成缓存中的数据频繁的置换出内存，然后又是物理的IO
应该是加大内存，或者是优化sql避免一些无所谓的读取操作
看了你几个出现次数比较多的等待，下面可以参考，另外，症状和解决方案-LATCH_XX
这意味着
存在非页闩锁
使用sys.dm_os_latch_stats来分析哪一个闩锁等待时间过长
和其它同时发生的等待类型结合查看
比如说CXPACKET和LATCH_EX与ACCESS_METHODs_SCAN_RANGE_GENERATOR往
往意味着存在大量扫描 症状和解决方案-LCK_M_XX
解决方案基于最开始被阻塞进程的等待类型
一个查范围更新或扫描造成的锁升级 症状和解决方案-
SOS_SCHEDULER_YIELD
这意味着 线程用完4毫秒的时间片，主动放弃CPU
存在自旋锁
不一定是CPU问题（CPU问题往往体现在长Runnable队列或大量signal wait）
通过执行计划查看是否存在大量扫描
查看等待类型
避免望文生义
更多分析
注意：该方式没有Resource_wait等待类型，因此一些查另外关于sqltrace的，参考这个
另外你的服务器硬件配置还有数据库大小是什么样的？
建议你查询一下执行次数最多的sql和最耗费IO的sql，看看执行计划是不是缺少索引之类的
数据库肯定不是简单的Insert/Update/Delete/Select
出现这种问题的原因，有2种：1.硬件瓶颈。
就想你说的，加了内存后，好像又恢复正常了，一段时间又不行了，难道是因为数据量新增的速度远快于，你所加的内存量吗？
我觉得从长期来看，随着数据量的增加，确实会导致硬件的瓶颈，这个时候确实考虑要增加内存。
但是我觉得你这个问题，不是增加内存这么简单的。2.需要优化sql语句。
sql server说白了，就是执行各种sql语句的一个程序，如果执行这些语句很慢，那么大部分的原因应该是你的sqli写的有问题，或者说你没有建立合理的索引。所以，综合上面的2个，你现在要做的就是找到那些产生阻塞的sql语句，尝试优化这些语句。如果你优化不了，那么可以贴出来，让大家帮你看看，如何优化
关于自己阻塞自己的问题，我查了一下资料，是这样说的
置于 CXPACKET和LATCH_EX 往意味着存在大量扫描，总是给人的感觉是你的数据库中存在大量的表扫描，因为这个原因造成缓存中的数据频繁的置换出内存，然后又是物理的IO
应该是加大内存，或者是优化sql避免一些无所谓的读取操作
对于你说的自我阻塞是否可以这样理解，因为外部读取sqlserver时，首先看的是缓冲池里面有没有这样的数据，有就直接取出来，没有的话，就会为其分配空间，然后先查询出来放到这块内存区域，但存和取是两个异步IO线程，彼此无法访问对方的资源，一定要等到先存完OK了，才能够读取吗？假如磁盘速度够快，那这种等待时间就会很小咯？也就数据库的机制就是这样的，看似一查询就出结果，其实底层内部是进行了这两个动作的吧？我们知道没有索引会查的很慢，索引的作用是更快速地检索，真正的内存读取还是靠磁盘速度吧？
sp_spaceused你说用gridview自动分页（假分页），就是全部查出来在客户端分页那种了，那优化的余地就很小了，
应该可以确认上面那些“等待”就是查询问题引起的了，
另外加内存的问题，数据库查询机制，也是治标不治本
你任意一个“查询”或者点击一下“下一页”都返回的结果集都比较大，这个一方面会造成大量的IO操作，
另一方面，会挤压内存，就是每次每个查询结果集都很大，占用大量内存，注意这个是相互的，
A查询返回大量结果集，B查询页返回大量结果集，相互抢占内存的使用，将其他查询缓存的数据写入磁盘，下次继续从磁盘读取，这个相互的你这个现在去改成分页读取数据的方式不太现实，光UI页面上的修改就够受了
最现实的是在应用端，在查询时去做一些限制，
比如一定要选择一个时间段等，不能不要任何条件随意查询，这样，尽可能地去减少每次查询返回的结果集我第一家公司也是这样的，用gridview假分页，但是因为限制了查询条件，比如默认给一个查询的起始时间等
也没有太明显的问题，当然我也不是说这是个好办法，只是没办法的办法
我不认为是并发引起的，不太可能说同一时刻非常多的人去写数据，最多就是很多查询操作，产生大量的IO操作，
因为并发引起的等待是pagelatch_XX
你那个是pageIOlatch_XX，就是你第二个截图第8行的那个，这数据IO等待，
置于为什么会产生IO等待，应该清楚了，每次查询都没有分页，直接扫描表
所以这些“等待”事件，应该就是因为大量的IO引起的我也没啥经验，属于事后诸葛亮的类型，哈哈
就好比病人说肚子疼，原因可能是多样的，
到底是肠胃炎还是其他原因，医生也不好说，如果病人说中午吃了生冷的事物，那确定原因的可能性是不是大了很多