Преобразование хранимых процедур SQL Server в пакет служб SSIS - PullRequest
6 голосов
/ 28 мая 2011

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

Мы планируем перенести эти хранимые процедуры в пакет служб SSIS ETL.

Кто-нибудь делал это в прошлом? Если да, то какой подход следует предпринять.

Благодарим вас за то, что кто-нибудь может дать совет о том, как преобразовать хранимую процедуру в пакеты SSIS ETL.

Спасибо

Ответы [ 2 ]

5 голосов
/ 28 мая 2011

Я делал это раньше, и для моей команды хорошо было выполнять поэтапный рефакторинг, начиная с исходного источника, а затем повторять процесс рефакторинга.

Первым шагом была попытка модулировать логику хранимых процедур в задачи «Выполнение SQL», которые мы связали вместе. Каждая задача была протестирована и утверждена, а затем мы интегрировали и обеспечили соответствие нового процесса результатам устаревших процедур.

После этого мы могли бы разделить отдельные задачи «Выполнение SQL» по всей группе и распределить нагрузку по анализу возможности дальнейшего рефакторинга SQL в задачах «Выполнение SQL» для собственных задач служб SSIS.

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

3 голосов
/ 28 мая 2011

Я бы предложил следующие шаги:

  1. Анализ хранимых процедур для определения списка источников и мест назначения. Например: если хранимая процедура dbo.TransferOrders перемещает данные из таблицы dbo.Order в dbo.OrderHistory. Тогда ваш источник будет dbo.Order, а пункт назначения будет dbo.OrderHistory.

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

  3. Попытайтесь выяснить, происходят ли какие-либо преобразования данных в хранимых процедурах. В службах SSIS доступны хорошие задачи преобразования данных. Вы можете оценить и перенести некоторые из этих функций из хранимых процедур в SSIS. Поскольку SSIS представляет собой инструмент рабочего процесса, я чувствую, что легче понять, что происходит внутри пакета, чем пролистывать много строк кода, чтобы понять функциональность. Но это только я. Предпочтения отличаются от человека к человеку.

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

  5. Если у вас есть таблица с именем dbo.Table1, заполняющая 5 разных таблиц. Я бы порекомендовал иметь их в одной упаковке. Даже если эта совокупность данных выполняется с помощью 5 различных хранимых процедур, вам не нужно переходить на 5 пакетов. Тем не менее, это снова зависит от вашего бизнес-сценария.

  6. Проектное решение SSIS может содержать несколько пакетов и повторно использовать источники данных. Вы можете использовать Execute SQL task, доступный в задаче «Поток управления», для выполнения существующих запросов, но я бы рекомендовал вам также взглянуть на некоторые из хороших задач преобразования, доступных в SSIS. Я использовал их в своем проекте, и они хорошо работают для операций ETL.

Эти шаги можно выполнить, просматривая одну хранимую процедуру за раз. Вам не нужно проходить все сразу.

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

Копирование данных из одной таблицы SQL в другую

Функция ведения журнала доступна в SSIS

Загрузка плоского файла с 1 миллионом строк в таблицы SQL с использованием SSIS

Надеюсь, это поможет.

...