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

Question

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

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

Я подумал о:

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

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

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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