sql-server - Azure SQL 连接超时

Question

好的，为了将我的应用程序移至云中，我已将本地 SQL 数据库移至 Azure SQL。问题是与新的 Azure SQL 数据库的连接非常“不稳定”，我打算将其带回内部。

任务是循环并在数据库中创建总共约 481K 条记录。

连接字符串是

"Server=tcp:xxx,1433;Initial Catalog=xx;Persist Security Info=False;User ID=xx;MultipleActiveResultSets=True;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;ConnectRetryCount=255;"

它每次运行的SQL查询并不复杂。只需将三个值插入三列即可。 (更改列和值以保护某些内部工作)

Insert Into TheTable (C1, C2, C3) VALUES ('V1', 'V2', 'V3')

但在随机点它会抛出这个。

System.ComponentModel.Win32Exception (0x80004005): 等待操作超时执行超时已过期。操作完成之前超时时间已过，或者服务器未响应。在System.Data.SqlClient.SqlConnection.OnError(SqlException异常， bool breakConnection，Action1wrappCloseInAction)在System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj， bool callerHasConnectionLock， bool asyncClose) 在System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior，SqlCommand cmdHandler，SqlDataReader dataStream，BulkCopySimpleResultSetbulkCopyHandler，TdsParserStateObject stateObj，Boolean＆dataReady) 在 System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(字符串方法名称， bool 异步，Int32 超时， bool asyncWrite) 在 System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource1 完成，字符串 methodName， bool 值 sendToPipe，Int32 超时， bool 值&usedCache， bool 值 asyncWrite， bool 值 inRetry) 在 System.Data.SqlClient.SqlCommand.ExecuteNonQuery() 位于 D:\PATHOFTHEFILE 中的 XX:第 420 行

请注意

1) 每次创建记录并在下一步中关闭它时，我都会打开和关闭连接。

2)除了我之外没有其他人访问数据库。

3) 为S1设置数据库服务。

4) 是的 - 讽刺的是，程序在第 420 行崩溃了。我正在尝试寻找对代码进行药物测试的方法。

问题

1) 我的连接字符串有问题吗？该文档指出，在连接到 Azure SQL 数据库时，我应该使用 30 的超时。坦率地说，当我将超时设置为 0 时，代码运行得更好(或者至少生命周期更长)。

2) 首先，我尝试使用单个连接来处理整个 481K INSERT 语句的循环。这是一个糟糕的设计吗？ Azure SQL 可靠性将保持连接多长时间？

3) 我对在 Azure SQL 上构建坚如磐石的应用程序的能力没有一种温暖的模糊感觉。有人可以给我指点一个关于本地 SQL 构建与 Azure SQL 构建之间差异的好引用吗？我已经查遍了所有能找到的东西，但似乎没有那么多。

4) 我喜欢可以使用 MMC 连接到 Azure SQL。但(一般来说)我无法再从 MMC 获取各种监控信息。任何人都有一个链接，可以帮助我真正了解数据库中发生的情况，而无需使用那个可怕的 Azure 门户

更新#1

被指控有罪

public static void RunSQL(string SQLString)
        {

        int a = 0;

        SqlCommand Command = new SqlCommand(SQLString, TheConnection);
        try
            {
            a = Command.ExecuteNonQuery();
            }
        catch (Exception ex)
            {

            Notifications.EventLogging.ProcessEvent(SQLString + " go boom " + ex.InnerException + ex.Message + ex.StackTrace);
            Notifications.EventLogging.ProcessEvent("Time Of Death" + DateTime.Now);
            Console.ReadKey();

            }

Answer 1

Azure SQL 实例托管在共享基础架构上。 Azure 将限制请求以确保服务器上的所有实例都能满足最低 SLA。在这一生中，死亡和纳税是有保障的，但 Azure SQL 连接却不然。

为了解决这个问题，您需要自动重试。多年来，Microsoft 提供了一些选项，从现已弃用的 ReliableSqlConnection 类开始。如今与 Azure SQL 交互的首选方式是使用 Entity Framework 6.x，它内置了自动重试功能。

实际上，流量较小且零星的 Azure SQL 数据库很少会遇到限制事件。我有一些开发人员 friend ，他们部署了访问 Azure SQL 数据库的生产代码，使用原始 SqlConnections 和 SqlCommands，当我告诉他们无法保证连接时，他们似乎真的感到惊讶。他们绝对不会遇到它!但如果你的服务器崩溃了(就像你正在做的那样)，我已经看到这种情况的发生足以引起人们的注意。

编辑 12-6-2018:过去几个月我自己也遇到过这个问题。梳理日志后，罪魁祸首是数据库流量激增，超出了我的 SQL Server 的 DTU 限制。在这种情况下，重试不一定是足够的解决方案，因为自动重试会有效地阻塞 SQL DB。要检查并查看您是否成为 DTU 限制的受害者，请转到 Azure SQL DB 的“概述”选项卡，查看资源利用率图表，并确保选择“最大值”作为指标。它默认为 Avg，这可以隐藏 DTU 流量中的峰值。

编辑 2019 年 8 月 6 日:如果您的 DTU 已达到上限并想知道是什么原因造成的，可以在 Azure 门户中的 Azure SQL 管理边栏选项卡上查看以下几个位置:

1. 查询性能洞察。您可以使用此处的工具来查找在给定时间段内运行的最消耗资源的查询。这是一个很好的起点。确保检查所有指标。
2. 性能建议。如果您缺少索引，它可能会列在此处。
3. 指标。检查所有列出的内容。确保将聚合设置为“最大”。

这应该为您提供良好(甚至很好)的错误指示。