Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
16.05.2016, 14:43
|
|||
---|---|---|---|
|
|||
Инструментарий по вылавливанию deadlock |
|||
#18+
Есть ли нормальный инструмент по вылавливанию deadlock-ов? "lock conflict on no wait transaction deadlock update.. At trigger..." Чтобы указал, что вот данная транзакция с вот таким апдейтом держит строку и дает отлуп вот этому апдейту... FireBird 2.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.05.2016, 14:51
|
|||
---|---|---|---|
Инструментарий по вылавливанию deadlock |
|||
#18+
Fofanov_Alexey, разве что аудит (или трейс). Потому что дэдлок обычно долго не живет, как и транзакция, в которой он возник. Если deadlock случился "прям щас", то может быть, можно успеть увидеть что-то в mon$. Но вообще-то, обычно сообщение deadlock - это конфликт обновления одной записи ИЗ ДВУХ транзакций. Так что, по уму надо знать, что делалось в обоих транзакциях, да еще и с какой записью. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.05.2016, 16:11
|
|||
---|---|---|---|
|
|||
Инструментарий по вылавливанию deadlock |
|||
#18+
Это не настоящий дедлок, это конфликт обновления одной и той же записи из двух разных транзакций. Берете HQbird PerfMon, запускаете трейс, ждете момента, когда произошел облом, фиксируете (лучше всего в приложении). Затем в БД лога PerfMon скрупулезно смотрите все открытые на тот момент транзакции, и в них смотрите выполняющиеся UPDATE или DELETE, далее сопоставляете с обломившимся и вуаля. Сразу скажу, чтобы избавиться от такого поведения, нужно будет модифицировать логику приложения - перед апдейтом, который меняет реальные данные, делать холостой апдейт, и обрабатывать его результат - если не вернул ошибки, можно делать основной апдейт, если вернул, значит, надо сообщать пользователю о невозможности производства апдейта (тапки заняты), ну и далее либо сохранить измененные данные, либо просто выкинуть их. С уважением, Алексей Ковязин www.ibase.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
|
16.05.2016, 16:22
|
|||
---|---|---|---|
|
|||
Инструментарий по вылавливанию deadlock |
|||
#18+
Alexey Kovyazinмодифицировать логику приложения - перед апдейтом, который меняет реальные данные, делать холостой апдейт, и обрабатывать его результат - если не вернул ошибки, можно делать основной апдейт, если вернул, значит, надо сообщать пользователю о невозможности производства апдейта А холостой-то апдейт тут зачем? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=40&tablet=1&tid=1562178]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 143ms |
0 / 0 |