Оператор слияния VS Преобразование поиска

Я застрял с проблемой с разными представлениями.

Текущий сценарий:

Я использую пакеты SSIS для передачи данных с сервера A на сервер B каждые 15 минут. Создал 10 пакетов для 10 разных таблиц, а также создал 10 промежуточных таблиц для них. В задаче DataFlow он выбирает данные с сервера A с идентификатором больше последнего импортированного идентификатора и сбрасывает их в промежуточную таблицу (каждая таблица имеет свою собственную промежуточную таблицу). После задачи DataFlow я использую оператор MERGE для объединения записей из промежуточного хранения. таблицы в таблицу назначения, где идентификатор НЕ соответствует.

Проблема:

Это позаботится обо всех вставленных новых записях, но если однажды запись будет выбрана заданием SSIS и обновлена ​​​​в источнике, я не смогу снова подобрать ее и не смогу получить обновленные данные.

Вопросы:

  • Как я смогу получить обновление, слишком сильно влияющее на исходный сервер базы данных.
  • Использовать ли оператор MERGE и выбирать 10 000 записей при каждом запуске? (каждые 15 минут)
  • Использую ли я преобразование LookUp для выполнения обновлений?
  • В некоторых таблицах содержится более 2 миллионов записей, и их число постоянно растет, так что какой подход для них лучше всего подходит?

ПРИМЕЧАНИЕ:

Я могу обрезать таблицы в месте назначения и повторно вставить полные данные для первого запуска.

Редактировать:

В источнике есть столбец «LAST_UPDATE_DATE», который я могу использовать в своем запросе.


person snp.it    schedule 07.05.2014    source источник
comment
Вы говорите, что существующие записи обновляются в источнике, и вам нужно их идентифицировать? Вам нужно добавить что-то в источник, например, столбец «последнее обновление» или таблицы триггеров/журналов для сбора информации CDC.   -  person Nick.McDermaid    schedule 08.05.2014
comment
Я бы реализовал в исходнике, а также в промежуточной и финальной таблицах эти 4 столбца: CreateBy, CreatedOn, ModifyBy, ModifyOn. Я также определяю естественный или бизнес-ключ таблиц, таким образом вы можете избежать использования этой истории об идентификаторе больше, чем то, что я не могу понять. Если вы предоставите эту информацию и, возможно, схему, я смогу вам помочь.   -  person Playing With BI    schedule 08.05.2014
comment
@ElectricLlama: Да, существующие записи обновляются. Использование триггера не рекомендуется.   -  person snp.it    schedule 08.05.2014
comment
Итак, проблема в том, что вы не знаете, какие записи в источнике были обновлены. Вам нужен либо существующий последний обновленный столбец (который должен быть заполнен приложением, которое изменяет данные), либо триггер для захвата и идентификации изменений на уровне базы данных. Вот и все.   -  person Nick.McDermaid    schedule 09.05.2014
comment
Вам обязательно нужно уточнить: можете ли вы в настоящее время идентифицировать измененные записи в источнике? (по CDC, поле last_updated или что-то в этом роде)   -  person Nick.McDermaid    schedule 14.05.2014


Ответы (1)


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

пример:

MERGE target_table as destination_table_alias
USING ( 
SELECT <column_name(s)>
 FROM  source_table
) AS source_alias
ON 
 [source_table].[table_identifier] = [destination_table_alias].[table_identifier]

WHEN MATCHED THEN UPDATE 
SET [destination_table_alias.column_name1] = mySource.column_name1,
    [destination_table_alias.column_name2] = mySource.column_name2
WHEN NOT MATCHED THEN
INSERT 
([column_name1],[column_name2])
VALUES([source_alias].[column_name1],mySource.[column_name2])

Итак, по вашим пунктам:

  1. Обновление может быть достигнуто с помощью логики WHEN MATCHED в операторе слияния.
  2. Если у вас есть последний идентификатор загружаемой таблицы, вы можете включить его в качестве фильтра в свой оператор выбора, чтобы набор данных был добавочным.
  3. Поиск не требуется, если используется 'WHEN MATCHED'.
  4. используя фильтр выбора в части выбора оператора слияния.

Надеюсь это поможет

person swilliams    schedule 08.05.2014
comment
Если я правильно понимаю, ОП не может определить, какие записи в источнике были обновлены, поэтому он не может их инсценировать. Поэтому на этом этапе ничего в промежуточной таблице никогда не будет НЕ СООТВЕТСТВУЕТ. - person Nick.McDermaid; 09.05.2014
comment
@SWilliams: я пишу этот оператор MERGE в задаче «Выполнение SQL», которая будет подключаться только к одному источнику данных (один сервер), а это означает, что мне нужно иметь как исходную, так и целевую таблицу на одном сервере. Как я могу сравнить таблицы на двух разных серверах. - person snp.it; 09.05.2014
comment
@SWilliams: у меня есть промежуточная таблица для этого, и я могу ее заполнить, но сколько данных я должен заполнить? (Top 10000, top2000) Невозможно составить полную таблицу, так как она запускается каждые 15 минут и содержит миллионы записей для нескольких таблиц. - person snp.it; 09.05.2014
comment
snp.it, правильно ли @ElectricLlama? Вы не можете определить, что изменилось в исходной системе? Я не уверен, что понимаю, как вы используете оператор слияния для извлечения данных из источника, если вы загружаете его в промежуточную таблицу. Может быть пару вариантов. 1. Можно ли использовать систему отслеживания измененных данных? Для этого требуется SQL Server Enterprise Edition. Если нет, 2. Есть ли в исходной системе уникальный ключ? Если это так, вы можете создать промежуточную таблицу, содержащую последний загруженный идентификатор из источника, и извлекать из исходной системы только те данные, которые больше, чем последний загруженный идентификатор. Требуется дополнительная информация. - person swilliams; 14.05.2014