Atualizando pacotes SSIS

Para reafirmar, você tem pacotes no SQL Server 2008 R2 e deseja migrá-los para o SQL Server 2012. Os pacotes geralmente são exportados para "formato de arquivo".

A única maneira de saber se eles atualizaram com sucesso é atualizá-los e descobrir. O maior desafio que me lembro foi com pacotes que tinham Componentes de Script (não Tarefas), já que o pipeline tem algumas mudanças estruturais grandes. A outra ressalva óbvia é se você usou uma tarefa/componente personalizado de terceiros/internos. Isso exigirá migração manual e modificação dos pacotes no Visual Studio.

Você tem duas opções com sua atualização. O SSIS agora tem dois modelos de implantação. Modelo de implantação de pacote , também conhecido como Classic/Legacy, que é o que você tem aqui. Os pacotes podem ser implantados no sistema de arquivos ou msdb, você controla sua configuração, registro, controle de versão, etc.

O modelo de implantação do projeto é a nova moda. Existe um catálogo SSISDB dedicado que lida com toda a configuração, registro, controle de versão, etc. para você. Eu geralmente o prefiro ao primeiro, pois fornece uma melhor experiência de gerenciamento e execução. A migração de projetos de modelo de implantação de pacote para o modelo de implantação de projeto requer a alteração dos próprios pacotes. O assistente de atualização ajudará nisso, mas removerá o registro e a configuração, pois deseja que você use a nova maneira. Isso exigirá mais testes do que o simples teste de fumaça exigido com um caminho de atualização do modelo de implantação de pacote. Se vale a pena o esforço, especialmente em um ambiente pesado de controle de alterações, é melhor responder por você.

Uma abordagem para atualização de implantação de pacote

dtutil.exe é a ferramenta de linha de comando para implantar pacotes SSIS. Assumindo o caminho de instalação padrão, você procuraria o dtutil que está dentro C:\Program Files\Microsoft SQL Server\100\DTS\Binn\dtutil.exepara extrair os pacotes como estão. Quando uma versão mais recente das ferramentas do SSIS toca um pacote de versão anterior, a primeira coisa que acontece é uma atualização na memória para essa versão do SSIS. Menciono isso como se você não usasse o controle de origem, talvez queira extrair os pacotes "como estão" da instância 2008 R2 existente antes de implantar na instância 2012. Eu tenho um script para isso

;
WITH FOLDERS AS
(
    -- Capture root node
    SELECT
        cast(PF.foldername AS varchar(max)) AS FolderPath
    ,   PF.folderid
    ,   PF.parentfolderid
    ,   PF.foldername
    FROM
        msdb.dbo.sysssispackagefolders PF
    WHERE
        PF.parentfolderid IS NULL

    -- build recursive hierarchy
    UNION ALL
    SELECT
        cast(F.FolderPath + '\' + PF.foldername AS varchar(max)) AS FolderPath
    ,   PF.folderid
    ,   PF.parentfolderid
    ,   PF.foldername
    FROM
        msdb.dbo.sysssispackagefolders PF
        INNER JOIN
            FOLDERS F
            ON F.folderid = PF.parentfolderid
)
,   PACKAGES AS
(
    -- pull information about stored SSIS packages
    SELECT
        P.name AS PackageName
    ,   P.id AS PackageId
    ,   P.description as PackageDescription
    ,   P.folderid
    ,   P.packageFormat
    ,   P.packageType
    ,   P.vermajor
    ,   P.verminor
    ,   P.verbuild
    ,   suser_sname(P.ownersid) AS ownername
    FROM
        msdb.dbo.sysssispackages P
)
SELECT 
    -- assumes default instance and localhost
    -- use serverproperty('servername') and serverproperty('instancename') 
    -- if you need to really make this generic
    'dtutil /sourceserver ' + @@SERVERNAME + ' /SQL "'+ F.FolderPath + '\' + P.PackageName + '" /copy file;".\' + P.PackageName +'.dtsx"' AS cmd
FROM 
    FOLDERS F
    INNER JOIN
        PACKAGES P
        ON P.folderid = F.folderid
 WHERE
     F.FolderPath LIKE '\SERV%';

Se você gosta de viver perigosamente, pode alterar o SELECT final para ignorar o sistema de arquivos e implantar diretamente no outro servidor. Isso pressupõe que você já criou a mesma estrutura de pastas ali.

'dtutil /sourceserver ' + @@SERVERNAME + ' /SQL "'+ F.FolderPath + '\' + P.PackageName + '" /destserver MyShiny2012Box /copy SQL;"'+ F.FolderPath + '\' + P.PackageName + '"' AS cmd

Eu observei o que foi dito acima e parece aproximadamente correto, mas você deve testá-lo. Ele deve renderizar um comando semelhante ao seguinte

dtutil /sourceserver localhost /SQL "\SERV-ABC\Package" /destserv MyShiny2012Box /copy SQL;"\SERV-ABC\Package"

Para que isso funcione, você precisa ter certeza de que dtutil é a versão 2012 que deve estar emC:\Program Files\Microsoft SQL Server\110\DTS\Binn\dtutil.exe

Dos comentários

Não confunda o ferramental com os produtos e/ou servidores instalados. A partir de 2005, há uma versão do SSMS lançada com cada versão do SQL Server (isso fica obscuro a partir do SQL Server 2016). O SSMS possui um "explorador de objetos". A parte do mecanismo de banco de dados do explorador de objetos pode ser usada para gerenciar todas as versões do SQL Server e a recomendação comum é sempre usar a versão mais recente do SSMS em seu ambiente, pois terá a maioria das correções de bugs, etc.

Onde este conselho pode falhar se você usar as opções "outras" para o Object Explorer. O SSIS é a única coisa que uso com regularidade, então abordarei isso.

Você deve usar a versão do SSMS que corresponda à instância do SQL Server de destino para que ela "funcione". Na captura de tela, você está conectado aos Serviços de Integração do servidor 2008 R2 ... seja lá o que for, mas ignore. Sim, ignore essa ferramenta blecherous como é inútil. Não ajuda se você tiver várias instâncias em execução e só executa pacotes em ... 32 ou 64 bits, não me lembro qual.

Em vez disso, use o único tipo de Pesquisador de Objetos que funciona em suas instâncias - o mecanismo de banco de dados. Os pacotes SSIS armazenados no "banco de dados" estarão no msdb. Use a consulta acima ou explore essas tabelas você mesmo. Todos os dados estão lá. Existem procedimentos tsql para mover pacotes, armazená-los, etc, embora eu prefira o dtutil.