Деадлоки при использовании SQL Server

[DeSp]

Две сессии намертво лочат друг друга, при этом клиенты повисают пока принудительно вручную не убивается одна из сессий.
Используется SQL Server 2k и LOCKTABLE(true,false).

В чем может быть проблема?

[Wizard_imported]

описан не дедлок. Когда действительно мертвая блокировка, SQL сам отрубает одну из транзакций, в результате чего пользователь получает сообщение типа "Ваше действие было заблокировано другим пользователем", в английской версии этого сообщения явно упоминается слово Deadlock.

Кто параметры к LOCKTABLE написал? попробуйте убрать
пусть будет просто LOCKTABLE;

[DeSp]

Если это не деадлок, то что?

[Wizard_imported]

просто лок, не дед...
возможно, конечно, что у вас как-то время ожидания в SQL настроено так, что в ситуацию долго не вмешивается сервер. К сожалению, я плох в администрировании SQL, может кто ещё подскажет...

[DeSp]

Я тоже не силен в администрировании SQL Server.
Как можно узнать время ожидания сервера перед принудительным отключением клиентов для разрешения дедлока?
В моем случае сервер не вмешивается в ситуацию на протяжении 15 минут, а дальше неизвестно, так как уже в ручную отключаются клиенты.

[Alterant]

Функциональность стандартная (какая?) или своя?

[DeSp]

Функциональность - управление складом: стандартная и самописная (складской контроль).

И все-таки есть ли параметр, отвечающий за время, через которое сервер отключит один из блокируемых процессов автоматически?

[Alterant]

Цитата:

Сообщение от DeSp

Функциональность - управление складом: стандартная и самописная (складской контроль).

И все-таки есть ли параметр, отвечающий за время, через которое сервер отключит один из блокируемых процессов автоматически?

<{POST_SNAPBACK}>

Рекомендую Вам прочитать документы:
Performance Troubleshooting Guide for Microsoft® Business Solutions–Navision (есть на Tools CD)
Microsoft Business Solutions–Navision SQL Server Option Resource Kit (есть на Tools CD 4.0)

Там описаны рекомендации по программированию для избежания дедлоков и описание методики диагностики дедлоков.

[Константин!]

Кажется для SQL Servera

SET LOCK_TIMEOUT время в мили сек

посмотри здесь http://rsdn.ru/article/db/mssqllocks.xml?print

А вобще Microsoft советует дождатся 4.1 там многие проблемы связаные с SQL говорят будут решены

[DeSp]

Да, спасибо за рекомендации, эти документы я уже читал и методикой воспользовался. Дедлоки обнаружены, они возникают при одновременном запуске одной операции разными клиентами. Порядок блокировок при этом должен быть одинаковый раз операция одна и та же, но выполнение приводит к дедлоку, непонятно почему.

[Wizard_imported]

Какая операция?
Вам удается дедлок воспроизвести?

[DeSp]

Да, дедлок удается воспроизвести.
Клиентами одновременно выполняется операция регистрации складского контроля. При этом возникают дедлоки по 3-м таблицам.

[Wizard_imported]

Цитата:

Сообщение от DeSp

Две сессии намертво лочат друг друга,

<{POST_SNAPBACK}>

всё таки как вы это определяете?
маловероятно возникновение дедлока при параллельной работе одной и той же функции.
Кода много в этом складском контроле? мож глянуть...
Если неодновременно - функция быстро выполняется?

[DeSp]

Определяется это просто - клиенты висят по 15 минут, пока вручную не обрубается один из них.
Операции регистрации могут быть длительными, но в разумных пределах - это явно не десятки минут.
Кода много.
Если неодновременно, то выполняется относительно быстро.
Я понимаю что это маловероятно, но это происходит слишком часто.

[rmv]

Какие именно таблицы блокируются?
Возможно из-за различного порядка блокировки таблиц в содеюнитах учета складских документов и в 80,90 кодеюните?

[DeSp]

Таблицы:
Резервирование Операция
Склад Операция Строка
Склад Операция Заголовок

Так как выполняется одна и та же операция, но разными клиентами, порядок блокировок таблиц должен быть одинаковым.

[Alterant]

Цитата:

Сообщение от DeSp

Таблицы:
Резервирование Операция
Склад Операция Строка
Склад Операция Заголовок

Так как выполняется одна и та же операция, но разными клиентами, порядок блокировок таблиц должен быть одинаковым.

<{POST_SNAPBACK}>

А нет ли где в коде COMMITов, снимающих блокировки и затем опять LOCKов?

[rmv]

Транзакция A заблокировала таблицу 1 и пытается прочитать данные из таблицы 2. Одновремено тразнакция B заблокировала таблицу 2 и пытается прочитать данные из таблицы 1. Здесь и возникает deadlock.

DeSp - и не факт что в разных участках кода порядок блокировок таблиц не может поменяться .

Обратите внимание на commit в 5763 кодеюинте.

[DeSp]

Ничего другого, как тщательно перелопатить весь код видимо не остается. А кода реально много и писал его не я.

[rmv]

Как вариант могу предложить все учитываемые документы ставить в очередь и учет текущего док-та проводить только после учета предыдущих.