ВСЕМ АКТУАЛЬНО : Накопление блокировок

Привет коллегам !

Популярная проблема, попадающаяся почти всем.
Вроде уже проскакивала по форуму, но без конкретных ответов :(

Большая база , много юзеров. Работает стабильно и быстро. Но ...
Иногда в результате некоторых действий
(например внеочередная сложная заливка данных, обновление чего либо, и т.п.)
возникает ДЕДЛОК. Его снимают из ЕМ. (Kill proc). И база начинает тормозить.
Иногда не сильно, иногда невыносимо. Винт сервера молчит.
Загруженность проца 90-100%. Deadlockов нет. Просто медленно работает.
Даже через 2 дня тормоза не проходят.
Перезагрузка сервера помогает ! Но это очень нежелательно.

Есть какие либо варианты обойтись без перезагрузки ?

Неплохо бы привести "снимки" состояния системы в моменты "Загруженности".

А можно подробнее, что такое снимок системы? т.с объяснение для ламера.

2JAN: "снимок" - это набор значений различных параметров, характеризующий состояние системы. Например, утилита sqldiag собирает такую информацию. Я не предлагаю приводить результаты sqldiag, но хотя бы итоги процедур sp_lock, sp_who2, sp_configure, итог DBCC OPENTRAN и пр.

2jimmers

Какие-такие снимки ?
Что и чем именно следует смотреть ? и "фотографировать" ?
Где увидеть приблизительную причину и время возникновения ?
Вообще это возможно ?

Подобную ситуацию сложно смоделировать.
При блокировках иногда даже нельзя зайти в ЕМ. Виснет.
Просто всех выгоняем и перегружаемся.

2LSV:

Не думаю, что EM необходим в подобной ситуации. Воспользуйтесь Query Analyzer'ом
для запуска вышеупомянутых процедур. Можете даже sqldiag использовать. Для решения
проблем блокировок вести лог запросов (флаги 3604 + 1204). Все же описано...

2 jimmers

Обычно смотрим Current activity (Я так понимаю это похоже на sp_who2)
При нормальной работе RUNNING процессов нет. Все СПЯТ.
Но при сильной блокировке массово появляются RUNNING процессы тех
пользователей, которые ждут отклика сервера (т.е. сидят и тормозят :-) )
При слабой блокировке RUNNING почти нет.
Или они изчезают/появляются.
Вопрос заключается в том, МОЖНО ЛИ С ЭТИМ БОРОТЬСЯ (с торможением) ?
Причина зачастую известна. Просто иногда пронесет а иногда и нет :-)
Как лучше всего делать обширные (и несрочные) изменения в интенсивно
используемой таблице ? Построчно что ли ?

Что значит "сильная блокировка", "слабая блокировка"?
Если Вы знаете, в чем проблема (а Вы писали, что в deadlock'е),
то следует переписать код таким образом, чтобы устранить их.
Как устранить - см. Books Online (минимизация длины транзакции,
последовательность операторов и т.д.). Что же до "интенсивно
используемой" таблицы, то очевидно, что несрочные изменения
следует по возможности проводить во время наименьшей активности.
Если же такой возможности нет, то перепроектировать БД таким
образом, чтобы необходимость массовых обновлений такой таблицы
свести к минимуму, например, за счет избыточности (хотя тут важна
специфика, универсального решения нет).

Удачи

Сильная блокировка - это когда невозможно работать.
Слабая - все нормально работают но приложение притормаживает.

Есть-ли хоть какая-то возможность выполнить, например UPDATE или DELETE
по заведома неизменным записям с низким приоритетом, чтобы не заблокировались работающие ЮЗЕРы ?
Пример : строки товара в документах.
Задача: удалить старые, ненужные строки, при условии что новые документы
все время добавляются.

Я делаю DELETE в ненапряжное время (проходит за 30-50сек не более).
Но иногда появляется юзер и лезет добавлять записи.
Зависает с таймаутом. А вообще при круглосуточной работе непросто
найти совсем ненапряжное время.

Давайте конкретно:

1. Схема таблицы (CREATE TABLE ...)
2. Примерное число и характер записей (два миллиона записей, поля заполнены на 100%)
3. Запрос Пользователя на добавление (BEGIN TRAN ... INSERT dbo.MyTable ...)
4. Запрос на удаление старых записей (DELETE dbo.MyTable WHERE IsDeleted = 1 ...)

П. 3 и 4. опишите подробно - в процедуре запросы или нет, уровни изоляции, и т.п.

Одним словом, чтобы любой мог взять и проверить.