asp.net 开发的网站，sql2000的数据库，部署到服务器上，有三四十个用户登陆就出现问题了，数据库堵塞。

首先要明确，阻塞是正常的，死锁是要避免的。

下列方法有助于最大限度地降低死锁：

按同一顺序访问对象。

避免事务中的用户交互。

保持事务简短并在一个批处理中。

使用低隔离级别。

使用绑定连接。

按同一顺序访问对象

如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。例如，如果两个并发事务获得 Supplier 表上的锁，然后获得 Part 表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在 Supplier 表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。

避免事务中的用户交互

避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。例如，如果事务正在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。

保持事务简短并在一个批处理中

在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长，其持有排它锁或更新锁的时间也就越长，从而堵塞了其它活动并可能导致死锁。

保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。

使用低隔离级别

确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。

使用绑定连接

使用绑定连接使同一应用程序所打开的两个或多个连接可以相互合作。次级连接所获得的任何锁可以象由主连接获得的锁那样持有，反之亦然，因此不会相互阻塞。

SQL Server 的内存管理机制是:

有可用内存, 则为新需求分配内存

无可用内存时, 释放内存来处理新需求.

这是SQL Server 缓冲池的预期行为。

默认情况下，在启动 SQL Server之后，SQL Server会根据 *** 作系统报告的物理内存数来动态增大或缩小高速缓冲存储器的容量。

只要可用物理内存大小保持在4MB到10MB之间，SQL Server 缓冲池就会继续增大（保留可用物理内存在4MB到10MB之间是为了

避免 *** 作系统因为缺少内存而频繁地换页）。如果物理可用内存变得较少的时候，则SQL Server会将一些内存释放给 *** 作系统。

解决方案：

1.给 *** 作系统、sql server打最新补丁

2.确保不是病毒原因（可能性比较小）

3.sql server设计时的要求就是最大可能的减少磁盘的I/O，磁盘I/O是比较消耗资源的，这个磁盘I/O包括了读取数据库文件

还有和虚拟内存的页交换。如果还有足够的可用内存它都会毫不吝啬的使用的（没有设置上限），它会根据需要动态获取和

释放内存的。你要分析的是这占用的内存开销主要用做了什么？是不是有大型的查询或事务 *** 作。

4.如果服务器是专职的数据库服务器，不建议设置最大内存上限。如果还有其它重要的服务在机器上运行，就要考虑它的内存

使用是否会影响其它服务的正常的运行和性能。如果你的服务器除了sql服务, 还有其他服务需求, 则需要设置sql server的最大内存限制

---