Создание множества SQL-задач в SQL Server 2005

Question

У меня есть несколько сохраненных процедур, которые я бы хотел, чтобы все выполнялось одновременно на сервере. Идеально все на сервере, не полагаясь на подключения к внешнему клиенту.

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

Я подумал:

• Запуск нескольких соединений из клиента, имея каждый запустить соответствующий SP.
• Настройка заданий для каждого SP и запуск заданий из Подключение к SQL Server или SP.
• Использование xp_cmdshell, чтобы начать дополнительные прогоны эквивалент Osql или whetever
• SSIS - мне нужно, чтобы увидеть, если пакет может быть динамически записывается обрабатывать больше ПЛов, потому что я не уверен, насколько доступ мои клиенты идут чтобы добраться до производства

в работе и cmdshell случаях, я, вероятно, столкнуться с проблемами на уровне разрешения от DBA ...

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

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

У меня в основном три слоя, у слоя 1 есть небольшое количество процессов и зависит, в основном, от всех фактов/измерений, которые уже загружаются (эффективны, звезды являются уровнем 0 - и да, к сожалению, все они должны быть загружен), уровень 2 имеет ряд процессов, которые зависят от некоторого или всего уровня 1, а уровень 3 имеет ряд процессов, которые зависят от некоторого или всего уровня 2. У меня уже есть зависимости в таблице, и я бы только сначала запускают все procs в определенном слое в то же время, поскольку они ортогональны внутри слоя.

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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