Wydanie 2012 SQL Server Integration Services, SSIS, dostarczyło katalog SSISDB, który śledzi operacje pakietów (między innymi). Domyślne wykonanie pakietu dla rozwiązań korzystających z modelu wdrażania projektu będzie mieć włączone logowanie do SSISDB.

Gdy pakiet jest wykonywany, System::ExecutionInstanceGUIDzapełniana jest wartością, która, jeśli użyje się jawnego rejestrowania (do sys.sysdtslog90/ sys.sysssislog), rejestruje wszystkie zdarzenia dla konkretnego wykonania pakietu.

Chciałbym wiedzieć, jak powiązać ExecutionInstanceGUID z czymkolwiek w katalogu SSISDB. Alternatywnie, jest pakiet SSIS wykonujący się w kluczu SSISDB do wartości jegocatalog.executions.execution_id

W końcu próbuję użyć istniejącej, niestandardowej tabeli audytu i połączyć ją z powrotem ze szczegółową historią w katalogu SSISDB, ale nie mogę znaleźć linku.

Za dużo na komentarz, ale próbowanie czegoś. Ze strony msdn tego katalogu tabeli systemowej. Wykonania otrzymuję:

id_wykonania - bigint - Unikalny identyfikator (ID) dla instancji wykonania.

Z tego artykułu - SSIS 2012 - Wyświetl informacje o menedżerze połączeń dla poprzednich wykonań - Rozumiem, że:

SSIS 2012 udostępnia nową zmienną systemową, ServerExecutionID, do użytku wewnątrz pakietów, więc jeśli wykonasz niestandardowe rejestrowanie / powiadomienia, dobrą zmienną jest włączenie, ponieważ będzie to bezpośredni wskaźnik do widoków katalogu, których użyjemy do znalezienia informacje o ciągu połączenia. ... Catalog.executions zawiera jeden wiersz na wykonanie. Tutaj będziemy filtrować według wykonania_id.

Z przykładowym zapytaniem:

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;

To, czego nie widzę, to Twój ExecutionInstanceGUID w tej tabeli. Widzę jednak ten starożytny przedmiot Connect, w którym znajduje się następująca historia:

SSIS RunningPackage.InstanceID! = System :: ExecutionInstanceGUID, chociaż powinny być równe.

Zatem doszedłem do wniosku, że ExecutionInstanceGUID nie jest związany z id_wykonania, ale jakąś kolumną InstanceId, na wypadek, gdybyś miał taką w SSISDB.

Stworzyłem projekt SSIS przy użyciu modelu wdrażania 2012, składającego się z jednego pakietu. W tym pakiecie dodałem Menedżera połączeń OLE DB, wskazałem go na tempdb i upuściłem Zadanie Skryptu na płótno. Włączyłem także jawne rejestrowanie przy użyciu Menedżera połączeń OLE DB i zarejestrowałem OnInformationzdarzenie.

Informacje o ogniu SCR

Skonfigurowałem moje zadanie skryptu, aby pobierało dwa parametry: System::ExecutionInstanceGUIDi System::ServerExecutionIDprzyznam w tym momencie, że nie zauważyłem drugiej zmiennej aż do odpowiedzi Mariana. W ramach zadania podnoszę 2 zdarzenia informacyjne, dzięki czemu mogę zapisać wartości. Powinno to zostać zarejestrowane zarówno w jawnej tabeli (dbo.sysssislog), jak i w „darmowym” logowaniu (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;
    }

Wdróż i wykonaj

Następnie wdrożyłem mój projekt na serwerze i wykonałem go.

Otworzyłem raport operacyjny i kliknąłem w SCR Fire infoszczegóły zadania.

Czerwony zakreślony element pokazuje, że przeglądamy szczegóły operacji 8, zgodnie z oczekiwaniami. Podświetlone linie to OnInformationzdarzenia, które wywołały bąbelki wartości tych dwóch zmiennych systemowych. Również zgodnie z oczekiwaniami wartość System::ServerExecutionIDdopasowana do tego, co było w raporcie. Wartość System::ExecutionInstanceGUIDjak zawsze była bez znaczenia, ale była obecna {3F515780-8062-40AA-B9EC-C320CBAC5EFD}.

Wiązanie wszystkiego razem

Miałem teraz dwa różne dzienniki, które chciałem związać.

zapytanie sysssislog

Uruchomienie tego zapytania spowodowało wycofanie odpowiednich wierszy ze starej tabeli rejestrowania.

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;

Wyniki wyglądały jak

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.

zapytanie catalog.operation_messages

Uruchomienie tego zapytania przed katalogu SSISDB wykazywały wszystkie wiadomości, które zostały w powyższym raporcie, a także potwierdzone mogę powiązać wartości w messagecelu operation_idjak również do ponaddbo.sysssislog.executionid

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

Te wyniki były

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

Zakończyć

Gdy pakiet jest wykonywany poza kontekstem katalogu SSISDB (inaczej przez SSDT-BI lub wiersz poleceń do .ispac), wartość System::ServerExecutionIDbędzie wynosić 0. To ma sens, ale przyszli czytelnicy albo używają POŁĄCZENIA ZEWNĘTRZNEGO podczas łączenia sysssislog do catalog.operation_messages, jeśli chcesz przechwycić wszystkie wykonania pakietu.

Kapelusz, moje serdeczne podziękowania i podziękowania należą się Marianowi za postawienie mnie na właściwej drodze. Biorąc pod uwagę wybór między przechowywaniem GUID (16 bajtów) a bigintem (8 bajtów) w mojej skróconej tabeli rejestrowania, nie jest to dla mnie żadnym problemem: monotonicznie zwiększaj dużą liczbę całkowitą, proszę.