Будут ли возникать взаимоблокировки при удалении строк из таблицы, добавляемой другим процессом?

Я должен заархивировать данные из таблицы в другую таблицу, пока используется исходная таблица. Процесс архивирования состоит в том, чтобы скопировать строки в другую таблицу, а затем удалить строки из исходной таблицы. Строки, подлежащие архивированию, выбираются столбцом со свойством Identity.

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

Удаляемые строки находятся в нижней части нумерации столбцов Identity, в то время как новые строки будут добавляться в конце таблицы.

Мое беспокойство - тупики. Есть ли вероятность того, что между двумя процессами могут возникнуть тупики?

Процесс архивирования будет запущен из хранимой процедуры? Должен ли я установить для параметра DEADLOCK_PRIORITY значение LOW, чтобы гарантировать, что в случае возникновения тупиковой ситуации будет завершен процесс архивирования, а не запущенное приложение?

Должен ли я также установить уровень изоляции транзакции?

Спасибо

Определение таблицы:

    CREATE TABLE [dbo].[DummyName](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Payment Reference] [nvarchar](18) NULL DEFAULT (N''),
    [Payment Amount] [decimal](28, 10) NULL,
    [Payment Date] [datetime] NULL,
    [Payer ID] [nvarchar](34) NULL DEFAULT (N''),
    [Payer Account] [nvarchar](174) NULL DEFAULT (N''),
    [Payer Name] [nvarchar](174) NULL DEFAULT (N''),
    [Payer Type] [nvarchar](35) NULL DEFAULT (N''),
    [Bank Reference] [nvarchar](16) NULL DEFAULT (N''),
...

Определение индекса:

ALTER TABLE [dbo].[DummyName] ADD PRIMARY KEY NONCLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

Строки, подлежащие архивированию, выбираются столбцом со свойством Identity.

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

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

Просто убедитесь, что не удалили слишком много строк сразу из «живой» таблицы после их архивирования, так как это может привести к эскалации блокировки (что может показаться нежелательным в вашей ситуации). Проверьте прекрасную статью Майкла Сварта по поводу этой темы делать пакетную обработку таким образом , что способствует производительности и параллелизм: Заботиться Когда Сценарии ПАРТИЙ

Несмотря на то, что ваша основная таблица представляет собой кучу , вы все равно должны быть в порядке в отношении взаимоблокировок, так как все ваши запросы будут стремиться искать на некластеризованном ПК и удалять с помощью RID оттуда. Кажется возможным, что вы можете столкнуться с блокировкой на уровне страницы (или взаимоблокировками) внутри самой кучи, в зависимости от множества факторов, но это будет трудно узнать наверняка, не увидев рабочую нагрузку в действии.

Должен ли я установить для параметра DEADLOCK_PRIORITY значение LOW, чтобы гарантировать, что в случае возникновения тупиковой ситуации будет завершен процесс архивирования, а не запущенное приложение?

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

Должен ли я также установить уровень изоляции транзакции?

Уровень изоляции по умолчанию ( READ COMMITTED) должен быть нормальным в этой ситуации.