Главная » Microsoft SQL Server, Базы данных » Обслуживаемые и управляемые пакеты

0

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

Перед этапом разработки очень важным моментом является проектирование, особенно если работа над приложением службы интеграции осуществляется в первую очередь, так как практические результаты часто используются на последующих этапах, в частности протоколирование, аудит и общая структура данных. Возможно, ключевым преимуществом разработки приложений с использованием службы интеграции является возможность централизации всей обработки данных в одном месте, с четким разграничением последовательности действий и возможностью обработки возникающих ошибок. Централизация существенно повышает работоспособность приложения по сравнению с традиционным подходом “сценарий — здесь, программа — там, а хранимая процедура — вообще неизвестно где”. Во время проектирования не забудьте уделить внимание и ряду других вопросов.

?               Идентифицируйте повторяющиеся фрагменты для их последующего многократного использования. Многие повторяющиеся задания выполняют над объектами одни и те же действия и используют одни и те же метаданные — именно они являются первыми кандидатами на помещение в отдельные субпакеты.

?               Ключом к успеху в процессе эксплуатации является подходящая стратегия протоколирования. Спросите себя, кто будет отвечать за устранение возникшей ошибки и как он о ней узнает. Например, как ответственный узнает, что некоторый пакет должен был быть запущен, но этого по некоторой причине не произошло? Какой уровень протоколирования достаточен? (Учтите, что “больше” не всегда “лучше”. Слишком много ненужных деталей способно только замаскировать истинную проблему.) Какой тип информации о состоянии пакета и среды необходим для выявления причины возникновения ошибки?

?               Концепции аудита могут оказаться полезными для операций согласования и восстановления после ошибок. Какой тип данных можно ассоциировать с данными, создаваемыми в пакете? Если необходим большой объем информации, подумайте о создании многоуровневого протокола, помещая в обработанные записи только идентификаторы.

?               Какие детали пакетов будут изменяться при запуске пакетов на разных платформах? Какой режим хранения (реестр, XML, SQL и т.п.) будет более эффективным при распространении данных конфигурации? Если возможно, используйте конфигурирование на уровне системы, а не на уровне пакета — это упростит распространение и сопровождение настроек.

?               Определите порядок восстановления после сбоев пакета. Спросите себя, потребуется ли вмешательство вручную для того, чтобы снова запустить пакет. Например, пакет, загружающий данные, может потребовать использования транзакций, чтобы после восстановления после сбоя не образовались дублирующиеся строки.

?               Для “долгоиграющих” пакетов продумайте логику расстановки контрольных точек, с которых можно заново запускать пакет.

?               Определите наиболее вероятные точки возникновения ошибок в пакете. Подумайте, какие действия придется предпринять для исправления ошибки (реально, а не теоретически). Если возможно, внесите эти действия в пакет, используя потоки ошибочных данных и ограничения, чтобы не нагружать лишней работой обслуживающий персонал.

Правильный стиль программирования также способен повысить обслуживаемость пакета. Давайте пакетам, заданиям, компонентам и прочим видимым объектам осмысленные имена. Свободно используйте примечания, чтобы обслуживающий персонал смог понять неочевидные решения и причины их использования. Это также поможет и разработчикам, которые в будущем будут развивать пакет. Обязательно используйте программы управления версиями, чтобы поддерживать историю пакета и связанные версии файлов.

Протоколирование

Поскольку множество пакетов предназначено для несопровождаемых операций, генерация журнала выполнения является отличным методом отслеживания операций и накопления отладочной информации. Щелкните правой кнопкой мыши в рабочей области конструктора пакетов и выберите в контекстном меню пункт Logging. Во вкладке Providers and Logs добавьте поставщика для каждого типа вывода, который будет протоколироваться (допустимо множество поставщиков). Во вкладке Details определите события, для которых будут создаваться записи в журнале. Расширенное представление (рис. 42.6) также позволяет выбрать столбцы, включаемые в каждую запись журнала.

Древовидное представление на левой панели является контейнером иерархии пакета. Флажки отвечают за параметр LoggingMode каждого объекта: пустой флажок соответствует режиму отключения, отмеченный — включенному режиму, а серый позволяет наследовать настройки протоколирования от родительского объекта. Если выделить какой-либо элемент в

Puc. 42.6. Расширенное представление вкладки Advanced

дереве, то отобразятся его детали. Следует отметить, что поставщики могут быть сконфигурированы только для пакета в целом, а параметры всех объектов с установленным параметром UseParent Set tings будут недоступны в отличие от параметров родительских объектов.

Стандартные поставщики журнала описаны ниже.

?               Text File. Запись в текстовый файл с разделителями. Конфигурирование выполняется в соответствующем диспетчере подключений.

?               SQL Profiler. Запись в файл . TRC, который можно просмотреть в утилите SQL Profiler. Этот метод может пригодиться, когда требуется наряду с журналом пакета просмотреть другую информацию о производительности сервера. Конфигурирование выполняется в соответствующем файловом диспетчере подключений.

?               SQL Server. Запись в таблицу dbo. sysdtslog90 базы данных, обозначенной в соответствующем диспетчере подключений OLE DB. Для обслуживания таблицы может быть выбрана любая база данных. Если схема таблицы не существует, то она будет создана при первом использовании.

?               Event Log. Запись в журнал событий Windows того компьютера, на котором выполняется пакет. Конфигурирование в данном случае не требуется.

?               XML File. Запись в файл XML. Конфигурирование выполняется в соответствующем диспетчере подключений.

Вкладка Details окна конфигурации протоколирования также имеет расширенный режим, позволяющий выбрать регистрируемые столбцы для каждого из событий. Когда необходимая конфигурация комбинаций “событие-столбцы” будет выстроена, ее можно сохранить в качестве шаблона и использовать в других пакетах.

Конфигурация пакета

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

Щелкните правой кнопкой мыши в рабочей области конструктора пакетов и выберите в контекстном меню пункт Package Configurations. В открывшемся окне отобразится список конфигураций, применяемый к пакету в порядке перечисления. Чтобы добавить новую конфигурацию, убедитесь, что конфигурации активизированы, и щелкните на кнопке Add. Когда запустится мастер конфигурации пакетов (Package Configuration Wizard), выберите необходимый тип конфигурации (размещение хранилища). В сущности, следует рассматривать три категории.

?               Registry & Environment Variable. Эти типы позволяют хранить только один параметр.

?               XML File & SQL Server Table. Каждый из этих типов позволяет хранить любое число настроек параметров.

?               Parent Package Variable. Осуществляет доступ из вызываемого пакета к содержимому одной переменной.

Большинство типов конфигураций позволяет идентифицировать место хранения либо непосредственно, либо с помощью переменной среды. Переменные среды могут оказаться полезными, когда в разных средах место хранения (например, файловый каталог) отличается. После определения типа конфигурации и места хранения параметр Select Properties to Export позволяет выбрать те параметры, которые будут изменяться в разных средах. В заключение просмотрите выбранные настройки, присвойте имя конфигурации и завершите работу мастера.

Конфигурации могут многократно использоваться в разных пакетах, если имена объектов, содержащих настраиваемые параметры, идентичны. В частности, пакеты, использующие одинаковые имена своих диспетчеров подключений, могут совместно использовать конфигурацию, определяющую сервер и имена файлов. Чтобы использовать готовую конфигурацию в дополнительных пакетах, выберите ее тип, а затем определите то же место хранения (например, файл XML), что и в исходном пакете. Когда откроется диалоговое окно, предупреждающее, что такая конфигурация уже существует, выберите опцию Reuse Existing.

Перезапуск из контрольной точки

Разрешение перезапуска пакета из контрольных точек позволяет не повторять выполнение заданий, завершившихся успешно. Учтите приведенные ниже правила использования точек перезапуска.

?               Только задания потока управления определяют точки перезапуска; все задания потока данных видны как единый рабочий элемент, независимо от того, сколько компонентов они содержат.

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

?               Любые контейнеры цикла следует запускать с самого начала.

?               Конфигурация, используемая при перезапуске, сохраняется в файле контрольной точки, а не в текущем файле конфигурации.

Включение контрольных точек выполняется с помощью установки следующих параметров пакета.

?               CheckpointFilename. Имя файла, в котором сохраняется информация о контрольной точке.

?               CheckpointUsage. Значение If Exists указывает начинать выполнение с контрольной точки, если такой файл существует, или с первой операции пакета в противном случае.

Значение Always указывает на завершение выполнения пакета, если файл контрольной точки не существует.

?               SaveCheckPoints. Для параметра сохранения контрольных точек следует установить значение true.

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

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии