SQL Server и обновление (или вставка) параллелизма

Question

Я получил большое преобразование - 299Gb изображений JPEG, уже находящихся в базе данных, в эквиваленты эскизов для целей отчетности и пропускной способности.

Я написал потокобезопасную функцию SQLCLR, чтобы сделать бизнес повторной выборки изображений, прекрасной работы.

Проблема заключается в том, что когда я выполняю ее в операторе UPDATE (из поля PhotoData в поле ThumbData), это выполняется линейно, чтобы предотвратить условия гонки, используя только один процессор для повторной выборки изображений.

Итак, как бы я мог наилучшим образом использовать 12 ядер и установку phat raid для этой машины базы данных? Следует ли использовать подзапрос в предложении FROM инструкции обновления? Это все, что требуется для обеспечения параллелизма в этой операции?

В любом случае операция разбивается на партии, около 4000 изображений на каждую партию (в оконном запросе около 391 тыс. Изображений), эта машина имеет много ресурсов для записи.

Answer 1

Я тоже рекомендую «круговую» методологию, защищаемую kragen2uk и onupdatecascade (я голосую за них). Я знаю, что я читал что-то раздражающее о процедурах CLR и SQL paralellism, но я забыл, что это было сейчас ... но я думаю, что они не играют хорошо вместе.

Бит, который я делал в прошлом при выполнении аналогичных задач, чтобы создать таблицу, в которой перечислены все партии выполняемой работы. Для каждого подключения, которое вы запускаете, оно идет в эту таблицу, выводит следующую партию, маркирует ее как обрабатываемую, обрабатывает, обновляет ее как «Готово» и повторяет. Это позволяет вам оценивать производительность, управлять масштабированием, останавливать и перезапускать без необходимости запускать, и дает вам что-то, чтобы показать, насколько полная задача (не говоря уже о том, что она фактически что-то делает).

Answer 2

Проверьте настройки конфигурации для максимальной степени параллелизма (MAXDOP) на вашем SQL Server. Вы также можете установить значение MAXDOP.

Эта ссылка может быть полезна для вас http://www.mssqltips.com/tip.asp?tip=1047

веселит

Answer 3

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

Следует отметить, что он будет решать только вопрос о том, следует ли использовать параллелизм в момент компиляции запроса. Кроме того, если запрос скомпилирован в то время, когда загрузка ЦП выше, SQL-сервер с меньшей вероятностью рассматривает параллелизм.

Answer 4

Найдите некоторые критерии, чтобы разбить набор на отдельные подмножества строк (1-100, 101-200, что угодно), а затем вызывать оператор обновления из нескольких соединений одновременно, где каждое соединение обрабатывает одно подмножество строк в таблице. Все соединения должны работать параллельно.