SQL2005数据迁移后变慢

时间:2022-10-17 20:47:46
公司网站跟数据库之前是放在同一台服务器上的,由于数据库增长很快,几个大表的数据已超过了3百万,且同时在线人数有4000人左右,所以近期把数据库迁移到另外一台服务器上,但是一个很头疼的问题出现了,偶尔会出现查询极其快的情况,但是大多数情况是查询比以前一台服务器上更慢了,经常超时。菜鸟我现在如热锅上的蚂蚁很想找出问题到底出现在哪里。
经过我自己分析:
1、可以排除查询不优化、索引不优化等问题。因为目前即使是一个数据只有1000条的小表也会遇到超时的情况
2、死锁发生的概率也不高

请问有没有那位遇到像我这种情况的,该如何去解决?最重要的是如何去分析问题出现在哪里,我该如何去找出问题的根源?

菜鸟我在此跪谢了!!!

13 个解决方案

#1


先看看服务器cpu,memory有瓶颈么

#2


你另外一台服务器硬件方面是否比原来的机器配置差,还有就是机房的问题,我们公司曾经也遇到过类似的情况,当时的机房是10M共享的带宽,数据库迁移到另外一台机器后,速度变的很慢,最后才知道是同一个机柜下面的其他公司的服务器占了大量的带宽,导致出现时慢时好的情况

#3


你把查询慢的那些表DBCC检查下,对那些语句看下执行计划,看看主要耗费在哪里,建议重建表,导入数据!

#4


重新优化,加索引之类的。

#5


引用 2 楼 wukai_c 的回复:
你另外一台服务器硬件方面是否比原来的机器配置差,还有就是机房的问题,我们公司曾经也遇到过类似的情况,当时的机房是10M共享的带宽,数据库迁移到另外一台机器后,速度变的很慢,最后才知道是同一个机柜下面的其他公司的服务器占了大量的带宽,导致出现时慢时好的情况

配置跟原来的服务器一模一样,而且跟原来服务器放在同一个机柜,服务器间建立了局域网。所以您说的问题应该都不会发生

#6


引用 4 楼 ssp2009 的回复:
重新优化,加索引之类的。

这种情况也不会发生,因为索引基本上算是合理的,之前在同一台服务器上也很快。况且目前某些数据只有1000条左右的表也会出现超时

#7


机房的带宽是多少,共享的吗,如果是,机柜里的其他机器如果访问量大的话肯定会影响你们的响应速度

#8


你光查了SQL SERVER的问题,你查过你的系统的问题了吗? 很多时候是非SQL SERVER 托你后腿

#9


重建索引试试。

#10


 难道是阻塞

#11


step 1.查看OS日志,将有红色跟黄色的提示解决掉
step 2.查毒\木马
step 3.网络问题检查,是否网络是否有丢包情况
step 4.查看执行计划,找出瓶颈,优化查询

#12


更新统计,检查执行计划,检查数据库文件分布、磁盘IO等

#13


好了,结贴了。感谢大家的回答,谢谢了!!!
问题最终还是找出来了,既不是硬件问题也不是网络问题,问题的根源在于一句sql造成资源无法释放。从而拖慢整个数据库。真是一句sql没写好真是能害死人啊!

#1


先看看服务器cpu,memory有瓶颈么

#2


你另外一台服务器硬件方面是否比原来的机器配置差,还有就是机房的问题,我们公司曾经也遇到过类似的情况,当时的机房是10M共享的带宽,数据库迁移到另外一台机器后,速度变的很慢,最后才知道是同一个机柜下面的其他公司的服务器占了大量的带宽,导致出现时慢时好的情况

#3


你把查询慢的那些表DBCC检查下,对那些语句看下执行计划,看看主要耗费在哪里,建议重建表,导入数据!

#4


重新优化,加索引之类的。

#5


引用 2 楼 wukai_c 的回复:
你另外一台服务器硬件方面是否比原来的机器配置差,还有就是机房的问题,我们公司曾经也遇到过类似的情况,当时的机房是10M共享的带宽,数据库迁移到另外一台机器后,速度变的很慢,最后才知道是同一个机柜下面的其他公司的服务器占了大量的带宽,导致出现时慢时好的情况

配置跟原来的服务器一模一样,而且跟原来服务器放在同一个机柜,服务器间建立了局域网。所以您说的问题应该都不会发生

#6


引用 4 楼 ssp2009 的回复:
重新优化,加索引之类的。

这种情况也不会发生,因为索引基本上算是合理的,之前在同一台服务器上也很快。况且目前某些数据只有1000条左右的表也会出现超时

#7


机房的带宽是多少,共享的吗,如果是,机柜里的其他机器如果访问量大的话肯定会影响你们的响应速度

#8


你光查了SQL SERVER的问题,你查过你的系统的问题了吗? 很多时候是非SQL SERVER 托你后腿

#9


重建索引试试。

#10


 难道是阻塞

#11


step 1.查看OS日志,将有红色跟黄色的提示解决掉
step 2.查毒\木马
step 3.网络问题检查,是否网络是否有丢包情况
step 4.查看执行计划,找出瓶颈,优化查询

#12


更新统计,检查执行计划,检查数据库文件分布、磁盘IO等

#13


好了,结贴了。感谢大家的回答,谢谢了!!!
问题最终还是找出来了,既不是硬件问题也不是网络问题,问题的根源在于一句sql造成资源无法释放。从而拖慢整个数据库。真是一句sql没写好真是能害死人啊!