Более двух лет SQL Server 2005 поставляется с SQL Server Integration Services (SSIS). Тем не менее многие компании все еще не конвертировали свои пакеты DTS в SSIS, возможно, потому, что процесс миграции представляется им чрезвычайно сложным или они не готовы выделить время на обучение сотрудников работе с новым продуктом.
Те, кто выполнял конвертацию, знают, что SSIS не является «следующей версией DTS». Отладка и журналирование — только две из областей, которые подверглись полному пересмотру в SSIS. Давайте посмотрим на возможности отладки и журналирования в SSIS.
Отладка пакетов в процессе разработки
Службы SSIS далеко обогнали DTS в области отладки, которая представляет собой процесс выявления ошибок, препятствующих работе пакета при выполнении или получении желаемых результатов. В DTS отладка обычно подразумевает использование оператора MsgBox или команды Stop из VBScript для того, чтобы имитировать контрольную точку в сценариях. Такие команды должны быть удалены из пакета, прежде чем будут переданы в рабочую эксплуатацию. По-другому построена отладка в SSIS, где ничто не должно быть удалено, когда пакет запускается в работу.
Проблема с инструментами отладки SSIS состоит в том, что они несовместимы со всеми типами задач. Таким образом, желательно знать, когда и какой инструмент следует использовать. Давайте рассмотрим возможности отладки SSIS на уровне пакета, следуя за отладчиком в рамках задач Control Flow и Data Flow.
Отладка на уровне пакета
В процессе разработки SSIS поддерживает красные или желтые значки при работе проектировщика, которые сообщают, когда с пакетом что-то неладно. Для просмотра сообщения, связанного с таким значком в коллекции пакетов, переместите мышь на значок, как показано на экране 1.
Эти сообщения обычно связаны с подключением к источнику данных или с путаницей в типах данных. Поскольку отсеивание сообщений в окне Output (которое расположено ниже области окна Error List в проектировщике SSIS) для отслеживания того, что вызвало ошибку пакета, может увеличить время отладки, SSIS позволяет выбрать вкладку проектировщика Progress, чтобы рассмотреть состав пакета, как показано на экране 2, и увидеть, где имела место ошибка.
Во время отладки пакета в среде Business Intelligence Development Studio можно увидеть, какая из задач выполняется и на каком она этапе выполнения, что обозначается цветом фона задачи: желтый указывает, что задача выполняется, зеленый — что задача завершена успешно, красный означает, что задача выполнена с ошибками. Для задачи Data Flow можно также получить подсчет обработанных строк. Нужно принять во внимание, что SSIS часто выполняет несколько различных задач одновременно, а DTS может в одно время выполнять только одну задачу. Одно из основных архитектурных различий между SSIS и DTS состоит в природе исполнения в SSIS.
Отладка задач Control Flow
Задачи Control Flow управляют исполнением пакета. Инструментальные средства отладки в SSIS для задач Control Flow сходны со средствами, которые имеются в любой приличной среде разработки. Контрольные точки и окна Debug могут быть особенно полезны при отладке задач Control Flow.
Контрольные точки предписывают SSIS остановить выполнение в указанной точке пакета. При обработке трудностей контрольная точка в режиме отладки Debug останавливает выполнение и в окне Debug предоставляет дополнительную информацию вроде значений переменных, стека вызывающей программы и сообщения состояния. Можно даже устанавливать контрольные точки в пакете, контейнере, задаче или в сценариях на уровне задачи. Можно даже устанавливать контрольные точки для остановки после достижения заданного числа ошибок или при совершении десятой итерации задачи в цикле For Loop. На экране 3 показано, как можно опросить объект для воспроизведения значений его характеристик в контрольное точке.
Откроем окно Locals из пункта меню Debug/Windows/Locals; это окно чаще всего применяется при отладке в SSIS. В нем отображаются значения всех переменных в пакете, и даже можно изменять значения переменных, что может быть полезно при переходе вперед к более дальней точке в пакете или моделировании некоторых условий при его выполнении.
Отладка задач Data Flow
Задачи Data Flow управляют тем, как и когда манипулировать данными в пакете. Первичный инструмент отладки, доступный в Data Flow, — это средство просмотра данных. Во время разработки задач Data Flow я использую средство просмотра данных, чтобы видеть, на что данные похожи в конвейере, когда они перетекают от одной задачи к другой, обычно перед задачей, которая реально загружает данные в место их назначения.
Можно добавить просмотр данных между двумя задачами Data Flow, щелкнув правой кнопкой на коннекторе, соединяющем две задачи; выбрать Data Viewers и затем выбрать просмотровщик данных, который вы хотите использовать. Можно просмотреть данные в таблице, диаграмме, диаграмме разброса данных или гистограмме. Я обычно просматриваю данные в таблице (см. экран 4), но рекомендую «поиграть» со всеми четырьмя средствами просмотра данных, чтобы получить более полное представление о них. Хотя я обычно удаляю свои представления данных перед развертыванием пакета в реальных условиях, так делать не нужно.
Можно модифицировать поля, выводимые просмотровщиком данных, и при установке просмотра данных, и после. Чтобы изменить просмотровщик данных после того, как он создан, щелкните правой кнопкой мыши по коннектору, выберите Data Viewers, укажите просмотровщик и затем нажмите Configure.
Еще одна технология отладки Data Flow, которую я часто использую во время разработки пакета и его отладки, — это задача RowCount. Задача RowCount связана только с задачами Data Flow. Задача RowCount — это не обычный инструмент отладки. Задача RowCount просто считает строки, прошедшие через конвейер, и помещает окончательное число в переменную. Я почти всегда использую RowCount как мой изначальный пункт назначения данных, потому что задача работает как средство исследования данных, через просмотр данных, без их загрузки куда-либо. Поскольку задача RowCount не несет никаких измеряемых служебных данных, она может применяться и для создания точки отсчета или диагностики проблем с производительностью.
Для получения дополнительной информации об использовании задачи RowCount смотрите описание «Integration Services: Performance Tuning Techniques» по адресу www.microsoft.com/technet/prodtechnol/sql/2005/ssisperf.mspx.
Журнал ошибок
Поскольку нельзя предвидеть все обстоятельства, которые возникнут в условиях эксплуатации, SSIS предусматривает мощные и гибкие возможности журналирования отображаемой информации после выполнения пакета (см. врезку «Конфликт типов данных»). Основная трудность в журналировании информации, достаточной для помощи в разработке, состоит в том, чтобы быстро диагностировать и минимизировать воздействие проблем, которые могут возникать при эксплуатации.
Несколько провайдеров журналирования ошибок позволяет указать, куда будут записаны сообщения: в текстовые файлы, в SQL Server Profiler, в таблицу SQL Server, в журнал событий Windows или в файлы формата XML. Можно указать, в какой журнал событий сообщения будут записываться и количество записываемой информации. Тип событий, которые вызывают запись сообщений в журнал, может изменяться на основании типа задачи Control Flow. Например, задача Data Flow может записывать в журнал такие события, как OnPipelineRowsSent и PipelineInitialization.
Для добавления функции журналирования в пакет щелкните в меню SSIS на пункте Logging и выберите одного или нескольких провайдеров журналов ошибок (то есть целевой журнал для записей), которые дают возможность записывать данные в место назначения. Установите флажок для событий, которые нужно записать в журнал, затем щелкните на вкладке Details и определите требуемые события. Далее щелкните на кнопке Advanced, чтобы задать поля, по которым будет вестись журнал, в противном случае журналирование будет вестись по всем полям. После настройки записей в журнале можно просматривать журнал событий в реальном времени в ходе процесса разработки, щелкая правой кнопкой в проектировщике Control Flow и выбирая Log Events.
Поскольку в файле регистрации ошибок каждая отслеживаемая задача идентифицируется по имени, я рекомендую реализовать стандарт именования, который уникально идентифицирует выполняемый пакет SSIS. В зависимости от событий, которые вы выбираете, файл регистрации ошибок может расти довольно быстро. Убедитесь, что регистрируются только события, которые нужны, и иногда удаляйте старые регистрационные записи. Поскольку SSIS не предлагает сразу способа сделать это, необходимо вручную сократить файлы регистрации, если провайдер журнала не обеспечивает соответствующие функциональные возможности. Например, если провайдер журнала ошибок настроен на отправку регистрационных сообщений в SQL Server, строки в таблице msdb.dbo.sysdtslog90 могут быть удалены после заданного периода времени. Можно также создавать настройки регистрации в виде шаблонов, чтобы реализовать один и тот же подход для пакетов, которые исполняют похожие функции, и упростить управление журналами.
Контрольные точки
Контрольные точки — другая мощная функция SSIS, которая позволяет перезапускать пакет при использовании в реальных условиях. Выполнение пакета SSIS, особенно пакета выборки, трансформации и загрузки (ETL), может оказаться делом долгим. По своей природе, ETL перемещает и трансформирует большие количества данных, а этот процесс может быть длительным. Сбой в работе двухчасового пакета или задачи ETL может стать катастрофическим в системе хранилища данных, для которой требуется надежность в установленный срок. Контрольные точки позволяют сохранять работу, которая была закончена, так, чтобы при перезапуске пакета после устранения проблемы, которая вызвала сбой, процесс продолжал работу с того места, где закончил. Контрольные точки не активированы по умолчанию, однако они должны быть включены в каждом пакете.
Важно разобраться, как работают контрольные точки до того как начать разрабатывать свои пакеты, потому что они могут повлиять на схему пакета. Обратите внимание, что контрольные точки могут быть применимы только к задачам Control Flow. Например, пакет не может быть перезапущен в середине задачи Data Flow, которая рассматривается как единое целое. Отсутствие контрольных точек в задачах Data Flow является хорошим аргументом в пользу компонентизации пакетов в раздельные логические задачи в задаче Data Flow или, что еще лучше, для формирования группы пакетов в пакете задач Data Flow. Например, можно сделать модульными пакеты, взяв один большой пакет и создав несколько маленьких, сгруппированных вместе внутри управляющего пакета. В этом случае можно назначать контрольные точки в каждом модульном пакете.
Каждый пакет должен быть настроен, чтобы использовать контрольные точки, на вкладке Details в окне Package (как показано на экране 5), и это даст возможность создать процесс SSIS, который включает родительский пакет и дочерние пакеты. Можно настроить каждый пакет и создать журнал контрольных точек для того, чтобы отследить информацию о выполнении в случае, если пакет даст сбой, как показано на экране 5. Если весь процесс работает без ошибок, файлы с журналами удаляются после того, как процесс ETL завершается. В таблице показаны свойства, которые нужно устанавливать для каждого пакета.
Отладка и журналирование в SSIS
Как мы видим, SSIS обеспечивает более мощную отладку и более эффективные возможности журналирования, чем DTS. Знать, когда и как использовать эти средства, весьма полезно: это позволит заметно сократить время, которое требуется для разработки пакетов и решения проблем после того, как пакет будет отправлен в эксплуатацию.
Эрин Велкер — независимый консультант по SQL Server, специализируется на бизнес-аналитике и производительности
Конфлик типов данных
Наиболее распространенная и надоедливая ошибка, которая мне встречалась, — конфликт типов данных при запуске пакета SSIS. Я обычно задаю совместимость типов данных, передаваемых по конвейеру. При считывании данных, например, из SQL Server, я часто устанавливаю соответствующий тип данных в месте назначения с помощью запроса на извлечение с использованием команды CAST. Если вам это не подходит, можно воспользоваться пунктом меню Show Advanced Editor, которое появляется при щелчке правой кнопкой мыши по компоненту Data Flow, позволяющему редактировать свойства объекта. После запуска редактора откройте вкладку Input and Output Properties, раскройте контейнер OLE DB Source Output в дереве, а затем Output Columns. Укажите столбец вывода и установите или измените тип данных и длину.