В хранимой процедуре SSIS используется Temp Table 2008 и 2014

В настоящее время я пишу пакет SSIS, который извлекает данные из хранимой процедуры через источник OLE DB. Хранимая процедура содержит довольно неприятный запрос, который я смог улучшить с помощью временных таблиц. Если я переключу эти временные таблицы на переменные таблицы, логические чтения скажутся от примерно 1,3 миллиона до примерно 56 миллионов. Мне неудобно с 1,3 миллионами, но я не могу доволен 56 миллионами логических чтений. Таким образом, я не могу преобразовать таблицы temp в переменные таблицы.

Однако SSIS (или, скорее, SQL Server) не может разрешить метаданные для этого запроса, поэтому пакет не будет работать. Я нашел несколько различных решений в Интернете, но ни один из них, похоже, не работает как для SQL Server 2008, так и для SQL Server 2014. В настоящее время мы обновляем все наши серверы до 2014 года, и этот конкретный пакет работает с 2008 годом в DEV, 2014 в QA и в 2008 году в производстве. К осени уровень PROD будет равен 2014, и после этого уровень DEV будет повышаться. К сожалению, я не могу дождаться, пока эти обновления не выпустят этот пакет SSIS. Данные должны начать двигаться к следующей неделе. Таким образом, мне нужно выяснить, как получить метаданные, разрешенные для обеих сред. Вот что я пробовал до сих пор:

  • Добавьте фиктивный выбор в блок IF 1=0 , который возвращает правильные метаданные. Это работает в 2008 году, но не в 2014 году.

  • Используйте SET FMTONLY OFF в начале хранимой процедуры. Это работает в 2008 году, но не в 2014 году. Кроме того, он заставляет хранимую процедуру запускаться один раз для каждого возвращенного столбца (в этом случае более 30), что является разрывом транзакции, даже если оно действительно работает.

  • Используйте EXEC ... WITH RESULT SETS (( ... ));. Это работает в 2014 году, но не в 2008 году.

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

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

Я мог бы также создавать реальные таблицы в базе данных, которые заменяют эти временные таблицы. Мне не очень нравится это решение, но это то, что я могу терпеть. Если я в конечном итоге сделаю это, я бы, вероятно, переключился на использование WITH RESULT SETS в будущем.

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

ОТВЕТЫ

Ответ 1

Несмотря на ваше нежелание, я думаю, что вы сделали правильный выбор, а специальная зона постановки - правильный путь. Большинство из ETL, с которыми я работал, имеют специальную промежуточную базу данных, не говоря уже о таблицах. Тогда у вас есть преимущество в том, что вы можете более четко контролировать хранилище, что делает производительность более надежной, и все это в целом более удобно. Например, вы можете создать выделенный непрерывный блок быстрого дискового пространства для этих таблиц со своей собственной группой файлов и т.д. Я бы наверняка увидел 2 отдельных SP, полагающихся на несколько физических таблиц, чем на самом деле gnarly single.

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