SQLserver2000挂起

步骤如下

1、在运行里输入regedt，然后按回车，进入注册表

2找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

下面的PendingFileRenameOperations

这个文件的值，然后删除就可以了

扩展资料

Internet 集成

SQL Server 2000 数据库引擎提供完整的XML 支持。它还具有构成最大的Web 站点的数据存储组件所需的可伸缩性、可用性和安全功能。SQL Server 2000 程序设计模型与 Windows DNA 构架集成，用以开发 Web 应用程序，并且SQL Server 2000 支持 English Query 和 Microsoft 搜索服务等功能，在Web 应用程序中包含了用户友好的查询和强大的搜索功能。

可伸缩性和可用性

同一个数据库引擎可以在不同的平台上使用，从运行 Microsoft Windows® 98 的便携式电脑，到运行 Microsoft Windows 2000 数据中心版的大型多处理器服务器。SQL Server 2000 企业版支持联合服务器、索引视图和大型内存支持等功能，使其得以升级到最大 Web 站点所需的性能级别。

企业级数据库功能

SQL Server 2000 关系数据库引擎支持当今苛刻的数据处理环境所需的功能。数据库引擎充分保护数据完整性，同时将管理上千个并发修改数据库的用户的开销减到最小。SQL Server 2000 分布式查询使您得以引用来自不同数据源的数据，就好象这些数据是 SQL Server 2000 数据库的一部分，同时分布式事务支持充分保护任何分布式数据更新的完整性。

复制同样使您得以维护多个数据复本，同时确保单独的数据复本保持同步。可将一组数据复制到多个移动的脱接用户，使这些用户自主地工作，然后将他们所做的修改合并回发布服务器。

易于安装部署和使用

SQL Server 2000 中包括一系列管理和开发工具，这些工具可改进在多个站点上安装、部署、管理和使用 SQL Server 的过程。SQL Server 2000 还支持基于标准的、与 Windows DNA 集成的程序设计模型，使 SQL Server 数据库和数据仓库的使用成为生成强大的可伸缩系统的无缝部分。

这些功能使您得以快速交付 SQL Server 应用程序，使客户只需最少的安装和管理开销即可实现这些应用程序。

数据仓库。 SQL Server 2000 中包括析取和分析汇总数据以进行联机分析处理 (OLAP) 的工具。SQL Server 中还包括一些工具，可用来直观地设计数据库并通过 English Query 来分析数据。

参考资料：

百度百科 Microsoft SQL Server 2000的特性

您好，SQL Server脱机数据库命令是指将数据库从运行状态转换为脱机状态的命令。在脱机状态下，数据库不再接受新的连接请求，同时也不能执行任何的数据 *** 作。这种状态通常用于备份或还原数据库、移动或复制数据库、或在数据库出现问题时进行修复。

下面是SQL Server脱机数据库命令的具体步骤：

1 打开SQL Server Management Studio，连接到要脱机的数据库实例。

2 在“对象资源管理器”中选择要脱机的数据库，右键单击并选择“任务”>“脱机”。

3 在“脱机数据库”对话框中，选择“立即脱机”，然后单击“确定”。

4 数据库将被脱机，并且无法执行任何 *** 作。如果需要重新连接数据库，请使用相应的命令将其重新连接。

5 如果需要将数据库重新上线，请在“对象资源管理器”中选择该数据库，右键单击并选择“任务”>“上线”。

需要注意的是，在执行脱机数据库命令之前，必须确保没有任何正在进行的活动会话或事务，否则可能会导致数据丢失或损坏。因此，在执行脱机命令之前，最好先备份数据库以确保数据的完整性和安全性。

像 SQL Server 这样的数据库管理系统依赖于文件输入/输出 *** 作的及时进行。有故障或配置不当的硬件、固件设置、筛选器驱动程序、压缩、程序错误以及 I/O 路径内的其他情况都可能导致阻塞或延迟 I/O 问题，并且很快对 SQL Server 性能产生消极影响。

上述问题对 SQL Server 的影响因问题细节的不同而差异很大，但它们通常导致阻塞、锁存器争用和超时、过长的响应时间以及资源的过度利用。

阻塞 I/O 是指必须进行外部干预才能完成的 I/O 请求（通常是 I/O 请求包 (IRP)）。这种状况通常需要执行完整的系统重新启动或类似 *** 作才能解决，并且强烈表明硬件有故障或者在 I/O 路径组件中存在程序错误。

延迟 I/O 是指无需干预即可完成但所花时间超过预期时间的 I/O 请求（同样，这通常是 IRP）。这种状况的原因通常是硬件配置、固件设置或筛选器驱动程序干预，需要硬件或软件供应商提供帮助以便跟踪和解决。

SQL Server 2000 SP4 包含数据库和日志文件 I/O（读和写）逻辑以便检测延迟和阻塞状况。当 I/O *** 作经过 15 秒钟或更长时间仍未完成时，SQL Server 会检测到并报告这一状况。以下消息将被记录到 SQL Server 错误日志中：

2007-11-1 00:21:2526 spid1 SQL Serverhas encountered 192

occurrence(s) of IO requests taking longer than 15 seconds to complete

on file [E:\SEDATA\stressdb5ndf] in database [stressdb] (7) The OS

file handle is 0x00000000000074D4 The offset of the latest long IO is:

x00000000022000"

该消息表明，当前工作负载需求超出了 I/O 路径或当前系统配置和功能，或者 I/O 路径含有不能正常工作的软件（固件、驱动程序）或硬件组件。

所记录的错误信息提供了以下信息：

• ### occurrences — 未能在 15 秒钟以内完成读或写 *** 作的 I/O 请求的数量。

• File information — 完整的文件名、数据库名和受影响文件的 DBID。

• File handle — 该文件的 *** 作系统句柄。可以通过调试器和其他实用工具来使用这一信息跟踪 IRP 请求。

• Offset — 上一个阻塞或延迟 I/O 的偏移量。可以通过调试器和其他实用工具来使用这一信息跟踪 IRP 请求。（注：在记录该消息的时候，该 I/O 可能不再阻塞或延迟。）

记录与报告

I/O 的报告和记录是按照文件执行的。延迟和阻塞 I/O 请求的检测和报告是两个不同的 *** 作。

检测（记录）是在 SQL Server 内部的两个位置处理的。第一个位置是在 I/O 实际完成的时候。如果请求花费了 15 秒钟以上，则发生记录 *** 作。第二个位置是在延迟写入器进程执行的时候。当延迟写入器执行时，它包含新的对所有挂起的数据和日志文件 I/O 请求进行检查的 *** 作，并且，如果已经超过了 15 秒钟的阈值，则会发生记录 *** 作。

报告是按照不低于 5 分钟的时间间隔执行的。当对文件进行下一次 I/O 请求时，发生报告 *** 作。如果记录 *** 作已经发生，并且自上一次报告发生以来已经过去了 5 分钟或更长时间，则向错误日志中写入新的报告（上面显示的错误消息）。

15 秒钟的阈值当前是不可调整的。尽管不推荐这样做，但您可以用跟踪标志 830 完全禁用延迟和阻塞 I/O 检测。在 SQL Server 启动期间设置启动参数 –T830 可以禁用延迟/阻塞 I/O 检测。使用 dbcc traceon(830, -1) 可以禁用对当前正在运行的 SQL Server 实例的检测。只有重新启动 SQL Server，Dbcc traceon 才会生效。

注：延迟或阻塞的给定 I/O 请求只会报告一次。如果消息报告 10 个 I/O 被延迟，则这 10 个报告不会再次发生。如果下一个消息报告 15 个 I/O 被阻塞，则表明 15 个新的 I/O 请求已经被延迟　性能和计划 *** 作

总体系统性能可能在 I/O 处理中扮演关键的角色。在研究延迟或阻塞 I/O 的报告时，应该考虑系统的综合运行状况。过多的负载可能导致整个系统（包括 I/O 处理）变慢。系统在发生问题时的行为可能是确定问题根源的关键所在。例如，如果 CPU 利用率在发生问题时变高或者保持较高水平，则可能表明系统中的某个进程正在消耗如此之多的 CPU 时间，以至于它以各种方式对其他进程产生了消极影响。

请查看性能计数器 Average Disk Sec/Transfer 以及 Average Disk Queue Length 或 Current Disk Queue Length，以获得特定的 I/O 路径信息。例如，SQL Server 计算机上的 Average Disk Sec/Transfer 通常低于 15ms。如果该值上升，则可能表明 I/O 子系统无法满足 I/O 要求。

请记住，SQL Server 充分利用了 Windows 的异步 I/O 功能，并且猛烈地扩展磁盘队列长度，因此上述性能计数器具有较高的值本身并不表明存在问题。

索引和并行性

特别常见的一种情况是，因为索引丢失以及由此导致的扫描、哈希和排序对 I/O 系统造成的压力，所以突发大量的 I/O。运行一遍“Index Turning Wizard”通常会有助于解决系统的 I/O 压力。如果添加索引可以帮助查询避免表扫描甚至排序或哈希，则系统可以获得多个优点：

• 减少完成 *** 作所需的物理 I/O，这直接等效于提高查询的性能。

• 数据缓存中只有较少的页面必须周转，因此缓存中的那些页面可以一直与活动查询相关。

• 避免不必要的排序和哈希。

• 可以降低 tempdb 利用率和减少争用情况。

• 减少资源利用率和/或并行 *** 作。因为 SQL Server 不能保证服务器在确定是否将查询并行化时考虑并行查询执行和系统中的负载，所以您针对串行执行优化所有查询。在 Q/A 环境中，应该将 max degree of parallelism 设置为 1，以便对根本没有从服务器收到任何并行计划的最糟糕情况强行进行调整。如果在测试环境中证实查询可以按串行方式高效执行，则生产环境中的并行计划可以提供出乎意料的性能改进。但是，很多情况下，SQL Server 选择并行执行，这是因为要遍历数据的绝对数量过于庞大。该数据量通常直接受到索引的影响。例如，如果丢失索引，则可能产生大量排序 *** 作。我们很容易就可以看出，执行排序 *** 作的多个辅助进程如何使响应速度比以串行方式处理排序更快速，不过我们需要了解，该 *** 作可能大幅增加 I/O 系统的压力。当多个辅助进程并发运行时，来自多个辅助进程的大型读请求可能导致 I/O 突发以及 CPU 利用率提高。很多时候，如果添加了索引或者发生了其他调整 *** 作，则可以调整查询以使其更快地运行并使用更少的资源。这不仅提高了相关查询的性能，而且还提高了系统的整体性能。

来自 Microsoft SQL Server Support 的实际示例

Microsoft SQL Server 和 Platforms Escalation Support 已经处理了下列方案，这些方案旨在提供一个参考框架，并且帮助树立有关延迟和阻塞 I/O 情况以及系统可能如何受到影响的预期。不存在给其他软硬件带来任何特殊或更高风险的特殊硬件或驱动程序集；在这个方面，所有系统都是相同的。

示例 1 — 阻塞 45 秒钟的日志写 *** 作：

一个尝试性的 SQL Server 日志文件写 *** 作周期性地阻塞 45 秒钟。该日志写 *** 作无法及时完成，从而产生阻塞情况，导致 30 秒钟的客户端查询超时。

请求被提交并阻塞（日志写挂起），导致查询继续占用锁并且阻塞来自其他客户端的传入请求。其他客户端开始超时并且使问题变得复杂，这是因为应用程序没有被设计为在发生超时的时候回滚尚未解决的事务。这会导致数以百计尚未解决的事务占用锁以及严重的阻塞。（有关事务处理和阻塞的详细信息，请参阅 INF: Understanding and Resolving SQLServer 70 or 2000 Blocking Problems）。应用程序使用连接池来维护 Web 站点，因此，随着更多的连接被阻塞，Web 站点创建了更多的连接，而这些连接又会被阻塞，该循环会一直持续下去。

在大约 45 秒钟之后，该日志写 *** 作将完成，但到此时为止，数以百计的连接已经积累起来，从而导致阻塞问题，并使得 SQL Server 和应用程序需要花费几分钟的时间进行恢复。当与应用程序问题结合起来的时候，延迟 I/O 状况会对系统产生非常消极的影响。

解决办法：这归因于 HBA 驱动程序中的延迟 I/O 请求。计算机具有多个带有故障转移支持的 HBA 卡。故障转移超时值被配置为 45 秒。当一个 HBA 落后或者在 45 秒钟或更长时间内未与 SAN 通信时，该 I/O 请求被路由到第二个 HBA 进行处理，并且会很快完成。硬件产品的推荐故障转移设置为 5 秒钟，以便避免出现这样的延迟状况。

如果在 SQL Server 2000 SP4 中已经有了新的自动报告该状况的功能，那么我们在疑难解答过程中就可以很快知道，基本问题是由于 SQL Server 外部的问题而发生的阻塞或延迟 I/O *** 作。事实上，我们花费了大量时间来解决一个在最初呈现为普通性能问题的问题。

示例 2 — 筛选器驱动程序干预：

许多防病毒软件和备份产品使用 I/O 筛选器驱动程序。这些筛选器驱动程序成为 I/O 请求栈的一部分，并且可以访问 IRP 请求。Microsoft 技术支持部门已经遇见过各种问题 — 从导致阻塞 I/O 的错误到筛选器驱动程序实现中的延迟状况。

其中，Microsoft SQL Server 技术支持部门遇到的一种情况是，涉及到用于备份处理（该过程能够备份在备份时处于打开状态的文件）的筛选器驱动程序。系统管理员错误地在文件备份选择中包括了 SQL Server 数据文件目录。当备份发生时，它试图收集备份开始时文件的一致镜像。在完成该 *** 作时，它将延迟后续的 I/O 请求，使它们能够在软件处理它们时逐个完成。

当备份开始时，SQL Server 的性能会急剧下降，因为针对 SQL Server 的 I/O 被强迫逐个完成。使该问题变得更为复杂的是，单 I/O 逻辑的特点使得 I/O 通常无法异步执行，因此当 SQL Server 期望发送 I/O 请求并继续工作时，UMS 辅助进程却在 I/O 完成之前一直阻塞在读或写调用中。SQL Server 预读功能实际上被筛选器驱动程序的 *** 作禁用了。而且，即使当备份完成时，筛选器驱动程序中的另一个程序错误仍然使单 I/O 行为保持不变。恢复 SQL Server 性能的方法是关闭数据库并重新打开它或者重新启动 SQL Server，以便在当前筛选器驱动程序交互未就绪的情况下释放并重新获取文件句柄。

解决办法：将 SQL Server 的数据文件从文件备份过程中排除，并且解决筛选器驱动程序中的导致文件被置于单 I/O 模式的程序错误。

示例 3 — 隐藏的错误：

很多高端系统具有用于处理负载平衡的多通道 I/O 路径以及类似的工具。Microsoft SQL Server 技术支持部门已经见过使用此类软件的情况，其中，尽管 I/O 请求失败，但软件确实正确地处理了错误状况，并且执行了无数次重试。I/O 被阻塞，并且 SQL Server 无法完成指定的 *** 作。与上面描述的日志写状况非常类似，在这样的状况对系统产生了消极影响之后，发生了很多糟糕的系统行为。

解决办法：在类似情况下，重新启动 SQL Server 可以在一定程度上缓解问题，但是，有时需要重新启动 Windows 来使处理恢复到正常状态。当然，I/O 子系统中的程序错误最终需要由 I/O 供应商解决。

SQL Server 2000 SP4 的新的对此类状况进行自动报告的功能使得类似问题的检测变得更加容易。我们不仅可以看到整个服务器的总体性能下降，而且还可以通过 SP4 所记录的新消息洞察问题的本质，并且知道该问题很可能出在 SQL Server 外部。

示例 4 — 远程存储/镜像/RAID 驱动器：

很多系统使用镜像或类似的技术来帮助防止丢失数据。其中一些系统是基于软件的，而其他系统是基于硬件的。Microsoft SQL Server 技术支持部门经常遇到的与这些系统有关的情况是延迟增加。

当针对镜像的 I/O 必须在 I/O *** 作被视为完成之前成功完成时，这显然会增加总体 I/O 时间。对于远程镜像安装，网络延迟和重试可能成为一个不利因素。当发生驱动器故障并且 RAID 子系统重新生成时，I/O 吞吐量可能会受到影响。

解决办法：在类似情况下，我们通常建议使用严格的配置设置（这随供应商和设备而异），以减少镜像延迟和 RAID 重新生成 *** 作。

RAID 系统开销和延迟可能导致 I/O 变慢，而 SQL Server 对此无能为力。就像任何其他应用程序一样，它是 RAID 硬件和驱动程序的客户端。当该类型的问题使服务器的速度过度降低时，SP4 中新的延迟和阻塞 I/O 报告功能有助于查明问题所在。

示例 5 — 压缩：

Microsoft 不在压缩驱动器上支持 SQL Server 70 或 2000 数据和日志文件。NTFS 压缩是不安全的，这不仅是因为它破坏了预写日志 (WAL) 协议，而且还因为它要求对每个 I/O 请求执行更多的处理。压缩禁止了异步 I/O，从而导致所有带有受影响数据或日志文件的 SQL Server I/O 都被同步执行。

解决办法：在这种情况下，我们总是建议客户解压缩他们的数据和日志文件。

NTFS 压缩可能导致 I/O 变慢，而 SQL Server 对此无能为力。就像任何其他用户模式应用程序一样，它是文件系统的客户端。当压缩对 SQL Server I/O *** 作产生不利影响时，SP4 中新的延迟和阻塞 I/O 报告功能有助于查明问题所在。

附加数据点

系统进程中提供的等待类型信息可能有助于诊断 I/O 瓶颈。缓冲区 I/O 锁存器等待类型和写日志等待是调查 I/O 路径性能的关键指标。Microsoft 知识库文章 822101: The waittype and lastwaittype fields in the sysprocesses table 概述了等待类型，并且详细介绍了与诊断延迟或阻塞 I/O 状况有关的 I/O 等待类型

点击开始——运行，输入regeditexe确定，就可以进入注册表，不过具体修改那一项要看你是什么软件啊，例如SQL 2000，你重新安装的时候提示挂起，你就可以百度一下2000安装挂起，就可以找到路径进去修改就可以，还可以下载一个sql挂起清除小工具，点击一下就可以，你是什么软件，就百度一下，一般都可以找到

清除库存数据。

1、金蝶K3Cloud单据挂起是因为数据库存满了，首先打开金蝶K3Cloud，接着找到收款单据。

2、然后选择单据设置，选择清楚数据库存，最后刷新一下，金蝶K3Cloud单据挂就可以解决了。

请求一直在挂起状态，程序中的各种页面跳转没有任何问题，就是在提交的时候无法提交成功，找了一两天，感觉不是程序的问题，将目光转向数据库。

发现数据库一堆锁表，问题终于确定是数据库锁表导致提交不成功的，使用工具查询

各种锁，看sql是一条查询语句很久没出结果，而这个查询语句锁了表。

在印象中锁表一直都是插入和更新才锁表，而且还是行锁，查询也会锁表，赶紧补习一下，数据库的锁有很多种，但大致可以分为S锁（共享锁）以及U锁（排他锁），查询的时候会加上S锁，S锁对其他的查询无影响，但是插入和更新则会因为这个锁导致无法插入和更新，而这个sql查询统计的时候耗时非常久，故而导致了整个应用出现问题。根据工具排查出某个古老的应用在进行这个查询，临时先将该应用关闭，恢复正常的业务。

但问题还是要解决，总不能一直关闭那个老应用吧，暂时给出的方案：

1，对表增加索引，让查询更快点

2，对查询语句进行修改，加上 WITH(NOLOCK) 来去掉这个共享锁，当然这也会产生其他问题，比如脏读问题，具体还是要看各自的业务，我这里这个查询并不影响，直接加上 WITH(NOLOCK) 即可，就不会影响插入更新了。

另外补充点：加了nolock其实还是有锁的， 很多人误以为使用了WITH(NOLOCK)后，数据库库不会产生任何锁。实质上，使用了WITH(NOLOCK)后，数据库依然对该表对象生成Sch-S（架构稳定性）锁以及DB类型的共享锁 ，这种锁如果你加入了新的列，而这个插入新列还是事务中，你会发现查询又会有阻塞，但实际这已经没影响了。

另外补充点小知识：

以mysql为例，有索引并且使用了该索引当条件的时候就是行锁，没有索引的时候就是表锁。innodb 的行锁是在有索引的情况下,没有索引的表是锁定全表的。看到这里应该明白了吧，其实加索引也能解决上面那个查询锁表的问题

sqlserver增删改数据时候，对表加IX锁，会阻止非脏读查询，但是不会阻止其他的不同记录的增删改，但是如果执行select则会被堵塞住

以mysql为例，有索引并且使用了该索引当条件的时候就是行锁，没有索引的时候就是表锁。innodb 的行锁是在有索引的情况下,没有索引的表是锁定全表的

sqlserver增删改数据时候，对表加IX锁，会阻止非脏读查询，但是不会阻止其他的不同记录的增删改，但是如果执行select则会被堵塞住

以上就是关于SQLserver2000挂起全部的内容，包括:SQLserver2000挂起、sqlserver脱机数据库命令、教你轻松解决SQLServer2000SP4的问题等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！