Создание нескольких задач SQL в SQL Server 2005

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

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

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

Реализация этого означала отказ от большинства функций SSIS и внедрение другого планировщика. Это нормально для продукта, но, вероятно, перебор для индивидуальной системы. Таким образом, более простое решение:

Вы можете управлять зависимостями на более крупном уровне, организовав ETL вертикально по измерениям (иногда называемым Предметно-ориентированный ETL), где один пакет SSIS и набор sprocs переносят данные от извлечения до создания измерений или таблиц фактов. Обычно размеры в основном разрознены, поэтому взаимозависимость минимальна. Там, где есть взаимозависимость, сделайте процесс загрузки одного измерения (или таблицы фактов) зависимым от того, что ему нужно в восходящем направлении.

Каждый загрузчик становится относительно модульным, и вы по-прежнему получаете полезную степень параллелизма, запуская процессы загрузки параллельно и позволяя планировщику SSIS работать над этим. Зависимости будут содержать некоторую избыточность. Например, таблица ODS может не зависеть от завершения загрузки измерения, но сам восходящий пакет переносит компоненты прямо в схему измерений до ее завершения. Однако на практике это маловероятно по следующим причинам:

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

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

вы можете захотеть взглянуть на сервис-брокер и его хранимые процедуры активации ... может быть вариантом ...

В конце концов, я создал программу консоли управления C#, которая запускает процессы Async, поскольку они могут быть запущены, и отслеживает соединения.