3.2G CPU*4
4G内存
6*80G SCSI HD
RAID 5磁盘数组
应用程序:VB+SQL三层结构
数据在4G以下没什么问题,到7G左右每周要重启一次,不然就会突然变慢,最后生产线无法接受,只能重启, 重启后马上好了.
速度变慢时CPU和内存利用率都很低,不超过50%,用查询分析器SELECT也很慢.用远程控制程序连服务器,桌面及其它管理程序反应很慢.
反应慢时,被锁的表很多,但都不是死锁.查看锁表的SP,都不很平常的,几乎是每分钟都要运行的SP或语句.不慢时性能都没问题,单个执行也没问题.
用性能监控器发现每个程序或语句都变慢.
加大过锁的数量
采用过纤程模式
都没有效果,请各位大侠指个方向,我真的受不了啦.
另:有些地方使用了光标和临时表.但结果集都很小,不过百行.
17 个解决方案
#1
幫你up
#2
1、杀毒
2、打SQL和系统补丁
你的数据库服务器配置很高，7G 的数据很平常，你的服务器的一半就可以应付了，对了，你看看你的数据库的日志是怎么设置的，是否自动增加，有没有设置自动增加最大值
2、打SQL和系统补丁
你的数据库服务器配置很高，7G 的数据很平常，你的服务器的一半就可以应付了，对了，你看看你的数据库的日志是怎么设置的，是否自动增加，有没有设置自动增加最大值
#3
你在那看的锁表信息?
阻塞也会导致这种情况出现(死锁是正常阻塞变为非正常阻塞后的现象)
阻塞也会导致这种情况出现(死锁是正常阻塞变为非正常阻塞后的现象)
#4
对数据库进行一下整理,计划维护
重建索引
重建索引
#5
up
#6
1.补订打好后.
2.杀毒
3.每天用sql profile和windows的性能监视器来分析有没有特殊的时间段.
4.到7G左右每周要重启一次,是不是那些数据库的设置有问题.检查数据库的设置
5.查看index变化情况
2.杀毒
3.每天用sql profile和windows的性能监视器来分析有没有特殊的时间段.
4.到7G左右每周要重启一次,是不是那些数据库的设置有问题.检查数据库的设置
5.查看index变化情况
#7
mark
#8
数据库压缩一下
#9
用的是什么防火墙啊，问题会不会在这！
#10
用的是什么防火墙啊，问题会不会在这！
#11
学习
#12
學
#13
我用的配置比你的差遠了,數據量為5.4G,但是還是不用每周重啟一次.
服务器配置: HP DL580服务器
2.8G CPU
1G内存
4*36.4G SCSI HD
RAID 磁盘数组
应用程序:VB+SQL三层结构
服务器配置: HP DL580服务器
2.8G CPU
1G内存
4*36.4G SCSI HD
RAID 磁盘数组
应用程序:VB+SQL三层结构
#14
現在問題沒有找到根源,但有兩點與大家共享:
1.曾發生過因為使用路由器進行ip+端口隔離而導致數據庫阻塞的現象.
2.經過跟蹤,發現有一個語句寫法有問題,share出來,大家免犯同樣錯誤.
table_sp(@p1,@p2,@p3.......)
select * from tableX where
(@p1='' or p1=@p1)
and (@p2='' or p2=@p2)
and (@p3='' or p3=@p2)
and (@p4='' or p4=@p2)
and (@p5='' or p5=@p2)
.....
這種寫法使能全能查找,但對付大表就死定了,SQL不知如何利用INDEX,每次都要建立運行計劃,DB必被拖死.
因我的系統中使用這個SP的機會很少,故很難跟蹤,修改此SP后,一切正常.
1.曾發生過因為使用路由器進行ip+端口隔離而導致數據庫阻塞的現象.
2.經過跟蹤,發現有一個語句寫法有問題,share出來,大家免犯同樣錯誤.
table_sp(@p1,@p2,@p3.......)
select * from tableX where
(@p1='' or p1=@p1)
and (@p2='' or p2=@p2)
and (@p3='' or p3=@p2)
and (@p4='' or p4=@p2)
and (@p5='' or p5=@p2)
.....
這種寫法使能全能查找,但對付大表就死定了,SQL不知如何利用INDEX,每次都要建立運行計劃,DB必被拖死.
因我的系統中使用這個SP的機會很少,故很難跟蹤,修改此SP后,一切正常.
#15
study
#16
學習
#17
up
#1
幫你up
#2
1、杀毒
2、打SQL和系统补丁
你的数据库服务器配置很高，7G 的数据很平常，你的服务器的一半就可以应付了，对了，你看看你的数据库的日志是怎么设置的，是否自动增加，有没有设置自动增加最大值
2、打SQL和系统补丁
你的数据库服务器配置很高，7G 的数据很平常，你的服务器的一半就可以应付了，对了，你看看你的数据库的日志是怎么设置的，是否自动增加，有没有设置自动增加最大值
#3
你在那看的锁表信息?
阻塞也会导致这种情况出现(死锁是正常阻塞变为非正常阻塞后的现象)
阻塞也会导致这种情况出现(死锁是正常阻塞变为非正常阻塞后的现象)
#4
对数据库进行一下整理,计划维护
重建索引
重建索引
#5
up
#6
1.补订打好后.
2.杀毒
3.每天用sql profile和windows的性能监视器来分析有没有特殊的时间段.
4.到7G左右每周要重启一次,是不是那些数据库的设置有问题.检查数据库的设置
5.查看index变化情况
2.杀毒
3.每天用sql profile和windows的性能监视器来分析有没有特殊的时间段.
4.到7G左右每周要重启一次,是不是那些数据库的设置有问题.检查数据库的设置
5.查看index变化情况
#7
mark
#8
数据库压缩一下
#9
用的是什么防火墙啊，问题会不会在这！
#10
用的是什么防火墙啊，问题会不会在这！
#11
学习
#12
學
#13
我用的配置比你的差遠了,數據量為5.4G,但是還是不用每周重啟一次.
服务器配置: HP DL580服务器
2.8G CPU
1G内存
4*36.4G SCSI HD
RAID 磁盘数组
应用程序:VB+SQL三层结构
服务器配置: HP DL580服务器
2.8G CPU
1G内存
4*36.4G SCSI HD
RAID 磁盘数组
应用程序:VB+SQL三层结构
#14
現在問題沒有找到根源,但有兩點與大家共享:
1.曾發生過因為使用路由器進行ip+端口隔離而導致數據庫阻塞的現象.
2.經過跟蹤,發現有一個語句寫法有問題,share出來,大家免犯同樣錯誤.
table_sp(@p1,@p2,@p3.......)
select * from tableX where
(@p1='' or p1=@p1)
and (@p2='' or p2=@p2)
and (@p3='' or p3=@p2)
and (@p4='' or p4=@p2)
and (@p5='' or p5=@p2)
.....
這種寫法使能全能查找,但對付大表就死定了,SQL不知如何利用INDEX,每次都要建立運行計劃,DB必被拖死.
因我的系統中使用這個SP的機會很少,故很難跟蹤,修改此SP后,一切正常.
1.曾發生過因為使用路由器進行ip+端口隔離而導致數據庫阻塞的現象.
2.經過跟蹤,發現有一個語句寫法有問題,share出來,大家免犯同樣錯誤.
table_sp(@p1,@p2,@p3.......)
select * from tableX where
(@p1='' or p1=@p1)
and (@p2='' or p2=@p2)
and (@p3='' or p3=@p2)
and (@p4='' or p4=@p2)
and (@p5='' or p5=@p2)
.....
這種寫法使能全能查找,但對付大表就死定了,SQL不知如何利用INDEX,每次都要建立運行計劃,DB必被拖死.
因我的系統中使用這個SP的機會很少,故很難跟蹤,修改此SP后,一切正常.
#15
study
#16
學習
#17
up