经过我自己分析:
1、可以排除查询不优化、索引不优化等问题。因为目前即使是一个数据只有1000条的小表也会遇到超时的情况
2、死锁发生的概率也不高
请问有没有那位遇到像我这种情况的,该如何去解决?最重要的是如何去分析问题出现在哪里,我该如何去找出问题的根源?
菜鸟我在此跪谢了!!!
13 个解决方案
#1
先看看服务器cpu,memory有瓶颈么
#2
你另外一台服务器硬件方面是否比原来的机器配置差,还有就是机房的问题,我们公司曾经也遇到过类似的情况,当时的机房是10M共享的带宽,数据库迁移到另外一台机器后,速度变的很慢,最后才知道是同一个机柜下面的其他公司的服务器占了大量的带宽,导致出现时慢时好的情况
#3
你把查询慢的那些表DBCC检查下,对那些语句看下执行计划,看看主要耗费在哪里,建议重建表,导入数据!
#4
重新优化,加索引之类的。
#5
配置跟原来的服务器一模一样,而且跟原来服务器放在同一个机柜,服务器间建立了局域网。所以您说的问题应该都不会发生
#6
这种情况也不会发生,因为索引基本上算是合理的,之前在同一台服务器上也很快。况且目前某些数据只有1000条左右的表也会出现超时
#7
机房的带宽是多少,共享的吗,如果是,机柜里的其他机器如果访问量大的话肯定会影响你们的响应速度
#8
你光查了SQL SERVER的问题,你查过你的系统的问题了吗? 很多时候是非SQL SERVER 托你后腿
#9
重建索引试试。
#10
难道是阻塞
#11
step 1.查看OS日志,将有红色跟黄色的提示解决掉
step 2.查毒\木马
step 3.网络问题检查,是否网络是否有丢包情况
step 4.查看执行计划,找出瓶颈,优化查询
step 2.查毒\木马
step 3.网络问题检查,是否网络是否有丢包情况
step 4.查看执行计划,找出瓶颈,优化查询
#12
更新统计,检查执行计划,检查数据库文件分布、磁盘IO等
#13
好了,结贴了。感谢大家的回答,谢谢了!!!
问题最终还是找出来了,既不是硬件问题也不是网络问题,问题的根源在于一句sql造成资源无法释放。从而拖慢整个数据库。真是一句sql没写好真是能害死人啊!
问题最终还是找出来了,既不是硬件问题也不是网络问题,问题的根源在于一句sql造成资源无法释放。从而拖慢整个数据库。真是一句sql没写好真是能害死人啊!
#1
先看看服务器cpu,memory有瓶颈么
#2
你另外一台服务器硬件方面是否比原来的机器配置差,还有就是机房的问题,我们公司曾经也遇到过类似的情况,当时的机房是10M共享的带宽,数据库迁移到另外一台机器后,速度变的很慢,最后才知道是同一个机柜下面的其他公司的服务器占了大量的带宽,导致出现时慢时好的情况
#3
你把查询慢的那些表DBCC检查下,对那些语句看下执行计划,看看主要耗费在哪里,建议重建表,导入数据!
#4
重新优化,加索引之类的。
#5
配置跟原来的服务器一模一样,而且跟原来服务器放在同一个机柜,服务器间建立了局域网。所以您说的问题应该都不会发生
#6
这种情况也不会发生,因为索引基本上算是合理的,之前在同一台服务器上也很快。况且目前某些数据只有1000条左右的表也会出现超时
#7
机房的带宽是多少,共享的吗,如果是,机柜里的其他机器如果访问量大的话肯定会影响你们的响应速度
#8
你光查了SQL SERVER的问题,你查过你的系统的问题了吗? 很多时候是非SQL SERVER 托你后腿
#9
重建索引试试。
#10
难道是阻塞
#11
step 1.查看OS日志,将有红色跟黄色的提示解决掉
step 2.查毒\木马
step 3.网络问题检查,是否网络是否有丢包情况
step 4.查看执行计划,找出瓶颈,优化查询
step 2.查毒\木马
step 3.网络问题检查,是否网络是否有丢包情况
step 4.查看执行计划,找出瓶颈,优化查询
#12
更新统计,检查执行计划,检查数据库文件分布、磁盘IO等
#13
好了,结贴了。感谢大家的回答,谢谢了!!!
问题最终还是找出来了,既不是硬件问题也不是网络问题,问题的根源在于一句sql造成资源无法释放。从而拖慢整个数据库。真是一句sql没写好真是能害死人啊!
问题最终还是找出来了,既不是硬件问题也不是网络问题,问题的根源在于一句sql造成资源无法释放。从而拖慢整个数据库。真是一句sql没写好真是能害死人啊!