Подтвердить что ты не робот

SSIS - назначение OLE DB - загрузка таблицы или представлений против быстрой загрузки

Из того, что я читал:

Режим доступа к данным в таблице или представлениях фиксирует каждую строку за раз в качестве транзакции. Таким образом, создание пакета, передающего 5 миллионов строк, занимает много времени (30 + минут).

Режим доступа к быстрой загрузке позволяет указать строки партии и размер фиксации при вставке в пункт назначения. Например, вставка 5 миллионов записей займет чуть более 2 минут.

Теперь возникает вопрос, где один из пакетов SSIS, загружаемых в DW, использует таблицу или режим доступа к данным в адресе OLE DB. По моему мнению, это для того, чтобы подобрать строки ошибок, которые он вставляет (ограничение ошибок) в таблицу записей ошибок. Таким образом, у нас есть процесс, который занимает более 30 минут. В свою очередь, Fast-Load займет менее 2 минут для того же действия.

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

Спасибо заранее.

4b9b3361

Ответ 1

То, что я видел в этой ситуации, - это каскадный отказ. Попытайтесь вставить в OLE DB Destination в последовательно меньших партиях, чтобы попытаться получить как можно больше в пакетном режиме, прежде чем запускать одиночные вставки.

Предположим, что у вас есть размер фиксации в 10 тыс. строк (произвольное число, проверка вашей ситуации и т.д.). Переадресовывать неудачные строки в OLE DB Destination, все еще в режиме быстрой загрузки, но с размером фиксации 2,5 тыс. Строк. Добавьте еще один пункт назначения ole db с размером фиксации, возможно, 100, а затем конечный пункт назначения, который находится в режиме RBAR. Затем вы можете идентифицировать неисправные строки и делать все, что с ними нужно сделать.

Ответ 2

Ну, я использовал пункт назначения в режиме Fastload, и я перенаправил его строки ошибок в другое Destination для одного и того же DestinationTable, но в режиме Row by row.

Это было не так медленно, как Row by Row, но не так быстро, как Fastload, но это сработало для меня!
Также у меня есть описание ошибки и реальные ошибки.