Советы общего назначения по SSIS, пока я жду уточнения потребностей.
Когда мне следует использовать инструменты служб SSIS и операторы TSQL
Люди часто испытывают искушение использовать трансформации из коробки, так как это выглядит правильно. Выберите таблицу в раскрывающемся списке, добавьте сортировку, добавьте другой источник данных, тоже сортируйте, объедините слияние, возможно, агрегат.
Когда проблемная область мала, скажем, от десятков до сотен тысяч, разница в обработке незначительна. Если пакет выполняется за 2 минуты вместо 1 или потребляет 80% памяти сервера по сравнению с 40% во время обработки, люди могут этого не заметить.
Когда объем данных достигает переломного момента, плохие решения по дизайну упаковки съедят ваш обед.
Сорт
Когда в вашей исходной СУБД есть запрос на отсортированные данные, в базе данных может быть кластерный индекс или что-то еще, что может сэкономить время на фактическую сортировку данных. Когда SSIS получит запрос на отсортированные данные, вы будете многократно платить за эти операции.
Сортировка в SSIS - это полностью блокирующая асинхронная операция. Это означает, что все данные, проходящие через эту точку, должны прибыть в это преобразование, быть обработанными до того, как они могут быть отправлены в нисходящем направлении. Если у вас есть ряды с баджиллионом или очень медленный источник, вы действительно заметите это, когда он выполнит одну из этих операций. Может быть, вы скажете, я могу подождать, потому что мне действительно нужны отсортированные данные, но время - не единственный ресурс, который вы тратите. Вы также удваиваете свои требования к памяти, поскольку асинхронные преобразования требуют копирования данных из одного буфера в другой.
Возможно, вы по-прежнему принимаете затраты времени и памяти для простоты использования предмета OOB, но вы можете не закончить оплату. Ваш сервер имеет 32 ГБ памяти, и SSIS использует их все. Каждая строка стоит тысячу байт, и у вас есть 16 миллионов строк данных, проходящих через ваш поток данных. Он попадает в сортировку, и данные начинают накапливаться. Как только появится последняя строка, вы использовали 16 ГБ памяти для исходных данных. Операции сортировки начинают сортировку, и она копирует 16 ГБ в другую 16 ГБ памяти и, к сожалению, SSIS не хватает памяти. Теперь вы платите третью цену за временное хранение файлов. Когда механизм выполнения находится под давлением памяти, он, в конечном счете, начинает пейджинг на диск. Как только это произойдет, игра заканчивается, если вы заботитесь о производительности, но ваши страдания могут не быть таковыми. Если вы не установили значение BlobTempStoragePath для каждого потока данных, этот файл будет записан во временное хранилище по умолчанию, которое, вероятно, C: \ что-то или другое. Ваши системные администраторы вырезали очень скудный раздел C, поскольку там работает только ОС, поэтому файл подкачки объемом 16 ГБ, внезапно записываемый на этот диск, занимает все доступное пространство, а затем ОС становится несчастной, пакет не работает и указатель пальцем начинается. Не то чтобы я когда-либо был там
Мораль истории
Насколько это возможно, делайте все в исходной системе. Приведенный выше сценарий предназначен для сортировки, но урок применим ко всем «общим» операторам.
Какой-нибудь совет по более эффективному решению здесь?
Что касается того, как вы можете очистить свой запрос, эти сопоставления сведут меня с ума. Есть ли шанс, что вы можете создать N справочных таблиц (или встроенную табличную функцию), чтобы обеспечить соответствие между сохраненным значением и представленным значением? Затем вы можете абстрагировать всю логику кейса.
Ссылки
Наконец, цифры в этом посте удивительно зависят от аппаратного обеспечения и рабочих нагрузок