27,579
社区成员
发帖
与我相关
我的任务
分享请高手帮助（数据库经常“阻塞”）
背景：系统采用c/s结构
服务器配置：PⅢXeon700／512M／18 G(2000年投入使用) ，
数据库： ms sql server 7.0 (sp2)
访问数据库进程数：90
现在数据库经常出现阻塞，一旦阻塞后影响其他人操作。
服务器配置：PⅢXeon700／512M／18 G(2000年投入使用) ，
数据库： ms sql server 7.0 (sp2)
访问数据库进程数：90
现在数据库经常出现阻塞，一旦阻塞后影响其他人操作。
...全文
请发表友善的回复…
发表回复
cgsun 2005-07-14
- 打赏
- 举报
sp_who2
里的blk
如果存在阻塞进程，则是该阻塞进程的系统进程 ID。否则该列为零。
当与给定的 spid 相关联的事务受到孤立分布式事务的阻塞时，该列将对阻塞孤立事务返回 '-2'。
里的blk
如果存在阻塞进程，则是该阻塞进程的系统进程 ID。否则该列为零。
当与给定的 spid 相关联的事务受到孤立分布式事务的阻塞时，该列将对阻塞孤立事务返回 '-2'。
cgsun 2005-07-14
- 打赏
- 举报
解和避免阻塞
当来自应用程序的第一个连接控制锁而第二个连接需要相冲突的锁类型时，将发生阻塞。其结果是强制第二个连接等待，而在第一个连接上阻塞。不管是来自同一应用程序还是另外一台客户机上单独的应用程序，一个连接都可以阻塞另一个连接。
说明 一些需要锁保护的操作可能不明显，例如系统目录表和索引上的锁。
大多数阻塞问题的发生是因为一个进程控制锁的时间过长，导致阻塞的进程链都在其它进程上等待锁。
常见的阻塞情形包括：
提交执行时间长的查询。
长时间运行的查询会阻塞其它查询。例如，影响很多行的 DELETE 或 UPDATE 操作能获取很多锁，这些锁不论是否升级到表锁都阻塞其它查询。因此，一般不要将长时间运行的决策支持查询和联机事务处理 (OLTP) 查询混在一起。解决方案是想办法优化查询，如更改索引、将大的复杂查询分成简单的查询或在空闲时间或单独的计算机上运行查询。
查询运行时间长并由此导致阻塞的一个原因是这些查询不适当地使用游标。游标可能是在结果集中浏览的便利方法，但使用游标可能比使用面向集合的查询慢。
取消没有提交或回滚的查询。
如果应用程序取消查询（如使用开放式数据库连接 (ODBC) sqlcancel 函数）但没有同时发出所需数目的 ROLLBACK 和 COMMIT 语句，则会发生这种情况。取消查询并不自动回滚或提交事务。取消查询后，所有在事务内获取的锁都将保留。应用程序必须提交或回滚已取消的事务，从而正确地管理事务嵌套级。
应用程序没处理完所有结果。
将查询发送到服务器后，所有应用程序必须立即完成提取所有结果行。如果应用程序没有提取所有结果行，锁可能会留在表上而阻塞其他用户。如果使用的应用程序将 Transact-SQL 语句透明地提交给服务器，则该应用程序必须提取所有结果行。如果应用程序没这样做（如果无法配置它执行此操作），则可能无法解决阻塞问题。为避免此问题，可以将这些应用程序限制在报表或决策支持数据库上。
分布式客户端/服务器死锁。
与常规死锁不同，分布式死锁无法由 Microsoft® SQL Server™ 2000 自动检测到。如果应用程序打开多个与 SQL Server 的连接并异步提交查询，则可能会发生分布式客户端/服务器死锁。
例如，一个客户端应用程序线程有两个开放式连接。该线程异步启动事务并在第一个连接上发出查询。应用程序随后启动其它事务，在另一个连接上发出查询并等待结果。当 SQL Server 返回其中一个连接的结果时，应用程序开始处理这些结果。应用程序就这样处理结果，直到生成结果的查询被另一个连接上执行的查询阻塞而导致再没有可用的结果为止。此时第一个连接阻塞，无限期等待处理更多的结果。第二个连接没有在锁上阻塞，但仍试图将结果返回给应用程序。然而，由于应用程序阻塞而在第一个连接上等待结果，第二个连接的结果将得不到处理。
若要避免此问题，请执行下列任一操作：
对每个查询使用查询超时。
对每个查询使用锁定超时。有关更多信息，请参见自定义锁超时。
使用绑定连接。有关更多信息，请参见使用绑定连接。
SQL Server 本质上是受客户端应用程序操纵的傀儡。客户端应用程序对服务器上获取的锁几乎有完全的控制（并对锁负责）。虽然 SQL Server 锁管理器自动使用锁保护事务，但这受客户端应用程序发出的查询类型和对结果的处理方式的直接鼓动。因此，大多数阻塞问题的解决方案都涉及检查客户端应用程序。
阻塞问题常要求检查应用程序提交的 SQL 语句本身，以及检查与连接管理、所有结果行的处理等有关的应用程序行为本身。如果开发工具不允许显式控制连接管理、查询超时、结果处理等，阻塞问题可能得不到解决。
设计应用程序以避免阻塞的准则包括：
不要使用或设计使用户得以填写编辑框的应用程序，编辑框会生成长时间运行的查询。例如，不要使用或设计提示用户输入的应用程序，允许某些字段保留空白或允许输入通配符。这可能导致应用程序提交运行时间过长的查询，从而导致阻塞问题。
不要使用或设计使用户得以在事务内输入内容的应用程序。
允许取消查询。
使用查询或锁定超时，防止失控查询和避免分布式死锁。
立即完成提取所有结果行。
使事务尽可能简短。
显式控制连接管理。
在所预计的并发用户全负荷下对应用程序进行应力测试。
当来自应用程序的第一个连接控制锁而第二个连接需要相冲突的锁类型时，将发生阻塞。其结果是强制第二个连接等待，而在第一个连接上阻塞。不管是来自同一应用程序还是另外一台客户机上单独的应用程序，一个连接都可以阻塞另一个连接。
说明 一些需要锁保护的操作可能不明显，例如系统目录表和索引上的锁。
大多数阻塞问题的发生是因为一个进程控制锁的时间过长，导致阻塞的进程链都在其它进程上等待锁。
常见的阻塞情形包括：
提交执行时间长的查询。
长时间运行的查询会阻塞其它查询。例如，影响很多行的 DELETE 或 UPDATE 操作能获取很多锁，这些锁不论是否升级到表锁都阻塞其它查询。因此，一般不要将长时间运行的决策支持查询和联机事务处理 (OLTP) 查询混在一起。解决方案是想办法优化查询，如更改索引、将大的复杂查询分成简单的查询或在空闲时间或单独的计算机上运行查询。
查询运行时间长并由此导致阻塞的一个原因是这些查询不适当地使用游标。游标可能是在结果集中浏览的便利方法，但使用游标可能比使用面向集合的查询慢。
取消没有提交或回滚的查询。
如果应用程序取消查询（如使用开放式数据库连接 (ODBC) sqlcancel 函数）但没有同时发出所需数目的 ROLLBACK 和 COMMIT 语句，则会发生这种情况。取消查询并不自动回滚或提交事务。取消查询后，所有在事务内获取的锁都将保留。应用程序必须提交或回滚已取消的事务，从而正确地管理事务嵌套级。
应用程序没处理完所有结果。
将查询发送到服务器后，所有应用程序必须立即完成提取所有结果行。如果应用程序没有提取所有结果行，锁可能会留在表上而阻塞其他用户。如果使用的应用程序将 Transact-SQL 语句透明地提交给服务器，则该应用程序必须提取所有结果行。如果应用程序没这样做（如果无法配置它执行此操作），则可能无法解决阻塞问题。为避免此问题，可以将这些应用程序限制在报表或决策支持数据库上。
分布式客户端/服务器死锁。
与常规死锁不同，分布式死锁无法由 Microsoft® SQL Server™ 2000 自动检测到。如果应用程序打开多个与 SQL Server 的连接并异步提交查询，则可能会发生分布式客户端/服务器死锁。
例如，一个客户端应用程序线程有两个开放式连接。该线程异步启动事务并在第一个连接上发出查询。应用程序随后启动其它事务，在另一个连接上发出查询并等待结果。当 SQL Server 返回其中一个连接的结果时，应用程序开始处理这些结果。应用程序就这样处理结果，直到生成结果的查询被另一个连接上执行的查询阻塞而导致再没有可用的结果为止。此时第一个连接阻塞，无限期等待处理更多的结果。第二个连接没有在锁上阻塞，但仍试图将结果返回给应用程序。然而，由于应用程序阻塞而在第一个连接上等待结果，第二个连接的结果将得不到处理。
若要避免此问题，请执行下列任一操作：
对每个查询使用查询超时。
对每个查询使用锁定超时。有关更多信息，请参见自定义锁超时。
使用绑定连接。有关更多信息，请参见使用绑定连接。
SQL Server 本质上是受客户端应用程序操纵的傀儡。客户端应用程序对服务器上获取的锁几乎有完全的控制（并对锁负责）。虽然 SQL Server 锁管理器自动使用锁保护事务，但这受客户端应用程序发出的查询类型和对结果的处理方式的直接鼓动。因此，大多数阻塞问题的解决方案都涉及检查客户端应用程序。
阻塞问题常要求检查应用程序提交的 SQL 语句本身，以及检查与连接管理、所有结果行的处理等有关的应用程序行为本身。如果开发工具不允许显式控制连接管理、查询超时、结果处理等，阻塞问题可能得不到解决。
设计应用程序以避免阻塞的准则包括：
不要使用或设计使用户得以填写编辑框的应用程序，编辑框会生成长时间运行的查询。例如，不要使用或设计提示用户输入的应用程序，允许某些字段保留空白或允许输入通配符。这可能导致应用程序提交运行时间过长的查询，从而导致阻塞问题。
不要使用或设计使用户得以在事务内输入内容的应用程序。
允许取消查询。
使用查询或锁定超时，防止失控查询和避免分布式死锁。
立即完成提取所有结果行。
使事务尽可能简短。
显式控制连接管理。
在所预计的并发用户全负荷下对应用程序进行应力测试。
vbman2003 2005-07-14
- 打赏
- 举报
现在比以前严重可能是因为表中数据量的增加。这种情况很可能是你的表或SQL语句有问题。当阻塞发生时，你可以在企业管理器中的“管理/当前活动.../进程信息”中查看阻塞进程信息。根据进程信息优化相关表和SQL语句。
vivianfdlpw 2005-07-14
- 打赏
- 举报
INF： 了解和解决 SQL Server 7.0 或 2000 阻塞问题
http://support.microsoft.com/kb/224453/zh-cn
如何监视 SQL Server 2000 阻塞
http://support.microsoft.com/kb/271509/EN-US/
http://support.microsoft.com/kb/224453/zh-cn
如何监视 SQL Server 2000 阻塞
http://support.microsoft.com/kb/271509/EN-US/
zaj001 2005-07-14
- 打赏
- 举报
1。以前有过阻塞，不过没有目前这么平繁。
2。现在对比以前的数据库进程要多20个左右。
3。也通过事件探察器跟踪过，sp_lock,sp_who2具体是怎么会事情？能解释吗？
2。现在对比以前的数据库进程要多20个左右。
3。也通过事件探察器跟踪过，sp_lock,sp_who2具体是怎么会事情？能解释吗？
zjcxc 2005-07-14
- 打赏
- 举报
没有直接的解决办法. 建议你这样去考虑问题:
1. 以前是否正常? 如果正常,那是数据多了,需要处理的时间长了,可以考虑提高服务器配置.
2. 如果一直这样,那是设计不合理,建议请专业DBA帮忙处理
一般的常规考虑:
1. 检查网络访问流量,看看是否带宽造成的
2. 检查服务器CPU和内在占用,看看是否硬件配置不够.
3. 通过事件探察器,sp_lock,sp_who2之类的手段,检查是那些程序发出的那些进程造成的堵塞,再根据这些情况去考虑优化处理的T-SQL代码,或者改写业务处理逻辑. 这个要专业DBA和花费一定时间跟踪业务去完成.
1. 以前是否正常? 如果正常,那是数据多了,需要处理的时间长了,可以考虑提高服务器配置.
2. 如果一直这样,那是设计不合理,建议请专业DBA帮忙处理
一般的常规考虑:
1. 检查网络访问流量,看看是否带宽造成的
2. 检查服务器CPU和内在占用,看看是否硬件配置不够.
3. 通过事件探察器,sp_lock,sp_who2之类的手段,检查是那些程序发出的那些进程造成的堵塞,再根据这些情况去考虑优化处理的T-SQL代码,或者改写业务处理逻辑. 这个要专业DBA和花费一定时间跟踪业务去完成.
