故障排除(数据库引擎)

1、故障排除（数据库引擎）1. 故障排除概念本节包含有关排除 SQL Server 数据库引擎 故障的信息。1.1 数据收集器故障排除 提供有关数据收集器常见问题的疑难解答信息。本主题解决以下类别的疑难问题：· 错误情况。此类别包含对象模型和运行时错误。· 性能问题。此类别包含一般和特定的性能情况。· 系统挂起。此类别包含数据收集过程中发生的子组件挂起。1.1.1 错误情况错误可能会由对象模型或在运行时引发。 对象模型错误数据收集器对象模型是一种托管 API，它提供一种编程方式来管理数据收集器属性和数据收集组。对象模型是为数据收集器提供配置机制的一组存储

2、过程和视图周围的薄包装。有关详细信息，请参阅数据收集器编程。对象模型错误可能来自对象模型的下列组件之一：· Transact-SQL 错误由从其中一个数据收集器存储过程调用的存储过程或 Transact-SQL 代码引发。· Transact-SQL 错误由数据收集器存储过程直接引发。· 托管异常由对象模型直接引发。下表说明了对象模型可能引发的错误。错误消息 错误号 说明 无法更新活动收集组 '%s' 的名称、目标、proxy_id 或 collection_mode。请停止该收集组，然后再次尝试将其更新。14669试图更新活动收集组。必须先停止收

3、集组，然后才能进行任何该类型的更新。当收集组处于活动状态时，只能更改上载计划。无法删除活动收集组 '%s'。请停止该收集组，然后再次尝试将其删除。14670试图删除正在运行的收集组。无法更新活动收集组 '%s' 中收集项 '%s' 的名称或参数。请停止该收集组，然后再次尝试更新该收集项。14671试图更新正在运行的收集组中的收集项。无法删除活动收集组 '%s' 中的收集项 '%s'。请停止该收集组，然后再次尝试删除该收集项。14672试图删除正在运行的收集组中的收集项。无法删除收集器类型 '%s'。

4、请删除与此收集器类型关联的所有收集项，然后再次尝试将其删除。14673试图删除具有关联的收集项的收集器类型。无法上载非活动收集组 '%s' 的数据。请启动该收集组，然后再次尝试上载数据。14674试图上载由未在运行的收集组收集的数据。无法更新名称、目标、proxy_id、logging_level 或 collection_mode，或者无法向活动收集组 '%s' 添加收集项。请停止该收集组，然后再次尝试将其更新。14675试图更新正在运行的收集组。该用户无权更改 '%s'。该用户必须是数据收集器角色 '%s' 的成员。14676

5、用户试图更新只能由特定数据收集器角色更改的属性。该用户无权执行此操作。该用户必须是数据收集器角色 '%s' 的成员。14677用户试图执行某操作，但不是所需的数据收集器角色的成员。外部用户已停止并关闭了 ID 为 %d 的 SQL Server 跟踪。SQL Server 跟踪收集器将尝试重新创建该跟踪。14678由数据收集器创建并使用的跟踪已在收集器运行时之外停止和关闭。此数据仓库中指定的 %s (%s) 无效。14679传递给管理数据仓库中某个存储过程的参数的值与仓库中的其他条目不匹配。只能对运行 SQL Server 2005 或更高版本的服务器执行此版本的 instmd

6、w.sql。14680试图在运行 SQL Server 2000 或早期版本的服务器上安装管理数据仓库。禁用收集器时不能执行此过程。请启用收集器，然后重试。14681试图执行与收集器的状态相冲突的操作。收集组的状态已更改，但是只有在启用收集器后，它才能启动或停止。14682试图在未启用收集器时启动或停止收集组。快照中或连续模式下的收集组需要一个计划。14683在快照中或连续模式下创建或更新收集组而未提供计划。捕捉到错误，编号: %d，级别: %d，状态: %d，过程: %s，行: %d，消息: %s14684数据收集器组件中发生一般性错误；在 catch 块中捕获到该错误并再次引发该错误。操作

7、无效。ID 为 %d 的收集组的状态当前为“未运行”。14685针对 is_running 状态为 0 的收集组调用 sp_syscollector_create_set_queue_and_service。配置存储区的 MDWInstance 和 MDWDatabase 参数不能为 Null。14686MDWInstance 或 MDWDatabase 参数的管理数据仓库连接字符串为 Null。cache_window 参数的值 (%d) 无效。允许的值为: -1 (缓存以前上载失败的所有上载数据)、0 (不缓存上载数据)、N (缓存以前 N 次上载失败的数据，其中 N >= 1)14

8、687试图将收集器配置存储区的 CacheWindow 参数的值设置为小于 -1 的值。SQL Server 代理停止时收集组无法启动。请启动 SQL Server 代理。14688试图在未启用 SQL Server 代理时启动收集组。如果未配置管理数据仓库，则收集组无法启动。请运行 instmdw.sql 脚本以创建并配置管理数据仓库。14689试图在未设置管理数据仓库时启动收集组。启用收集器时无法执行此过程。请禁用收集器，然后重试。14690试图执行与收集器的状态相冲突的操作。收集器的状态不能为 Null。这可能表示收集器配置数据发生内部损坏。14691对 sp_syscollector_

9、verify_collector_state 的调用发现 CollectorEnabled 参数的值为 Null。这可能表示收集器的配置数据发生内部损坏。 运行时错误当收集包或上载包在运行中遇到问题时便会发生运行时错误。这些错误可能来自下列组件之一：· SQL Server 2008 Integration Services (SSIS) 包的数据流。这些错误可能是由于数据转换失败或出现数据截断导致的。数据收集器会记录受错误影响的行号，并将其记录在数据收集器日志表中。· SSIS 包的控制流。这些错误记录在 msdb 数据库的 SSIS 日志表 (msdb.d

10、bo.sysssislog) 中，并冒泡到数据收集器日志表中。· 数据收集器运行时组件 (dcexec.exe)。这些错误直接记录在数据收集器日志表中。有关详细信息，请参阅数据收集器日志记录。我们建议采用以下方法之一获取有关运行时错误的状态信息。.1 Transact-SQL 存储过程和视图若要查看所有当前正在运行和已完成的收集组或包的状态，请运行以下查询：复制代码use msdbselect * from syscollector_execution_log_full上述查询将返回以下结果集。列名 说明 log_id每个收集组执行的唯一 ID。它用于将此视图与其他详细

11、日志联接起来。parent_log_id父包或收集组的 ID。对于收集组而言，此值为 NULL。各个 ID 以父子关系链接在一起，以便可以轻松确定哪个收集组启动了哪个包。此外，此视图将日志条目按其父子链接进行分组并缩进包的名称，从而使调用链清晰可见。name该日志条目所表示的收集组或包的名称。collection_mode记录该条目时的收集组活动，即收集或上载。start_time收集组或包启动的时间。last_iteration_time对于连续运行的包而言，是包上次捕获快照的时间。finish_time对于已完成的包和收集组而言，是运行完成的时间。duration包或收集组已经运行的时间（

12、以毫秒为单位）。operator启动该收集组或包的操作员。status收集组或包的状态。此值可以为：· 0 - 正在运行· 1 - 已完成· 2 - 失败failure_task当收集组或包失败时，导致失败的 SSIS 包中的任务的名称。package_execution_id指向 SSIS 日志表的链接。collection_set_id指向数据收集器配置表的链接。注意：您可以使用 collection_set_id 作为筛选器以专注于日志中的特定收集组。 有关详细信息，请参阅 syscollector_execution_log_full (Transact-

13、SQL)。您可以通过执行数据收集器提供的函数之一获取有关收集组和包执行的其他信息。以下函数将返回有关收集组或包的详细统计信息，包括由包记录的错误行的数目。复制代码select * from fn_syscollector_get_execution_stats(log_id)下一个函数将返回与某个包的 package_execution_id 相匹配的 SSIS 日志 (sysdtslog90) 部分。如果该包失败，则这是找出错误根源的最好方式。复制代码select * from fn_syscollector_get_execution_details(log_id).2 数据

14、收集器状态报表您可以通过查看 SQL Server Management Studio 中提供的日志获取与前面的 Transact-SQL 查询返回的信息相同的信息。有关详细信息，请参阅如何查看收集组日志。1.1.2 性能问题有三个主要的数据源可用于检查和诊断性能。首先，上一部分介绍的日志表还提供了可用于解决性能问题的有用信息。fn_syscollector_get_execution_stats 函数可返回以下信息。列名 说明 avg_row_count_in进入包的数据流任务的平均行数。min_row_count_in进入包的数据流任务的最小行数。max_row_count_in进入包的数

15、据流任务的最大行数。avg_row_count_out退出包的数据流任务的平均行数。min_row_count_out退出包的数据流任务的最小行数。max_row_count_out退出包的数据流任务的最大行数。avg_duration在包的数据流组件中消耗的平均时间（以毫秒为单位）。min_duration在包的数据流组件中消耗的最短时间（以毫秒为单位）。max_duration在包的数据流组件中消耗的最长时间（以毫秒为单位）。第二个性能数据源是 syscollector_execution_log_full 表，该表提供有关已经完成运行或正在运行的收集组所用时间的信息。最后，可以使用性能计

16、数器来帮助评估性能问题。尤其是，数据收集器进程 (dcexec.exe) 实例的标准进程计数器为数据收集器运行时组件使用了多少系统资源提供了非常好的指示器。 性能问题具体情况运行数据收集器时最有可能出现两种性能问题情况：· 数据收集器消耗的系统资源过多。· 数据收集器无法承受收集负荷。.1 系统资源过度消耗如果进程性能计数器的分析表明 dcexec.exe 进程使用的系统资源过多，则需要进行以下调查。首先，确定是否大部分资源都由一个收集组占用。· 若要标识该收集组，请将进程 ID 映射到 syscollector_execution_l

17、og_full 中的收集组 ID，然后在 syscollector_collection_sets 表中查找该收集组。· 确定该收集组所收集的内容。使用以下查询列出该收集组中的所有收集项：复制代码select * from syscollector_collection_set_items where collection_set_id = <id>· 使用来自上述查询的信息，考虑以下问题：o 收集项是否过多？o 大部分问题是否都由一个收集项所导致？o 收集的数据是否过多？o 如果对上述任何问题的回答为“是”，请考虑修改收集或收集项以减少所收集的数据量。这将减少

18、资源消耗。其次，确定问题是否由活动收集组的数量过多所导致。· 使用以下查询查看系统中定义的收集组数：复制代码select count(*) from syscollector_collection_sets· 使用以下查询查看当前正在运行的收集组数：复制代码select count(*) from syscollector_execution_log_full where parent_log_id is null and status = 1· 如果性能问题是间歇性的，请检查问题是否映射到任何收集或上载活动。如果所有计划都完全相同，则这可能是导致问题的原因。通过

19、调整收集或上载计划或许就可以解决问题。.2 无法承受负荷这种情况只发生在连续运行的收集组中。如果收集频率较高并且要收集的数据量较大，则收集包可能无法在为单个快照迭代分配的时间内处理数据。可以通过将日志表中的 avg_duration 和 max_duration 列与为特定收集项定义的收集频率进行比较来检测这种情况。如果 max_duration 值大于频率值，则收集包可能无法始终满足配置的频率要求。如果 avg_duration 值大于频率值，则收集包会一直出现相同的问题。对于后一种情况，应减小频率或修改收集项以限制所收集的数据量。1.1.3 系统挂起如果作为数据收集器的一部分

20、运行的某个包停止处理但并未退出而是停留在该状态，则会出现系统挂起。多数系统挂起问题都可以通过停止并重新启动收集组得到解决。区分真正挂起和预期行为非常重要。· 连续运行的收集包多数时间处于等待状态，它会定期醒来收集数据快照。收集数据后，该包会回到等待状态。这种等待状态可能看似系统挂起，实际并不是。若要对此进行验证，请检查可疑包的 syscollector_execution_log_full 表。如果 last_iteration_time 不晚于当前时间，则该情况不属于挂起。· 包可能会设计为等待某个将触发收集操作的事件。这种情况下，包将会等待该事件。这种情况并不是挂起。若

21、要验证是否有与数据收集器相关的系统挂起，请执行以下检查：· 首先，标识与要调查的收集组相对应的 dcexec.exe 进程 ID。· 接下来，检查该进程是否正在运行以及是否使用了任何资源。任何挂起进程的 CPU 占用率通常都为 0% 并且不会分配较多内存。该进程也可能会占用高百分比的 CPU。如果是这种情况，则它可能正在进行循环并且未退出内存。· 最后，检查进程的日志表以查看它上次更新的时间。如果更新时间长于收集项的频率，则该进程可能已挂起。有多种原因可导致数据收集器进程挂起。下面列出了最常见的原因：· 包等待发出下一个迭代信号，但没有信号发出。

22、3; 包等待由另一个包所占有的共享锁，但该锁未释放。· 包执行过程中出现错误且未得到适当处理，控制流中断，但包未完全失败。在上述任何情况下，日志中都会有与系统挂起相关的特定条目。请查看是否有任何指示原因的消息。出现系统挂起时，请创建 dcexec.exe 进程的转储并做进一步调查。1.2 对数据库引擎连接进行故障排除 包含有关解决数据库引擎连接问题的信息。1.2.1 故障排除：超时时间已到 当 SQL Server 数据库引擎实例未运行、服务器名称键入错误或者存在网络问题或防火墙时，通常会发生“超时时间已到”错误。 错误文本在 SQL Server Management

23、 Studio 中，此错误显示为：“无法连接到 <服务器名>。”“超时时间已到。在操作完成之前超时时间已过或服务器未响应。（Microsoft SQL Server，错误: -2）”在 sqlcmd 中，可能出现的超时错误包括：“SQL 网络接口: 定位指定的服务器/实例时出错”“Sqlcmd: 错误: Microsoft SQL Server Native Client : 客户端无法建立连接。”“Sqlcmd: 错误: Microsoft SQL Server Native Client : 登录超时时间已到。”“无法与 SQL Server 建立连接”“建立与服务器的连接时出

24、错。当连接到 SQL Server 时，此故障可能会因为 SQL Server 在默认设置下不允许进行远程连接而引发的。” 此错误的常见原因原因 解决方法 键入的服务器名称不正确。使用正确的服务器名称，然后重试。服务器中的 SQL Server 服务未运行。启动 SQL Server 数据库引擎实例。数据库引擎实例的 TCP/IP 端口被防火墙阻塞。将防火墙配置为允许访问数据库引擎。数据库引擎由于已被更改或者不是默认实例而不侦听端口 1433，并且没有运行 SQL Server Browser 服务。要么启动 SQL Server Browser 服务，要么指定 TCP/IP 端

25、口号进行连接。SQL Server Browser 服务正在运行，但 UDP 端口 1434 被防火墙阻塞。将防火墙配置为允许访问服务器上的 UDP 端口 1434，或者连接指定 TCP/IP 端口号。客户端和服务器未配置为使用相同的网络协议。使用 SQL Server 配置管理器，确认服务器和客户端计算机至少有一个通用的启用协议。网络无法将服务器名称解析为 IP 地址。可使用 PING 程序对此进行测试。修复网络上的计算机名称解析问题，或者使用服务器的 IP 地址连接。这不是 SQL Server 问题。有关帮助，请参阅 Windows 文档或与网络管理员联系。无法使用 IP 地址连接到网络

26、。可使用 PING 程序对此进行测试。修复网络上的 TCP/IP 问题。这不是 SQL Server 问题。有关帮助，请参阅 Windows 文档或与网络管理员联系。 不常见错误.1 多个服务器 IP 地址在连接到群集或具有多个 IP 地址的非群集计算机上安装的 SQL Server 命名实例时，Windows Vista 或 Windows Server 2008 上的客户端可能会收到此错误。所有 SQL Server 版本都可能会出现这种问题。原因 在连接到远程计算机上的命名实例时，客户端使用用户数据报协议 (UDP) 连接到 SQL Server 计算机或群集

27、上的 SQL Server Browser 服务以获取连接端点（TCP 端口号或命名管道）。Windows Vista 或 Windows Server 2008 客户端上的防火墙不允许对 UDP 进行松散源映射。即，响应必须是从所查询的相同 IP 地址中返回的。如果响应不是从最初针对的 IP 地址中返回的，客户端防火墙将删除数据包。在尝试连接到群集服务器或具有多个 IP 地址的非群集服务器计算机时，可能会出现这种问题。下表介绍可导致 UDP 数据包被删除的操作系统组合。这可以阻止连接到 SQL Server 的命名实例或未在 TCP 端口 1433 上侦听的 SQL Server 默认实例。

28、客户端操作系统 运行 SQL Server 的操作系统 SQL Server 2008 结果 SQL Server 2005 结果 Windows XP 或 Windows Server 2003Windows XP 或 Windows Server 2003UDP 数据包未被删除。UDP 数据包未被删除。Windows XP 或 Windows Server 2003Windows Vista 或 Windows Server 2003UDP 数据包未被删除。UDP 数据包未被删除。Windows Vista 或 Windows Server 2008Windows XP 或 Windows

29、 Server 2003UDP 数据包被删除。无法连接。UDP 数据包被删除。无法连接。Windows Vista 或 Windows Server 2008Windows Vista 或 Windows Server 2008（x86、IA64）UDP 数据包未被删除。UDP 数据包被删除。无法连接。Windows Vista 或 Windows Server 2008Windows Vista 或 Windows Server 2008 (x64)UDP 数据包被删除。无法连接。UDP 数据包被删除。无法连接。解决方法 若要解决此问题，请执行以下操作之一：· 在连接字符串中，将

30、TCP 端口号或命名管道名称指定为服务器名称的一部分。· 在客户端计算机上具有高级安全功能的 Windows 防火墙中创建例外。注意：如果在防火墙中创建例外，可能会使计算机或网络更容易受到恶意用户或恶意软件（如病毒）的攻击。建议您不要使用这种解决方法，此处提供该信息的目的是，如果没有切实可行的替代方法，您可以自行决定是否采用这种解决方法。 · 例外可以是以下任一情况：o 为连接到 SQL Server 的应用程序添加例外规则。o 添加一个入站规则，以允许来自 SQL Server 计算机或群集的所有可能的 IP 地址的通信。1.2.2 故障排除：强行关闭的连接 使用 TCP

31、/IP 连接到 SQL Server 时，可能会出现此错误。 错误文本该错误出现时可能具有以下格式：· TCP_PROV: 现有连接被远程主机强行关闭。· 访问接口编号: 7，错误: 10054，错误消息:“TCP 访问接口: 现有连接已被远程主机强行关闭”· 未处理的异常: 在向服务器发送请求时发生传输级错误。(访问接口: TCP 访问接口，错误: 0 - 现有连接已被远程主机强行关闭。) 此错误的常见原因下表列出了此错误的常见原因和解决方法。原因 解决方法 客户端已与不支持的 SQL Server Native Client 版本连

32、接。将客户端计算机更新为 SQL Server Native Client 的服务器版本。发生故障的网络硬件正在删除部分 TCP 通信。使用网络监视程序分析 TCP SYN、ACK 和 FIN 消息。SynAttackProtect 设置可能正在删除连接。请参阅后面的“在 Windows Server 2003 SP1 上运行时，连接可能被强行关闭”部分。.1 在 Windows Server 2003 SP1 上运行时，连接可能被强行关闭当使用大量到 Windows Server 2003 Service Pack 1 上运行的 SQL Server 数据库引擎实例的客户端连接

33、尝试测试可伸缩性时，如果请求到达的速度快于 SQL Server 提供的连接速度，则 Windows 可能会删除这些连接。这是 Windows Server 2003 Service Pack 1 的一项安全功能，可实现有限的传入 TCP 连接请求队列。若要解决此问题，请使用 regedit.exe 实用工具添加以下注册表项：项 类型 名称 值 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersDWORDSynAttackProtect00000000安全说明：设置此注册表项可能会使服务器面临 SYN 泛滥和拒绝服务

34、攻击的威胁。只有在必要并且了解这些安全风险的情况下，才可以添加此注册表值。完成测试后，请删除此注册表值。 1.2.3 故障排除：在管道的另一端没有进程 连接到 SQL Server 的客户端如果在 SQL Server 上未启用命名管道支持时连接到该服务器（即使可以使用其他协议，如 TCP/IP），可能会遇到此命名管道错误。如果服务器上未启用命名管道，则拒绝客户端试图使用命名管道进行连接。以下两种情况下会出现此错误：· 客户端试图只使用命名管道进行连接，而服务器上未启用命名管道协议。· 客户端试图使用任何可用的协议进行连接，但在客户端协议顺序中，named pipes 列在

35、 TCP 之前。 错误文本named pipes 提供程序：在管道的另一端没有进程。Microsoft SQL Server Native Client：通信链接失败。Microsoft SQL Server Native Client：在与服务器建立连接时出现错误。当连接到 SQL Server 时，此故障可能是因为 SQL Server 在默认设置下不允许进行远程连接而引发的。 此错误的常见原因原因 解决方法 客户端试图使用 named pipes 进行连接，而服务器没有配置为允许使用 named pipes 进行远程连接。使用 TCP/IP 进行连接，或使用

36、SQL Server 配置管理器通过 named pipes 进行远程连接。客户端协议顺序是在尝试 TCP 协议之前试图使用 named pipes 协议进行连接，而服务器上未启用 named pipes。在客户端计算机上使用 SQL Server 配置管理器，在协议顺序列表中将 TCP 移动到 Named Pipes 之前。1.2.4 故障排除：用户 'x' 登录失败 因密码或用户名错误而使身份验证失败并导致连接尝试被拒时，类似下面的消息将返回到客户端：“用户 '<user_name>' 登录失败”。（Microsoft SQL Server，错误

37、: 18456）”。返回到客户端的其他信息有：“用户 '<user_name>' 登录失败。（.Net SqlClient 数据访问接口）”-“服务器名称: <computer_name>”“错误号: 18456”“严重性: 14”“状态: 1”“行号: 65536”也可能返回以下消息：“消息 18456，级别 14，状态 1，服务器 <computer_name>，第 1 行”“用户 '<user_name>' 登录失败。” 其他错误信息为了增强安全性，返回到客户端的错误消息有意隐藏身份验证错误的本

38、质。但是，在 SQL Server 错误日志中，对应的错误包含映射到身份验证失败条件的错误状态。将错误状态与以下列表进行比较以确定登录失败的原因。状态 说明 2用户 ID 无效。5用户 ID 无效。6尝试同时使用 SQL Server 身份验证与 Windows 登录名。7登录已禁用，密码不正确。8密码不正确。9密码无效。11登录有效，但服务器访问失败。12登录是有效的登录，但服务器访问失败。18必须更改密码。存在其他错误状态，并表示一个意外的内部处理错误。 示例在此示例中，身份验证错误状态为 8。这指示密码不正确。日期 来源 消息 2007-12-05 20:12:56.34登

39、录错误: 18456，严重性: 14，状态: 8。2007-12-05 20:12:56.34登录用户 '<user_name>' 登录失败。CLIENT: <IP 地址>注意：如果 SQL Server 使用 Windows 身份验证模式进行安装，并随后更改为 SQL Server 和 Windows 身份验证模式，则最初禁用 sa 登录名。这会导致状态 7 错误：“用户 'sa' 登录失败”。要启用 sa 登录名，请参阅如何更改服务器身份验证模式。1.2.5 故障排除：在系统管理员被锁定时如何连接到 SQL Server本主题介绍作为

40、系统管理员如何可以重新获得对 SQL Server 数据库引擎的访问权限。系统管理员可能会由于下列原因之一失去对 SQL Server 实例的访问权限：· 作为 sysadmin 固定服务器角色成员的所有登录名都已经被误删除。· 作为 sysadmin 固定服务器角色成员的所有 Windows 组都已经被误删除。· 作为 sysadmin 固定服务器角色成员的登录名用于已经离开公司或者无法找到的个人。· sa 帐户被禁用或者没有人知道密码。可以让您重新获得访问权限的一种方法是重新安装 SQL Server 并将所有数据库附加到新实例。这种解决方案很耗时，

41、并且若要恢复登录名，可能还需要从备份中还原 master 数据库。如果 master 数据库的备份较旧，则它可能未包含所有信息。如果 master 数据库的备份较新，则它可能与前一个实例具有同样的登录名；因此管理员仍将被锁定。 解决方法使用 -m 或 -f 选项在单用户模式下启动 SQL Server 的实例。计算机的本地 Administrators 组的任何成员都可以随后作为 sysadmin 固定服务器角色的成员连接到 SQL Server 实例。注意：在单用户模式下启动 SQL Server 实例时，请首先停止 SQL Server Agent 服务。否则，SQL Ser

42、ver 代理可能会首先连接，并阻止您作为第二个用户连接。 当您将 -m 选项与 sqlcmd 或 SQL Server Management Studio 一起使用时，可以将连接限制为指定的客户端应用程序。例如，-m"sqlcmd" 将连接限制为单个连接并且该连接必须将自身标识为 sqlcmd 客户端程序。当您正在单用户模式下启动 SQL Server 并且未知的客户端应用程序正在占用这个唯一的可用连接时，使用此选项。若要通过 Management Studio 中的查询编辑器进行连接，请使用 -m"Microsoft SQL Server Management

43、Studio - Query"。重要提示：不要将此选项作为安全功能使用。客户端应用程序提供客户端应用程序名称，并且提供假名称来作为连接字符串的一部分。 有关如何在单用户模式下启动 SQL Server 的分步说明，请参阅如何配置服务器启动选项（SQL Server 配置管理器）。1.3 对数据库邮件进行故障排除 提供有关数据库邮件常见问题的疑难解答信息。1.3.1 数据库邮件故障排除：常规步骤 数据库邮件故障排除涉及到对数据库邮件系统进行下列方面的常规检查。这些过程按逻辑顺序介绍，但可以按任何顺序进行评估。 确定是否启用了数据库邮件1. 在 SQL Server Man

44、agement Studio 中，使用查询编辑器窗口连接到 SQL Server 的实例，然后执行下面的代码：复制代码sp_configure 'show advanced', 1; GORECONFIGURE;GOsp_configure;GO2. 在“结果”窗格中，确认 Database Mail XPs 的 run_value 设置为 1。3. 如果 run_value 不为 1，将不会启用数据库邮件。数据库邮件不会自动启用，以减少恶意用户可用来发起攻击的功能数。有关详细信息，请参阅了解外围应用配置器。4. 如果您确定可以启用数据库邮件，请执行下面的代码：复制代码sp_c

45、onfigure 'Database Mail XPs', 1; GORECONFIGURE;GO5. 要将 sp_configure 过程还原为不显示高级选项的默认状态，请执行下面的代码：复制代码sp_configure 'show advanced', 0; GORECONFIGURE;GO 确定是否对用户进行了正确的配置以发送数据库邮件1. 若要发送数据库邮件，用户必须是 DatabaseMailUserRole 的成员。sysadmin 固定服务器角色和 msdb db_owner 角色的成员将自动成为 DatabaseMailUserRo

46、le 角色的成员。若要列出 DatabaseMailUserRole 的所有其他成员，请执行以下语句：复制代码EXEC msdb.sys.sp_helprolemember 'DatabaseMailUserRole'2. 若要将用户添加到 DatabaseMailUserRole 角色中，请使用以下语句：复制代码sp_addrolemember rolename = 'DatabaseMailUserRole' ,membername = '<database user>'3. 若要发送数据库邮件，用户必须有权访问至少一个数据库邮件

47、配置文件。若要列出用户（主体）及其有权访问的配置文件，请执行以下语句：复制代码EXEC msdb.dbo.sysmail_help_principalprofile_sp;4. 使用数据库邮件配置向导创建配置文件并授予用户访问这些配置文件的权限。 确定是否已启动数据库邮件1. 当有电子邮件要处理时，将激活数据库邮件外部程序。当指定的超时期限内没有要发送的电子邮件时，将退出该程序。若要确定是否已启动数据库邮件激活，请执行以下语句：复制代码EXEC msdb.dbo.sysmail_help_status_sp;2. 如果未启动数据库邮件激活，请执行以下语句将其启动：复制代码EXEC

48、 msdb.dbo.sysmail_start_sp;3. 如果已启动数据库邮件外部程序，请使用以下语句检查邮件队列的状态：复制代码EXEC msdb.dbo.sysmail_help_queue_sp queue_type = 'mail'4. 邮件队列的状态应为 RECEIVES_OCCURRING。邮件队列的状态可能会不时发生改变。如果邮件队列的状态不是 RECEIVES_OCCURRING，请使用 sysmail_stop_sp 尝试停止队列，然后再使用 sysmail_start_sp 启动队列。注意：使用 sysmail_help_queue_sp 结果集中的 le

49、ngth 列确定邮件队列中的电子邮件数量。 确定数据库邮件中的问题是影响配置文件中的所有帐户，还是只影响某些帐户1. 如果确定只有某些配置文件可以发送邮件，而不是所有配置文件都可以，则可能是有问题的配置文件所使用的数据库邮件帐户存在问题。若要确定哪些帐户可以成功发送邮件，请执行以下语句：复制代码SELECT sent_account_id, sent_date FROM msdb.dbo.sysmail_sentitems;2. 如果有问题的配置文件未使用列出的任何帐户，那么可能是该配置文件可以使用的所有帐户都不能正常工作。若要测试各个帐户，请使用数据库邮件配置向导创建一个只包

50、含一个用户的新配置文件，然后通过“发送测试电子邮件”对话框使用新帐户发送邮件。3. 若要查看数据库邮件返回的错误消息，请执行以下语句：复制代码SELECT * FROM msdb.dbo.sysmail_event_log;注意：当邮件被成功传递到 SMTP 邮件服务器上时，数据库邮件即认为邮件已被发送。虽然后续错误（例如，收件人的电子邮件地址无效）仍然可能会使邮件无法传递，但是不会包含在数据库邮件日志中。 配置数据库邮件以重试邮件传递1. 如果确定数据库邮件失败是由于无法可靠地到达 SMTP 服务器而导致的，则可以通过增大数据库邮件尝试发送每封邮件的次数来增加邮件传送的成功率

51、。启动数据库邮件配置向导，然后选择“查看或更改系统参数”选项。还可以将更多帐户与配置文件相关联，这样，当从主帐户进行故障转移时，数据库邮件将使用故障转移帐户发送电子邮件。2. 在“配置系统参数”页上，“帐户重试次数”的默认值为 5 次，“帐户重试延迟时间”的默认值为 60 秒，这意味着如果在 5 分钟之内不能到达 SMTP 服务器，邮件传递将失败。增大这些参数可以延长邮件传递失败之前的时间。注意：当发送大量邮件时，虽然较大的默认值可以提高可靠性，但会显著增加资源的使用量，因为会一遍又一遍地尝试传递大量邮件。若要从根本上解决问题，需要解决阻碍数据库邮件与 SMTP 服务器快速建立联系的网络问题或

52、 SMTP 服务器问题。 安全性只有 sysadmin 固定服务器角色的成员才能对数据库邮件的所有方面进行故障排除。如果用户不是 sysadmin 固定服务器角色的成员，则只能获得他们尝试发送的电子邮件的有关信息，而不能获得其他用户发送的电子邮件的有关信息。1.3.2 数据库邮件故障排除：发送测试电子邮件 使用“发送测试电子邮件”对话框来测试使用特定配置文件发送邮件的能力。 过程.1 发送测试电子邮件1. 使用对象资源管理器，连接到配置了数据库邮件的 SQL Server 数据库引擎实例，展开“管理”，右键单击“数据库邮件”，然后单击“发送测试电子邮

53、件”。如果不存在数据库邮件配置文件，将通过一个对话框提示用户创建配置文件，同时还会打开数据库邮件配置向导。2. 在“从 <实例名> 发送测试电子邮件”对话框中，从“数据库邮件配置文件”框中选择要测试的配置文件。3. 在“收件人”框中，键入测试电子邮件收件人的电子邮件名称。4. 在“主题”框中，键入测试电子邮件的主题行。更改默认主题，以便更好地标识电子邮件以进行故障排除。5. 在“正文”框中，键入测试电子邮件的正文。更改默认主题，以便更好地标识电子邮件以进行故障排除。6. 单击“发送测试电子邮件”，将测试电子邮件发送到数据库邮件队列。7. 发送测试电子邮件将打开“数据库邮件测试电子邮

54、件”对话框。请记下“发送电子邮件”框中显示的数字。这是测试电子邮件的 mailitem_id。单击“确定”。8. 在工具栏上，单击“新建查询”以打开“查询编辑器”窗口。执行以下语句以确定测试电子邮件的状态：复制代码SELECT * FROM msdb.dbo.sysmail_allitems WHERE mailitem_id = <the mailitem_id from the previous step> ;9. sent_status 列将指示是否已发送测试电子邮件。10. 如果发生错误，则执行以下语句以查看错误消息： 权限只有 sysadmin 固定服务器角

55、色的成员才能使用“发送测试电子邮件”对话框。如果用户不是 sysadmin 固定服务器角色的成员，可以使用 sp_send_dbmail 过程来测试数据库邮件。1.3.3 数据库邮件故障排除：找不到存储过程“sp_send_dbmail” sp_send_dbmail 存储过程安装在 msdb 数据库中。您必须从 msdb 数据库执行 sp_send_dbmail，或为存储过程指定一个由三部分构成的名称。使用数据库邮件配置向导启用并配置数据库邮件。1.3.4 数据库邮件故障排除：配置文件无效 本主题说明如何排除报告配置文件无效的错误消息的故障。导致出现此消息的可能原因有两个。指定的配置文件不存

56、在，或者运行 sp_send_dbmail (Transact-SQL) 的用户没有访问配置文件的权限。若要检查配置文件的权限，请使用配置文件名作为参数来运行存储过程 sysmail_help_principalprofile_sp (Transact-SQL)。使用存储过程 sysmail_add_principalprofile_sp (Transact-SQL) 或数据库邮件配置向导向 msdb 用户或组授予访问配置文件的权限。1.3.5 数据库邮件故障排除：拒绝了对 sp_send_dbmail 的权限 本主题介绍如何对报告尝试发送数据库邮件的用户不具有执行 sp_send_dbmai

57、l 的权限的错误消息进行故障排除。错误文本如下：复制代码EXECUTE permission denied on object 'sp_send_dbmail', database 'msdb', schema 'dbo'.若要发送数据库邮件，用户必须是 msdb 数据库中的用户，并且是 msdb 数据库中的 DatabaseMailUserRole 数据库角色的成员。若要将 msdb 用户或组添加到此角色中，请使用 SQL Server Management Studio 或对需要发送数据库邮件的用户或角色执行以下语句。复制代码EXEC msd

58、b.dbo.sp_addrolemember rolename = 'DatabaseMailUserRole' ,membername = '<user or role name>'GO1.3.6 数据库邮件故障排除：邮件已排队，但未传递 本主题说明如何解决电子邮件已成功排队但没有传送的问题。 诊断问题数据库邮件外部程序在 msdb 数据库中记录电子邮件活动。首先，要确认数据库邮件是否已启用，应使用 sp_configure 系统存储过程的 Database Mail XPs 选项。然后在 msdb 数据库中执行下面的语句，检查邮件队列的