sql server 2000 数据量大，能做负载么？

端到端拓扑的事务性复制

    SQL Server 2005对端到端(P2P)拓扑结构上事务性的复制加强了支持。P2P的拓扑结构支持无限的发布服务器，它们彼此之间可以互相交换事务。

    P2P拓扑是SQL Server的一个巨大进步。现在，多端点服务器可以更改数据，并且向其他的发布者复制事务。这就是说，订阅服务器不再被限制在主要的报告环境中，可以通过事务性负载全球共享的方式将服务器分布开来。当用户的数量增加的时候，只要简单地向这个群体中添加服务器即可。

    除了将负载分布之外，这个拓扑结构还增加了可用性。如果任何一个点的服务器不可达，则池中其他服务器就会共享这个负载，因为每个服务器都有其他所有服务器上可获得的全部数据集合。

 数据库镜像和快照

    SQL Server 2005引入了数据库镜像的概念，来帮助获得高可用性。特别提醒的是，只要它正式发布了，数据库镜像就可以在SQL Server 2005上使用。然而，只有到SQL Server 2005 Service Pack 1才会支持镜像。

    数据库快照是SQL Server 2005中引入的另一项特性。快照是某一个时间点上的数据库的克隆。只要对镜像数据库进行了快照，就可以让用户查询快照。快照的生成通常只需要几秒钟，因为它实际上在这个过程中并没有拷贝任何数据。因此，要把负载分布到主服务器和备用服务器上，就可以将数据库做镜像，然后阶段性地对备份服务器进行快照。而且还可以使用快照在主服务器上进行报告。

    软件实现SQL Server 2005的负载均衡 还有就是中间层！

说说是什么cpu和内存

你这样的数据流量和连接频率也不算大啊

如果cpu大于至强双核，内存超过6g，应该是流畅的

这种问题很多公司都存在！

解决方法从三方面入手（更改服务器的方案基本不用想，并且性能提升是很有限的，主要是从软件方面入手）：
一、优化数据库，找时执行时费时、费资源的查询语句，依据此分析相关数据表；主要优化对象：
1）优化索引；尤其是聚集索引，不可乱加但该加的一定要加，其他索引根据前面分析的结果进行添加或修改；2）优化查询语句写法；尽量用短语句，嵌套少些，避免在 Select 语句的字段列表中用函数；3）优化游标；能不用游标就不用，要用的话，最后能用临时表来替代；4）汇总的算法优化，计算保存中间数据，就是把汇总时总从明细数据开始，改为平时计算好中间数据，汇总时利用中间数据，等等；

二、数据结转，就是把历史数据转移到历史数据库（最好有单独的服务器），保持正式数据库中的数据量最少（能满足公司核心业务即可）；

三、日常维护，比如每周最好能重启一次服务器，能清理掉垃圾数据，清理增加很快的日志数据，等等；

最好是从架构上入手，一个在线库（支持在线业务），一个查询库（支持数据查询），两数据库间的数据保持同步(查询库可以比正式可以延迟几分钟)，当一条数据完成使用，就从在线库中删除。这样可保持在线库中数据量的最小化，系统效率上就有保障了。当然查询库中得区分开来，哪些是真的要删除的，哪些是推出正式库而查询库需要继续保留的。

先想到的就这些，希望能对你有所帮助。
Good Luck!

数据不是很多，我觉得慢是因为你的代码效率问题。
优化一下数据库脚本，还有程序代码。
数据库中常用的字段建索引，每个表都建立主键。

数据库集群 服务器集群

硬盘太差