Многопоточность и блокировка записей БД

Вместо того, чтобы изобретать велосипед, вы должны сделать это с помощью служб SQL Server Integration Services (SSIS). Он оптимизирован для этих сценариев, особенно в выпуске 2008 года.

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

Для справки, к таким проблемам вы подходите, разбивая свои данные. Я говорю не о физическом разбиении хранилища (т.е. добавить разбиение таблиц), а о логическом, обрабатывающем разбиении. Вы делите свои 2 млн. записей в N разделах на основе имеющихся у вас критериев, которые можно использовать на уровне доступа к данным, например. индексированный столбец, а затем выделить N процессоров, каждый из которых начнет работать в своем собственном разделе. Идея состоит в том, чтобы процессоры не перекрывались при попытке доступа к одним и тем же строкам. «Процессоры» могут быть потоками или, что еще лучше, ThreadPool ставит в очередь рабочие элементы, которые используют асинхронные методы доступа к базе данных.

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

with cte as (
   select top (@batchSize) *
   from myTable with (rowlock, updlock, readpast)
   where <record is ready to be processed>)
update cte
   set <mark record processing>
output inserted.*

Хитрость заключается в блокирующих подсказках, используемых при выборе: при принудительной блокировке и блокировке записи блокируются для обработки текущим процессором. Добавляя подсказку readpast, каждый процессор будет пропускать записи, которые уже заблокированы другими процессорами. Таким образом, каждый процессор получает свою собственную партию записей @batchSize для обработки, какой бы ни была обработка.

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

я бы сделал так:

• настройте одну таблицу (изначально пустую) для хранения ПК ваших основных строк. Назовите это PKs_Done_Table
• Один поток «выбрать бла из таблицы, в которой нет pk (выбрать pk из PKs_done_Table)
• тот же поток захватывает строки (или блоки строк — используйте NTILE или множественное чтение) из этого выбора и передает их другим потокам для фактической обработки.

Обработка потоков:

• принимает строки/блоки строк
• начать транзакцию
• делает работу
• вставляет pks готовой работы в PKs_done_table
• совершает транзакцию.

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