Используя SQL Server Business Intelligence Development Studio, я делаю много простых файлов в потоки данных назначения OLE DB, чтобы импортировать данные в мои таблицы SQL Server. В разделе «Режим доступа к данным» в редакторе назначения OLE DB по умолчанию используется «таблица или представление», а не «таблица или представление - быстрая загрузка». В чем разница; Единственное заметное отличие, которое я могу заметить, заключается в том, что быстрая загрузка передает данные намного быстрее.
Режим доступа к данным потока данных SSIS - в чем смысл «таблицы или представления» по сравнению с быстрой загрузкой?
Ответы:
Режимы доступа к данным целевого компонента OLE DB доступны в двух вариантах - быстрый и не быстрый.
Быстрый, «таблица или представление - быстрая загрузка» или «переменная имени таблицы или представления - быстрая загрузка» означает, что данные будут загружаться на основе набора.
Медленно - либо «таблица или представление», либо «таблица или переменная имени представления» приведут к тому, что SSIS выдаст в базу данных операторы вставки singleton. Если вы загружаете 10, 100, может быть, даже 10000 строк, вероятно, между этими двумя методами заметна небольшая разница в производительности. Тем не менее, в какой-то момент вы собираетесь насытить ваш экземпляр SQL Server всеми этими небольшими запросами. Кроме того, вы собираетесь использовать чертовски в своем журнале транзакций.
Зачем вам нужны не быстрые методы? Плохие данные. Если бы я отправил 10000 строк данных, а 9999-я строка имела дату 2015-02-29, у вас было бы 10 000 атомарных вставок и фиксаций / откатов. Если бы я использовал метод Fast, весь пакет из 10 тыс. Строк будет либо сохранен, либо ни одного из них. И если вы хотите знать, какие строки (ы) допустили ошибку, самый низкий уровень детализации у вас будет 10k строк.
Теперь есть подходы к тому, чтобы как можно быстрее загружать как можно больше данных и при этом обрабатывать грязные данные. Это подход каскадного сбоя, и он выглядит примерно так
Идея заключается в том, что вы найдете правильный размер для вставки как можно большего количества данных за один снимок, но если вы получите неверные данные, вы попытаетесь восстановить данные последовательно меньшими партиями, чтобы получить неверные строки. Здесь я начал с Максимального размера вставки (FastLoadMaxInsertCommit), равного 10000. В расположении строки ошибок я изменяю его на Redirect Rowс Fail Component.
Следующий пункт назначения такой же, как указано выше, но здесь я пытаюсь выполнить быструю загрузку и сохраняю ее партиями по 100 строк. Опять же, протестируйте или сделайте вид, что пришли к разумному размеру. Это приведет к отправке 100 пакетов по 100 строк, потому что мы знаем, что где-то там есть хотя бы одна строка, которая нарушила ограничения целостности для таблицы.
Затем я добавляю третий компонент в микс, на этот раз сохраняю партиями по 1. Или вы можете просто изменить режим доступа к таблице с версии Fast Load, потому что она даст тот же результат. Мы сохраним каждую строку индивидуально, и это позволит нам «что-то» делать с одной (-ой) плохой строкой.
Наконец, у меня есть безопасное место назначения. Может быть, это «та же» таблица, что и предполагаемый пункт назначения, но все столбцы объявлены как nvarchar(4000) NULL. Все, что попадает за эту таблицу, необходимо исследовать и очищать / отбрасывать, или каким бы ни был ваш плохой процесс разрешения данных. Другие выдают дамп в плоский файл, но на самом деле все, что имеет смысл для отслеживания неверных данных, работает.
Быстрая загрузка хорошо документирована под опциями FAST LOAD
Сохраните значения идентификаторов в импортированном файле данных или используйте уникальные значения, назначенные SQL Server.
Сохранить нулевое значение во время операции массовой загрузки.
Проверьте ограничения на целевой таблице или представлении во время операции массового импорта.
Получите блокировку на уровне таблицы на время операции массовой загрузки. Укажите количество строк в пакете и размер фиксации.
В чем разница; Единственное заметное отличие, которое я могу заметить, заключается в том, что быстрая загрузка передает данные намного быстрее.
Под капотом table or viewбудет использоваться отдельная команда SQL для каждой строки для вставки, против table or view - with fast loadбудет использоваться команда BULK INSERT.
Если вы видите выше варианты, которые доступны в BULK INSERT, например, number of rows in the batch= ROWS_PER_BATCHи commit size=BATCHSIZE
Другой сценарий будет ..
Максимальный размер фиксации вставки по умолчанию (2147483647) слишком велик. Так, например, вы вставляете 500К строк и из-за нарушения ПК пакет не выполняется. В этом случае весь пакет не будет работать, если вы используете опцию FAST LOAD. Вы также не сможете получить описание ошибки.
Это где вы можете иметь в table or viewкачестве конечного вывода ошибок. Таким образом, из 500 КБ вы используете FAST LOAD, начиная с размера вставки 5 КБ. В случае сбоя 1 строки в этом пакете вы перенаправляете эти 5K партии на table or viewзагрузку - при этом используется вставка строки за строкой ТОЛЬКО для строк 5K, а также вы можете перенаправить ошибку table or viewв плоский файл ... если 5K, вы сможете точно определить, что вызвало сбой.
Преимущество вышеописанного метода состоит в том, что если ни одна из строк не завершится с ошибкой, он будет использовать BULK INSERT (быстрая загрузка) для всего пакета.
Поклонник SSIS billinkc ответил на аналогичный вопрос о Stackoverflow .