解决常见 Notification Services 问题

下面是 Microsoft 编制的、Notification Services 用户遇到的问题及其解决方法列表。

重要提示：
在排除 Notification Services 应用程序故障时，请先转到 Windows 事件查看器中的应用程序日志。应用程序日志中的事件通常是确定应用程序问题根源的最佳方法。

部署与管理疑难解答

因超时错误导致创建实例失败

创建 Notification Services 实例的进程将执行多项任务，每项任务都有时间限制。数据库创建进程所需的时间要比其他操作所需的时间长；此操作的时间限制为 10 分钟，通常已经足够。但是，如果实例配置或应用程序定义指定了非常大的数据库大小（若干个 GB），则创建进程可能会超时；这时将显示超时消息。

若要成功创建该实例，必须在 ADF 和配置文件中减小数据库文件大小，然后再创建该实例。随后可以使用 SQL Server Management Studio 或 Transact-SQL 语句增大数据库文件的大小。

因事务日志已满而导致创建实例失败

如果添加的日志已满或几乎已满，则创建 Notification Services 的实例可能会失败。增大事务日志的 size 和 maxsize 值，然后重试。

更新实例失败

由于应用程序定义或实例配置中存在错误，因此更新 Notification Services 实例可能会失败。在更新实例之前，应验证所有 XML 文件，以降低发生这一错误的可能性。如果确实出现错误，请先修复文件，然后再次尝试执行更新。

由于更新实例时将修改实例和应用程序数据库，因此在更新实例之前应始终备份该实例和应用程序数据库。

有关更新实例的详细信息，请参阅更新实例属性。有关更新应用程序的详细信息，请参阅更新应用程序。

Windows 服务未启动

如果您使用 NS$instanceName Windows 服务来运行 Notification Services 引擎组件，而 Windows 服务未启动，则可能的原因包括：服务密码不正确、您尝试启动的实例名与 Notification Services 实例名不完全匹配、数据库不可访问，或配置为运行该服务所使用的 Windows 用户帐户可能不具备作为服务进行登录的权限。请尝试执行下列操作解决此问题：

• 验证服务帐户是 SQLServer2005NotificationServicesUser$ 的成员ComputerName 组（在 Windows 中）。 SQLServer2005NotificationServicesUser$ComputerName 组的成员具有读取和执行 Notification Services 二进制文件（包括 NSService.exe）的权限。
• **重置 Windows 密码。**使用 Notification Services 命令配置服务密码时，如果密码中包含特殊字符或者存在输入错误，则无法启动 NS$instanceName 服务。
  若要解决此问题，请使用“服务”应用程序更新密码：
  1. 在“控制面板”中，打开**“管理工具”**。
  2. 打开**“服务”**。
  3. 右键单击 NS$instanceName 服务（instanceName 代表 Notification Services 实例的名称），然后单击“属性”。
  4. 单击**“登录”选项卡，在“密码”和“确认密码”**文本框中键入密码。 单击“确定”。
  5. 右键单击该服务，然后单击**“启动”**。
• **检查数据库。**如果服务无法访问实例和应用程序数据库，则不会启动。
  • 实例注册表中的数据库名称是否正确？
  • 承载实例和应用程序数据库的数据库引擎实例是否正在运行？
  • 实例和应用程序数据库是否可用？
  • 是否存在任何阻止服务访问数据库的网络问题？
• **从“服务”应用程序中启动服务。**如果使用 net start 命令启动服务，则在命令提示符下使用的字符必须与配置文件中使用的 Unicode 字符匹配。如果字符不匹配，则实例无法启动。
  若要解决此问题，请使用 Windows 服务应用程序启动服务：
  1. 在“控制面板”中，打开**“管理工具”**。
  2. 打开**“服务”**。
  3. 右键单击 NS$instanceName 服务，然后单击“启动”。

错误未写入应用程序日志中

如果 Notification Services 引擎未启动，但应用程序日志中未包含任何指示错误原因的错误记录，则可能是因为应用程序日志已满。若要重新配置应用程序日志，请执行下列操作：

1. 在“控制面板”中，打开**“管理工具”**。
2. 打开**“事件查看器”**。
3. 右键单击**“应用程序”，然后单击“属性”**。
4. 执行下列两种操作或其中一种操作：
   • 增大**“最大日志大小”**值。
   • 选择**“根据需要覆盖事件”**。

应用程序日志中出现错误

如果应用程序日志中出现错误，请尝试重新启动 Notification Services 引擎。

例如，如果在 Windows 服务运行时从实例中删除了某个应用程序，而后事件日志中出现了与已删除应用程序相关的错误，重新启动 Windows 服务应能避免出现此类错误。

有关详细信息，请参阅启动和停止 Notification Services 实例。

事件收集疑难解答

无法将事件提交给应用程序

在排除事件收集故障时，请验证下列各项：

• 如果使用宿主事件提供程序，请验证运行事件提供程序的 Notification Services 引擎正在运行。
• 确保事件收集已启用。通过运行 nscontrol status 命令可以快速查看实例组件的状态。如果事件处于“已禁用”或“启用挂起”状态，则无法提交事件。
  有关查看状态的详细信息，请参阅查看实例、应用程序和组件的状态。
  有关启用和禁用组件的详细信息，请参阅启用和禁用实例、应用程序或组件。
• 验证用于运行事件提供程序的帐户在实例和应用程序数据库中具备 NSEventProvider 权限。

文件系统观察器事件提供程序失败

如果服务器上的性能计数器损坏，则可能导致文件系统观察器事件提供程序失败。如果事件日志中出现下列错误，则说明性能计数器已损坏：

事件 ID：2980

如果性能计数器已损坏，计数器将不会返回值。若要解决此问题，请执行下列操作：

1. 如果实例正在运行，请停止该实例。有关详细信息，请参阅启动和停止 Notification Services 实例。
2. 关闭查询 Notification Services 性能计数器的所有应用程序，如系统监视器。
3. 重新注册实例。有关详细信息，请参阅更新注册表信息。

这将为实例重新创建性能计数器。可能需要多次运行这些步骤。

通知生成和传递疑难解答

生成重复的通知

如果订阅方收到重复的通知，请验证收集和使用事件的方式：

• 验证当您的通知生成规则应访问与通知类同名的视图时，并不直接访问通知表。视图仅返回当前事件集，而通知表包含尚未通过清空操作删除的所有事件。
  例如，如果事件类的名称为 StockEvent，请在您的订阅规则中使用 StockEvent 视图，而不是 NSStockEventEvents 表。
• 如果您从其他源（如事件历史记录或外部表）获取事件，则您的查询必须包含仅选择用于创建通知所需数据的逻辑。例如，可以包括在前 24 小时内提交的事件或某列具有特定值的事件。订阅规则中的语句可以修改事件源中的值，这样可以跟踪事件使用情况。
• 验证您未多次提交同一事件数据。

有关编写订阅规则的详细信息，请参阅定义订阅规则。

未生成或传递通知

如果无法从应用程序发送通知，请检查下列各项：

• 运行生成器组件的 Notification Services 引擎是否正在运行？是否已启用？
• 是否存在可用事件？
  在实例数据库中运行 NSDiagnosticEventClass 存储过程。搜索 EventBatchesCollectedCount 列，查看事件是否在指定时间到达。
• 是否存在订阅？
  在应用程序数据库中使用 NSSubscriptionClassNameView 视图来验证应用程序具有要评估的订阅。
• 是否正确安排已计划的订阅？
  在应用程序数据库中使用 NSSubscriptionClassNameView 视图或在应用程序数据库中运行 NSScheduledSubscriptionList 和 NSScheduledSubscriptionDetails 存储过程来查看订阅详细信息。
• 通知中引用的订阅方设备是否存在？
  在订阅规则中，必须提供订阅方 ID 和订阅方设备名称。订阅方设备名称必须与为订阅方定义的订阅方设备的名称匹配。若要查看订阅方设备，请在实例数据库中使用 NSSubscriberDeviceView。
• 规则是否超时？
  如果生成通知的订阅规则超时，则应用程序不会生成通知。验证下列各项：您的规则有效、您对事件和订阅数据定义了正确的索引、正在运行清空操作以删除旧数据，以及规则未被服务器上运行的其他进程阻塞。有关制定订阅规则的详细信息，请参阅定义订阅规则。
• 是否正在生成通知？
  在实例数据库中运行 NSDiagnosticNotificationClass 存储过程，验证是否正在生成通知。在 NotificationsGenerated 列中搜索生成通知的时间间隔。如果该列中没有通知，则说明没有事件或订阅，或者订阅类匹配规则未将任何通知插入通知类函数。有关规则的详细信息，请参阅定义订阅规则。
• 通知是否失败？
  运行 NSDiagnosticFailedNotifications 存储过程，检查是否存在未送达的通知。
• 通知是否发送到正确的传递通道？
  验证应用程序为通知类定义了正确的协议，以及添加到应用程序中的订阅使用了正确的传递通道。
• 传递通道是否正常运行？
  运行 NSDiagnosticDeliveryChannel 报告，查看传递通道是否正常运行。
• 是否启用了分发服务器？
  有关启用和禁用组件的详细信息，请参阅启用和禁用实例、应用程序或组件。

出现一般性传递错误

某些传递错误实际上是配置错误。例如，如果未正确配置 SMTP 传递通道，当 Notification Services 试图通过传递通道传递通知时，可能会收到如下消息：

SMTP 传递通知的一般性错误

如果收到类似错误，请验证传递通道的配置是否正确。有关详细信息，请参阅定义传递通道。

SMTP 传递失败

当 Internet 信息服务 (IIS) SMTP 协议与本地 IIS SMTP 服务一起使用时，Notification Services 必须搜索 IIS 目录以确定传递通知的目标位置。只有管理员才能访问这一信息。

若要使用本地 IIS SMTP 服务，用于运行分发服务器引擎组件的帐户必须是本地“管理员”组的成员。

分发服务器超时

如果事件日志中出现各种超时错误，则说明分发服务器的日志记录级别过高。这种情况通常只有在数据库系统正在忙于处理大量通知，因而无法处理分发和日志记录任务时才会出现。

若要解决该问题，请将日志记录设置为关闭。有关详细信息，请参阅指定传递协议执行设置。

Vacuumer 疑难解答

数据未被删除，从而导致事件和通知表非常大

如果数据未按预期方式从应用程序数据库中删除，请检查下列各项：

• 应用程序定义是否提供了清空计划？有关详细信息，请参阅配置数据删除操作。
• 是否指定了合理的保持期？（保持期越长，表中积累的数据将越多。）
• 清空进程是否在系统活动较少的时期运行？如果不是，清空操作所需的系统资源可能不足，无法有效删除数据。
  请注意，开始时间为 UTC 值。例如，如果您将 02:00:00 值指定为开始时间，则格林威治时间为凌晨 2:00。若要以您的时区指定凌晨 2:00 的时间，请加上或减去您的时区与格林威治时间之差。例如，太平洋时间比格林威治时间晚 8 个小时。若要在太平洋时间凌晨 2:00 运行清空进程，请将开始时间指定为 10:00:00。
• 清空持续时间是否足够长？根据数据量，您可能需要较长的一段时间来运行清空操作。

若要评估清空性能，请使用下列资源：

• 运行 NSSnapshotApplications 存储过程来确定上次运行清空操作的时间以及删除事件和通知的数量。有关详细信息，请参阅 NSSnapshotApplications (Transact-SQL)。
• 使用 Windows 性能来监视 NS$instanceName: Vacuumer 性能对象。有关详细信息，请参阅 NS$instance_name：Vacuumer 对象。

Web 应用程序疑难解答

我的订阅管理应用程序无法访问 Notification Services 实例

您的订阅管理应用程序必须能够定位并访问实例和应用程序数据库。这要求在运行应用程序的服务器上注册该实例，并且要求将应用程序所用的帐户添加到实例和应用程序数据库中的 NSSubscriberAdmin 角色。有关详细信息，请参阅部署订阅管理界面。

请参阅

任务

关于 Notification Services 的常见问题
配置 Notification Services 事件日志记录
使用事件消息

帮助和信息

获取 SQL Server 2005 帮助