1.c/s 三层erp
2.数据库服务器是win2003+SqlServer2005
3.数据库服务器是ibm 至强2.5八核，内存12G
4.中间层服务器是ibm 至强2.5四核win2000Server 4G内存
4.数据库文件60G，压缩后40G
用 sp_who[sa] 显示410个连接。
最近erp 很慢，重新索引收缩数据库后，还是很慢。数据库服务器也重做了。
请问是什么原因？
数据库服务器 sqlserver 压缩 索引
------解决方案--------------------
这种情况通常要从等待状态入手：
SELECT * FROM sys.dm_os_wait_stats
ORDER BY wait_time_ms DESC
select * from sys.dm_os_waiting_tasks
ORDER BY wait_duration_ms DESC
------解决方案--------------------
你看那些大表数据，是不是因为他们做什么操作时慢。我在维护一个sql2000数据库时，也存在慢的时候，在操作哪些页面慢时，用户都有反应，你就要针对那个大表优化。
还有看日志文件，如果太大了就要截断日志、清空日志
------解决方案--------------------
第一个等待状态，暗示“可能”内存不够，导致查询所需的数据需要从磁盘加载到buffer，这个过程中产生第一个等待类型。第二个等待类型，暗示可能过多的行操作，对于OLTP来说，一般不需要并行操作，甚至很多优化的方案都是直接定义“不用并行”
如果你的服务器开了一段时间，那这些数据是比较靠谱的，假设你不是重启后马上查询的话，建议如下：
1、用性能计数器查看SQL Server: Buffer Manager: Page life expectancy 的时间，一般平均值应该在300s以上，1000s更好。过低意味着内存不够，当然这种情况下通常是缺少合理甚至完全全少索引，导致经常表扫描或者范围扫描，每次都占用很大内存，导致内存中的数据频繁清空。
2、为了不影响服务器级别的设置，先不要降低并行设置，但是可以可以先提高并行阈值，让其“达不到”并行运行的开销而依旧选择串行执行：
sp_configure 'show advanced options',1
go
RECONFIGURE
go
sp_configure 'cost threshold for parallelism',25
GO
RECONFIGURE
GO
3、绝大部分问题都是索引和查询导致的。如果上面的无效，看看重建聚集索引、做日志备份、还有监控一下磁盘问题：
http://blog.csdn.net/dba_huangzj/article/details/8614817
------解决方案--------------------
用profiler创建一个sql trace，然后运行一段时间，再用数据库优化顾问（DTA）来分析一下，看看是否大量丢失索引或者统计信息缺失情况。
------解决方案--------------------
你先检查一下其他脚本，比如你图中最后一行，那个logout的你做不了什么的了