A versão 2012 do SQL Server Integration Services, SSIS, entregou um catálogo SSISDB que rastreia as operações de pacotes (entre outras coisas). A execução do pacote padrão para soluções usando o modelo de implantação do projeto terá o logon no SSISDB ativado.

Quando um pacote é executado, ele System::ExecutionInstanceGUIDé preenchido com um valor que, se alguém estiver usando log explícito (para sys.sysdtslog90/sys.sysssislog ), registraria todos os eventos para uma execução específica do pacote.

O que eu gostaria de saber é como vincular um ExecutionInstanceGUID a qualquer coisa no catálogo SSISDB. Como alternativa, é um pacote SSIS executando no privado SSISDB com o valor de seucatalog.executions.execution_id

Por fim, estou tentando usar a tabela de auditoria personalizada existente e vinculá-la ao histórico detalhado no catálogo SSISDB, mas não consigo encontrar o link.

Demais para comentar, mas tentando alguma coisa. Na página msdn da tabela de sistema catalog.executions , recebo:

activation_id - bigint - O identificador exclusivo (ID) da instância de execução.

Neste artigo - SSIS 2012 - Exibir informações do Connection Manager para execuções anteriores - eu entendo que:

O SSIS 2012 fornece uma nova variável de sistema, ServerExecutionID, para seu uso dentro de pacotes; portanto, se você fizer log / notificações personalizadas, é uma boa variável a incluir, pois será um ponteiro direto para as visualizações de catálogo que usaremos para encontrar informações da cadeia de conexão. ... Catalog.executions contém uma linha por execução. É aqui que filtraremos por activation_id.

Com uma consulta de amostra de:

DECLARE @execution_id BIGINT = 41753; -- Your execution_id/ServerExecutionID goes here.
SELECT e.package_name,
        e.start_time,
        e.end_time,
        e.status,
        emc.package_path,
        CAST(emc.property_value AS VARCHAR(1000)) AS connection_string
   FROM catalog.executions e
   JOIN catalog.event_messages em
     ON e.execution_id = em.operation_id
   JOIN catalog.event_message_context AS emc WITH (FORCESEEK)
     ON em.event_message_id = emc.event_message_id
    AND emc.property_name = 'ConnectionString'
    AND emc.context_type = 80 -- Connection Managers
  WHERE e.execution_id = @execution_id;

O que não vejo é o seu ExecutionInstanceGUID nesta tabela. O que vejo, porém, é este item antigo do Connect, onde há a seguinte história:

SSIS RunningPackage.InstanceID! = System :: ExecutionInstanceGUID, embora devam ser iguais.

Portanto, minha conclusão é que ExecutionInstanceGUID não está relacionado ao Execution_id, mas a alguma coluna InstanceId, caso você possa ter um no SSISDB.

Criei um projeto SSIS usando o Modelo de Implantação 2012 que consiste em um único pacote. Nesse pacote, adicionei um Gerenciador de conexões OLE DB, apontei para tempdb e soltei uma tarefa de script na tela. Também ativei o log explícito usando o Gerenciador de conexões OLE DB e capturei o OnInformationevento.

Informações sobre incêndio do SCR

Eu configurei minha tarefa de script para pegar dois parâmetros: System::ExecutionInstanceGUIDe System::ServerExecutionIDadmito que, neste momento, eu não havia notado a segunda variável até a resposta de Marian. Dentro da tarefa, levanto 2 eventos de Informações para que eu possa obter os valores registrados. Isso deve ser registrado na tabela explícita (dbo.sysssislog) e no log "livre" (catalog.operation_messages).

    public void Main()
    {
        bool fireAgain = true;
        string description = string.Empty;
        string variable = string.Empty;
        string value = string.Empty;

        variable = "System::ServerExecutionID";
        value = Dts.Variables[variable].Value.ToString();
        description = string.Format("{0}: {1}", variable, value);
        Dts.Events.FireInformation(0, "Reporting", description, string.Empty, 0, ref fireAgain);

        variable = "System::ExecutionInstanceGUID";
        value = Dts.Variables[variable].Value.ToString();
        description = string.Format("{0}: {1}", variable, value);
        Dts.Events.FireInformation(0, "Reporting", description, string.Empty, 0, ref fireAgain);

        Dts.TaskResult = (int)ScriptResults.Success;
    }

Implantar e executar

Em seguida, implantei meu projeto em um servidor e o executei.

Abri o relatório de operações e cliquei nos SCR Fire infodetalhes da tarefa.

O item circulado em vermelho mostra que estamos visualizando os detalhes da Operação 8, conforme o esperado. As linhas destacadas são os OnInformationeventos que borbulharam os valores dessas duas variáveis ​​do sistema. Também como esperado, o valor System::ServerExecutionIDcorresponde ao que estava no relatório. O valor de System::ExecutionInstanceGUIDera sem sentido, como sempre, mas estava presente {3F515780-8062-40AA-B9EC-C320CBAC5EFD}.

Amarrando tudo junto

Agora eu tinha dois logs diferentes que queria amarrar.

consulta sysssislog

A execução dessa consulta retirou as linhas relevantes da tabela de log da velha escola.

SELECT
    L.event
,   L.source
,   L.message 
FROM
    dbo.sysssislog AS L
WHERE
    L.executionid = '{3F515780-8062-40AA-B9EC-C320CBAC5EFD}'
ORDER BY
    L.id ASC;

Os resultados pareciam

event   source  message
PackageStart    ParameterTest   Beginning of package execution.

OnInformation   SCR Fire info   System::ServerExecutionID: 8
OnInformation   ParameterTest   System::ServerExecutionID: 8
OnInformation   SCR Fire info   System::ExecutionInstanceGUID: {3F515780-8062-40AA-B9EC-C320CBAC5EFD}
OnInformation   ParameterTest   System::ExecutionInstanceGUID: {3F515780-8062-40AA-B9EC-C320CBAC5EFD}
PackageEnd  ParameterTest   End of package execution.

consulta catalog.operation_messages

A execução deste consulta contra o catálogo SSISDB mostrou todas as mensagens que estavam no relatório acima e também confirmados eu poderia ligar o valor messagepara operation_id, bem como sobre adbo.sysssislog.executionid

SELECT 
    OM.* 
FROM 
    catalog.operation_messages AS OM
WHERE
    OM.operation_id = 8;

Esses resultados foram

operation_message_id    operation_id    message_time    message_type    message_source_type message extended_info_id
30  8   2013-04-02 21:02:34.1418917 -05:00  10  30  ParameterTest:Validation has started.   NULL
31  8   2013-04-02 21:02:34.1738922 -05:00  10  40  SCR Fire info:Validation has started.   NULL
32  8   2013-04-02 21:02:34.1768872 -05:00  20  40  SCR Fire info:Validation is complete.   NULL
33  8   2013-04-02 21:02:34.1788903 -05:00  20  30  ParameterTest:Validation is complete.   NULL
34  8   2013-04-02 21:02:34.3349188 -05:00  30  30  ParameterTest:Start, 9:02:34 PM.    NULL
35  8   2013-04-02 21:02:34.4009253 -05:00  30  40  SCR Fire info:Start, 9:02:34 PM.    NULL
36  8   2013-04-02 21:02:34.4009253 -05:00  10  40  SCR Fire info:Validation has started.   NULL
37  8   2013-04-02 21:02:34.4019251 -05:00  20  40  SCR Fire info:Validation is complete.   NULL
38  8   2013-04-02 21:02:34.4219283 -05:00  70  40  SCR Fire info:Information: System::ServerExecutionID: 8 NULL
39  8   2013-04-02 21:02:34.4259295 -05:00  70  40  SCR Fire info:Information: System::ExecutionInstanceGUID: {3F515780-8062-40AA-B9EC-C320CBAC5EFD}    NULL
40  8   2013-04-02 21:02:34.4409316 -05:00  40  40  SCR Fire info:Finished, 9:02:34 PM, Elapsed time: 00:00:00.031. NULL
41  8   2013-04-02 21:02:34.4419388 -05:00  40  30  ParameterTest:Finished, 9:02:34 PM, Elapsed time: 00:00:00.125. NULL

Embrulhar

Quando o pacote é executado fora do contexto do catálogo SSISDB (também conhecido como SSDT-BI ou da linha de comando para um .ispac), o valor de the System::ServerExecutionIDserá 0. Ele faz sentido, mas os futuros leitores usam um LEFT OUTER JOIN ao vincular sysssislog a catalog.operation_messages se você deseja capturar todas as execuções do pacote.

Gorjeta de chapéu, meus sinceros agradecimentos e o crédito da resposta vão para Marian por me colocar no caminho certo. Dada a escolha entre armazenar um GUID (16 bytes) e um bigint (8 bytes) na minha tabela de log resumida, é um acéfalo para mim: aumentar monotonicamente o número inteiro grande, por favor.