Подтвердить что ты не робот

Повторное развертывание пакетов SSIS - кеш?

Недавно мы заметили, что перераспределенные пакеты SSIS иногда не включают последние изменения... Когда я просматриваю dtsx с помощью блокнота, я вижу измененный script в коде, поэтому изменения, безусловно, есть.

Мое предположение заключалось в том, что компоненты пакетов SSIS script в конечном итоге скомпилированы в сборку где-то в процессе - это вполне вероятно, так как я предполагаю, что код С# не может работать без компиляции. Поэтому теоретически, если эти сборки затем будут кэшироваться и не будут немедленно перезаписаны (по какой-то причине), это объяснит эту проблему.

Единственное "доказательство", которое заставляет меня думать, что моя теория верна, - если я продолжаю запускать пакет в какой-то момент, он внезапно переходит к новому коду.

Однако до сих пор я не нашел, почему и как это происходит, если есть... Может ли кто-нибудь помочь?

UPDATE: MSDN говорит: "В отличие от более ранних версий, где вы могли бы указать, были ли предварительно скомпилированы сценарии, все сценарии предварительно скомпилированы в SQL Server 2008 Integration Services (SSIS) и более поздних версиях". - Если предварительно скомпилированные они означают, что вместо фактического пакета запускается предварительно скомпилированная версия (я думаю, это потому, что сам пакет, похоже, не скомпилирован, поскольку код отображается в "Блокноте" ), должен быть способ принудительно чтобы перезаписать предварительно скомпилированную сборку... но как?

UPDATE: Одним из четырех основных компонентов SSIS является служба SQL ServerIntegration Services, которая является службой Windows. По-видимому, эта служба будет кэшировать метаданные компонентов/задач, чтобы механизм времени выполнения SSIS мог опросить кеш, чтобы увидеть, что установлено, что может ускорить загрузку пакетов. Однако, если пакеты хранятся в файловой системе (а не в службах интеграции SQL) и выполняются с помощью агентских заданий, задание агента будет использовать 64-разрядную версию DTEXEC для выполнения пакетов. Я еще не нашел доказательств того, что там будет задействовано какое-либо кэширование, но есть определенные возможности для проверки ряда параметров на этапе проверки выполнения, таких как номера версий, - может быть по какой-то причине.

4b9b3361

ОТВЕТЫ

Ответ 1

Это немного знакомо с чем-то, с чем я столкнулся некоторое время назад. К сожалению, я не помню точно , когда я столкнулся с этим (так что я не могу проверить наверняка), но я верю. Исправление, которое я нашел, состояло в том, чтобы убедиться, что Я явно вызвал команду Build | Build st_5bd541c294054c25b9e7eb55b92bd0e2 из меню редактора script (VSTA) перед закрытием окна. (Конкретное имя проекта будет отличаться для каждого script, очевидно, поскольку оно основано на GUID, однако в Build есть только одно возможное подменю.)

Явное приглашение команды Build гарантирует, что двоичный код для script получает ASCII-кодировку и сохраняется в XML полученного файла .dtsx. Я привык к SSIS 2005, всегда создавая для меня всякий раз, когда я закрывал редактор script. По-видимому, есть причудливые крайние случаи, когда SSIS 2008 не всегда создает проект script, когда редактор закрывается.

BTW, предварительно скомпилированные исполняемые файлы, как представляется, хранятся в теге исходного XML-кода под названием BinaryItem:

  <DTS:Executable DTS:ExecutableType="Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask, Microsoft.SqlServer.ScriptTask, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" DTS:ThreadHint="0">
    <DTS:Property DTS:Name="ObjectName">SCR_StepOne</DTS:Property>
    <DTS:ObjectData>
      <ScriptProject Name="ST_5bd541c294054c25b9e7eb55b92bd0e2" VSTAMajorVersion="2" VSTAMinorVersion="1" Language="CSharp" EntryPoint="Main" ReadOnlyVariables="User::FileOneName,User::OutputFolder" ReadWriteVariables="">
        <BinaryItem Name="\bin\release\st_5bd541c294054c25b9e7eb55b92bd0e2.csproj.dll">
          TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
          AAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
          ZGUuDQ0KJAAAAAAAAABQRQAATAEDADuOb04AAAAAAAAAAOAAAiELAQgAABAAAAAIAAAAAAAAPi8A
          AAAgAAAAQAAAAABAAAAgAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAMAQIUAABAA

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

Предостережение: я не нашел официальную документацию Microsoft по этому вопросу.

Ответ 2

Вы посмотрели на sysssispackages, чтобы сравнить номер сборки версии пакета в msdb с вашим номером сборки в Visual Studio/SSIS?

SELECT name, verbuild
FROM msdb.dbo.sysssispackages
WHERE name LIKE '%bla%'

(Откорректируйте предложение WHERE как необходимо, чтобы найти свой пакет. Никогда не "ВЫБЕРИТЕ * FROM msdb.dbo.sysssispackages", поскольку он содержит пакет XML в одном из столбцов.)

И в Visual Studio откройте пакет, затем щелкните правой кнопкой мыши на фоне пакета и выберите "Свойства" в контекстном меню. Посмотрите на поле VersionBuild. Он должен соответствовать номеру из SELECT выше!

Я знаю, что это не фактическое решение вашей проблемы, но это может помочь найти причину проблемы. Если число больше, это означает, что развертывание пакета не работает.

Ответ 3

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

  • Создайте свой пакет.
  • Откройте свойства на вашем пакете и запишите свойство "Версия сборки" (в качестве альтернативы откройте .dtsx в блокноте и найдите атрибут DTS: VersionBuild.)
  • Разверните свой пакет.
  • На шаге задания агента SQL перейдите на вкладку "Проверка".
  • Введите конструкцию версии в поле ввода "Проверить сборку пакета".
  • Выполнение задания.

Я не знаю, заставит ли SSIS выкинуть свой кеш и получить недавно развернутый пакет, но я знаю, если вы измените номер сборки пакета .dtsx вручную, а затем попытайтесь повторно запустить этап задания он терпит неудачу, потому что сборка пакета не соответствует тому, что она ищет, поэтому она определенно выполняет проверку времени выполнения.