SQL Azure - один сеанс блокирует всю БД для обновления и вставки

Ошибка 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

Ответ 1

Возможно, вы столкнулись с проблемами SE_REPL *, которые в настоящее время сталкиваются с большим количеством людей, использующих Sql Azure (включая мою компанию).

Когда вы испытываете таймауты, попробуйте проверить ожидания ожидания для типов wait:

SE_REPL_SLOW_SECONDARY_THROTTLE
SE_REPL_COMMIT_ACK

Выполните следующие действия, чтобы проверить типы ожидания для текущих подключений:

SELECT TOP 10 r.session_id, r.plan_handle,
r.sql_handle, r.request_id,
r.start_time, r.status,
r.command, r.database_id,
r.user_id, r.wait_type,
r.wait_time, r.last_wait_type,
r.wait_resource, r.total_elapsed_time,
r.cpu_time, r.transaction_isolation_level,
r.row_count
FROM sys.dm_exec_requests r

Вы также можете проверить историю сортировок для этого, выполнив:

SELECT * FROM sys.dm_db_wait_stats
ORDER BY wait_time_ms desc

Если вы видите много типов SE_REPL * wait, и они остаются на ваших соединениях на какое-то время, тогда в основном вы ввернуты. Microsoft осознает эту проблему, но у меня уже есть недельный билет поддержки, и они по-прежнему работают над этим.

Ожидается, что SE_REPL * ждет, когда подчиненные репликации Sql Azure отстают. В принципе, весь db приостанавливает запросы, пока репликация завершается:/

Таким образом, по существу тот аспект, который делает Sql Azure высокодоступным, приводит к тому, что базы данных становятся беспорядочно недоступными. Я бы смеялся над иронией, если бы не убивал нас.

Посмотрите эту тему: http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8