Была ли эта страница полезной?
Ваш отзыв об этом контенте важен для нас. Расскажите нам о том, что вы думаете.
Дополнительный отзыв?
1500 символов осталось
MSDN Library

Рекомендации по предотвращению отклонения запросов и завершения соединений в базе данных SQL Azure

Обновлено: Июль 2015 г.

Чтобы предотвратить отказы в запросе и прекращения соединений в База данных SQL Azure, следует правильно управлять ресурсами приложения в приложениях базы данных SQL. Чтобы обеспечить нормальное продолжение работы пользователя в случае разрыва соединения, повторно установите подключение и повторно выполните незавершенную команду или запрос. В следующих разделах приводится список рекомендаций по написанию кода для подключения к базе данных SQL. Эти рекомендации по написанию кода мало отличаются от рекомендаций, относящихся к локальному SQL Server.

Шлюз потока табличных данных базы данных SQL повторно пытается установить соединения в течение 30 секунд, прежде чем сообщить об ошибке. Если ожидается большой объем трафика в приложении, реализуйте в приложении логику повторных попыток. Если соединение завершается ошибкой, выполните следующие действия.

  • Обрабатывайте простой и временные отключения.

    noteПримечание
    Установите обновление надежности 1 для .NET Framework 4.0, исправляющее проблему с возвратом SqlClient мертвых соединений приложению. С этим обновлением SqlClient проверяет, не мертво ли соединение в пуле, прежде чем вернуть его приложению. Если соединение мертво, SqlClient возобновляет соединение и лишь затем передает его приложению. Подробную информацию об этой проблеме см. в разделе Минимизация ошибок пула соединений в базе данных SQL.

  • Приложение должно пытаться подключиться к базе данных SQL с интервалами в 10 секунд, чтобы ресурсы стали доступны и подключение было восстановлено. В зависимости от приложения, баз данных и рабочей нагрузки сети время задержки можно увеличить.

  • Если соединение снова прерывается, измените рабочую нагрузку. Если соединение продолжает прерываться, обратите внимание на код ошибки, выясните настоящую проблему и затем попытайтесь изменить рабочую нагрузку. Для снижения рабочей нагрузки можно реализовать в клиентском приложении очередь или механизм задержки.

    Другим решением может быть перепроектирование приложения и базы данных для устранения узких мест. Убедитесь, что приложение не перегружает tempdb частыми операциями DDL и DML. Кроме того, убедитесь, что транзакции не блокируют никаких ресурсов. Когда это уместно, секционируйте базу данных на несколько баз данных.

  • Убедитесь, что код может восстанавливаться после регулирования. Пользователи должны предполагать, что соединения могут разорваться в приложении в любое время. В связи с этим по возможности выполняйте пакетные запросы в рамках одной транзакции. Это минимизирует случаи частичного завершения пакета с приведением базы данных в неожиданное или непротестированное состояние. Для этого может понадобиться использовать инструкции BEGIN TRANS/COMMIT TRANS для каждого нерегламентированного пакета и в начале и в конце каждой хранимой процедуры.

  • Выясните, как логика повторных попыток влияет на правильность приложения (идемпотентность). При выполнении обновлений и вставок важно понимать, что случится, если соединение будет разорвано до получения сообщения об успехе. Если транзакция прерывается, верным решением будет повторить попытку соединения. Если же транзакция фиксируется, то повторный запуск транзакции будет некорректен. Пользователям, выполняющим изменения, не являющиеся идемпотентными, может понадобиться изменить логическую схему базы данных, чтобы получить возможность определять повторные фиксации транзакций, возникшие из-за логики повторных попыток, используемой для защиты от разрывов соединения.

Используйте код повтора для внесения в журнал ошибок регулирования. Это позволит различать синтаксис временного соединения, регулирования и аппаратного сбоя, отсутствие хранимых процедур и т. д. Это будет особенно полезно в сценариях устранения неполадок, когда подключиться к базе данных SQL невозможно. В этом случае меры по устранению неполадок будут отталкиваться от сведений в журнале, а вероятность эффективного устранения неполадок будет тем выше, чем выше качество внесенной в журнал информации. Дополнительные сведения о реализации ведения журналов в приложениях баз данных SQL см. в разделе Реализация ведения журналов для приложений базы данных SQL Azure.

См. также

Показ:
© 2015 Microsoft