13.10.2005, 18:15 | #41 |
Участник
|
А Вас не затруднит перебросить текст этого codeunit с указанием точки блокировки ?
|
|
17.10.2005, 09:34 | #42 |
Участник
|
rmv,
Резалтсет процедуры sp_lock по зависшему и блокирующему клиенту cl1 показывает, что он получил все необходимые ему ресурсы (Status=GRANT) и не ждет никого, то есть ни кем не заблокирован. Резалтсет sp_lock болкируемого клиента cl2 показывает, что он ждет (Status=WAIT) освобождения ресурса Type=KEY и Mode=RangeS-U. То есть, получается, что клиент cl1 ни кем не заблокирован, но почему-то висит, блокируя других. Почему? |
|
17.10.2005, 09:49 | #43 |
Участник
|
DeSp - если бы Вы запостили результаты, можно было бы разговаривать более предметно. Могу лишь предположить, что cl2 споткнулся на коде IF WhseActivLine.FIND('+') THEN, то бишь на ключе, ранее заблокированным cl1. Сравните все резурсы, заблокированные в экслюзивном (X) режиме.
|
|
19.10.2005, 13:47 | #44 |
Участник
|
rmv, я бы запостил резалтсеты по клиентам, но у cl2 в резалтсете с десяток тысяч записей - в 2 кб не получится аттач уместить. В аттаче привожу пример блокировок cl1(spid=56) и блокировки cl2(spid=57) со статусом WAIT. Оба клиента блокируют таблицу Warehouse Activity Line: ObjId=79911952 в Mode=IX.
Используя SQL Profiler я наткнулся на странную вещь: дедлок все-таки есть!, кроме того клиент cl1 был выбран жертвой и отключен, судя по сообщениям в логе профайлера. Однако, по какой-то причине cl1 остается висеть, при этом, видимо не разблокировав ресурс, нужный cl2. В логе профайлера после получения Exception: Error 1205, Severity 13, State 50 cl1 начинает массовые разблокировки и далее висит, не делая ничего. Лог по cl1 продолжается с момента времени принудительного отключения cl1 вручную через kill process - продолжаются разблокировки. |
|
20.10.2005, 11:12 | #45 |
Участник
|
После того как клиенты повисли, регулярно обновляю инфу в EM -> Current Activity ->Process info:
Блокирующий клиент имеет: spid=56, status=sleeping, open transactions=0, command=awaiting command, wait time=0, wait type=not waiting, wait resource=..., blocking 1. Блокируемый имеет: spid=55, status=sleeping, open transactions=1, command=execute, wait time=0, wait type=miscellaneous, wait resource=..., blocked by 56 . Похоже на симптомы "осиротевшего" коннекта (orphaned session) у 56, но почему в логе профайлера сервер пишет, что был обнаружен и разрешен дедлок? Как он так разрешил дедлок, что заблокированные ресурсы 56-го не освободились, не давая продолжить 55-му, а сам 56-й продолжает висеть? Lockeadlock Chain - оба клиента лочили RangeS-U ключ с IndexId=1 в таблице Warehouse Activity Line. Это первичный ключ с SumIndexField, MaintainSIFTindex=No. Кроме того, после отключения 56 вручную через kill process его клиент Navision выдал сообщение: "Внутренняя ошибка 1247 в модуле 19, обратитесь к вашему дилеру, если нужна помощь" и аварийно закрылся. Кто-нибудь может подсказать в чем все-таки проблема? |
|
21.10.2005, 10:25 | #46 |
Участник
|
Попробуйте отключить этот индекс, как SIFT и если проблема исчезнет, то наверное надо искать в коде посдедовательность блокировок, которое могло к этому привести.
|
|