Кажется сумасшедшим, чтобы делать это в этой последней дате, но ...SSIS против производительности DTS
Я восстановления некоторые ETL инфраструктуры с Ракетно источником Software ВСЕЛЕННОЙ и назначения SQL. Старая платформа назначения была SQL 2000 на Windows Server 2003, новая платформа - SQL 2012 на Windows Server 2012. В обоих случаях для подключения к источнику используется драйвер ODBC. На новой платформе все отлично работает, но время выполнения пакета экспоненциально медленнее. Например, одна таблица с примерно 1,3 миллионами строк и 28 столбцами занимает около часа, используя SQL 2000/DTS и более 3,5 часов с использованием SQL 2012/SSIS. Оба SQL-сервера виртуализованы на Xen Server, на сервере 2012 года больше ОЗУ и больше vCPU, ни у машины нет преимуществ в дисковой инфраструктуре. Никакие показатели (Memory, disk IO и т. Д.) Не краснеют (или действительно даже приближаются) на сервере 2012 во время выполнения пакета.
Я прочитал несколько сообщений на форуме, описывающих один и тот же сценарий, но ни у кого действительно не было решения, которое работает для меня. Поскольку все эти сообщения были довольно датированы (большинство из этих преобразований из DTS в SSIS произошло в SQL 2005-ых днях), мне было любопытно, была ли какая-нибудь более свежая информация.
Пакеты очень простые табличные копии, без преобразований. Я использую столбец «SELECT», столбец, .. FROM sourcetable »для моего исходного подключения и« Таблица или представление - быстрая загрузка »для моего адресата. Медленный APPEARS должен быть на стороне источника уравнения, хотя я не могу быть уверен.
Любая помощь приветствуется.
У вас есть мои соболезнования по поводу работы с DTS;) Тем не менее, было бы интересно удалить текущий пункт назначения и передать эти результаты в задачу сценария или что-то, что может действовать как приемник данных, не влияя на производительность. Цель состоит в том, чтобы увидеть, что представляет собой теоретический максимальный уровень SSIS, который способен извлекать данные из вашего источника. Запустите N раз с сервера, чтобы установить базовую линию. Если это сопоставимо с временем с пунктом назначения, хорошо, что было бы интересно ... Мое следующее место, чтобы посмотреть, будет ли изменение количества строк в буфере до более низкого значения улучшит производительность. – billinkc
Статья, в которой говорится о подходе к запоздалым SQL Server источник http://sqlblog.com/blogs/rob_farley/archive/2011/02/17/the-ssis-tuning-tip-that-everyone-misses.aspx – billinkc
billinkc, я не знаю, как я вознаграждаю вас за это , но ты мой герой на этот день, и теперь я уезжаю на выходные с чувством триумфа вместо поражения! Скорее интуитивно понятный, чтобы уменьшить буфер, но это была волшебная пуля. На следующей неделе я сделаю тонкую настройку, но уменьшив значение по умолчанию от 10 000 строк до 10, сократит время выполнения одного пакета со среднего часа и изменится на 23 минуты, что эквивалентно старому времени DTS. Не могу вас поблагодарить! – stinkyP