数据库访问：响应时间问题。 [第一帖]

[agent]

向各位高手请教一些关于数据库设计与访问的问题。数据库：MS SQL Server 2000。

我的系统是实时性要求较高的系统 （类似VoIP系统），响应时间不能大于5秒。 架构为 Client / Server / Database, 其中Client 为分布在全球的客户端，5000~10000个目前。 Server为运行于一个服务器计算机上的程序。 当一个Client上线，连接到Server后，server接收其请求，处理，返回。现在的问题是 处理时间 过长，导致Client超时。 因为处理数据部分要访问数据库，其时间很难锁定，而且server一般情况会收到成千上万个数据报，有时更会导致访问数据库被阻塞。

请问，是否 MS SQL Server 2000 本身就不能胜任这样的应用，还是数据库设计、访问（ADO访问）或者配置（默认配置）上有什么问题呢。 如果是设计等的问题的话，我应该注意什么问题呢？ 如何改进呢？

已经向几位版主请教了，请在此接分。分不够，会继续开贴谢分。

[子陌红尘]

如果高峰期并发访问数以千计，不单是SQL Server 2000可能处理不过来，包括操作系统、网络乃至PC服务器可能都无法正常的工作。这种局面下，一台用作数据库后台的PC服务器估计已不能胜任工作的，要考虑采用多太服务器实现负载均衡。

[pbsql]

单层恐怕是不行，还有一个问题就是网络带宽（服务器端），主要是要提高服务器端的处理能力

呵呵，听听其他人还有什么说法

[agent]

谢谢大家的回复。

当并发访问量很大时候，必要的硬件支持是一定的。

我在考虑，在数据量非常大的情况下，如何来处理以及交换数据。这时候可能是多个Server在一个负载平衡下来协同，但是问题也产生了， 多个server之间如何交换数据呢？ 通过数据库么？根据现在的经验，速度一定很慢的不可忍受。 所以想到了 Memory Database， 但是代价很大，价格因素，不予考虑。 那么，只能自己实现交换了？ 内存交换？ 还是什么方式呢？ 如果采用内存直接交换的方式，那我现有的 procedure 好像就没办法继续使用了， 但是很多业务都是使用 procedure 来处理的啊。
请高手给点意见。

但是目前还不到这一阶段，所以对于怎么解决目前烧眉毛的问题，请大家不吝金言。

[pbsql]

你看看这个的相关部分估计会有所帮助：
http://www.csdn.net/download/next_csdn.rar

[agent]

谢谢 风云,学习中...

[cpio]

你这种超时并不一定就是数据库处理超时

而是你发出SQL请求后没收到回应，可能是网络太慢引起的

做成B/S模式可能好些

要真是数据库的问题，那就只能想办法优化，换好的硬件

[agent]

to cpio(就这么简单):

数据库会响应的，就是比较慢，比如20秒，或上百秒。

[agent]

版主和高手们都很忙啊，再忙也的抽时间看看俺的贴子啊~_~

[agent]

难道大家都是理论家？ CSDN 的高手呢？

[tjan]

先用事件探查器抓一些超过你指定时间的查询，比如 5秒的，然后看看是否有恰当的索引。