См. BOL: Contents->Accessing and Changing Relational Data->Locking->Customizing Locking with SQL Server->Deadlocking.
Или в индексе набери deadlock и получишь сслыки на несколько статей.

Там подробно все описано, даже с картинками

Glory, аплодисменты по поводу "START DEADLOCK"!!! Для меня это стало зарядом бодрости на весь день

>Какое свойство языка Transact SQL является типичной причиной мертвых блокировок?
Это бессмысленный вопрос. И вообще, что такое "свойство языка Transact SQL"? Что-то не припоминаю такого термина.

Пример Guaranteed Deadlock - отличная иллюстрация. Куда проще-то. Хочу напомнить, что транзакции бывают не только явные. Совершенно аналогичный пример можно написать, сделав конфликт между потоком, пишущим в таблицу, на которую повешен триггер и потоком, читающим из таблицы, изменения в которую вносит вышеупомянутый триггер. Будет то же самое, только якобы без транзакций. Хотя реально это окажется все тот же Guaranteed Deadlock.

Vasia, ты хоть объясни, чего нужно-то?

Блин, а... Чем тебя не устраивает Guaranteed Deadlock, выдранный из BOL и приведенный здесь Glory? Проще не бывает!

Скрипт:
create table t1(
col1_1 int,
col1_2 sysname
)
go

create table t2(
col2_1 int,
col2_2 sysname
)
go

insert into t1 values (1, '1')
insert into t2 values (2, '2')

Теперь сценарий, как добиться дедлока.

1. Открываем 1-й коннект. Выполняем
begin tran
update t1 set col1_2 = '11'
2. Открываем 2-й коннект. Выполняем
begin tran
update t2 set col2_2 = '222'
3. На 1-м коннекте выполняем
update t2 set col2_2 = '22'
4. На 2-м коннекте выполняем
update t1 set col1_2 = '111'
5. На 2-м коннекте получаем сообщение
"Transaction (Process ID 61) was deadlocked on {lock} resources with another process and has been chosen as the deadlock victim. Rerun the transaction."

Так пойдет?

(Задумчиво так...) Знаешь, меня первый раз в жизни БЛАГОДАРЯТ за deadlock!