Поиск преобразования в ошибке SSIS: не препятствует вставке уже существующей записи - PullRequest
0 голосов
/ 08 февраля 2019

У меня есть пакет служб SSIS, который считывает из источника, выполняет преобразование поиска, чтобы проверить, существует ли запись в месте назначения, если она существует, она перенаправляет для сопоставления с выводом и обновляет ее, в противном случае для сопоставления не выводит и вставляет ее.Проблема в том, что иногда он вставляет запись, которая должна быть перенаправлена ​​для обновления.Это делается с помощью задания, если я вручную выполню пакет, все в порядке.Компонент поиска настроен правильно с соответствующим столбцом.

Я не могу понять, почему это происходит, самая глупая вещь - я не могу отладить его, потому что вручную все в порядке.

Есть идеи?

1 Ответ

0 голосов
/ 09 февраля 2019

Два варианта в тех сценариях, в которых у вас есть вставки, которые должны были быть обновлениями.

Дублирующиеся исходные значения

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

Исходные данные

Key|Value
A  |abc
B  |bcd
A  |cde

Данные назначения

Key|Value
C  |yza
B  |zab

В этой ситуации, при условии поведения по умолчанию компонента Lookup, полного кэша, перед пакетомначинает выполнение, SSIS запускает исходный запрос для справочной таблицы Lookup.Только после того, как все данные таблицы поиска будут кэшированы , поток данных станет потоком данных.

  • В первом ряду A: abc попадает в поиск.Нет, нет данных и выкл в путь вставки.
  • Вторая строка B: bcd попадает в поиск.Нет, нет данных и выкл в путь вставки.
  • Третья строка A: cde попадает в поиск.Нет, нет данных и нет пути к пути вставки (и, возможно, к нарушению первичного / уникального ключа)

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

В этой ситуации есть два решения: во-первых, изменить режим кэширования с полного на нет(или частично).При этом компонент поиска будет выдавать запрос к целевой таблице для каждой строки , которая проходит через поток данных.Это может дорого обойтись для больших рядов.Это также не будет надежным доказательством, потому что поток данных имеет концепцию буферов, и в ситуации, подобной нашей выборке из трех строк, все они помещаются в один буфер.Все строки в буфере будут попадать в «Уточняющий запрос» примерно в одно и то же время, и, следовательно, целевая таблица по-прежнему не будет содержать значение A, когда третья строка проходит через компонент.Вы можете затормозить поток данных и заставить его обрабатывать по одной строке за раз, изменив размер буфера на 1, но это, как правило, не будет хорошим решением.

Другое разрешение будет дедуплицировать /справиться с выживанием.Какая строка должна попасть в базу данных, если у нашего источника разные значения для одного и того же бизнес-ключа?Первый, последний, выбрать один?Если вы не можете удалить данные до того, как они попадут в поток данных, вам нужно будет выполнить дедупликацию данных с помощью компонента Aggregate, чтобы свести ваши данные как можно лучше.

Поиск с учетом регистра

Исходные данные

Key|Value
A  |abc
B  |bcd
a  |cde

Целевые данные

Key|Value
C  |yza
B  |zab

Другой сценарий, когда компонент Lookup укушает вас, заключается в том, что сопоставление по умолчанию, полный кэш, основано на правилах сопоставления .NET для строк.,Таким образом, AAA не равно AaA.Если ваш поиск выполняет сопоставление строк, даже если ваша база данных имеет регистр нечувствительный , поиск SSIS не будет нечувствительным.

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

Затем я гарантирую, что данные в моей справочной таблице будут одинаково обработаны при использовании компонента «Уточняющий запрос».

Предупреждения компонента поиска

Режим полного кэширования: - нечувствителен к изменениям справочных данных - совпадения с учетом регистра - как правило, быстрее в целом - задерживает поток данных до кэширования данных поиска - пустые совпадения пустыестрока - Кэшированные данные требуют ОЗУ

Нет режима кэширования: - чувствительны к изменениям в справочнике - сопоставление чувствительности к регистру основано на правилах системы поиска (в БД чувствительна к регистру, вы получаете чувствительное совпадение)- Это зависит (100 строк исходных данных, 1000 строк справочных данных - никто не заметит. 1B строк исходных данных и 10B строк справочных данных - кто-то заметит. Существуют ли индексы для поддержки поиска и т. Д.) - Соответствует NULLничего - Нет заметных накладных расходов памяти SSIS

Частичный кэш:Частичный кеш по большей части похож на параметр «Нет кеша», за исключением того, что, когда он сопоставляется со справочной таблицей, он будет кешировать это значение до тех пор, пока не закончится выполнение или пока оно не будет вытолкнуто из-за нехватки памяти

Кэш поиска НУЛЕВОЙ ответ

...