Как устранить предупреждения «неиспользуемые выходные столбцы» в заданиях служб SSIS? - PullRequest
3 голосов
/ 06 ноября 2008

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

+--------------------+
| OLEDB Source task: |
| read staging table |
+--------------------+
          |
          |
+---------------------------+
| OLEDB Command task:       |
| upsert into history table |
+---------------------------+
          |
          |
+---------------------------+
| OLEDB Command task:       |
| delete from staging table |
+---------------------------+

моя задача 'upsert' выглядит примерно так:

--------------------------------------
-- update existing rows first...
update history
set    field1 = s.field1
    ...
from   history h
inner  join staging s
on     h.id = s.id
where  h.last_edit_date <> s.last_edit_date -- only update changed records

-- ... then insert new rows
insert into history
select s.*
from   staging s
join   history h
on     h.id = s.id
where  h.id is null
--------------------------------------

Задача очистки также является командой SQL:

--------------------------------------
delete from staging
--------------------------------------

Поскольку у задачи upsert нет определений выходных столбцов, в журнале я получаю кучу предупреждений:

[DTS.Pipeline] Warning: The output column "product_id" (693) on output 
"OLE DB Source Output" (692) and component "read Piv_product staging table" (681) 
is not subsequently used in the Data Flow task. Removing this unused output column 
can increase Data Flow task performance. 

Как я могу исключить ссылки на эти столбцы? Я попытался добавить несколько разных задач, но ни одна из них не позволяет мне «проглотить» входные столбцы и исключить их из вывода задачи. Я хотел бы сохранить свои журналы в чистоте, чтобы я видел только реальные проблемы. Есть идеи?

Спасибо!

Ответы [ 6 ]

5 голосов
/ 06 ноября 2008

Объединить все - выберите только те столбцы, через которые вы хотите пройти, - удалите все остальные.

Я думал, что они решат эту проблему в версии 2008 года, чтобы колонки могли быть обрезаны / подавлены из конвейера.

2 голосов
/ 06 ноября 2008

ОК, я нашел обходной путь на форумах MSDN :

использовать преобразование компонента скрипта между заданиями 1 и 2; выбрать все входные столбцы; оставьте тело скрипта пустым.

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

По-прежнему неясно, зачем мне вообще нужен источник OLEDB, поскольку SQL в задаче 2 подключается к исходным таблицам и выполняет всю работу, но когда я удаляю источник OLEDB, поток данных запускается, но не обрабатывает строки, таким образом, промежуточная таблица никогда не очищается, и затем последующий процесс размещения измененных строк в промежуточной таблице не выполняется из-за нарушений PK. Но это проблема для другого дня. Это немного неуклюже, но мои журналы чистые.

1 голос
/ 14 апреля 2017

У меня такой же вопрос. Я получил хороший ответ. Вы можете найти это здесь .

Как сказал * Марк Войцехович :

Вот несколько рекомендаций по снижению сложности, которые, в свою очередь, улучшат производительность:

  • Уменьшить столбцы в источнике. Если вы выбираете столбцы, которые впоследствии никоим образом не используются, затем удалите их из запроса или снимите их с исходного компонента. Удаление столбцов таким способом удаляет их из буфера, который будет занимать меньше памяти.
  • Уменьшить количество компонентов в потоке данных . Очень длинные потоки данных легко создавать, их сложно тестировать и еще сложнее поддерживать. Потоки данных ожидают единицу работы , то есть поток данных отсюда туда с несколькими вещами в середине. Вот где потоки данных сияют, фактически они защищают себя от сложности с ограничениями памяти и максимальным количеством потоков. Лучше разделить работу на отдельные потоки данных или хранимые процедуры. Вы можете поместить данные в таблицу и прочитать их дважды, например, вместо многоадресной рассылки.
  • Использовать базу данных. SSIS - это такой же инструмент оркестровки, как и инструмент перемещения данных. Я часто обнаруживал, что при использовании простых потоков данных для обработки данных , за которыми следуют вызовы хранимых процедур для обработки данных , они всегда превосходят поток данных «все в одном».
  • Увеличьте количество раз, когда вы записываете данные . Это полностью противоречит интуиции, но если вы обрабатываете данные в меньших наборах операций, они быстрее выполняются и легче тестируются. При наличии чистого листа я часто буду проектировать ETL для записи данных из источника в промежуточную таблицу, выполнять этап очистки из таблицы этапов в другую, при желании добавить соответствующий шаг для объединения данных из разных источников в еще одну таблицу и наконец, последний шаг для загрузки целевой таблицы. Обратите внимание, что каждый источник помещается в собственную целевую таблицу, а затем объединяется, используя базу данных. Первый и последний шаги настроены для быстрого выполнения и предотвращения блокировки или блокировки на любом конце.
  • Массовая загрузка . Предыдущий шаг действительно хорош, когда вы гарантируете, что происходит массовая загрузка. Это может быть непросто, но обычно вы можете достичь этого, используя «быструю загрузку» в месте назначения OLEDB и никогда с помощью команды oledb. Удаление индексов и их повторное добавление выполняется быстрее, чем загрузка на месте (за редким исключением).
1 голос
/ 27 ноября 2008

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

Это легко исправить, дважды щелкнув по источнику данных. В вашем случае (Исходная задача OLEDB: | | читать промежуточную таблицу) Затем нажмите на столбцы и отмените выбор столбцов, которые вам не нужны ни в одном из ваших будущих заданий.

Это удалит эти предупреждения из вашего журнала прогресса.

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

0 голосов
/ 20 ноября 2008

Ваш DataFlow Task должен заканчиваться словом "upsert". Затем вернитесь в поток управления и создайте Execute SQL Task для удаления из подготовки. Свяжите свой DataFlow Task с вашим исполнительным sql.

Я не использую сторонний инструмент для своих апперсетов, но делаю так, как предлагает Cade, который состоит в том, чтобы разделить ваш поток данных на новые записи, которые просто направляются на OLE DB Destination (или подобные), и обновлять записи, которые могут на вашу команду oledb для обновлений. Вы можете разделить поток, используя объединение или поиск.

0 голосов
/ 08 ноября 2008

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

Мне кажется, что очистка будет выполняться один раз для каждой строки, но это не имеет смысла.

DataFlow обычно не используются для выполнения массовых действий для каждой строки, поступающей по конвейеру. Если вы используете конвейер, UPSERT-ы обрабатываются с использованием компонентов Lookup (или стороннего TableDifference), а затем spli в конвейере к назначению OLEDB (BULK INSERT) и либо команде OLEDB (один раз на UPDATE), либо другому назначению OLDEB для «ОБНОВЛЕНИЕ ПРОЦЕДУРЫ».

Обычно я делаю это с DataFlow для загрузки промежуточной таблицы без какого-либо разделения, а затем с одной задачей «Выполнение SQL» в потоке управления для выполнения всего остального в прямом SQL UPSERT (как у вас), вызывая SP.

OLEDBCommand полезен, если вы не хотите иметь промежуточную таблицу и вместо этого читаете плоский файл и хотите выполнить UPDATE или INSERT, используя компонент Lookup или что-то еще. Но он будет вызываться для каждой строки в конвейере.

...