Azure SQL连接正在计时

好吧，为了将我的应用程序移到云端，我将本地SQL数据库移到了Azure SQL中。问题是，与新的Azure SQL数据库的连接是如此'flakey'，我即将把它带回家。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异常，布尔breakConnection，动作1 wrapCloseInAction) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady) at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async, Int32 timeout, Boolean asyncWrite) at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource 1次完成，字符串方法名，布尔sendToPipe，的Int32超时，布尔& usedCache，布尔asyncWrite，布尔inRetry）在System.Data.SqlClient.SqlCommand .ExecuteNonQuery（）在XX中d：\ PATHOFTHEFILE：线420

注意

1）我打开和每个I创建记录时间关闭连接并在下一步骤关闭它。

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(); 

      }

来源

2017-02-22 TRH

您是否使用SqlConnections和SqlCommands连接到数据库？如果是这样，我相信我确切地知道你的问题是什么。 –

有罪负责 - 请参阅我上面的实际代码在更新＃1 – TRH

Azure的SQL实例托管在共享基础架构上Azure会限制请求以确保服务器上的所有实例都能达到最低SLA。在这一生中，死亡和税收都是有保证的，但Azure SQL连接不是。

要解决这个问题，您需要自动重试。多年来，微软提供了几个选项，从现在已弃用的ReliableSqlConnection类开始。目前与Azure SQL交谈的首选方式是使用实体框架6.x，该框架内置了自动重试功能。

实际上，看到光线和偶发流量的Azure SQL数据库很少会看到一个节流事件。我曾经有过部署生产代码的开发者朋友使用了原始的SqlConnections和SqlCommands，并且当我告诉他们连接不能保证时，似乎真的很惊讶。他们从未穿过它！但是如果你从服务器上下了地狱（正如你所做的那样），我发现它足以引起人们的注意。

切换到EF6，这将被照顾。

来源

2017-02-22 01:56:28

好的，我明白了。但是我正在看DTU的这个服务器实例（S1），它似乎没有超过可用DTU的20％-30％。我认为在Azure开始查杀连接之前，DTU必须达到100％。我的意思是，毕竟，我们有不同的DTU级别来适应不同级别的服务器冲击 - 对吗？作为一个短期修复，我会尝试一个Thread.Sleep之间的迭代，看看是否减轻负载。但我会尝试EF转换作为我的周末项目。 – TRH

请记住，“DTU”是由Microsoft未提供的其他几个度量标准组成的度量标准。仅仅因为DTU不被钉住并不意味着你没有被限制。这是一个涉及EF的能力和使用Azure SQL时需要的页面：https://msdn.microsoft.com/en-us/library/dn456835(v=vs.113).aspx –

是的，那是我的恐惧 - 我盯着组成DTU的未定义参数之一，而没有在整个DTU范围内出现它。我会让你的链接在本周末阅读。 – TRH

Azure SQL连接正在计时

回答

相关问题