Випуск 2012 року інтеграційних служб SQL Server, SSIS, представив каталог SSISDB, який відстежує операції з пакетами (серед іншого). Виконання пакету за замовчуванням для рішень, що використовують модель розгортання проекту, увімкне журнал до SSISDB.

Коли пакет виконується, System::ExecutionInstanceGUIDзаповнюється значення, яке, якби використовується явний журнал (до sys.sysdtslog90/ sys.sysssislog), записувало б усі події для виконання певного пакету.

Що я хотів би знати, це те, як я прив’язую ExecutionInstanceGUID до всього, що знаходиться в каталозі SSISDB. Крім того, це пакет SSIS, який виконується в таємниці SSISDB на значення йогоcatalog.executions.execution_id

Зрештою, я намагаюсь використовувати існуючу, власну таблицю аудиту і пов'язувати її з детальною історією в каталозі SSISDB, але не можу знайти посилання.

Занадто багато для коментаря, але щось намагаюся. На сторінці msdn цього системного столу каталог. Виконання я отримую:

Execution_id - bigint - Унікальний ідентифікатор (ID) для примірника виконання.

З цієї статті - SSIS 2012 - Перегляд інформації менеджера підключень для минулих виконань - я розумію, що:

SSIS 2012 надає нову системну змінну, ServerExecutionID, для використання у пакетах, тому, якщо ви робите будь-який користувацький журнал / сповіщення, це хороша змінна включити, оскільки це буде прямим вказівником на представлення каталогів, які ми будемо використовувати для пошуку інформація про рядок з'єднання. ... Каталог.виконання містить один рядок на виконання. Тут ми будемо фільтрувати за виконанням_id.

Зі зразком запиту:

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;

Те, що я не бачу, - це ExecutionInstanceGUID у цій таблиці. Однак я бачу цей старовинний елемент Connect, де є така історія:

SSIS RunningPackage.InstanceID! = Система :: ExecutionInstanceGUID, хоча вони повинні бути рівними.

Отже, мій висновок полягає в тому, що ExecutionInstanceGUID пов'язаний не з Execu_Iid, а з деяким стовпцем InstanceId, на випадок, якщо він може бути у SSISDB.

Я створив проект SSIS, використовуючи модель розгортання 2012 року, що складається з одного пакету. У цьому пакеті я додав OLE DB Connection Manager, вказав на tempdb і скинув завдання на сценарій на полотно. Я також увімкнув явну реєстрацію за допомогою цього OLE DB Connection Manager і захопив OnInformationподію.

Інформація про пожежу SCR

Я налаштував своє сценарій завдання захопити два параметри: System::ExecutionInstanceGUIDі System::ServerExecutionIDя визнаю, що в цей момент я не помітив другої змінної до відповіді Маріана. Всередині завдання я піднімаю 2 Інформаційні події, щоб я міг записати значення. Це слід увійти як до явної таблиці (dbo.sysssislog), так і до "вільної" реєстрації (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;
    }

Розгортання та виконання

Потім я розгорнув свій проект на сервері та виконав його.

Я відкрив звіт про операції та натиснув SCR Fire infoдеталі завдання.

Червоний круглий елемент показує, що ми переглядаємо деталі для операції 8, як очікувалося. Виділені рядки - це OnInformationподії, які перекидають значення цих двох системних змінних. Також, як і очікувалося, значення System::ServerExecutionIDвідповідало тому, що було у звіті. Значення System::ExecutionInstanceGUIDбуло безглуздо, як завжди, але воно було присутнім {3F515780-8062-40AA-B9EC-C320CBAC5EFD}.

Зв’язуючи це все разом

Тепер у мене було два різних колоди, які я хотів зв’язати разом.

запит sysssislog

Запуск цього запиту відтягнув відповідні рядки з таблиці журналів старої школи.

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;

Результати виглядали приблизно так

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.

запит catalog.operation_messages

Виконання цього запиту до каталогу SSISDB показали всі повідомлення , які були в зазначеній доповіді , а також підтвердили , я міг би зв'язати значення в messageс operation_id, а також доdbo.sysssislog.executionid

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

Ці результати були

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

Загорнути

Коли пакет виконується поза контекстом каталогу SSISDB (він же через SSDT-BI або з командного рядка до .ispac) значення з System::ServerExecutionIDбуде 0. Це має сенс, але читачі в майбутньому або використовувати LEFT OUTER JOIN при посиланні sysssislog на каталог.operation_messages, якщо ви хочете зафіксувати всі виконання пакету.

Наконечник капелюха, мої щирі подяки та заслуга відповіді відмовляються від Мар'яна за те, що він поставив мене на правильний шлях. З огляду на вибір між збереженням GUID (16 байт) та bigint (8 байтів) у моїй узагальненій таблиці реєстрації, для мене це не є монітором: монотонно збільшуючи велике ціле число, будь ласка.