вставку новой строки в таблицу...
К чему вопрос, нет ли какого-то монитора, который на дедоках автоматически записывал в журнал все запросы поучаствовавшие в нем?
А то висят насколько процессов и иногда бросают исключения. Но когда человек замечает - там уже все заролбэчилочь и блокировок нет.
Профайлер и запись в файл, с фильтром по нужному?
В смысле SMS или другой профайлер? Записывать все запросы всех процессов за полчаса, а потом искать чисто по таймстампам... Но что искать Ведь неизвестно С КАКИМИ подключениями оно задедлочилось
собирай трассу дедлоков. Т.е. отбери события как на картинке
он не хочет это на сервере что-то делать.. или с клиента в этом софте... хочет внутри своего
Сервер локальный, просто не могу сидеть и тупить 15 минут пока там выскочит. В понедельник попробую
Если в своем, да еще и на 2008r2 то лучше использовать файловую трассировку. В 2008 r2 уже появились расширенные события, но с массой ограничений. Вобщем, предлагаю погуглить насчет sp_trace_create + sp_trace_set_event + sp_trace_setfilter
у меня попроще ситуация, 2019
Это как раз пилить велосипед. Надеюсь что скриншот выше хватит
Ага, помогло, спасибо. В сухом остатке, MsSql2008r2 не умеет в merge, уж какие там обсуждения бушевали лет 15 назад, какие эксперименты ставили мудробородые старцы... Даже и с хинтами, с которым мёрж совсем-совсем точно работает, все равно дедлочить, хотя и заметно реже. Не через 2-3 минуты, а через 5-7. Поменял, ругаясь, стандартный sql на update-from-join и заработало. Ну и к вопросу о настоящести БД. В фаерберде бы это решилось одним триггером с двумя однострочными командами. Вместо двух развесистых instead-of триггеров, которые к тому же пришлось бы переписывать, если менять список столбцов (не буду почти наверняка, но сам факт, что из-за за такой ерунды надо заново служебные триггера писать...) В общем, понятие настоящести БД в первую очередь упирается в привычку, всяк кулик и свое болото.
Обсуждают сегодня