排查 Azure SQL 数据库和 Azure SQL 托管实例的连接问题和其他问题

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

与 Azure SQL 数据库或 Azure SQL 托管实例连接失败时，你会收到错误消息。 连接问题可能由以下原因导致：重新配置、防火墙设置、连接超时、登录信息不正确，或无法在应用程序设计过程中应用最佳做法和设计准则。 此外，如果达到了某些 Azure SQL 数据库或 SQL 托管实例资源的最大限制，则无法再连接。

暂时性故障错误消息（40197、40613 等）

Azure 基础结构能够在 SQL 数据库服务中出现大量工作负荷时动态地重新配置服务器。 此动态行为可能会导致客户端程序失去其与数据库或实例的连接。 此类错误情况称为 暂时性故障。 之所以会发生数据库重新配置事件是因为，有计划内事件（例如，软件升级）或计划外事件（例如，进程故障或负载均衡）。 大多数重新配置事件的生存期通常较短，应在最多 60 秒内完成。 但是，这些事件偶尔可能需要更长时间才能完成，例如当大型事务导致长时间运行的恢复时。 下表列出了在连接到 Azure SQL 数据库时应用程序可能会收到的各种暂时性错误。

暂时性故障错误代码的列表

解决暂时性连接问题的步骤

1. 检查 Azure 服务仪表板在由应用程序报告错误期间是否发生任何已知的服务中断。
2. 连接到云服务的应用程序（如 Azure SQL 数据库）应预期会有定期重新配置事件并实施重试逻辑来处理这些错误，而不是向用户呈现应用程序错误。
3. 由于数据库即将达到其资源限制，因此错误看起来像是暂时性连接问题。 请参阅资源限制。
4. 如果连接问题继续存在，或者应用程序发生错误的持续时间超过 60 秒或在特定的一天中看到错误多次发生，请通过在 Azure 支持网站上选择“获取支持”提出 Azure 支持请求。

实现重试逻辑

强烈建议客户端程序包含重试逻辑，以便它可以提供一段时间来让暂时性故障纠正自身，并尝试重建连接。 我们建议在第一次重试前延迟 5 秒钟。 如果在少于 5 秒的延迟后重试，云服务有超载的风险。 对于后续的每次重试，延迟应以指数级增大，最大值为 60 秒。

有关重试逻辑的代码示例，请参阅：

• 使用 ADO.NET 弹性连接到 SQL
• 使用 PHP 弹性连接到 SQL

有关在应用程序中处理暂时性错误的其他信息，请查看排查 SQL 数据库的暂时性连接错误

连接池 (ADO.NET) 中提供了有关使用 ADO.NET 的客户端的阻塞期的说明。

与服务器建立连接时，出现网络相关或特定于实例的错误

如果应用程序无法连接到服务器，则会出现此问题。

若要解决此问题，请尝试执行解决常见连接问题的步骤部分所述的步骤（按所述顺序执行）。

找不到或无法访问服务器/实例（错误 26、40、10053）

错误 26：查找指定的服务器时出错

System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.(provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)

错误 40：无法与服务器建立连接

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

错误 10053：在接收来自服务器的结果时发生传输级错误

10053: A transport-level error has occurred when receiving results from the server. (Provider: TCP Provider, error: 0 - An established connection was aborted by the software in your host machine)

如果应用程序无法连接到服务器，则会出现这些问题。

若要解决这些问题，请尝试执行解决常见连接问题的步骤部分所述的步骤（按所述顺序执行）。

由于防火墙问题而无法连接到服务器

错误 40615：无法连接到 <服务器名称>

若要解决此问题，请通过 Azure 门户在 SQL 数据库上配置防火墙设置。

错误 5：无法连接到 <服务器名称>

若要解决此问题，请在客户端与 Internet 之间的所有防火墙上，确保为出站连接打开端口 1433。

无法登录到服务器（错误 18456、40531）

用户“<用户名>”登录失败

Login failed for user '<User name>'.This session has been assigned a tracing ID of '<Tracing ID>'. Provide this tracing ID to customer support when you need assistance. (Microsoft SQL Server, Error: 18456)

若要解决此问题，请让服务管理员为你提供有效的用户名和密码。

服务管理员通常可使用以下步骤添加登录凭据：

1. 使用 SQL Server Management Studio (SSMS) 登录到服务器。

2. 在 master 数据库中运行以下 SQL 查询，检查是否已禁用该登录名：

   SELECT name, is_disabled FROM sys.sql_logins;
   

3. 如果禁用了相应的名称，请使用以下语句来启用它：

   ALTER LOGIN <User name> ENABLE;
   

4. 如果 SQL 登录用户名不存在，请编辑并运行以下 SQL 查询，以创建新的 SQL 登录名：

   CREATE LOGIN <SQL_login_name, sysname, login_name>
   WITH PASSWORD = '<password, sysname, Change_Password>';
   GO
   

5. 在“SSMS 对象资源管理器”中，展开“数据库”。

6. 选择要授予用户权限的数据库。

7. 右键单击“安全性”，然后选择“新建”、“用户” 。

8. 在带有占位符的生成的脚本（下方显示了示例）中，按此处的步骤替换模板参数，并执行它：

   CREATE USER [<user_name, sysname, user_name>]
   FOR LOGIN [<login_name, sysname, login_name>]
   WITH DEFAULT_SCHEMA = [<default_schema, sysname, dbo>];
   GO
   
   -- Add user to the database owner role
   EXEC sp_addrolemember N'db_owner', N'<user_name, sysname, user_name>';
   GO
   

   也可使用 sp_addrolemember 将特定的用户映射到特定的数据库角色。

   注意

   在 Azure SQL 数据库中，考虑使用更新的 ALTER ROLE 语法来管理数据库角色成员身份。

有关详细信息，请参阅在 Azure SQL 数据库中管理数据库和登录名。

连接超时过期错误

System.Data.SqlClient.SqlException (0x80131904)：连接超时过期

System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=3; handshake=29995;

System.Data.SqlClient.SqlException (0x80131904)：超时过期

System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

System.Data.Entity.Core.EntityException：基础提供程序在打开时失败

System.Data.Entity.Core.EntityException: The underlying provider failed on Open. -> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. -> System.ComponentModel.Win32Exception: The wait operation timed out

无法连接到 <服务器名称>

Cannot connect to <server name>.ADDITIONAL INFORMATION:Connection Timeout Expired. The timeout period elapsed during the post-login phase. The connection could have timed out while waiting for server to complete the login process and respond; Or it could have timed out while attempting to create multiple active connections. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=231; handshake=983; [Login] initialization=0; authentication=0; [Post-Login] complete=13000; (Microsoft SQL Server, Error: -2) For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=-2&LinkId=20476 The wait operation timed out

这些异常可能是连接或查询问题造成的。 若要确认此错误是否由连接问题造成，请参阅确认错误是否由连接问题造成。

发生连接超时的原因是应用程序无法连接到服务器。 若要解决此问题，请尝试执行解决常见连接问题的步骤部分所述的步骤（按所述顺序执行）。

网络连接终止错误

SQL 客户端库使用 TCP 网络协议连接到 Azure SQL 数据库和 Azure SQL 托管实例。 客户端库使用名为 TCP 提供程序的较低级别组件来管理 TCP 连接。 当 TCP 提供程序检测到远程主机意外终止了现有 TCP 连接时，客户端库将引发错误。 由于该错误是客户端错误，而不是 SQL Server 错误，因此不包含 SQL 错误号。 而是错误号为 0，并使用来自 TCP 提供程序的错误消息。

网络连接终止错误的示例包括：

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) An existing connection was forcibly closed by the remote host

A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

The client was unable to establish a connection because of an error during connection initialization process before login. Possible causes include the following: the client tried to connect to an unsupported version of SQL Server; the server was too busy to accept new connections; or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

由于数据库或弹性池暂时不可用，可能会发生连接终止错误。 由于数据库服务器和客户端应用程序之间的网络基础结构中存在各种问题（包括防火墙、网络设备等），也可能发生这些错误。这些问题可能是暂时性的，也可能是永久性的。 作为一般指导，应用程序应在将这些错误视为永久失败之前，对这些错误使用固定次数的重试尝试。

资源调控错误

Azure SQL 数据库使用基于资源调控器的资源治理实现来强制实施资源限制。 详细了解 Azure SQL 数据库中的资源管理。

首先列出最常见的资源治理错误及其详细信息，然后是资源治理错误消息表。

错误 10928 和 10936：资源 ID：1。 [数据库或弹性池] 的请求限制为 %d，现已达到该限制

如果达到数据库级别限制，则本例中的详细错误消息如下：Resource ID : 1. The request limit for the database is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.

如果达到弹性池限制，则此情况下的详细错误消息如下：Resource ID : 1. The request limit for the elastic pool is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance. 弹性池限制高于数据库限制，有关详细信息，请参阅资源限制。 当池中的多个数据库同时使用某个资源（例如辅助角色）时，可能会达到这些限制。

此错误消息指示已达到数据库或弹性池的辅助角色限制。 数据库或弹性池的服务目标的最大并发辅助角色值将存在，而不是占位符 %d。

如果需要，使用专用管理员连接 (DAC) 进行连接

如果在接近或达到工作线程限制的情况下正在进行实时事件，则在使用 SQL Server Management Studio (SSMS) 或 Azure Data Studio 连接时可能会收到错误 10928。 即使已达到最大工作线程阈值，一个会话也可以使用用于数据库管理员的诊断连接 (DAC) 进行连接。

要从 SSMS 建立与 DAC 的连接：

• 从菜单中，选择“文件”“新建”>“数据库引擎查询”
• 从“服务器名称”字段中的连接对话框中，输入 admin:<fully_qualified_server_name>（类似于 admin:servername.database.chinacloudapi.cn）。
• 选择“选项”
• 选择“连接属性”选项卡
• 在“连接到数据库:”框中，键入数据库的名称
• 选择“连接”。

如果您收到错误 40613 Database '%.*ls' on server '%.*ls' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '%.*ls'，这可能表示另一个会话已连接到 DAC。 一次只能有一个会话连接到单个数据库或弹性池的 DAC。

如果在选择“连接”后遇到错误“连接到服务器失败”，若是你使用的是 SSMS 18.9 之前的版本，则可能仍然成功建立了 DAC 会话。 SSMS 的早期版本试图提供 Intellisense 与 DAC 的连接。 但失败了，因为 DAC 只支持一个工作线程，而 Intellisense 需要一个单独的工作线程。

不能将 DAC 连接与对象资源管理器一起使用。

查看 max_worker_percent 使用情况

要查找数据库 14 天的资源消耗统计信息，请查询 sys.resource_stats 系统目录视图。 max_worker_percent 列显示已使用的工作线程相对于数据库的工作线程限制的百分比。 连接到你的逻辑服务器上的 master 数据库以查询 sys.resource_stats。

SELECT start_time, end_time, database_name, sku, avg_cpu_percent, max_worker_percent, max_session_percent 
FROM sys.resource_stats;

您还可以从 sys.dm_db_resource_stats 动态管理视图中查询过去一小时内的资源消耗统计信息。 直接连接到您的数据库查询 sys.dm_db_resource_stats。

SELECT end_time, avg_cpu_percent, max_worker_percent, max_session_percent
FROM sys.dm_db_resource_stats;

尽可能降低工作线程使用率

链阻塞会导致数据库中工作线程数量的激增。 大量的并发并行查询可能会导致大量的工作线程。 提高最大并行度 (MAXDOP) 或将 MAXDOP 设置为零都可以增加活动工作线程的数量。

按照以下步骤对工作线程不足的事件进行会审：

1. 调查是否正在发生阻塞，或者你是否可以确定大量并发工作线程。 数据库返回错误 10928 时，请运行以下查询以检查当前请求并检查是否发生阻塞。 您可能需要使用专用管理员连接 (DAC) 进行连接才能执行该查询。

   SELECT
       r.session_id, r.request_id, r.blocking_session_id, r.start_time, 
       r.status, r.command, DB_NAME(r.database_id) AS database_name,
       (SELECT COUNT(*) 
           FROM sys.dm_os_tasks AS t 
           WHERE t.session_id=r.session_id and t.request_id=r.request_id) AS worker_count,
       i.parameters, i.event_info AS input_buffer,
       r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
       r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
   FROM sys.dm_exec_requests as r
   JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
   OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
   WHERE s.is_user_process=1;
   GO
   

   1. 查找包含 blocking_session_id 的行，以确定阻塞的会话。 在列表中查找每个 blocking_session_id，以确定该会话是否也发生阻塞。 这最终将导致出现头阻塞程序。 优化最前面的阻塞查询。

      注意

      有关对长期运行的查询或阻塞的查询进行故障排除的详细信息，请参阅了解并解决 Azure SQL 数据库的阻塞问题。

   2. 要识别大量并发工作线程，请查看总体请求数和每个请求的 worker_count 列。 Worker_count 是采样时的工作线程数量，并且可能随着请求的执行不断变化。 如果增加工作线程的原因是为了以最佳并行度运行的并发查询，则调整查询以降低资源利用率。 有关详细信息，请参阅查询优化/提示。

2. 评估数据库的最大并行度 (MAXDOP) 设置。

提高工作线程上限

如果即使解决了阻塞、优化了查询并验证了 MAXDOP 设置，但数据库或弹性池始终达到其辅助角色限制，请考虑纵向扩展数据库或弹性池以提高辅助角色上限。

根据服务层和计算大小，查找 Azure SQL 数据库的资源限制：

• 使用 vCore 购买模型的单一数据库的资源限制
• 使用 vCore 购买模型的弹性池的资源限制
• 使用 DTU 购买模型的单一数据库的资源限制
• 使用 DTU 购买模型的弹性池的资源限制

详细了解工作线程的 Azure SQL 数据库资源治理。

错误 10929：资源 ID：1

10929: Resource ID: 1. The %s minimum guarantee is %d, maximum limit is %d and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database. See http://go.microsoft.com/fwlink/?LinkId=267637 for assistance. Otherwise, please try again later.

错误 40501：服务当前繁忙

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: %ls. Code: %d.

这是一个引擎限制错误，表示超过了资源限制。

有关资源限制的更多信息，请参阅逻辑 SQL 服务器资源限制。

错误 40544：数据库已达到其大小配额

40544: The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions. Incident ID: <ID>. Code: <code>.

当数据库达到其大小配额时会发生此错误。

以下步骤可帮助你解决此问题，或提供更多的选项：

1. 使用 Azure 门户中的仪表板检查数据库的当前大小。

   注意

   若要识别哪些表消耗了最多的空间，因此确定可能需要清理哪些表，请运行以下 SQL 查询：

   SELECT o.name,
    SUM(p.row_count) AS 'Row Count',
    SUM(p.reserved_page_count) * 8.0 / 1024 AS 'Table Size (MB)'
   FROM sys.objects o
   JOIN sys.dm_db_partition_stats p on p.object_id = o.object_id
   GROUP BY o.name
   ORDER BY [Table Size (MB)] DESC;
   GO
   

2. 如果当前大小未超过所用版本支持的最大大小，你可以使用 ALTER DATABASE 来增大 MAXSIZE 设置。

3. 如果数据库已超过所用版本支持的最大大小，请尝试以下一个或多个步骤：

   • 执行一般的数据库清理活动。 例如，使用截断/删除操作清理不需要的数据，或者使用 SQL Server Integration Services (SSIS) 或批量复制程序 (bcp) 实用工具移出数据。
   • 请将数据分区或删除、删除索引或查阅文档以找到可能的解决方案。
   • 有关数据库缩放的信息，请参阅缩放单一数据库资源和缩放弹性池资源。

错误 40549：存在长时间运行的事务，因此已终止会话

40549: Session is terminated because you have a long-running transaction. Try shortening your transaction.

如果反复出现此错误，请尝试执行以下步骤来解决问题：

1. 运行以下查询，看看任何打开的会话中的 duration_ms 列是否具有较高的值：

   SELECT
       r.start_time, DATEDIFF(ms,start_time, SYSDATETIME()) as duration_ms, 
       r.session_id, r.request_id, r.blocking_session_id,  
       r.status, r.command, DB_NAME(r.database_id) AS database_name,
       i.parameters, i.event_info AS input_buffer,
       r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
       r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
   FROM sys.dm_exec_requests as r
   JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
   OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
   WHERE s.is_user_process=1
   ORDER BY start_time ASC;
   GO
   

   您可以选择忽略以下行：其中的 input_buffer 列显示从 sys.fn_MSxe_read_event_stream 读取的查询：这些请求与扩展事件会话相关。

2. 查看 blocking_session_id 列以查看阻塞是否会导致事务长时间运行。

   注意

   有关故障排除 Azure SQL 数据库中阻塞的详细信息，请参阅了解并解决 Azure SQL 数据库阻塞问题。

3. 请考虑批量处理查询。 有关批处理的信息，请参阅如何使用批处理来改善 SQL 数据库应用程序的性能。

错误 40551：由于过度使用 tempdb，已终止会话

40551: The session has been terminated because of excessive TEMPDB usage. Try modifying your query to reduce the temporary table space usage.

若要解决此问题，请执行以下步骤：

1. 更改查询以减少临时表空间的用量。
2. 删除不再需要的临时对象。
3. 截断表，或删除未使用的表。

错误 40552：由于过度使用事务日志空间，已终止会话

40552: The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.

若要解决此问题，请尝试执行以下方法：

• 此问题可能是插入、更新或删除操作造成的。 通过立即实施批处理或拆分为多个较小的事务，来尝试减少操作的行数。
• 此问题可能是索引重建操作造成的。 若要解决此问题，请确保表中受影响的行数 * (所更新字段的平均字节大小 + 80) < 2 GB。
• 对于索引重建，所更新字段的平均大小应替换为平均索引大小。
• 有关详细信息，请参阅排查 Azure SQL 数据库中的已满事务日志错误和排查 Azure SQL 托管实例中的已满事务日志错误。

错误 40553：由于过度使用 内存，已终止会话

40553: The session has been terminated because of excessive memory usage. Try modifying your query to process fewer rows.

若要解决此问题，请尝试优化查询。

有关详细的故障排除过程，请参阅我的查询是否在云中正常运行？。

有关其他内存不足错误和示例查询的详细信息，请参阅排查 Azure SQL 数据库的内存不足错误。

资源管理错误消息表

弹性池错误

以下错误与创建和使用弹性池有关：

无法打开登录名请求的数据库 "master"。 登录失败

发生此问题的原因是帐户无权访问 master 数据库。 但在默认情况下，SQL Server Management Studio (SSMS) 会尝试连接到 master 数据库。

若要解决此问题，请执行以下步骤：

1. 在 SSMS 的登录屏幕上选择“选项”，然后选择“连接属性”。

2. 在“连接到数据库”字段中，输入用户的默认数据库名称作为默认登录数据库，然后选择“连接” 。

   

只读错误

如果尝试向一个处于只读状态的数据库写入，会收到错误消息。 在某些情况下，数据库处于只读状态的原因可能不会立即明了。

错误 3906：无法更新数据库 "DatabaseName"，因为数据库是只读的。

尝试修改一个处于只读状态的数据库时，将引发以下错误。

Msg 3906, Level 16, State 2, Line 1
Failed to update database "%d" because the database is read-only.

你可能已连接到只读副本

对于 Azure SQL 数据库和 Azure SQL 托管实例，你可以连接到只读副本上的数据库。 在本例中，使用 DATABASEPROPERTYEX() 函数的以下查询将返回 ：

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');
GO

如果要使用 SQL Server Management Studio 进行连接，请验证是否已在连接选项的“其他连接参数”选项卡中指定了 ApplicationIntent=ReadOnly。

如果是使用连接字符串从应用程序或客户端进行连接，请验证连接字符串是否指定了 ApplicationIntent=ReadOnly。 有关详细信息，请参阅连接只读副本。

数据库可能被设置为只读

如果你使用的是 Azure SQL 数据库，则数据库本身可能已被设置为只读。 可以通过以下查询来验证数据库的状态：

SELECT name, is_read_only
FROM sys.databases
WHERE database_id = DB_ID();

可以使用 ALTER DATABASE Transact-SQL 在 Azure SQL 数据库中修改数据库的只读状态。 目前不能将托管实例中的数据库设置为只读。

确认错误是否由连接问题造成

若要确认某个错误是否由连接问题造成，请查看帧的堆栈跟踪，其中会显示打开连接的调用，如下所示（请注意对 SqlConnection 类的引用）：

System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
 at System.Data.SqlClient.SqlConnection.Open()
 at AzureConnectionTest.Program.Main(String[] args)
ClientConnectionId:<Client connection ID>

如果异常是由查询问题触发的，则你会看到如下所示的调用堆栈（请注意对 SqlCommand 类的引用）。 对于这种情况，请优化查询。

  at System.Data.SqlClient.SqlCommand.ExecuteReader()
  at AzureConnectionTest.Program.Main(String[] args)
  ClientConnectionId:<Client ID>

有关优化性能的更多指导，请参阅以下资源：

• 如何维护 Azure SQL 索引和统计信息
• 手动优化 Azure SQL 数据库中的查询性能
• 使用动态管理视图监视 Azure SQL 数据库的性能
• 在 Azure SQL 数据库中操作 Query Store

解决常见连接问题的步骤

1. 确保已在应用程序服务器上启用 TCP/IP 作为客户端协议。 有关详细信息，请参阅配置客户端协议。 在未安装 SQL 工具的应用程序服务器上，运行 cliconfg.exe（SQL Server 客户端网络实用工具）来验证是否已启用 TCP/IP。

2. 检查应用程序的连接字符串，确保配置正确。 例如，确保连接字符串指定了正确的端口 (1433) 和完全限定的服务器名称。 请参阅获取连接信息。

3. 尝试增大连接超时值。 我们建议至少使用 30 秒连接超时。

4. 使用 SQL Server Management Studio (SSMS)、UDL 文件、ping 或 telnet 来测试应用程序服务器与 Azure SQL 数据库之间的连接。 有关详细信息，请参阅排查连接问题和连接问题的诊断。

   注意

   作为故障排除步骤，还可以在不同的客户端计算机上测试连接。

5. 最佳做法是确保实施重试逻辑。 有关重试逻辑的详细信息，请参阅排查 SQL 数据库的暂时性故障和连接错误。

如果这些步骤无法解决问题，请尝试收集更多的数据，然后联系支持人员。 如果应用程序是云服务，请启用日志记录。 此步骤会返回发生失败时的 UTC 时间戳。 此外，SQL 数据库会返回跟踪 ID。 Azure 客户支持服务可使用此信息。

有关如何启用日志记录的详细信息，请参阅为 Azure 应用服务中的应用启用诊断日志记录。

后续步骤

通过以下文章详细了解相关主题：

• Azure SQL 数据库连接体系结构
• Azure SQL 数据库和 Azure Synapse Analytics 网络访问控制
• 排查 Azure SQL 数据库中的已满事务日志错误
• 排查 Azure SQL 托管实例中的已满事务日志错误
• 排查 SQL 数据库和 SQL 托管实例中的临时连接错误
• 分析和防止 Azure SQL 数据库中的死锁