Импорт новой таблицы базы данных - PullRequest
1 голос
/ 22 октября 2008

Там, где я нахожусь, есть основная система, работающая на большом мэйнфрейме AIX. Для создания отчетов и операций существует ночной дамп из мэйнфрейма в SQL Server, так что каждый из наших 50-ти клиентов находится в своей собственной базе данных с идентичными схемами. Каждую ночь этот дамп занимает около 7 часов, и мы ничего не можем с этим поделать: мы застряли на том, что предоставил поставщик приложений.

После дампа на сервер sql мы используем его для запуска ряда других ежедневных процедур. Одной из таких процедур является импорт данных в своего рода таблицу «песочницы» для управленческих отчетов, которая объединяет записи из особенно важной таблицы из разных баз данных в одну таблицу, которую менеджеры, которые не знают sql, могут использовать для запуска специальных отчетов. не затирая остальную часть системы. Это, опять же, бизнес: руководители хотят этого, и у них есть возможность увидеть, как мы это реализуем.

Процесс импорта этой таблицы сам по себе занимает пару часов. Он фильтрует около 40 миллионов записей, распределенных по 50 базам данных, в 4 миллиона записей, а затем индексирует их по определенным столбцам для поиска. Даже в пару часов это по-прежнему меньше трети первоначальной загрузки, но у нас заканчивается время для ночной обработки, мы не контролируем дамп мэйнфрейма, и мы контролируем это. Поэтому мне было поручено искать способы улучшить существующую процедуру.

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

Итак, мой вопрос: какой самый эффективный способ загрузить эту таблицу? Правильно ли мы думаем, что индексирование позже лучше? Или мы должны создать индексы перед импортом данных? Должны ли мы загружать таблицу в порядке индекса, чтобы избежать массового переупорядочения страниц, а не крупных клиентов в первую очередь? Может ли параллельная загрузка усугубить ситуацию, вызвав одновременный доступ к большому количеству дисков или лишив нас возможности контролировать порядок? Есть другие идеи?

Обновление
Ну, что-то не так. Я смог провести некоторые тесты в течение дня, и нет никакой разницы во времени загрузки, создаются ли индексы в начале или в конце операции, но мы экономим время на построение самого индекса ( Курс строится практически мгновенно без данных в таблице).

Ответы [ 4 ]

1 голос
/ 22 октября 2008

Индекс в конце, да. Также рассмотрите возможность установки уровня журнала в BULK LOGGED, чтобы минимизировать записи в журнал транзакций. Просто не забудьте установить его обратно в ПОЛНОЕ после того, как вы закончили.

1 голос
/ 22 октября 2008

Я довольно много работал с загрузкой больших массивов данных в SQL Server и провел некоторое тестирование производительности при включении индекса и его последующем добавлении. Я обнаружил, что BY FAR гораздо эффективнее создать индекс после загрузки всех данных. В нашем случае загрузка с добавлением индекса в конце заняла 1 час, а добавление индекса с включенным индексом - 4 часа.

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

1 голос
/ 22 октября 2008

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

Вы можете получить выигрыш в производительности, используя bcp для загрузки данных в промежуточную область и выполняя несколько задач параллельно (SSIS сделает это). Напишите универсальную оболочку для пакетного файла для bcp, которая принимает путь к файлу (и, если необходимо, имя таблицы) и запускает серию заданий в полдюжины потоков с задачами «Выполнение процесса» в SSIS. Для 50 рабочих мест, вероятно, не стоит пытаться написать процесс контроллера загрузки, управляемый данными. Оберните эти задачи в контейнер последовательности, чтобы вам не приходилось явно поддерживать все зависимости.

Вы должны обязательно удалить и заново создать индексы, так как это значительно сократит количество операций ввода-вывода во время процесса.

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

0 голосов
/ 22 октября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...