SQL Server巨难的问题请教

[QDZZQ]

我在SQL Server2000数据库维护中遇到这种怪事，无从下手请高手指教：
我的数据库是StandBy方式集群的SQL Server2000，有10几个数据库，其中一个业务数据库最大，使用频率最高，应用程序是多线程并发处理（主要是文件处理和业务逻辑处理，并发量高）+Web访问方式数据库，定期（每天夜间）使用磁带备份数据。最近出现这种怪事，这个业务是数据库的某些表（表现为4～6个表，数据量较大，但是完全在可承受范围内）通过应用程序不能访问（现象为速度很慢，偶尔有处理成功的），但是这些表通过Web方式访问很正常，另外相同的数据库里面其他的业务数据表是正常使用的，数据库服务器的资源情况正常、日志无异常。
怪事在于，由于某些业务处理失败，我把其中的一个堵塞最严重的业务的数据表清理（未完全清理，正常情况下保留100天数据，这次清理保留10天数据）到历史库（我用脚本Inset到历史库，同时清理运行库的表数据），则一切恢复正常，包括其他原来同样存在处理失败和积压的业务数据，都恢复了正常。
请高手协助分析分析原因，高分相赠，非常感谢！！！！

[fuanwei]

1.数据库表是否做查询优化
2.应用程序查询或者处理中是否做了时间限制(超时断开连接)
3.应用程序是否进行大数据量处理,如果是可以使用olap

[jinjazz]

对于大数据量
使用合理的索引
改为sql2005，使用分区表
如果还不行就用analysis service做商业智能

[wlinglong]

2000 看看语句能不能再优化了 ,然后看看网络的网速 和网络是否稳定,

[dawugui]

对于大数据量,遇到怪问题的机率是非常大的.

最好的解决办法就是把不需要的数据移走.

对大数据量的表设计合理的结构,增加必须的索引,添加必要的主键能减少怪问题的出现机率.

[正宗老冉]

要不行，就抽时间重新调整一下设计。

[QDZZQ]

程序应该是没问题的，后台数据处理主要是根据主键来判断增、删、改的。谢谢各位的不吝回复。
补充一点情况，就是最近10天前曾经把阵列柜的一块磁盘换过。

[QDZZQ]

请高手分析一下是不是索引密度引起的？

[zccmy22]

说实话，我能力有限真的帮不上，不过可以帮你顶一下。

[mengfeihui]

查查 阵列柜 吧？

[十一月猪]

是不是可能被lock了


如果是查询： select ... from table(nolock)

[flairsky]

就是最近10天前曾经把阵列柜的一块磁盘换过。

看是否碎片太多，看磁盘是否有坏道！这个很重要，因为我们也遇到过，换硬盘就搞定。

[kakajya]

[Quote=引用 2 楼 jinjazz 的回复:]
对于大数据量
使用合理的索引
改为sql2005，使用分区表
如果还不行就用analysis service做商业智能
[/Quote]

[QDZZQ]

问题解决了，感谢各位参与。谜底在于索引碎片过多，重新整理即可。