|
问？：
一个数据库运行了5年多，数据库文件有4G，最大的一个表有1200W条记录，其他2个较大的表有80W条记录，服务器硬件配置是 CPU AMD 雷鸟1G ，512 M DDR内存，RAID1 32G SCSI硬盘，操作系统时WIN2000 SERVER SP4， 数据库是SQL SERVER 2000，数据库文件大小为4G，磁盘分区为NTFS，日志文件已经清空，连接数一般为30。这个数据库是7*24小时运行，一直运行很正常，最近1个月访问速度确变得很慢，对只有3万条记录的表做INSERT和UPDATE操作速度比以前慢了很多，SELECT操作速度也有下降。这种情况在用户多时比较明显，用户少时会快一点。我用win 2000的任务管理器查看服务器的CPU和内存资源占用情况发现数据库有任务处理时CPU的占用多为14％一下，个别时候会达到90％但立刻降下来了，内存资源使用未满。
现在我想搞清楚数据库为什么会变慢，有什么解决办法？
答！： 1:
变慢这是必然的，主要的业务数据表的数据越来越多，可以把主要的业务数据表采取转表的措施，把一段时间不用的数据转如到另一个表中，这样主数据表表的大小就无限增大，查询和修改速度就快些。
答！： 2:
如果真如楼主说的那样，好几年运行都正常的话，那可能要从网络和客户端来检查了！从企业管理器中，"管理"-->"当前活动"-->"锁/进程ID"或"进程信息"来看看有没有被锁掉的进程信息，从而追踪看是哪台机器占用了进程，再查看那台机器的操作！
答！： 3:
在当前活动－》进程信息那里发现很多数据库进程处于sleeping状态
答！： 4:
看看表的索引是不是有问题了
答！： 5:
dbcc checkdb 看看是否有错误
答！： 6:
關注...
答！： 7:
用dbcc checkdb查过没发现错误
答！： 8:
无论数据库怎么慢，服务器的CPU占用率一般在20％以内，大部分时间是在10％以内，内存使用也未满。
用事件探查器观察，发现登录用户数量多时，一个用户的进程被另一个用户中断后要很长时间才会恢复。比如一个用户的进程要插入一批记录，此时另一个用户的进程执行一条SELECT语句，INSERT操作要等一段时间才恢复，SELECT和INSERT不对同一个表，不存在锁的问题。
数据库经常会运行
Select N\' Testing Connection..........
Ececute msdb.dbo.SP_sqlageng_get_perf_counters
ApplicationName为SQLAgent_Alert Engine
答！： 9:
重建索引试试
DBCC INDEXDEFRAG(\'db_name\',\'table_name\',\'IX_name\')
答！： 10:
几个主要表已经重建过索引了
答！： 11:
服务器差了点吧。。。用了5年了 数据量这么大 慢也真正常嘛！~
答！： 12:
关注
答！： 13:
服务器的CPU和内存使用都没达到满负荷状态，不会是扛不住吧。
答！： 14:
SQL 打个补丁，是不是受到RPC攻击了？
乱说乱说
答！： 15:
楼上的朋友，服务器是连在LAN里的，不会受到攻击吧。具体打哪个补丁？
答！： 16:
SQLServer Sp4
答！： 17:
现在完了，数据库写记录写不进去，SELECT操作就可以，不过很慢。
答！： 18:
啊,严重了
答！： 19:
昨晚搞到8点多才可以写入数据，但是现在数据库的速度还不比较慢。昨晚发现日志文件在1天内突然从200M猛增到5G，太恐怖了，清空了日志，收缩了下数据库又可以写记录了。现在发现ping服务器时经常看见掉包的现象，这会不会影响服务器的速度？
Select N\' Testing Connection..........
Ececute msdb.dbo.SP_sqlageng_get_perf_counters
ApplicationName为SQLAgent_Alert Engine
这两个事件经常出现，是不是掉包引起的？
|