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

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

Что я хотел бы знать, так это как связать ExecutionInstanceGUID с чем-либо в каталоге SSISDB. Или же пакет SSIS, выполняющийся в SSISDB, может быть привязан к значению егоcatalog.executions.execution_id

В конечном итоге я пытаюсь использовать существующую настраиваемую таблицу аудита и связать ее с подробной историей в каталоге SSISDB, но, похоже, не могу найти ссылку.

Слишком много комментариев, но что-то пытаюсь. Со страницы msdn этой системной таблицы catalog.executions я получаю:

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

Из этой статьи - SSIS 2012 - Просмотр информации диспетчера подключений для прошлых выполнений - я понимаю, что:

SSIS 2012 предоставляет новую системную переменную ServerExecutionID для использования внутри пакетов, поэтому, если вы делаете какие-либо настраиваемые записи в журнал / уведомления, это хорошая переменная для включения, поскольку она будет прямым указателем на представления каталога, которые мы будем использовать для поиска информация о строке подключения. ... Catalog.executions содержит по одной строке на исполнение. Это где мы будем фильтровать по execute_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! = System :: ExecutionInstanceGUID, хотя они должны быть равны.

Таким образом, я пришел к выводу, что ExecutionInstanceGUID не связан с execute_id, а с некоторым столбцом InstanceId, на случай, если он есть в SSISDB.

Я создал проект служб SSIS, используя модель развертывания 2012 года, состоящую из одного пакета. В этом пакете я добавил диспетчер соединений OLE DB, указал его на базу данных tempdb и бросил задачу Script на холст. Я также включил явное ведение журнала с помощью этого диспетчера подключений OLE DB и записал 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 с catalog.operation_messages, если вы хотите перехватить все выполнения пакета.

Шляпный отзыв, мое искреннее спасибо и благодарность за ответ отправляемся к Мариан за то, что поставили меня на правильный путь. Учитывая выбор между хранением GUID (16 байт) и bigint (8 байт) в моей обобщенной таблице журналирования, для меня нет ничего сложного: монотонно увеличивать большое целое, пожалуйста.