SSIS OLEDB Выполнение SQL-команд выполняется медленно

Question

У меня есть таблица с более чем миллионными записями.

1. Когда я выполняю свой запрос в SSMS, он занимает около 1:24 менее 2 минут точно в любой момент времени и возвращает около 600 000 записей.
2. SSIS занимает больше двух часов, и я смог экспортировать его только один раз.

Вот пример SQL:

SELECT distinct 
A.Col1, A.Col2, A.Col3, A.Col4, A.Col5, A.Col6, A.Col7, B.Col3 
FROM tblA A 
inner join tblB B on A.Col1 = B.col1 and 
A.Col2 = 'AB' AND A.Col3 Not In ('A','B','C') AND 
A.Col3 In ('FPC','FPE','PRN','SUB','RVW','FPO','FEV','PRM') 

Примечание: Индексы делают существует для всех столбцов выберите SQL-запрос (и для столбцов, указанных в пункте где).

В SSIS,

1. У меня есть задачи потока данных на поток управления.
2. OleDB Источник с запросом SQL-запроса.
3. OleDB Направление tbl.

что может вызвать задержку в SSIS?

Answer 1

Ваша проблема, скорее всего, с вашим назначением OLE DB и скоростью, с которой он может принимать строки. Вы можете подтвердить это, проверив копию вашего пакета с удаленным местом назначения OLE DB.

Предполагая, что в этом случае наиболее распространенная причина заключается не в использовании опции «Быстрая загрузка» в пункте назначения OLE DB для доставки на SQL Server.

Answer 2

По моему опыту, это может быть одна из двух вещей:

1. Это может быть то, что известно как параметр-фырканье. Это просто означает, что иногда он связывает плохой (медленный) план запроса с параметрами запроса +, и из-за кеширования этот плохой план может стать «застрявшим» и постоянно повторно использоваться для конкретного приложения или использовать его. Способ обнаружить это - использовать SQL Profiler для захвата плана запроса для запроса задачи SSIS, а затем сравнить его с планом запроса быстродействующей версии SSMS. Если планы запросов существенно различаются, у вас, вероятно, есть проблема с параметром-обнюхиванием.

2. Однако для SSIS существует более распространенная проблема (на которую ссылается мой комментарий/вопрос и ответ Майка Хони): Поскольку SSIS использует конвейерную архитектуру, все, что вам нужно, это один медленный компонент в цепочке, чтобы остановить работу весь трубопровод. И одна очень распространенная причина медленных компонентов не использует лучшие настройки задачи для задач потока данных.

Использование «Fast Load» является одним из возможных вариантов, однако в моем опыте, есть еще один параметр, который чаще всего является проблемой для конвейеризации в сетях, и это «DefaultBufferMaxRows». Значение по умолчанию для этого - 10 000, которое я всегда считал слишком высоким для сетевых подключений и, вероятно, должен составлять от 100 до 1000 для этих ситуаций.

Это свойство целевого DFT (задачи потока данных) в потоке управления, поэтому для его изменения просто выберите значок этой задачи в представлении «Управление потоком». Вы должны увидеть DefaultBufferMaxRows в области свойств (в разделе «Разное»). Вы также можете уменьшить пропорциональность DefaultBufferSize.