Нужно запустить Entrprise Manager и посмотреть какой процесс лочит. Потом посмотреть профайлером какой запрос при этом выполняется. А далее по результатам...

Я конечно всё понимаю, но разве так должен выглядеть ответ
квалифицированного специалиста просящему пользователю?

Вот такая ссылочка

http://www.sql.ru/articles/mssql/2007/011005DeadlockTroubleshootingPart…

была бы выше всяких похвал....

----
TSCRM 3.0.4.112 X25 100 лицензий.
Microsoft SQL Server Enterprise Edition (64-bit)
Version 9.00.3054.00

Ну что, же.

Долго 'вкуривал' доки и гуглил....

в результате обнаружилось что передрались процессы
с одной машины за событие exchangeEvent.

оказалось, что при нажатии кнопочки 'Refresh'
любого грида, сама кнопочка не блокируется до
получения результата ;-( !!! т.е. многократные
нажатия пораждают новые нити запроса к базе...

С некоторой надеждой полез в wnd_BaseGridArea,
но обломился.... кнопочка Refresh внутри компонента
и вмешательство в её обработку невозможна....

прилагаю resourece-list дедлока:

resource-list
pagelock fileid=1 pageid=705288 dbid=5 objectname=tscrm.dbo.tbl_Task id=lock8145cd80 mode=IX associatedObjectId=72057615756558336
owner-list
owner id=process15f322088 mode=IX
waiter-list
waiter id=processedab08 mode=S requestType=wait
exchangeEvent id=port80120e20 nodeId=3
owner-list
owner event=e_waitNone type=producer id=processedab08
waiter-list
waiter event=e_waitPortOpen type=producer id=processef1048
waiter event=e_waitPortOpen type=producer id=processc3f6d8
waiter event=e_waitPortOpen type=producer id=processec5c18
objectlock lockPartition=0 objid=458484712 subresource=FULL dbid=5 objectname=tscrm.dbo.tbl_ContactInTask id=lock1adb85a80 mode=S associatedObjectId=458484712
owner-list
owner id=processef1048 mode=S
waiter-list
waiter id=process15f322088 mode=IX requestType=wait

process15f322088 - в момент дедлока вставляет новую задачу,
с одного компьютера,все остальные процессы - порождены многократными нажатиями refresh в гриде задач с другого....

Что можно сделать?

--
TSCRM 3.0.4.112 X25 100 лицензий.
Microsoft SQL Server Enterprise Edition (64-bit)
Version 9.00.3054.00

"Sergey E. Yakovlev" написал:Что можно сделать?

Ждать пока поправят в ядре :(
1) Начнут отключать кнопку
2) Исправят поведение грида при ошибке открытия датасета. Со вторым сам сталкивался. Явно где-то вместо

Lock();
try
Open();
finally
UnLock();
end;

написали просто

Lock();
Open();
UnLock();

А сколько времени занимает создание задачи? Может попробовать этот кусок ускорить? Например попробовать поубирать редко используемые индексы.

Боюсь, что ждать модификаций ядра для нашей версии (см. в подписи) придется вечно, дай бог, чтобы я ошибался ;-)

Самостоятельно развивая TSCRM "c коробки" пришли к выводу,
что накручивать логику на итак очень "толстом" и "медленном"
клиенте (Delphi + JScript) очень накладно (выливается в сильное торможение на клиентах) + проблемы на плохих и узких каналах в регионы (чем больше запросов к базе по каждой задаче, тем большая вероятность что в случае сбоя получим проблемы с целостностю данных).

В результате решили по максимуму перекладывать логику на базу в триггера и процедуры. Так что на создании и/или обновлении задачи висит довольно солидная логика и уйти
от неё вряд ли получиться.

Пока порекомендовал пользователям не "дрючить" Refresh самозабвенно....

--
TSCRM 3.0.4.112 X25 100 лицензий.
Microsoft SQL Server Enterprise Edition (64-bit)
Version 9.00.3054.00

Deadlock, как правило, не зависит от частоты Selectов.
Скорее всего проблема именно в тригере на обновление задачи, и если Вы приведете его текст - можно будет что-то посоветовать.

Упс!

т.е. resourece-list дедлока просто "гонит пургу",
это всё происки проклятого микрософта :-)

----
TSCRM 3.0.4.112 X25 100 лицензий.
Microsoft SQL Server Enterprise Edition (64-bit)
Version 9.00.3054.00

Так что на счет текста тригера?

Он очень большой и включает в себя вызовы большого количества процедур. Более того, он не один...

Лучше подтвердите или опровергните информацию о возможности многократного нажатия на Refresh...

--
TSCRM 3.0.4.112 X25 100 лицензий.
Microsoft SQL Server Enterprise Edition (64-bit)
Version 9.00.3054.00

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

Нет, явного управления транзакциями не присутствует
в принципе.

--
TSCRM 3.0.4.112 X25 100 лицензий.
Microsoft SQL Server Enterprise Edition (64-bit)
Version 9.00.3054.00

Раз интерес к проблеме всё-таки появился :-)

Вот ссылка на полное описание дедлока:
http://enic.atwebpages.com/uploads/Main/log.zip

---
TSCRM 3.0.4.112 X25 100 лицензий.
Microsoft SQL Server Enterprise Edition (64-bit)
Version 9.00.3054.00

Сергей, а Вы не создавали дополнительно на таблицах кластерные индексы?

Нет, кластерные только ID-шки, только что перепроверил.

Всё понимаю, кроме одного, в отчете по локу (одно письмо назад) чётко прослеживается 4 одновременных запроса с
одного подключения пользователя машины BY171SQL05 (он сидит напротив меня), также в этом же отчете видно что они
передрались за ресурс:
exchangeEvent id=port80120e20 nodeId=3
а не за какой либо объект бд (таблица, индекс),
и самый первый вопрос должен быть как он с одной копии
tscrm смог породить 4 нити запроса SELECT COUNT(*) FROM(SELECT... в одном подключении к базе. Кстати у него админские права в tscrm. (т.е. права не проверяются, работает быстрее)
Второй юзер (process15f322088) (который вставлял новую задачу) в другом городе на относительно медленном канале....

----
TSCRM 3.0.4.112 X25 100 лицензий.
Microsoft SQL Server Enterprise Edition (64-bit)
Version 9.00.3054.00

Сергей, а Вы не смотрели ссылку SQL Server 2005 - Deadlock - Exchange Event
У Вас несколько процессоров на сервере? Включен ли параллелизм?

Да, 2 x Xeon 5110 т.е. в сумме четыре ядра.
Параллелизм естественно включен.

Однако, ознакомившись со статьёй (ссылка на которую
содержится в последнем коменте внутри Вашей ссылки):

http://blogs.msdn.com/bartd/archive/2008/09/24/today-s-annoyingly-unwie…

сделал ряд умозаключений:

1) Учиться можно (и нужно) бесконечно.
2) Кнопка Refresh была нажата только один раз
а нити - результат интеллектуальной деятельности
планировщика запросов mssql, имеющего в распоряжении многопроцессорную систему.
3) В статье речь идет не совсем о текущей проблеме
(там рассматривается дедлоки между нитями одного запроса,
которые, в таком случае признаются ошибками в работе планировщика и подлежат исправлению в последующих фиксах на mssql). А в нашем случае в дедлоке участвует не один процесс.

4) Методы "обхода", представленные в статье, безусловно полезны (опубликуем их здесь для общей информации, а также на случай удаления форума):

---------------------------
Wherever you have threads waiting for resources, there is a risk that they will end up in a circular blocking chain (thread A holding resource X and waiting for resource Y, thread B holding resource Y and waiting for resource X). The synchronization objects used in parallel query execution are no exception; in rare cases, the threads running a single query can end up deadlocking with one another. Most intra-query parallelism deadlocks are considered bugs, although some of them can be risky bugs to fix. If you run into one and you're already on the latest SQL service pack, your best bet may be to investigate workarounds. Luckily, this type of deadlock is relatively uncommon, and in most cases it's possible to work around the problem by eliminating parallelism in the query. Try one of these two approaches:

Workaround #1: Add an index or improve the query to eliminate the need for parallelism. In most cases, the use of parallelism in a query indicates that you have a very large scan, sort, or join that isn't supported by proper indexes. If you tune the query, you will often find that you end up with a much quicker and more efficient plan that doesn't use parallelism, and therefore isn't subject to this type of problem. Of course, in some queries (DSS/OLAP-type queries, in particular) it may be difficult to eliminate all large scans.

Workaround #2: Force single-threaded execution with an "OPTION (MAXDOP 1)" query hint at the end of the query. If you can't modify the query, you can apply the hint to any query with a plan guide (assuming that you're running SQL 2005 or later).

---------------------------

В связи с тем, что "Виновных" вроде бы не нашли :-)

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

P.S. Александр, хочу сказать Вам отдельное спасибо
за предоставленную информацию о тонкостях работы
mssql на многопроцессорных системах! СПАСИБО.

--
TSCRM 3.0.4.112 X25 100 лицензий.
Microsoft SQL Server Enterprise Edition (64-bit)
Version 9.00.3054.00

Сергей, так проблема ушла когда отключили параллелизм? Или Вы не пробовали?
Не раз встречал на sql.ru рекомендации отключать параллелизм, так как сервер не всегда корректно строит план, но включать его вечером скажем на всякие служебные запросы - бекап, верификация, перестройка индексов.

Пока не отключал,
надо разбираться с plan guide-ами, так как в запросе
добавить (MAXDOP 1) tscrm видимо не позволит.

В целом, после совета не нажимать Refresh многократно,
проблема почти не вылазит.

--
TSCRM 3.0.4.112 X25 100 лицензий.
Microsoft SQL Server Enterprise Edition (64-bit)
Version 9.00.3054.00