La versione 2012 di SQL Server Integration Services, SSIS, ha fornito un catalogo SSISDB che tiene traccia delle operazioni dei pacchetti (tra le altre cose). L'esecuzione del pacchetto predefinito per le soluzioni che utilizzano il modello di distribuzione del progetto avrà la registrazione su SSISDB attivata.

Quando viene eseguito un pacchetto, System::ExecutionInstanceGUIDviene popolato con un valore che, se si utilizzasse la registrazione esplicita (in sys.sysdtslog90/ sys.sysssislog), registrerebbe tutti gli eventi per un'esecuzione specifica del pacchetto.

Quello che mi piacerebbe sapere è come legare un ExecutionInstanceGUID a qualsiasi cosa nel catalogo SSISDB. In alternativa, è un pacchetto SSIS in esecuzione in privato SSISDB al valore del suocatalog.executions.execution_id

In definitiva, sto cercando di utilizzare la tabella di controllo personalizzata esistente e collegarla alla cronologia dettagliata nel catalogo SSISDB, ma non riesco a trovare il collegamento.

Troppo per un commento, ma provando qualcosa. Dalla pagina msdn della tabella di sistema catalog.executions ottengo:

execution_id - bigint - L'identificatore univoco (ID) per l'istanza di esecuzione.

Da questo articolo - SSIS 2012 - Visualizza le informazioni di Connection Manager per le passate esecuzioni - Comprendo che:

SSIS 2012 fornisce una nuova variabile di sistema, ServerExecutionID, per l'uso all'interno dei pacchetti, quindi se si eseguono registrazioni / notifiche personalizzate è una buona variabile da includere in quanto sarà un puntatore diretto alle viste del catalogo che utilizzeremo per trovare informazioni sulla stringa di connessione. ... Catalog.executions contiene una riga per esecuzione. Questo è dove filtreremo per esecuzione_id.

Con una query di esempio di:

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;

Quello che non vedo è il tuo ExecutionInstanceGUID in questa tabella. Quello che vedo, però, è questo antico oggetto Connect in cui c'è la seguente storia:

SSIS RunningPackage.InstanceID! = System :: ExecutionInstanceGUID sebbene debbano essere uguali.

Quindi la mia conclusione è che ExecutionInstanceGUID non è correlato a execution_id, ma a qualche colonna InstanceId, nel caso in cui potresti averne uno nel SSISDB.

Ho creato un progetto SSIS utilizzando il modello di distribuzione 2012 costituito da un singolo pacchetto. In quel pacchetto, ho aggiunto una Gestione connessione OLE DB, l'ho puntato su tempdb e ho lasciato un'attività Script sulla tela. Ho anche attivato la registrazione esplicita utilizzando quella Gestione connessione OLE DB e acquisito l' OnInformationevento.

Informazioni sul fuoco SCR

Ho configurato il mio compito script per afferrare due parametri: System::ExecutionInstanceGUIDe System::ServerExecutionIDdevo ammettere, a questo punto, avevo non notato la seconda variabile fino risposta di Marian. All'interno dell'attività, raccolgo 2 eventi informativi in ​​modo da poter registrare i valori. Questo dovrebbe essere registrato sia nella tabella esplicita (dbo.sysssislog) sia nella registrazione "libera" (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;
    }

Distribuire ed eseguire

Ho quindi distribuito il mio progetto su un server ed eseguito.

Ho aperto il Rapporto operazioni e fatto clic sui SCR Fire infodettagli dell'attività.

L'elemento cerchiato in rosso mostra che stiamo visualizzando i dettagli dell'operazione 8, come previsto. Le linee evidenziate sono gli OnInformationeventi che hanno fatto gorgogliare i valori di quelle due variabili di sistema. Inoltre, come previsto, il valore di System::ServerExecutionIDcorrisponde a ciò che era nel rapporto. Il valore di System::ExecutionInstanceGUIDera insignificante come sempre ma era presente {3F515780-8062-40AA-B9EC-C320CBAC5EFD}.

Legare tutto insieme

Ora avevo due diversi tronchi che volevo legare insieme.

query sysssislog

L'esecuzione di questa query ha recuperato le righe pertinenti dalla tabella di registrazione della vecchia scuola.

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;

I risultati sembravano

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.

query catalog.operation_messages

L'esecuzione di questa query sul catalogo SSISDB ha mostrato tutti i messaggi presenti nel rapporto precedente e ha anche confermato che potevo collegare il valore messagea operation_idoltre che adbo.sysssislog.executionid

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

Quei risultati furono

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

Incartare

Quando il pacchetto viene eseguito al di fuori del contesto del catalogo SSISDB (ovvero tramite SSDT-BI o la riga di comando in un .ispac) il valore di System::ServerExecutionIDsarà 0. Ha senso, ma i lettori futuri utilizzano un LEFT OUTER JOIN quando si collega sysssislog a catalog.operation_messages se si desidera catturare tutte le esecuzioni del pacchetto.

Suggerimento per il cappello, i miei sinceri ringraziamenti e il merito della risposta vanno a Marian per avermi messo sulla strada giusta. Data la scelta tra la memorizzazione di un GUID (16 byte) e un bigint (8 byte) nella mia tabella di riepilogo riepilogativa, per me è un gioco da ragazzi: aumentare il numero intero grande monotonicamente, per favore.