Generando múltiples tareas SQL en SQL Server 2005

Question

Tengo varios procesos almacenados que me gustaría ejecutar todos simultáneamente en el servidor. Idealmente, todo en el servidor sin depender de las conexiones a un cliente externo.

¿Qué opciones hay para lanzar todo esto y hacer que se ejecuten simultáneamente (ni siquiera necesito esperar hasta que se realicen todos los procesos para realizar un trabajo adicional)?

He pensado en:

• Lanzar conexiones múltiples desde un cliente, teniendo cada inicio el SP apropiado.
• Configuración de trabajos para cada SP y comenzando los trabajos desde una Conexión de SQL Server o SP.
• utilizando xp_cmdshell para iniciar ejecuciones adicionales equivalente a osql o whetever
• SSIS: necesito ver si el paquete se puede escribir dinámicamente para manejar más SP, porque no estoy seguro de cuánto acceso tendrán mis clientes en producción

En los casos de trabajo y cmdshell, probablemente me encuentre con problemas de nivel de permisos del DBA ...

SSIS podría ser una buena opción, si puedo manejar la lista de SP en una tabla.

Esta es una situación de datawarehouse, y el trabajo es en gran medida independiente y NOLOCK se usa universalmente en las estrellas. El sistema es un equipo de 8 vías de 32 GB, así que lo cargaré y lo reduciré si veo problemas.

Básicamente tengo tres capas, la Capa 1 tiene un pequeño número de procesos y depende básicamente de todos los datos / dimensiones que ya se están cargando (efectivas, las estrellas son una Capa 0, y sí, desafortunadamente, todas deberán ser cargadas) ), La capa 2 tiene una serie de procesos que dependen de una parte o la totalidad de la capa 1, y la capa 3 tiene una serie de procesos que dependen de una parte o la totalidad de la capa 2. Ya tengo las dependencias en una tabla, y solo inicialmente inicie todos los procs en una capa particular al mismo tiempo, ya que son ortogonales dentro de una capa.

Answer 1

Al final, creé un programa de consola de administración de C # que inicia los procesos Async ya que pueden ejecutarse y realiza un seguimiento de las conexiones.

Answer 2

¿Es SSIS una opción para ti? Puede crear un paquete simple con tareas Ejecutar SQL paralelas para ejecutar los procesos almacenados simultáneamente. Sin embargo, dependiendo de lo que hagan sus procesos almacenados, puede o no beneficiarse de iniciar esto en paralelo (por ejemplo, si todos acceden a los mismos registros de la tabla, es posible que haya que esperar a que se liberen los bloqueos, etc.)

Answer 3

En un momento dado, realicé un trabajo de arquitectura en un producto conocido como Acumen Advantage que tiene un administrador de almacén que hace esto.

La estrategia básica para esto es tener un DB de control con una lista de los sprocs y sus dependencias. En función de las dependencias, puede hacer una Ordenamiento topológico para darles una orden de ejecución. Si Para ello, debe administrar las dependencias: todos los predecesores de un procedimiento almacenado deben completarse antes de que se ejecute. El solo hecho de comenzar el proceso en varios subprocesos no lo logrará por sí mismo.

Implementar esto significó que se eliminara gran parte de la funcionalidad de SSIS en la cabeza e implementar otro programador. Esto está bien para un producto, pero probablemente sea excesivo para un sistema a medida. Una solución más simple es así:

Puede administrar las dependencias en un nivel más general organizando el ETL verticalmente por dimensión (a veces conocido como ETL orientado al sujeto ) donde un solo paquete SSIS y un conjunto de datos extraen los datos Extracción a través de dimensiones de producción o tablas de hechos. Normalmente, las dimensiones se silenciarán en su mayoría, por lo que tendrán una interdependencia mínima. Donde haya interdependencia, haga que una dimensión (o tabla de hechos) cargue el proceso dependiendo de lo que necesite en sentido ascendente.

Cada cargador se vuelve relativamente modular y aún se obtiene un grado útil de paralelismo iniciando los procesos de carga en paralelo y dejando que el programador de SSIS lo resuelva. Las dependencias contendrán alguna redundancia. Por ejemplo, una tabla ODS puede no depender de que se complete una carga de dimensión, pero el propio paquete ascendente lleva los componentes directamente al esquema dimensional antes de que se complete. Sin embargo, es probable que esto no sea un problema en la práctica por las siguientes razones:

• El proceso de carga probablemente tenga muchas otras tareas que se pueden ejecutar mientras tanto
• La mayoría de las tareas que consumen muchos recursos serán las cargas de tablas de hechos, que en su mayoría no dependerán unas de otras. Donde hay una dependencia (por ejemplo, una tabla de resumen basada en el contenido de otra tabla), esto no se puede evitar de todos modos.

Puede construir los paquetes SSIS para que recojan toda su configuración de un archivo XML y la ubicación se pueda suministrar de forma externa en una variable de entorno. Este tipo de cosas se pueden implementar con bastante facilidad con sistemas de planificación como Control-M. Esto significa que un paquete SSIS modificado puede implementarse con una intervención manual relativamente pequeña. El personal de producción puede recibir los paquetes para implementar junto con los procedimientos almacenados y puede mantener los archivos de configuración por entorno sin tener que manipular manualmente la configuración de los paquetes SSIS.

Answer 4

es posible que desee consultar a Service Broker y sus procedimientos almacenados de activación ... podrían ser una opción ...