Избегайте, чтобы мертвая блокировка для параллельного удалила

У меня есть стол, названный продуктами, у которого есть много колонок.

Это - временная таблица, используемая для сообщения о цели. Данные будут обработаны к этому столу одновременно многопользовательскими запросами. (отделите Хранимую процедуру, чтобы сделать операции DML к этому столу),

Структура таблицы: Создайте продукты стола (случай uniqueidentifier, вставленная дата и время, col1, col2...)

Вставленная колонка будет населена с GETDATE (), чтобы иметь, когда данные будут вставлены. И у колонки случая есть newid() стоимость. у одного пользовательского запроса будет один уникальный идентификатор; может иметь миллион рядов. Ниже вопросы, которые будут выполнены одновременно, который порождение мертвой блокировки. Пожалуйста, советуйте мне

Query1: "Установите изоляцию транзакции readuncommitted Удалите P из продуктов (Nolock) где случай = 'XXXX xxx xxx xx'"

Query2: "Set transaction isolation readuncommitted Delete P from Products (Nolock) where inserted<=DATEADD(hh, -10, getdate())"

Примечание: несгруппированный индекс создается на колонке случая.

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

Обратите внимание, что я не мог способный к первичному ключу, поскольку он потребляет время, когда я вставляю 10 миллионов рядов в стол (это для одной сделки; есть 20 параллельных переходов). Отчет должен быть произведен раньше. И у моей процедуры есть многократные 35 DML statments, есть приблизительно 15 Операторов удаления, например, колонка с другими колонками (Удалите из стола где случай = @instance и col1 = @col1).

1
nl ja de
Смотрите на это stackoverflow.com/questions/9952137/…
добавлено автор Phil, источник

2 ответы

(1) Необходимо прекратить использовать прочитанный нейтральный изоляция. Использование, по крайней мере , прочитанный переданный .

(2) There are a number of things you could try to avoid deadlocks, like ensuring your different transactions access database objects in the same order, etc. This would be worth a read - http://support.microsoft.com/kb/169960

(3) Отключите повышение уровня блокировок для своего стола (больше гранулированных замков так лучший параллелизм, но больше замка наверху):

alter table Products set (lock_escalation disable)

(4) Отвергните Замки Страницы и позвольте Блокировки строки на своих индексах (будет означать, что вы не можете дефрагментировать индексы, но можно все еще восстановить их):

alter index [] on Product set (allow_row_locks = on, allow_page_locks = off)
5
добавлено

Во-первых, нет никакого замка, что можно взять эти операторы удаления помимо монопольной блокировки. Ваш isolation level and NOLOCK hints are being ignored by Sql Server:

(Nolock) Только относится , ИЗБРАННЫЙ заявление.

Два предложения:

Измените свой некластерный индекс на случай к кластерному индексу. НО, только сделайте это, если можно измениться NEWID() к NEWSEQUENTIALID ().

Во-вторых, вместо того, чтобы выступить удаляют , чтобы удалить отчеты, более старые, чем 10 часов... рассматривают осуществление катящегося разделения. Это удалит любое утверждение, вызванное очисткой с ваш другим , удаляют операции.

1
добавлено
SqlCom.ru - Стиль жизни SQL
SqlCom.ru - Стиль жизни SQL
908 участник(ов)

Правила чата - https://t.me/sqlcom/88269 @sqlcom - основной канал (только MS SQL) @sql_ninja - второй канал (SQL вопросы начального уровня и свободное общение) @Gopnegbot - Викторина по SQL Server (наберите в привате /quiz). Предложения в @sql_ninja

SQL_Ninja
SQL_Ninja
340 участник(ов)

Правила чата - https://t.me/sqlcom/88269 @sqlcom - основной канал (только SQL) @sql_ninja - второй канал (SQL вопросы начального уровня и свободное общение) @Gopnegbot - Викторина по SQL Server (наберите в привате /quiz)