Оптимизация производительности BCP для данных BLOB

Я занимаюсь планированием оперативной миграции базы данных объемом 2 ТБ в многораздельные таблицы. В широком смысле система представляет собой хранилище документов, при этом большая часть пространства выделяется для больших объектов размером от 50 до 500 КБ, с небольшим процентом в диапазоне от 500 КБ до 1 МБ. Часть миграции будет включать данные BCPing из старой базы данных в новую.

BCP является предпочтительным подходом, поскольку текущее / историческое разделение данных позволяет извлекать более старые данные поэтапно (в течение более тихих периодов) до окончательного переключения, сводя к минимуму влияние на работающую систему. Объем данных и доступность хранилища не позволяют перестроить на месте схему разделов .

Я подозреваю, что может быть некоторый выигрыш в производительности при экспериментировании с KILOBYTES_PER_BATCH, а не с ROWS_PER_BATCH, из-за содержимого BLOB. В документации BCP предполагается, что SQL может оптимизировать операции на основе этого значения.

Чего я не могу найти, так это какого-либо руководства о природе этих оптимизаций или о том, с чего начать тестирование. В отсутствие предложений я попробую начать с коротких пробежек на границах 4/8/16/32/64 МБ.

Вероятно, выигрывают от изменения размера пакета (параметр BCP -a, а не настройка уровня сервера), но я склонен довести это значение до 65535, если у кого-то нет более формального подхода.

Это не прямой ответ на ваш вопрос, но есть несколько статей, которые вы могли бы прочитать, прочитав их (если вы не нашли их первыми :-)). Они о загрузке большого количества данных с использованием bcp / массового копирования. Я прочитал их все и не нашел ничего подробного о KILOBYTES_PER_BATCH, все они используют ROWS_PER_BATCH, но я уверен, что вы найдете другую полезную информацию.

• Загрузка 1 ТБ менее чем за 1 час (от команды SQL CAT) - список советов здесь (цитата):

  • Запустите столько процессов загрузки, сколько у вас доступно процессоров. Если у вас 32 процессора, запустите 32 параллельных загрузки. Если у вас 8 процессоров, запустите 8 параллельных загрузок.
  • Если у вас есть контроль над созданием ваших входных файлов, сделайте так, чтобы они имели размер, равномерно делимый на количество потоков загрузки, которые вы хотите запустить параллельно. Также убедитесь, что все записи принадлежат одному разделу, если вы хотите использовать стратегию переключения раздела.
  • Используйте BULK вместо BCP, если вы запускаете процесс на компьютере с SQL Server.
  • Используйте разделение таблиц, чтобы получить еще 8-10%, но только если ваши входные файлы ГАРАНТИРУЮТСЯ, чтобы соответствовать вашей функции разделения, то есть все записи в одном файле должны быть в одном разделе.
  • Используйте TABLOCK, чтобы избежать блокировки строк одновременно.
  • Используйте ROWS PER BATCH = 2500 или что-то вроде этого, если вы импортируете несколько потоков в одну таблицу.

• 10 лучших рекомендаций по созданию хранилища реляционных данных большого масштаба (от команды SQL CAT) - советы (цитата):

  • Используйте модель восстановления SIMPLE или BULK LOGGED во время начальной загрузки данных.
  • Создайте секционированную таблицу фактов с кластеризованным индексом.
  • Создайте неиндексированные промежуточные таблицы для каждого раздела и отдельные файлы исходных данных для заполнения каждого раздела.
  • Заполните промежуточные таблицы параллельно (используйте несколько задач BULK INSERT, BCP или SSIS)
  • Создайте кластерный индекс для каждой промежуточной таблицы, затем создайте соответствующие ограничения CHECK.
  • ПЕРЕКЛЮЧИТЕ все разделы в разделенную таблицу.
  • Построить некластеризованные индексы на многораздельной таблице.

• Руководство по производительности загрузки данных (от команды SQL CAT)

• Загрузка массовых данных в секционированную таблицу - статья с рекомендациями по SQL Server (статья Technet)

• Пример нарастающей массовой нагрузки в SQL Server 2000 (статья Technet)

• Извлеченные уроки и выводы из большого ускоренного POC (от команды SQL CAT)

• Советы по настройке производительности для SQL Server BCP (Брэд МакГи)

• Влияние на производительность: поиск оптимального размера партии (Линчи Ши)

и очевидные ссылки MSDN:

• Управление партиями для группового импорта
• Управление размерами группового копирования
• Вопросы производительности при массовом копировании
• Рекомендации по оптимизации массового импорта
• Оптимизация производительности массового импорта

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