排除针对 Azure 的 SQL Server 托管备份的故障

本主题介绍可用于排查SQL Server Microsoft Azure 托管备份操作期间可能发生的错误的任务和工具。

概述

SQL Server托管备份到 Microsoft Azure 内置了检查和故障排除功能，因此在许多情况下，内部故障由SQL Server托管备份到 Microsoft Azure 过程处理。

这种情况的一个示例是删除备份文件，导致日志链中断，从而影响可恢复性 - SQL Server Microsoft Azure 托管备份将识别日志链中的中断，并计划立即执行备份。 但是，我们仍建议您监视运行状态，并解决所有需要手动干预的错误。

SQL Server Microsoft Azure 的托管备份使用系统存储过程、系统视图和扩展事件来记录事件和错误。 系统视图和存储过程提供SQL Server Microsoft Azure 托管备份配置信息、备份计划备份的状态，以及扩展事件捕获的错误。 SQL Server托管备份到 Microsoft Azure 使用扩展事件来捕获要用于故障排除的错误。 除了记录事件外，SQL Server 智能管理策略还提供运行状态，电子邮件通知作业使用这种状态来提供错误和问题的通知。 有关详细信息，请参阅监视SQL Server托管备份到 Azure。

SQL Server Microsoft Azure 的托管备份也使用手动备份到 Azure 存储时使用的相同日志记录， (SQL Server备份到 URL) 。 有关备份到 URL 相关问题的详细信息，请参阅SQL Server备份到 URL 最佳做法和故障排除中的故障排除部分

常规故障排除步骤

1. 启用电子邮件通知，开始接收有关错误和警告的电子邮件。

   或者，也可定期运行 smart_admin.fn_get_health_status 以检查合计的错误和计数。 例如，number_of_invalid_credential_errors 是尝试备份但出现凭据无效错误的智能备份的次数。 Number_of_backup_loops 和 number_of_retention_loops 不是错误；但是，它们指示备份线程和保持线程扫描数据库列表的次数。 通常，如果未 @begin_time 提供 和 @end_time ，函数显示过去 30 分钟的信息，那么我们通常应看到这两列的非零值。 如果为零，则表示系统过载，甚至系统未响应。 有关详细信息，请参阅本主题后面的 排查系统问题 部分。

2. 检查扩展事件日志，了解错误详细信息和其他相关事件。

3. 使用日志中的信息解决问题。 如果系统出现问题或错误时，可能需要重新启动服务或 SQL Server 代理。

常见错误原因

以下是产生故障的常见错误列表：

1. 对 SQL 凭据的更改：如果SQL Server托管备份到 Microsoft Azure 使用的凭据的名称发生更改或被删除，SQL Server托管备份到 Microsoft Azure 将无法进行备份。 应将更改应用于SQL Server Microsoft Azure 的托管备份配置设置。

2. 对存储访问密钥值的更改：如果更改了 Azure 帐户的存储密钥值，但 SQL 凭据未使用新值更新，SQL Server Microsoft Azure 的托管备份在对存储进行身份验证时将失败，并且无法备份配置为使用此帐户的数据库。

3. 对 Azure 存储帐户的更改：删除或重命名存储帐户而不对 SQL 凭据进行相应更改将导致 microsoft Azure SQL Server托管备份失败，并且不会执行任何备份。 如果删除存储帐户，则务必用有效的存储帐户信息重新配置数据库。 如果重命名了存储帐户或更改了密钥值，请确保这些更改反映在 Microsoft Azure SQL Server托管备份所使用的 SQL 凭据中。

4. 对数据库属性的更改： 更改恢复模式或更改名称可能会导致备份失败。

5. 对恢复模式的更改：如果数据库的恢复模式从完全备份或大容量日志更改为简单，备份将停止，并且SQL Server托管备份到 Microsoft Azure 时跳过数据库。 有关详细信息，请参阅SQL Server托管备份到 Azure：互操作性和共存

最常见的错误消息和解决方案

1. 启用或配置SQL Server托管备份到 Microsoft Azure 时出错：

   错误：“无法访问存储 URL...。提供有效的 SQL 凭据...“：你可能会看到此错误和引用 SQL 凭据的其他类似错误。 在这种情况下，请查看你提供的 SQL 凭据的名称，以及存储在 SQL 凭据中的信息（存储帐户名称和存储访问密钥），并确保它们是最新的且有效的。

   错误：“...无法配置数据库...。因为它是系统数据库“：如果尝试为系统数据库启用SQL Server Microsoft Azure 托管备份，将看到此错误。 SQL Server托管备份到 Microsoft Azure 不支持系统数据库的备份。 要为系统数据库配置备份，请使用其他 SQL Server 备份计术，如维护计划。

   错误：“ ...提供保留期...“：如果在首次配置这些值时未为数据库或实例指定保留期，则可能会看到有关保留期的错误。 如果您提供的不是 1 到 30 之间的值，可能也会看到错误。 允许对保持期使用的值为 1 到 30 之间的数字。

2. 电子邮件通知错误：

   错误：“未启用数据库邮件...” - 如果启用电子邮件通知，但未在实例上配置数据库邮件，将看到此错误。 必须在 实例上配置数据库邮件，以便能够接收有关 Microsoft Azure SQL Server托管备份的运行状况状态的通知。 有关如何启用数据库邮件的信息，请参阅配置数据库邮件。 要使用数据库邮件接收通知，您还必须启用 SQL Server 代理。 有关详细信息，请参阅 开始之前。

   以下是可能看到的与电子邮件通知关联的错误编号的列表：

   • ErrorNumber： 45209

   • ErrorNumber： 45210

   • ErrorNumber：45211

3. 连接错误：

   • 与 SQL 连接相关的错误：当连接到 SQL Server 实例时，会发生这些错误。 扩展事件通过管理通道公开这些类型的错误。 以下是两个扩展事件，对于与此类型的连接问题相关的错误，可能看到这些扩展事件：

     FileRetentionAdminXEvent，其 event_type 为 SqlError。 有关此错误的详细信息，请查看该事件的 error_code、error_message 和 stack_trace。 error_code是 SqlException 的错误号。

     具有以下消息/消息前缀的 SmartBackupAdminXevent：

     “例如，配置SQL Server Azure 的托管备份默认设置时发生内部错误。 该错误可能是暂时性的。”

     “可能正在遇到 SQL Server 连接问题。 正在当前迭代中跳过数据库。”

     “查询日志使用情况信息失败。 该故障可能是暂时性的。 正在当前迭代中跳过数据库。”

     “加载 SSMBackup2WA 代理元数据时遇到了 SQL 异常。 该故障可能是暂时性的。 将重试该操作。”

     “SSMBackup2WA 在..."

   • 连接到存储帐户出错：

     在 event_type 为 XstoreError 的 FileRetentionAdminXEvent 中报告存储异常。 有关此错误的详细信息，请查看该事件的 error_message 和 stack_trace。

     由于 SQL Server 托管备份使用基础的“备份到 URL”技术，因此与存储连接相关的错误同时适用于两个功能。 有关故障排除步骤的详细信息，请参阅SQL Server备份到 URL 最佳做法和故障排除文章的故障排除部分。

排除系统问题

下面是系统 (SQL Server出现问题、SQL Server 代理) 及其对SQL Server托管备份到 Microsoft Azure 的影响时的一些情况：

• SQL Server Microsoft Azure 托管备份正在运行时，Sqlservr.exe停止响应或停止工作：如果SQL Server停止工作，SQL 代理将正常关闭，SQL Server Microsoft Azure 的托管备份也会停止，并将事件记录在 SQL Agent.out 文件中。

  如果 SQL Server 停止响应，则在管理通道中记录事件。 事件日志的一个示例：

  SQL 错误（引擎未响应或收到 sqlException: SqlException:
  管理通道 xevent 中将显示错误代码、消息和堆栈跟踪以及某些额外信息，如：
  “可能正在遇到 SQL Server 连接问题。 在当前迭代中跳过数据库”

• 运行SQL Server托管备份到 Microsoft Azure 时，SQL 代理停止响应或停止工作：

  如果 SQL 代理停止工作，SQL Server托管备份到 Microsoft Azure 也会停止，并在管理通道中记录事件。 这与 SQL Server 停止响应时的场景类似。

  如果 SQL 代理停止响应，SQL Server托管备份到 Microsoft Azure 将无法继续执行备份操作，并且事件会记录在管理通道中。 事件日志的一个示例：

  作业挂起: 请参阅管理通道 xevents
  数据库备份的“+ Constants.DBBackupInfoMsgMaxWaitTime + ”小时内未从SQL Server收到进度更新。 SSM 云备份将继续等待。”

如果已启用电子邮件通知，则会收到一条通知，其中包括 备份循环数 和 保留循环数。 如果通知中返回的其中一列的值为零或两列的值都为零，则可能表示系统未响应。

警告

生成报表结果的内部进程，假设引擎诊断日志与 SQL 代理错误日志处于同一位置，默认为在 SQL Server 实例的错误日志所在的文件夹中。 如果引擎诊断日志移到与 SQL 代理错误日志位置不同的位置，系统就找不到智能备份诊断日志，电子邮件通知中的报表也就可能不正确。 例如，你可能会在报告的所有字段中看到 值 0 ，包括备份循环数和保留循环数。 在这种情况下，诊断日志已移动到其他位置，这不表示系统不响应，只是系统找不到日志。 首先应确保诊断日志的位置和 SQL 代理错误日志处于同一位置。 若要验证诊断日志的当前位置，可以使用 sys.dm_os_server_diagnostics_log_configurations。 该 path 列返回引擎诊断日志的当前位置。 它应与 SQL 代理错误日志位于同一文件夹中。 使用 dbo.sp_get_sqlagent_properties 存储过程可以获取 SQL 代理错误日志路径。

检查扩展事件日志以了解错误的详细信息。 修复错误或重新启动 SQL Server Agent 以更正该状况。