Простые SQL-запросы не заканчиваются [закрыто]

Я не совсем знаю, как сформулировать вопрос, потому что мы еще немного знаем, но я хотел бы спросить раньше, чем позже, потому что это похоже на то, что нельзя пренебрегать.

На этой неделе у нас начались проблемы с нашим сервером базы данных. Кажется, это проблема согласованности данных, и это проявляется в таймаутах даже для очень простых запросов и небольших таблиц. Мы «исправили» проблему, перезапустив сервер ранее на этой неделе, и он ушел, но теперь кажется, что он возвращается и на этот раз на более важных таблицах. Например, я только что провел расследование и смотрю на такой запрос:

SELECT * FROM table WHERE id = 1234

для конкретного идентификатора. Таблица содержит около 30 миллионов строк. Но похоже, что это происходит только для небольшой доли записей. Бьюсь об заклад, когда я перезагружаю сервер или выполняю резервное копирование и восстанавливаю базу данных на другом сервере, все будет хорошо. Но я попытаюсь.

На данный момент я бегу:

DBCC CHECKTABLE ('table', NOINDEX)

но, похоже, он будет работать вечно. Когда мы впервые столкнулись с проблемами, я проверил оскорбительную таблицу, и все было в порядке. Этот новый стол намного больше.

Некоторая справочная техническая информация:

• SQL Server 2008 R2, Windows Server 2008 R2
• AWS / EC2, m2.2xlarge, 32 ГБ ОЗУ, 4 x 1 ТБ RAID 0
• почти нет дискового ввода-вывода, кажется, что большая часть базы данных находится в памяти
• общий размер БД: 100 ГБ

Объемы ELB являются «совершенно новыми». Мы создали их на этой неделе.

Изменить: я просто использовал следующую команду:

SELECT
    sqltext.TEXT,
    req.session_id,
    req.blocking_session_id,
    req.wait_type,
    req.wait_time,
    req.last_wait_type,
    req.wait_resource,
    req.open_transaction_count,
    req.transaction_id,
    req.total_elapsed_time
FROM
    sys.dm_exec_requests req
CROSS APPLY
    sys.dm_exec_sql_text(req.sql_handle) AS sqltext

и обнаружил, что мой запрос ожидает общей блокировки (LCK_M_S), где блокирующий сеанс ожидает другой общей блокировки, заблокированной сеансом, который не существует.

Редактировать 2: ОК, сеанс существует (я нашел его с помощью sys.dm_exec_sessions), но сейчас он, похоже, ничего не делает.

Редактировать 3: я не могу найти ничего интересного о сессии. Я вижу, с какого веб-сервера это происходит, но не более того.

Редактировать 4: Редактировать 4: Мы обнаружили возможную ошибку в нашем коде: функция, которая не проверяла соединение с базой данных. С другой стороны, похоже, что транзакция, которую использовала функция, использовалась для правильного размещения, и в этом случае все блокировки должны были быть удалены. Это все еще не очень ясно для меня, но это, кажется, вероятная причина. Мы собираемся исправить ошибку и следить за ней.

Для меня эта проблема была вызвана тем, что соединение с базой данных оставалось открытым, Visual Studio была приостановлена ​​в режиме отладки. Остановка процесса отладки позволила выполнить запрос немедленно.

Какой тип ожидания для запроса, когда он зависает? Это точно скажет вам, чего он ждет. Найдите и установите sp_whoisactive на сервере и запустите хранимую процедуру, когда у вас возникнут проблемы. Это покажет вам spid и даст вам тип ожидания.

Скорее всего, вы заблокированы тем, кто пишет в эту строку, или другой строкой на этой странице, или вы ожидаете ответа диска.

Попробуйте запустить DBCC CHECKDBпроблемную БД и дождаться ее окончания. Если существует физическое несоответствие данных, которое приводит к такому странному поведению, работать с этой БД слишком опасно, так как вы можете потерять все свои данные.

1. Сделайте резервную копию как можно скорее.
2. Проверьте БД.

НО

Если в таблице есть BLOB-столбцы с относительно большими объемами данных, абсолютно нормально, чтобы проверка этой таблицы занимала много времени.

не совсем уверен, что вы ожидаете в качестве ответа, но если в таблице более 30 миллионов строк, ожидается, что команда DBCC будет работать в течение длительного времени.

Когда ты говоришь:

Но похоже, что это происходит только для небольшой доли записей

Вы имеете в виду, что вы обеспокоены тем, что вся таблица не сканируется? Это нормально, если у вас есть индекс по ID, индекс будет сканироваться, что приведет к меньшему количеству операций чтения.