Режимы доступа к данным целевого компонента 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. Все, что попадает за эту таблицу, необходимо исследовать и очищать / отбрасывать, или каким бы ни был ваш плохой процесс разрешения данных. Другие выдают дамп в плоский файл, но на самом деле все, что имеет смысл для отслеживания неверных данных, работает.
