дохнет SQL server

[Dweller]

У нас тут начал подыхать SQL server.
Куча Locks, до 300,000 (не шутка)

Начал проверять кто чего блокирует - увидел удивительную вещь, процесс работает с одной базой но запросы выполняет по таблицам которые в другой базе но на том же самом сервере. Думаю что все эти запросы какие-то фантомные.
Я вот думаю может сервер теряет связь с сетью и процессы из-за этого цепляют чужие пакеты??

[J.K.]

У нас тут начал подыхать SQL server.
Куча Locks, до 300,000 (не шутка)

Начал проверять кто чего блокирует - увидел удивительную вещь, процесс работает с одной базой но запросы выполняет по таблицам которые в другой базе но на том же самом сервере. Думаю что все эти запросы какие-то фантомные.
Я вот думаю может сервер теряет связь с сетью и процессы из-за этого цепляют чужие пакеты??

Пример, как себя нужно вести в подобных ситуациях есть, типа, когда Били самолично облажался при его показе SQL.
Лоеры в $S хорошие, кому хочешь ... заткнут. Так что все хорошо

Подожди, должны ответить, тут народ знает как скл сервер блокирует таблицы лучше всех.

[Big Cheese]

У нас тут начал подыхать SQL server.
Куча Locks, до 300,000 (не шутка)

Начал проверять кто чего блокирует - увидел удивительную вещь, процесс работает с одной базой но запросы выполняет по таблицам которые в другой базе но на том же самом сервере. Думаю что все эти запросы какие-то фантомные.
Я вот думаю может сервер теряет связь с сетью и процессы из-за этого цепляют чужие пакеты??

А раньше как было? не было ли недавних изменений, апгрейдов? Процесс - это в смысле клиентское приложение? В любом случае, идея насчет "цеплять чужие пакеты" выглядит сомнительно, я думаю, проблема может быть в конфигурации сессии. Насколько я понимаю, обращение к другой базе порождает распределенную транзакцию, отсюда и куча блокировок...

Пример, как себя нужно вести в подобных ситуациях есть, типа, когда Били самолично облажался при его показе SQL.
Лоеры в $S хорошие, кому хочешь ... заткнут. Так что все хорошо

Подожди, должны ответить, тут народ знает как скл сервер блокирует таблицы лучше всех.

И мне, и мне такой травы! J.K., надо все-таки придерживаться сложившейся терминологии, Вы же взрослый человек В вашем случае вполне достаточно написать "M$ - сакс и масдай, БГ - урод" -смысл тот же самый, зато сразу все понятно

[tengiz]

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

Это что за байка? Поделитесь - никогда не слышал, чтобы БГ самолично показывал SQL да ещё чтобы тот при показе "облажался".

[tengiz]

У нас тут начал подыхать SQL server...

А подробнее можно? Чем смотрите блокировки? Вы уверены, что точно знаете как правильно интерпретировать диагностику, генерируемую подобными инструментами? Что говорят sp_who/sp_who2/sysprocesses?

[Dweller]

А подробнее можно? Чем смотрите блокировки? Вы уверены, что точно знаете как правильно интерпретировать диагностику, генерируемую подобными инструментами? Что говорят sp_who/sp_who2/sysprocesses?

Пока сервер еще жив, смотрю с помощью вот этого (рис.), а когда он не откликается то с помощью SpotLight. Он и показывает тысячи блокировок.

[Dweller]

забыл добавить что SQL statement в окошке не имеет никакого отношения к базе - он для другой базы на том же сервере.

[SkyWalker]

Захватите запросы в Profiler. Там будет понятно что и кто является их источником. Там же будет видно на какой базе выполнен запрос.
Затем уже можно будет анализоровать дальше.

[tengiz]

KY Dweller,

Вдобавок к тому что уже был сказано SkyWalker, посмотрите на MSDN информацию о том, как нужно диагностировать проблемы с блокированием - начните с Troubleshooting Locking. Кроме того, вот примерная процедура, которую я обычно делал, когда разбирался с непонятным внезапным замедлением работы приложения на SQL Server - старая добрая последовательность осмотра больного, которая годится для любой версии SQL Server начиная с 4.21:

1. sp_who/sp_who2. Смотрим есть ли процессы у для которых в колонке blkby стоит не 0, что означает, что такой процесс ждёт на какой-нибудь блокировке другой процесс, spid которого будет указан вместо 0.

2. Если блокированных процессов больше, чем некоторый порог, определяемый приложением и текущей нагрузкой разбираемся дальше. мне для OLTP системы не понравится ситуация при которой постоянно блокированно > 10% процессов.

3. Пытаемся определись глубину очередей ожидания (процесс 1 ждёт процесс 2, который ждёт процесс 3, который уже никого не ждёт - глубина = 2), если глубина больше 3-4 мне тоже это не понравится.

4. Пытаемся определить есть ли общий источник у цепочек ожидания ( п1 ждёт п2, п2 ждёт п3, п3 не ждёт никого, п4 ждёт п5, п5 ждёт п3 - две цепочки с общим источником) если цепочек c общим источником много (>10% цепочек приводят к одному и тому же процессу-хулигану в "голове") разбираемся дальше.

5. С "головой" очереди ожидания (для указанного выше примера это п3) разбираемся отдельно - возможно транзакция выполняемая "головой" и является источником проблем. Разбираемся с планами запросов, с конкретными блокировками, которые накладываются при исполнеии этой транзакции в изолированных условиях и т.д. Часто именно тут собака и зарыта.

Так как всё это нужно делать довольно быстро, описанная выше процедура может быть реально осуществима если типичное время реакции для отдельной транзакции не меньше, чем сотни миллисекунд или около того. Кроме того, нужно заранее написать соответствующие скрипты/хранимые процедуры которые автоматически осуществят поиск самой популярной "головы" цепочки.

Для SQL Server 7.0 и выше можно провести более детальный анализ шага разборок с "головой" ещё и при помощи SQL Server Profiler.

Ещё один друг DBA - Perfmon если при работе с SQL Server 7.0 и выше есть подозрение на наличие аномального поведения по блокировкам. SQL Server предоставляет довольно большой и подробрый набор счётчиков.

Все числовые параметры и пороги, который я приводил выше - только для иллюстрации порядка значений величин - не более того, это всё слишком сильно зависит от конкретной аппаратуры / приложения.

[Dweller]

большое спасибо за советы!
в-общем, сетевики что-то перетрясли на выходных и все теперь нормально.
если будет опять барахлить буду запускать Profiler, записывать все T-SQL транзакции в базу и потом уже разбираться когда зависнет....
основная проблема была в том что до момента зависания все было классно и не было никаких блокировок а потом вдруг их появлялось сразу тысячи и не было никакой возможности даже их просмотреть потому что весь сервер переставал быть доступным.

[YellowMan]

Попробуйте еще и посмотреть когда последний раз обновлялась статистика - примерно треть моих внезапных тормозов были вызваны именно старой статистикой.