使用有关 Azure SQL 数据库和 Azure SQL 托管实例性能问题的智能见解性能诊断日志

适用于:Azure SQL 数据库Azure SQL 托管实例

本页介绍如何使用智能见解生成的有关 Azure SQL 数据库和 Azure SQL 托管实例性能问题的性能诊断日志,以及其格式和它为满足自定义开发需求所包含的数据。 可将此诊断日志发送到 Azure 事件中心Azure 存储或第三方解决方案,用于自定义 DevOps 警报和报告功能。

日志标头

诊断日志使用 JSON 标准格式输出 Intelligent Insights 的发现成果。

访问 Intelligent Insights 日志的确切类别属性是固定值“SQLInsights”。

日志的标头很常见,由时间戳(TimeGenerated)组成,显示创建条目的时间。 它还包括一个资源 ID(ResourceId),该 ID 引用条目所关联的特定数据库。 类别()、级别(CategoryLevel)和作名称(OperationName)是值不更改的固定属性。 它们指示日志条目是信息性的,并且它来自 Intelligent Insights (SQLInsights)。

"TimeGenerated" : "2017-9-25 11:00:00", // time stamp of the log entry
"ResourceId" : "database identifier", // value points to a database resource
"Category": "SQLInsights", // fixed property
"Level" : "Informational", // fixed property
"OperationName" : "Insight", // fixed property

问题 ID 和受影响的数据库

问题标识属性 (issueId_d) 提供了一种在解决之前唯一跟踪性能问题的方法。 同一问题的日志报告状态中的多个事件记录将共享同一问题 ID。

除了问题 ID 外,诊断日志还报告与诊断日志中报告的问题相关的特定事件的开始(intervalStartTime_t)和结束intervalEndTme_t时间戳。

弹性池(elasticPoolName_s)属性指示出现问题的数据库所属的弹性池。 如果数据库不属于弹性池,此属性将没有值。 检测到问题的数据库在数据库名称 (databaseName_s) 属性中披露。

"intervalStartTime_t": "2017-9-25 11:00", // start of the issue reported time stamp
"intervalEndTme_t":"2017-9-25 12:00", // end of the issue reported time stamp
"elasticPoolName_s" : "", // resource elastic pool (if applicable)
"databaseName_s" : "db_name", // database name
"issueId_d" : 1525, // unique ID of the issue detected
"status_s" : "Active" // status of the issue - possible values: "Active", "Verifying", and "Complete"

检测到的问题

Intelligent Insights 性能日志的下一部分包括通过内置人工智能检测到的性能问题。 检测结果会在 JSON 诊断日志的属性中公开。 这些检测结果包含问题类别、问题的影响、受影响的查询和指标。 检测属性可能包含多个检测到的性能问题。

检测到的性能问题使用以下检测属性结构进行报告:

"detections_s" : [{
"impact" : 1 to 3, // impact of the issue detected, possible values 1-3 (1 low, 2 moderate, 3 high impact)
"category" : "Detectable performance pattern", // performance issue detected, see the table
"details": <Details outputted> // details of an issue (see the table)
}]

下表提供了输出到诊断日志的可检测性能模式和详细信息。

检测类别

category 属性描述可检测性能模式的类别。 请查看下表,了解可检测性能模式的所有可能类别。 有关详细信息,请参阅 使用 Intelligent Insights 排查性能问题

相应地,诊断日志文件中输出的详细信息可能因检测到的性能问题而异。

可检测性能模式 输出的详细信息
达到资源限制
  • 受影响的资源
  • 查询哈希
  • 资源消耗百分比
  • 工作负载增加
  • 执行增加的查询数量
  • 对工作负载增加影响最大的查询的查询哈希
  • 内存压力
  • 内存分配器
  • 锁定
  • 受影响的查询哈希
  • 阻止的查询哈希
  • 增加的 MAXDOP
  • 查询哈希
  • CXP 等待时间
  • 等待时间
  • Pagelatch 争用
  • 导致争用的查询的查询哈希
  • 缺失的索引
  • 查询哈希
  • 新建查询
  • 新查询的查询哈希
  • 异常等待统计信息
  • 异常等待类型
  • 查询哈希
  • 查询等待时间
  • tempdb 争用
  • 导致争用的查询的查询哈希
  • 致使整体数据库 pagelatch 争用等待时间增加的查询 [%]
  • 弹性池 DTU 不足
  • 弹性池
  • 最高的 DTU 消耗数据库
  • 最高使用者使用的池 DTU 百分比
  • 计划回归
  • 查询哈希
  • 完善的计划 ID
  • 错误的计划 ID
  • 数据库范围的配置值更改
  • 与默认值相比的数据库范围的配置更改
  • 客户端缓慢
  • 查询哈希
  • 等待时间
  • 定价层降级
  • 文本通知
  • 影响

    impact 属性描述检测到的行为对数据库存在的问题造成多少影响。 影响范围从 1 到 3,3 影响最大、2 影响居中,1 影响最小。 影响值可以用作自定义警报自动化的输入,具体取决于特定需求。 受影响的属性查询 (QueryHashes) 提供受特定检测影响的查询哈希列表。

    受影响的查询

    Intelligent Insights 日志的下一部分提供关于受检测到的性能问题影响的特定查询信息。 此信息作为嵌入在属性中的 impact_s 对象数组披露。 影响属性包含实体和指标。 实体指的是特定的查询 (Type: Query)。 唯一的查询哈希在 Value 属性下被披露。 此外,每个公开的查询后跟指标和值,指示检测到的性能问题。

    在以下日志示例中,检测到具有哈希 0x9102EXZ4 的查询的执行持续时间增加(Metric: DurationIncreaseSeconds)。 秒值 110 表示执行此特定查询需要 110 秒的时间。 因为可以检测到多个查询,所以此特定日志部分可能包含多个查询条目。

    "impact" : [{
    "entity" : {
    "Type" : "Query", // type of entity - query
    "Value" : "query hash value", // for example "0x9102EXZ4" query hash value },
    "Metric" : "DurationIncreaseSeconds", // measured metric and the measurement unit (in this case seconds)
    "Value" : 110 // value of the measured metric (in this case seconds)
    }]
    

    指标

    报告的每个指标的度量单位在属性下 metric 提供,其可能值为秒、数字和百分比。 度量后的指标值在 value 属性中报告。

    DurationIncreaseSeconds 属性提供以秒为单位的度量单位。 度量单位 CriticalErrorCount 是一个表示错误计数的数字。

    "metric" : "DurationIncreaseSeconds", // issue metric type - possible values: DurationIncreaseSeconds, CriticalErrorCount, WaitingSeconds
    "value" : 102 // value of the measured metric (in this case seconds)
    

    根本原因分析和改进建议

    Intelligent Insights 性能日志的最后部分是对已确定的性能下降问题的根本原因进行自动分析。 信息以易于理解的文本显示在根本原因分析(rootCauseAnalysis_s)属性中。 日志中可能包含改进建议。

    // example of reported root cause analysis of the detected performance issue, in a human-readable format
    
    "rootCauseAnalysis_s" : "High data IO caused performance to degrade. It seems that this database is missing some indexes that could help."