La version 2012 de SQL Server Integration Services, SSIS, a fourni un catalogue SSISDB qui suit les opérations des packages (entre autres). L'exécution de package par défaut pour les solutions utilisant le modèle de déploiement de projet aura la connexion à SSISDB activée.

Lorsqu'un package s'exécute, le System::ExecutionInstanceGUIDest renseigné avec une valeur qui, si l'on utilisait une journalisation explicite (vers sys.sysdtslog90/ sys.sysssislog), enregistrerait tous les événements pour une exécution de package spécifique.

Ce que j'aimerais savoir, c'est comment lier un ExecutionInstanceGUID à n'importe quoi dans le catalogue SSISDB. Alternativement, un package SSIS s'exécute-t-il dans la base SSISDB sur la valeur de soncatalog.executions.execution_id

En fin de compte, j'essaie d'utiliser la table d'audit personnalisée existante et de la relier à l'historique détaillé du catalogue SSISDB, mais je n'arrive pas à trouver le lien.

Trop pour un commentaire, mais essayez quelque chose. À partir de la page msdn de cette table système catalog.executions, j'obtiens:

execution_id - bigint - L'identifiant unique (ID) pour l'instance d'exécution.

De cet article - SSIS 2012 - Afficher les informations du gestionnaire de connexion pour les exécutions passées - Je comprends que:

SSIS 2012 fournit une nouvelle variable système, ServerExecutionID, pour votre utilisation à l'intérieur des packages, donc si vous effectuez des enregistrements / notifications personnalisés, c'est une bonne variable à inclure car ce sera un pointeur direct vers les vues de catalogue que nous utiliserons pour trouver informations de chaîne de connexion. ... Catalog.executions contient une ligne par exécution. C'est là que nous filtrerons par execution_id.

Avec un exemple de requête 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;

Ce que je ne vois pas, c'est votre ExecutionInstanceGUID dans ce tableau. Ce que je vois, cependant, est cet ancien élément Connect où il y a l'histoire suivante:

SSIS RunningPackage.InstanceID! = System :: ExecutionInstanceGUID bien qu'ils doivent être égaux.

Donc, ma conclusion est que ExecutionInstanceGUID n'est pas lié à execution_id, mais à une colonne InstanceId, au cas où vous pourriez en avoir un dans SSISDB.

J'ai créé un projet SSIS en utilisant le modèle de déploiement 2012 composé d'un seul package. Dans ce package, j'ai ajouté un gestionnaire de connexions OLE DB, l'ai pointé vers tempdb et j'ai déposé une tâche de script sur le canevas. J'ai également activé la journalisation explicite à l'aide de ce gestionnaire de connexions OLE DB et capturé l' OnInformationévénement.

Informations sur le SCR Fire

J'ai configuré ma tâche de script pour saisir deux paramètres: System::ExecutionInstanceGUIDet System::ServerExecutionIDje dois admettre qu'à ce stade, je n'avais pas remarqué la deuxième variable jusqu'à la réponse de Marian. À l'intérieur de la tâche, je déclenche 2 événements d'information afin de pouvoir enregistrer les valeurs. Cela doit être enregistré à la fois dans la table explicite (dbo.sysssislog) et dans la journalisation "gratuite" (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;
    }

Déployer et exécuter

J'ai ensuite déployé mon projet sur un serveur et l'ai exécuté.

J'ai ouvert le rapport des opérations et j'ai cliqué sur les SCR Fire infodétails de la tâche.

L'élément encerclé en rouge montre que nous visualisons les détails de l'opération 8, comme prévu. Les lignes en surbrillance sont les OnInformationévénements qui ont propulsé les valeurs de ces deux variables système. Comme prévu, la valeur de System::ServerExecutionIDcorrespondait à ce qui était dans le rapport. La valeur de System::ExecutionInstanceGUIDn'a pas de sens comme toujours mais elle était présente {3F515780-8062-40AA-B9EC-C320CBAC5EFD}.

Lier le tout ensemble

J'avais maintenant deux journaux différents que je voulais lier ensemble.

requête sysssislog

L'exécution de cette requête a retiré les lignes pertinentes de la table de journalisation à l'ancienne.

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;

Les résultats ressemblaient à

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.

requête catalog.operation_messages

L'exécution de cette requête sur le catalogue SSISDB a montré tous les messages qui figuraient dans le rapport ci-dessus et a également confirmé que je pouvais lier la valeur messageà operation_idainsi que surdbo.sysssislog.executionid

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

Ces résultats ont été

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

Emballer

Lorsque le package est exécuté en dehors du contexte du catalogue SSISDB (alias via SSDT-BI ou la ligne de commande vers un .ispac), la valeur de la System::ServerExecutionIDsera 0. Cela a du sens, mais les futurs lecteurs utiliseront une LEFT OUTER JOIN lors de la liaison de sysssislog à catalog.operation_messages si vous souhaitez intercepter toutes les exécutions du package.

Pointe du chapeau, mes remerciements chaleureux et le crédit de réponse vont à Marian pour m'avoir mis sur la bonne voie. Étant donné le choix entre stocker un GUID (16 octets) et un bigint (8 octets) dans ma table de journalisation résumée, c'est une évidence pour moi: augmenter monotone gros entier s'il vous plaît.