Azure SQL Connections Timing Out

Question

Хорошо, пытаясь переместить мое приложение в облако, я переместил локальную базу данных SQL в Azure SQL. Проблема в том, что подключение к этой новой базе данных Azure SQL настолько «чешуйчатое», что я собираюсь вернуть его в дом.

Задача состоит в том, чтобы создать и создать в базе данных всего около 481 тыс. Записей.

Строка соединения

"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 завершение, струнный имяМетод, Boolean, Int32 sendToPipe тайм-аут, Boolean & usedCache, булева asyncWrite, булева inRetry) в System.Data.SqlClient.SqlCommand .ExecuteNonQuery() в XX в D: \ PATHOFTHEFILE: линия 420

Обратите внимание, что

1) Я открываю и закрывая соединение каждый раз, когда я создаю запись и закрытие его на следующем шаге.

2) Нет никого, кто попал бы в базу данных, кроме меня.

3) Служба базы данных установлена ​​для S1.

4) Да, я получаю иронию в том, что программа рушится на линии 420. Я пытаюсь найти способы тестирования наркотиков на код.

Вопросы

1) Есть ли что-то не так с моей строки подключения? В документации говорится, что я должен использовать Timeout 30 при подключении к базе данных Azure SQL. Честно говоря, код работал лучше (или, по крайней мере, дольше), когда у меня был тайм-аут, установленный на 0.

2) Сначала я попытался использовать одно соединение для обработки цикла через все 481K инструкции INSERT. Это плохой дизайн? Как долго будет поддерживать надежность Azure SQL?

3) Я не получаю теплое нечеткое представление о способности создавать надежные приложения на Azure SQL. Может ли кто-то указать мне хорошую ссылку на разницу между построением для локального SQL и Azure SQL. Я прошел через все, что смог найти, и там, похоже, не так много.

4) Мне нравится, что я могу подключиться к Azure SQL с MMC. Но есть (в общем говоря) все виды информации о мониторинге, которые я больше не могу получить от MMC.Кто-нибудь есть ссылка на то, что может помочь мне действительно понять, что происходит в базе данных без использования этого страшного Azure Portal

UPDATE # 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 Connections - нет.

Чтобы справиться с этим, вам необходимо выполнить автоматическую повторную попытку. На протяжении многих лет Microsoft предоставила несколько вариантов, начиная с теперь устаревшего класса ReliableSqlConnection. В наши дни предпочтительным способом общения с Azure SQL является создание Entity Framework 6.x, в котором встроена автоматическая повторная попытка.

На практике база данных Azure SQL, которая видит легкий и спорадический трафик, редко видит событие дроссельной заслонки. У меня были друзья разработчиков, которые развернули производственный код, попав в базу данных Azure SQL, использовали необработанные SqlConnections и SqlCommands, и, казалось, искренне удивлялись, когда я сказал им, что соединения не гарантируются. Они никогда не столкнетесь с этим! Но если вы попадаете в ад с сервера (как вы это делаете), я видел, что это случается достаточно, чтобы быть заметным.

Переключитесь на EF6, и об этом позаботятся.