对空白报表进行故障排除 - Operations Manager

选择错误类型的实体作为报表目标

对于此问题和其他问题，我们将专注于性能报告。它们是返回空白的最常见步骤，通常也适用于其他报表。第一步是标识生成报表数据的实体和性能计数器。获取此信息的最简单方法是在 监视中查找 相应的性能视图。性能视图中的图例将列出实体、性能计数器和性能收集规则的名称。

例如，如果要对 Exchange 2003 管理包中的 Exchange 信息存储使用 情况报告进行故障排除，请转到 “监视 ”并打开 “IS 性能数据 ”视图。此视图的路径Microsoft Exchange Server/Exchange 2003/Components/IS 性能数据。在性能视图中，图例将显示性能数据的目标、计数器和集合规则。在 IS 性能数据 视图中，目标始终是 信息存储 ，路径始终是运行 IS 服务的服务器的名称。如果选中图例中任何行的框，则该 信息存储 上该计数器的性能数据将显示在图表中。如果图表中显示一行，则将收集数据。

在此示例中，目标始终是 信息存储 。这意味着，只有在运行 Exchange 信息存储使用 情况报告时，才必须选择 信息存储 实体。除了 信息存储 之外，任何其他实体都不会返回任何数据。因此，如果选择 Exchange 2003 角色对象，则会生成一个空报表。若要选择 信息存储 实体作为报表目标，请选择 “添加对象 ”，键入搜索字符串 的信息存储 ，然后选择 “搜索 ”。将显示每个 信息存储的 列表。搜索结果中的路径值将为你提供托管 信息存储 的服务器名称。

其他大多数报表也适用相同的原则。若要对 Exchange SMTP 使用 情况报告进行故障排除，请转到 “监视 ”，并在 Microsoft Exchange Server/Exchange 2003/SMTP 下打开 SMTP 性能数据 视图。你将看到该目标始终为 SMTP 。若要排查 SQL Server 2005 管理包中SQL Server 数据库空间 报表的问题，请转到 “监视 ”并在 “SQL Server/性能 ”下打开 “数据库可用空间”性能 视图。你将看到该目标始终是数据库名称。请记住，图例中 的目标 将是搜索字符串和配置报表参数时必须使用的目标。

未为报表目标启用性能收集规则或生成性能数据的脚本

同样，你将依赖 监视中的性能 视图。如果未收集性能数据，性能视图中会显示两种症状之一：

图例中未列出预期的实体。

该实体在图例中列出，但选中其框时不会显示任何数据。

如果性能视图图例中缺少预期的实体，这可能意味着尚未发现该实体。例如，你可能在未显示在列表中的代理上运行 信息存储 或 SQL Server 2005 数据库引擎。若要检查这一点，请打开 “我的工作区 ”，创建新的状态视图，并将状态视图配置为显示与该实体类型相关的数据。如果预期实体未显示在视图中，则尚未发现它。然后，将此问题作为发现问题进行故障排除，而不是作为报告问题进行故障排除。

如果性能视图图例中缺少预期实体，这可能也意味着该计数器的性能收集规则未为该目标启用。如果禁用规则，则可能会发生这种情况。某些管理包包含默认禁用的性能收集规则，需要重写才能启用这些规则。管理包指南中对此进行了说明。例如，使用 Exchange 2003 管理包时，必须创建替代来启用消息跟踪的性能收集规则。如果不这样做，则不会为 SMTP Out 和 SMTP In 报表收集任何数据。有关启用的性能收集规则以及任何手动配置步骤（如果适用）的信息，请参阅管理包指南。

如果在管理包指南中找不到答案，请在创作中找到性能收集规则，并验证它是否已为目标实体启用。查找规则的最简单方法是在性能视图图例中标识规则名称，然后使用 “创作 ”中的搜索工具查找规则。例如，你发现无法在 Exchange 2003 管理包中一致地获取 Exchange 磁盘使用 情况报告的数据。请转到 “监视 ”，并在“Microsoft Exchange Server/Exchange 2003/Server 性能”下打开 PhysicalDisk 性能视图。你注意到，某些 Exchange 服务器未在图例中列出，但其他服务器则位于该图例中。图例中列出了以下规则名称：

所有磁盘的平均磁盘队列长度 ()

当前磁盘队列长度 (所有磁盘)

磁盘读取 /秒 (所有磁盘)

磁盘写入/第二 (所有磁盘)

打开 “创作” ，并使用 “搜索 ”命令查找名为“ 平均磁盘队列长度”的规则 (所有磁盘) 。打开规则属性并发现此规则已禁用，并且有一个替代项，用于仅为一组选择的 Exchange 服务器启用该规则。这解释了为什么某些 Exchange 服务器未为此报表生成数据。必须调整规则配置，以面向所有 Exchange 服务器，而不是自定义组。

代理上的运行状况服务存在功能问题

在某些情况下，预期实体可能列在性能视图图例中，但在选中其框时不会显示任何数据。这可能指示代理的性能或功能问题。例如，代理上的运行状况服务可能未运行，或者代理可能无法连接到其管理服务器。尝试增加性能视图返回几天的时间范围。这可能有助于确定何时停止收集性能数据。此外，请检查相应代理上的 Operations Manager 事件日志，并查找运行状况服务和运行状况服务模块错误。具体而言，查找指示性能计数器缺失的事件。此外，请检查运行状况服务脚本 6026 或 6024 事件。当运行状况服务超过专用字节或句柄计数的阈值并重新启动时，将记录这些事件。出现此问题时，性能数据收集中可能会存在缺口。

管理服务器无法将数据插入 OperationsManagerDW 数据库

如果一个或多个管理服务器无法写入 OperationsManagerDW 数据库，则症状会多种多样且不可预测。对于使用一个管理服务器的代理，你可能有报告数据，但对于使用另一台管理服务器的代理则没有报告数据。报告在所有情况下都可能是零星的。

识别这些问题的第一步是在所有管理服务器上检查 Operations Manager 事件日志。 HealthService 2115 事件是数据库访问问题的常见症状。当服务器收集无法插入到数据库中的数据时，运行状况服务会在管理服务器上记录这些事件。操作数据和报告数据可能会发生这种情况。通常，事件说明中列出的工作流 ID 将指示已收集的数据类型。 ID 中 包含 DataWarehouse 的工作流与报告数据相关。将此类问题作为数据库连接或数据库性能问题进行故障排除。事件 ID 2115 中记录了此错误的一个已知原因，并且管理服务器在 System Center Operations Manager 2007 中生成“无法将数据写入Data Warehouse”警报。

如果看不到 2115 个事件，请在事件日志上配置筛选器，以显示源 运行状况服务模块 和类别 Data Warehouse 中的警告和错误事件。当管理服务器上的任何数据仓库工作流失败时，将记录这些数据。这些事件的说明通常包括返回的SQL Server错误和工作流名称。工作流名称可能提供有关受影响任务的一些上下文。命名 Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData 的工作流收集用于报告的性能数据，并将数据插入数据库中。

数据卡在 OperationsManagerDW 数据库的过渡表中

首先检查管理服务器上的事件 ID 31552 上的 Operations Manager 事件日志，事件说明中列出了以下工作流名称：

Microsoft.SystemCenter.DataWarehouse.StandardDataSetMaintenance

StandardDataSetMaintenance 是工作流 (也称为规则) ，用于整理、优化和聚合数据仓库中的数据。如果此工作流失败，数据可能会卡在过渡表中。此规则在命名 StandardDatasetMaintenance 的数据库中 OperationsManagerDW 运行存储过程，该存储过程调用其他存储过程来处理暂存、聚合、优化和整理标准数据集。所有存储过程名称都以 StandardDataset 开头。默认情况下，规则每 60 秒运行一次。如果看到 31553 或其他错误事件，这可能表示事件中列出的数据集存在问题。请继续阅读，了解有关此操作的详细信息以及故障排除的步骤。

管理服务器将原始报告数据插入数据库中的暂存表中 OperationsManagerDW 。然后运行另一组工作流，将数据从过渡表移到每小时和每日表。这些是用于报表的表。因此，如果性能数据卡在过渡表中，则报表将无法返回数据。若要检查暂存表中的性能数据，请对 OperationsManagerDW 数据库运行以下查询：

Use OperationsManagerDW
Select
   DateTime
   Perf.PerformanceStage
Order By
   DateTime
此表中日期超过一两天的记录可能指示数据未按预期移动到每日和每小时表。 现在，在我们前进之前，让我们来谈谈数据库中的维护。 维护分为所谓的 数据集。 运行维护时，我们会为数据库中的每个数据集运行它。 若要更好地查看此信息，请运行以下查询：
Use OperationsManagerDW;
With AggregationInfo As
   Select
      AggregationType =
            AggregationTypeId = 0
            'Raw'
            AggregationTypeId = 20
            'Hourly'
            AggregationTypeId = 30
            'Daily'
   ,AggregationTypeId, MIN(AggregationDateTime) As 'TimeUTC_NextToAggregate'
   ,SUM(Cast (DirtyInd As Int)) As 'Count_OutstandingAggregations', DatasetId
      StandardDatasetAggregationHistory
   Where
      LastAggregationDurationSeconds Is Not NULL
   Group By
      DatasetId, AggregationTypeId
   Select
      SDS.SchemaName,
      AI.AggregationType,
      AI.TimeUTC_NextToAggregate,
      Count_OutstandingAggregations,
      SDA.MaxDataAgeDays,
      SDA.LastGroomingDateTime,
      SDS.DebugLevel,
      AI.DataSetId
      StandardDataSet As SDS WITH(NOLOCK)
         AggregationInfo As AI WITH(NOLOCK)
         On SDS.DatasetId = AI.DatasetId
         dbo.StandardDatasetAggregation As SDA WITH(NOLOCK)
         On SDA.DatasetId = SDS.DatasetId
         And SDA.AggregationTypeID = AI.AggregationTypeID
   Order By
      SchemaName Desc
这将显示所有 数据集 类型及其相关信息。 下面是有关你看到的列的一些信息：
SchemaName：这是数据集的名称 (例如，perf、state、一些其他自定义数据集等。) 你会注意到，警报和事件不会显示在此处，这是因为这些数据集没有聚合表。
AggregationType：数据集可以聚合到不同的粒度级别，此查询显示每种类型的聚合 (的结果，例如每小时、每日) 。
TimeUTC_NextToAggregate：这是要聚合的下一时间间隔以 UTC 格式的时间戳。 对于每日聚合类型，只需查看 YYYY-MM-DD 值并忽略其余值即可。
Count_OutstandingAggregations：这是数据集背后的聚合数。 如果看到 介于 1 和 3 之间的值，则会有效地赶上。 如果 (上述状态的情况) 你会看到更大的数字，那么你就落后了。
MaxDataAgeDays：这是为给定数据集的聚合设置的保留策略。
LastGroomingDateTime： 相当直截了当。
DebugLevel：可以在数据集上打开调试级别，并获得类似跟踪来诊断问题。 此处的关键要点是，你只希望在短时间内打开此功能，如果在数据集中看到大于 0 的值，则不进行调查，然后将其设置为 0。
DataSetId：这是数据集的 GUID，稍后会派上用场。
通过上述信息，我们现在可以看到是否有任何数据集滞后。 我们将再次使用此处示例的性能数据集。 让我们运行此查询：
Use OperationsManagerDW
Select
   AggregationDateTime,
   LastAggregationDurationSeconds
   StandardDatasetAggregationHistory AS AH
   Inner Join
      StandardDataSet As DS
      On AH.DatasetId = DS.DatasetId
Where
   DS.SchemaName = 'Perf'
Order By
   AggregationDateTime Desc
如果看不到当前日期的记录，则表示聚合未发生。 指示聚合速度缓慢的高值 LastAggregationDurationSeconds 。 这些类型的问题通常表示SQL Server配置或性能问题。 检查SQL Server错误日志和SQL Server性能分析是一个不错的开始位置。
或者，可以检查所谓的 DirtyInd 条目。 DirtyInd 条目指示一个略有不同的问题，即数据正在聚合，但数据比过程可以跟上的数据多。 默认情况下，性能聚合一次只移动 100，000 行，因此，如果存在大量性能数据，则可能会落后，从而导致报表空白或不完整。 若要 Dirtyind 检查条目，请运行以下查询：
Declare @DataSet as uniqueidentifier
   @DataSet =
      Select
         DataSetId
         StandardDataSet
      Where
         SchemaName = 'Perf'
   Select
      StandardDataSetAggregationHistory
   Where
      DataSetId = @DataSet
      And DirtyInd = 1
如果从上述查询中看到超过 4-5 个条目，可能需要手动运行维护。 在手动运行它或执行后续步骤之前，需要关闭我们的默认维护规则。 若要关闭规则，请转到控制台，打开 “创作”，选择 “规则”。 将范围更改为 标准数据集。 替代 Perf 数据集 的规则 (或要对) 进行故障排除的数据集。 现在，请在管理服务器上等待获取确认已应用新配置的 1210 事件，并继续执行后续步骤。
若要手动运行维护，请运行以下查询：
Declare @DataSet uniqueidentifier
   @DataSet =
      Select
         DataSetId
         StandardDataset
      Where
         SchemaName = 'Perf'
   Exec StandardDataSetMaintenance @DataSet
继续运行上述项，直到只有 1-3 个条目 (这是正常的，每个聚合类型) 一个条目。 如果看到多个条目 (超过 100) ，则可能需要运行以下命令：
Declare @i int
   @i = 0
   Declare @DataSet uniqueidentifier
      @DataSet =
         Select
            DataSetId
            StandardDataset
         Where
            SchemaName = 'Perf'
      While(@i <= 500)
      Begin
         Exec StandardDataSetMaintenance @DataSet
            @i = @i + 1 Waitfor Delay '00:00:05'
这将基于设置的值 While(@i<=500)在循环中运行维护。 可以将此值设置为所需的任何值，但不建议高于 500。 可以通过再次运行 Dirtyind 查询来检查循环的进度，该查询在循环进行时应返回较少的行。 脚本再次完成检查 Dirtyind 条目后，如果现在为最新，请测试报表。 如果仍然有太多条目，请继续运行脚本，直到聚合是最新的。