2016-09-01 8 views
0

Я пытаюсь реализовать процесс ETL для наших медленно изменяющихся таблиц измерений типа 1 в базе данных SQL 2014. Нагрузка должна происходить на разных серверах, и я бы предпочел не использовать связанные серверы.Как обрабатывать строки, которые были удалены из источника, используя SSIS Slowly Changing Dimension

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

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

+0

Не связано, просто интересно, что не так с использованием связанных серверов? – Anton

+1

Вы неправильно понимаете SSIS ... вам нужно будет переместить данные в таблицу в процессе слияния. У SSIS нет выхода как такового, но он имеет метод обработки ошибок, который может использоваться для создания «удаленных» строк. Конечно, один сплошной TSQL MERGE мог бы это сделать, но позволяет предположить, что разрозненные таблицы требуют SSIS ... тогда распознать удаленную строку является несуществующей строкой в ​​SSIS. Тем не менее, плохая строка все еще является строкой в ​​SSIS. –

+0

Спасибо за информацию. Я думаю, что слияние с TSQl будет лучшим вариантом. Есть несколько причин, по которым я не хотел использовать связанные серверы рядом с безопасностью, которую я получил в прошлом (другой разработчик не смог что-то сделать так, как я его настроил, и в конечном итоге ставил SA для аутентификации и т. Д.), но также потому, что этот процесс должен быть способен нажимать на несколько серверов и легко перейти к новым, и довольно просто изменить строку подключения с конфигурациями пакетов в SSIS. Конечно, это может быть сделано со связанными серверами и с немного динамическим SQL. – schiznig

ответ

0

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

Если вы хотите сделать это в SSIS, вы можете использовать Lookup, чтобы найти строки, которые необходимо удалить (найдите строки в своем месте назначения, которые не находятся в исходном файле, используя вывод соответствия), затем OLE DB Command, чтобы удалить их. Но я бы подумал о том, чтобы просто переместить данные в промежуточную область и сделать это в TSQL, потому что SSIS будет делать это с помощью агонистической строки. Аналогично инструменту SCD - это может быть нормально при небольших объемах данных, но если вы имеете дело с большими суммами (или может быть в будущем), это может стать неуправляемым.

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

+0

Спасибо за информацию. Большинство из этих таблиц выглядят довольно маленькими, наибольшее число может составлять 5000 строк, но, похоже, лучше всего будет использовать область промежуточной области/TSQL. Я подозревал, что слияние стадий/TSQL будет тем, что мне нужно будет делать, но просто хотел проверить, не было ли у SSIS волшебной пули, поскольку я немного взволновался, когда увидел преобразование SCD. – schiznig

+0

@schiznig - К сожалению, у SSIS много функциональности, что, честно, больше проблем, чем того стоит. Вы правы, чтобы использовать его, чтобы избежать связанных серверов и управлять конфигурацией - это область, где он сияет, но многие задачи и преобразования не так или иначе не оптимальны. И в некоторых случаях их сложнее использовать, чем эквивалент SQL! –

 Смежные вопросы

  • Нет связанных вопросов^_^