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

Informações de incêndio SCR

Eu configurei minha tarefa de script para obter dois parâmetros: System::ExecutionInstanceGUIDe System::ServerExecutionIDdevo admitir que, neste ponto, não havia notado a segunda variável até a resposta de Marian. Dentro da tarefa, crio 2 eventos de informação 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, como esperado. As linhas destacadas são os OnInformationeventos que criaram os valores dessas duas variáveis ​​do sistema. Também como esperado, o valor de System::ServerExecutionIDcorrespondeu ao que estava no relatório. O valor de System::ExecutionInstanceGUIDnão fazia sentido como sempre, mas estava presente {3F515780-8062-40AA-B9EC-C320CBAC5EFD}.

Amarrando tudo junto

Agora eu tinha dois troncos 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 desta consulta no catálogo SSISDB mostrou todas as mensagens que estavam no relatório acima e também confirmou que eu poderia vincular o valor messagea operation_ide também 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 linha de comando para um .ispac), o valor do the System::ServerExecutionIDserá 0. Faz sentido, mas os leitores futuros usarão LEFT OUTER JOIN ao vincular sysssislog a catalog.operation_messages se desejar capturar todas as execuções do pacote.

Dica 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) em minha tabela de log resumida, é óbvio para mim: aumentar monotonicamente o grande número inteiro, por favor.

Demais para um comentário, mas tentando alguma coisa. Na página msdn dessa tabela de sistema catalog.executions , obtenho:

Execution_id - bigint - O identificador exclusivo (ID) para a instância de execução.

A partir deste artigo - SSIS 2012 - Exibir informações do gerenciador de conexões para execuções anteriores - entendo que:

O SSIS 2012 fornece uma nova variável de sistema, ServerExecutionID, para seu uso dentro de pacotes, portanto, se você fizer qualquer registro/notificação personalizado, é uma boa variável incluir, pois será um ponteiro direto para as exibições de catálogo que usaremos para localizar informações da cadeia de conexão. ... Catalog.executions contém uma linha por execução. É aqui que filtraremos por operation_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 é seu ExecutionInstanceGUID nesta tabela. O que vejo, porém, é este antigo item 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 a operation_id, mas a alguma coluna InstanceId, caso você tenha uma no SSISDB.