导出 (0) 打印
全部展开

防止拒绝请求或终止连接的 Azure SQL Database 最佳做法

更新时间: 2013年7月

注:本页面内容可能不完全适用中国大陆地区运营的 Windows Azure服务。如要了解不同地区 Windows Azure 服务的差异, 请参考本网站.

若要在 Azure SQL Database 中避免请求被拒或连接终止,你必须在 SQL Database 应用程序中适当地管理应用程序资源。若要在连接关闭时提供顺畅的用户体验,请重新建立连接,然后重新执行失败的命令或查询。以下部分会提供一系列建议在连接 SQL Database 时采用的编码做法。这些建议的编码做法与和适用于本地 SQL Server 的编码做法相差不大。

在应用程序中实现重试逻辑

SQL Database TDS 网关会在报告失败前重试连接大约 30 秒。如果你预期会有很高的应用程序流量,则请在应用程序中构建重试逻辑。如果连接失败,请执行以下操作:

  • 处理闲置和暂时性断开。

    note注意
    安装 .NET Framework 4.0 可靠性更新 1,以修复 SqlClient 返回与应用程序之间的连接无效的问题。有了此项更新,SqlClient 会先检查池中的连接是否无效,然后再将它返回应用程序。如果连接无效,SqlClient 会先重新连接,然后再将它返回应用程序。有关此问题的详细信息,请参阅将 SQL Database 中的连接池错误最小化

  • 以 10 秒的间隔重试连接 SQL Database,直到资源可用并再次建立你的连接。根据应用程序、数据库和网络工作负载,你必须根据需要增加延迟时间。

  • 如果连接再次终止,请更改你的工作负载。如果连接再次终止,请查看错误代码,找出实际问题,然后尝试更改工作负载。你可以在客户端应用程序中实现队列或延迟机制来降低你的工作负载。

    另一种解决方案是重新设计应用程序和数据库,以消除资源瓶颈。请确保应用程序不会因为过多的 DDL 或 DML 操作而使 tempdb 过载。此外,请确保事务不会阻止任何资源。在适当情况下,请考虑将数据库分区为多个数据库。

  • 确定代码可以从限制中恢复。用户应该假设连接可以在应用程序中随时断开。因此,请尽可能在单个事务中进行批处理请求。这会使批处理部分完成和使数据库处于意外/未经测试状态的可能性降至最低。要这样做,你可能想要对每个即席批处理和在每个存储过程的开头/结尾执行 BEGIN TRANS/COMMIT TRANS。

  • 了解重试逻辑会如何影响应用程序的正确性(幂等性)。在执行更新或插入时,请务必了解连接中断时发生的情况,然后再返回成功。如果事务中止,则重试连接是正确的步骤。如果事务实际上已经提交,则再次运行事务可能不正确。执行非幂等性更改的用户可能需要修改他们的逻辑数据库架构,才能根据所用的重试逻辑检测重复的事务提交,以避免连接断开。

记录限制错误

使用重试代码来记录限制错误,以区分暂时性连接、限制和硬故障语法、缺少存储过程等。在你无法连接 SQL Database 时,这对故障排除特别有用。在这种情况下,故障排除工作将关注记录的信息;有效排除故障的能力将与所记录信息的质量相关。有关在 SQL Database 应用程序中实施日志记录的详细信息,请参阅为 Azure SQL Database 应用程序实现日志记录

另请参见

社区附加资源

显示:
© 2014 Microsoft