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


Что не мешает фанатам одной СУБД по любому поводу советовать пользователям другой СУБД выбросить это дерьмо и поставить себе нормальную СУБД.
Впрочем, так обстоит дело с любым софтом, а не только с СУБД :)


2.5

што???

вообще через mon$ никакие записи "определить" нельзя.
- update выдает конфликт с номером транзакции
- по номеру транзакции ищем ее sql в mon$statements и ее коннект в mon$attachments. Смотрим на update/delete, разумеется, ну или вызов процедур, раз у вас там в селективных процедурах тоже update/delete есть.
Всё.

А "записи" (конкуренция) определяются только по параметрам конфликтных update/delete из трейса.
Забыли еще про состояние 2 - stalled :)

Терминологическая путаница: замените в моем вопросе слово "записи" на "строки, возвращаемые запросом"
Итак:
Можно ли я по значению поля mon$state определить, что запрос, указанный в этой строке, не мог блокировать таблицу?

[+]

Хм...
авторА он может и не позволить изменять настройку серверов или запускать лишнее программное обеспечение на клиентских компьютерах

Но вы почему-то не поняли, когда я строки, возвращаемые запросом к таблице mon$statements, назвал записями ;)

Запросов UPDATE в приложении очень мало. В основном запросы SELECT FROM STORED_PROC. Кроме того, запросы могут быть не в самом EXE-шнике, а, например, в DLL.

В БД несколько тысяч ХП. Средний размер одной ХП, навскидку, пара сотен строк. Dependncies может не помочь, так как текст некоторых запросов собирается в run-time. Кроме того, есть еще различные dll, где тоже могут выполняться запросы. При этом каждую из найденных ХП нужно проверять, а не могла ли она выполняться в приложении в тот момент, когда возникла блокировка.
А если я ничего так и не найду, а выяснится, что у заказчика еще и дополнительные скрипты запускаются, про которые я ни сном, ни духом...
И это предлагают мне в противовес решению, сбросить в лог тексты запросов из mon$statements, которые выполнялись в блокирующей транзакции. Даже если их там окажется несколько десятков, все равно масштабы несравнимы.


А на локальной базе ошибка не возникает. И у других заказчиков тоже не возникает. Только у одного. Спереть у него базу со всеми настройками я не могу.


Транзакции и так NOWAIT. Проверочный запрос отработал корректно и сохранил в лог, что блокирующая транзакция принадлежит соединению, открытому моим же приложением.

Сейчас поправил код приложения. Перед выполнением проблемного UPDATE-а (но после старта транзакции) сбрасываю в лог все транзакции моего соединения. А если транзакций больше, чем одна, то еще и все стейтменты моего соединения. А только потом выполняю запрос UPDATE. Если блокирующая транзакция не асинхронная, то должен все поймать.

И все они вызываются из твоего приложения?..

Нет, не все. Но есть ХП, которые вызываются из ХП, которые вызываются из моего приложения.
А есть ХП, которые вызываются из ХП, которые вызываются из ХП, которые вызываются из моего приложения.
А есть... :)

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


И не надо. Тебе не ошибку надо воспроизводить, а разобраться в потоке выполнения
и работе с транзакциями твоего приложения. Ошибка - следствие. Кривая работа с
транзакциями - причина. И именно причину-то тебе надо найти и устранить.

И что я тогда буду искать? Одновременную работу нескольких транзакций что ли?


В теме были советы о том, что надо писать хорошие программы и не надо писать плохие программы.
Были советы переделать БД как надо.
Но вот совет ар жизни о том, чем и за сколько можно заниматься, пока первый :D