Ошибка SQL Azure.
У меня есть проблема, которая проявляется в следующем исключении на нашем сайте (asp.net):
Время ожидания истекло. Период ожидания, прошедший до завершения операция или сервер не отвечает. Заявление было прекращается.
Это также приводит к заявлениям о обновлении и вставке, которые никогда не завершаются в SMSS. При запросе: sys.dm_tran_locks
отсутствуют блокировки X или IX, и при запросе sys.dm_tran_active_transactions
или sys.dm_tran_database_transactions
нет транзакций.
Проблема присутствует для каждой таблицы в базе данных, но другие базы данных в одном экземпляре не создают проблемы. Продолжительность выпуска может быть от 2 минут до 2 часов и не происходит в какое-то определенное время суток.
База данных не заполнена.
В какой-то момент эта проблема не разрешилась сама, но я смог решить проблему, запросив sys.dm_exec_connections
найти самый длинный сеанс, а затем убить его. Странно, что соединение было 15 минут, но проблема блокировки присутствовала более 3 часов.
Есть ли что-нибудь еще, что я могу проверить?
ИЗМЕНИТЬ
В соответствии с Полом ниже. Я действительно отследил проблему, прежде чем он ответил. Я опубликую шаги, которые я использовал, чтобы понять это ниже, в случае, если они помогут кому-либо еще.
Следующие запросы выполнялись, когда присутствовал "период ожидания".
select * from sys.dm_exec_requests
Как мы видим, все запросы WAIT ждут на сеансе 1021, который является запросом на репликацию! TM Request
указывает на транзакцию DTC, и мы не используем распределенные транзакции. Вы также можете увидеть wait_type SE_REPL_COMMIT_ACK
, который снова подразумевает репликацию.
select * from sys.dm_tran_locks
Снова ожидание на сеансе 1021
SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_time_ms desc
И да, SE_REPL_CATCHUP_THROTTLE
имеет общее время ожидания 8094034
ms, то есть 134.9 минут!
Также см. следующий форум для получения подробной информации по этой проблеме. http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8
Мне был дан следующий ответ в моем сообщении с Microsoft (мы видели эту проблему с четырьмя нашими 15 базами данных в ЕС центр обработки данных):
Вопрос: Были ли внесены изменения в эти мягкие дросселирования в течение последних трех недель, т.е. с тех пор, как мои проблемы начал?
Ответ: Нет, не было.
Вопрос: Существуют ли способы предотвратить или предупредить, что мы приближаемся к пределу?
Ответ: Нет. Вопрос не может быть вызвано вашей заявкой, но может быть вызвано другим арендаторы полагаются на одно и то же физическое оборудование. Другими словами, ваш приложение может иметь очень небольшую нагрузку и все еще сталкивается с проблемой. Другими словами, ваш собственный трафик может быть причиной этой проблемы, но это может быть также вызвано другими арендаторами, полагающимися на то же самое физическое оборудование. Невозможно заранее знать, что проблема скоро произойдет - это может произойти в любое время без предупреждения. SQL Команда Azure Operations не контролирует этот тип ошибок, поэтому они не будет автоматически пытаться решить проблему для вас. Поэтому, если вы запустите в него у вас есть два варианта:
Создайте копию своего db и используйте это и надейтесь, что db будет размещен на другом сервере с меньшей нагрузкой.
Обратитесь в службу поддержки Windows Azure и сообщите об этой проблеме и позвольте им сделать для вас вариант 1