Мертвые блокировки - это действительно поможет?

Случайное добавление параметров SET в запрос вряд ли поможет. Боюсь,

SET NOCOUNT ON

не повлияет на проблему.

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

предотвратит снятие вашим запросом общих блокировок. Помимо чтения «грязных» данных, это также может привести к тому, что ваш запрос будет читать одни и те же строки дважды или вообще не читать, в зависимости от того, какие другие параллельные действия происходят.

Решит ли это вашу проблему тупиковой ситуации, зависит от ее типа. Это не будет иметь никакого эффекта, если проблема заключается в взаимоблокировке двух писателей из-за нелинейного упорядочения запросов блокировки. (транзакция 1 обновляет строку a, транзакция 2 обновляет строку b, затем tran 1 запрашивает блокировку на b и tran 2 запрашивает блокировку на a)

Можете ли вы опубликовать проблемный запрос и график взаимоблокировок? (если вы используете SQL 2005 или новее)

NOCOUNT не позволит вашему запросу возвращать количество строк обратно в вызывающее приложение (т. Е. Затронуто 1000000 строк).

TRANSACTION ISOLATION LEVEL READ UNCOMMITTED допускает «грязные» чтения, как указано здесь .

Уровень изоляции может помочь, но вы хотите разрешить грязное чтение?

Лучшее руководство:

http://technet.microsoft.com/es-es/library/ms173763.aspx

Фрагмент:

Указывает, что операторы могут читать строки, которые были изменены другими транзакции, но еще не совершенные.

Транзакции, выполняющиеся в READ НЕОБХОДИМЫЙ уровень не выдаёт общий блокировки для предотвращения других транзакций от изменения данных, прочитанных текущая сделка. ПРОЧИТАЙТЕ НЕПРЕРЫВНО транзакции также не блокируются эксклюзивные блокировки, которые предотвратят текущая транзакция из чтения строк которые были изменены, но не совершенные другими сделками. Когда эта опция установлена, можно читать незафиксированные модификации, которые называются грязным чтением. Ценности в данные могут быть изменены, а строки могут появляются или исчезают в наборе данных до окончания сделки. Эта опция имеет тот же эффект, что и установка NOLOCK на всех столах во всех Операторы SELECT в транзакции. Это наименее ограничительный из уровни изоляции.

В SQL Server вы также можете минимизировать блокировка разногласий при защите транзакции из грязных чтений незафиксированные изменения данных с использованием либо:

Уровень изоляции READ COMMITTED с READ_COMMITTED_SNAPSHOT опция базы данных установлена ​​в положение ON. В Уровень изоляции SNAPSHOT

.

С другой стороны, есть два других аспекта, которые могут помочь.

1) Индексы и индексы, используемые SQL. Стратегия индексации, используемая в таблицах, повлияет на количество затронутых строк. Если вы вносите изменения в данные с использованием уникального индекса, вы можете снизить вероятность возникновения взаимоблокировок.

Алгоритм один - конечно, он не сработает во всех случаях. Использование NOLOCK является целевым, а не глобальным.

The "old" way:
UPDATE dbo.change_table
   SET somecol = newval
 WHERE non_unique_value = 'something'

The "new" way:
INSERT INTO #temp_table
    SELECT uid FROM dbo.change_table WITH (NOLOCK)
     WHERE non_unique_value = 'something'

UPDATE dbo.change_table
   SET somecol = newval
  FROM dbo.change_table c
       INNER JOIN
       #temp_table t
       ON (c.uid = t.uid)

2) Продолжительность транзакции Чем дольше открыта транзакция, тем выше вероятность возникновения разногласий. Если есть способ сократить время, в течение которого записи остаются заблокированными, вы можете снизить вероятность возникновения взаимоблокировки. Например, выполните столько же операторов SELECT (например, поисков) в начале кода вместо выполнения INSERT или UPDATE, затем поиска, затем INSERT, а затем еще одного поиска. Здесь можно использовать подсказку NOLOCK для SELECT в «статических» таблицах, которые не изменяются, уменьшая «след» блокировки кода.