Iniciar procedimientos almacenados secuencialmente o en paralelo

Question

Tenemos un procedimiento almacenado que se ejecuta cada noche y que a su vez da inicio a una serie de otros procedimientos. Algunos de esos procedimientos podrían lógicamente ejecutarse en paralelo con algunos de los otros.

• Como puedo indicar a SQL Server si un procedimiento se debe ejecutar en paralelo o en serie — es decir: arrancó de forma asíncrona o el bloqueo?
• Cuáles serían las implicaciones de ejecutarlos en paralelo, teniendo en cuenta que ya he determinado que los procesos no competirán por el acceso a la tabla o los bloqueos, solo el disco total io y la memoria. En su mayor parte, ni siquiera usan las mismas tablas.
• ¿Importa si algunos de esos procedimientos son el mismo procedimiento , solo con diferentes parámetros?
• Si comienzo un par o procedimientos de forma asincrónica, ¿hay un buen sistema en SQL Server para esperar a que ambos finalicen, o necesito que cada uno de ellos establezca una bandera en algún lugar y compruebe y sondee el indicador periódicamente usando WAITFOR DELAY?

Por el momento estamos todavía en SQL Server 2000.

Como nota al margen, esto es importante ya que el procedimiento principal se inició en respuesta a la finalización de un volcado de datos en el servidor de una sistema de mainframe El volcado del mainframe demora aproximadamente 2 horas cada noche y no tenemos control sobre él. Como resultado, estamos constantemente tratando de encontrar maneras de reducir los tiempos de procesamiento.

Answer 1

Tuve que investigar esto recientemente, así que encontré esta vieja pregunta que mendigaba una respuesta más completa. Solo para ser totalmente explícito: TSQL no no (solo) tienen la capacidad de iniciar otras operaciones TSQL asincrónicamente.

Eso no significa que usted no tiene todavía una gran cantidad de opciones (algunos de ellos mencionado en otras respuestas):

• de aplicaciones personalizadas: escribir una aplicación personalizada simple en el idioma de su elección, utilizando métodos asíncronos. Llame a un proceso almacenado SQL en cada subproceso de la aplicación.
• SQL Agent jobs: Crea varios trabajos SQL e inícialos de forma asincrónica desde tu proc usando sp_start_job. Puede verificar si ya han terminado utilizando la función no documentada xp_sqlagent_enum_jobs como se describe en this excellent article por Gregory A. Larsen. (O haga que los trabajos mismos actualicen su propia tabla JOB_PROGRESS como sugiere Chris). Literalmente tendría que crear un trabajo por separado para cada proceso paralelo que prevea ejecutar, incluso si ejecutan el mismo proceso almacenado con diferentes parámetros.
• Automatización OLE: Uso sp_oacreatesp_oamethod y para poner en marcha un nuevo proceso de llamar a otro procedimiento almacenado como se describe en this article, también por Gregory A. Larsen.
• Paquete DTS: Cree un paquete DTS o SSIS con un flujo de tareas de bifurcación simple. DTS iniciará tareas en spids individuales.
• Service Broker: Si usted está en SQL2005 +, mirar en el uso Service Broker
• CLR ejecución paralela: Utilice los comandos de CLR Parallel_AddSql y Parallel_Execute como se describe en this article por Alan Kaplan (SQL2005 + solamente).
• Tareas programadas de Windows: Se presenta a continuación, pero no soy un admirador de esta opción.

No tengo mucha experiencia con Service Broker o CLR, por lo que no puedo comentar sobre esas opciones. Si fuera yo, probablemente usaría varios trabajos en escenarios más simples y un paquete DTS/SSIS en escenarios más complejos.

Un último comentario: SQL ya intenta paralelizar operaciones individuales siempre que pueda *. Esto significa que ejecutar 2 tareas al mismo tiempo en lugar de una después de la otra no es garantía de que termine antes. Pruébelo cuidadosamente para ver si realmente mejora algo o no.

Teníamos un desarrollador que creó un paquete DTS para ejecutar 8 tareas al mismo tiempo. Desafortunadamente, era solo un servidor de 4 CPU :)

* Asumiendo la configuración predeterminada.Esto se puede modificar alterando el Grado máximo de paralelismo o la Máscara de afinidad del servidor, o usando la sugerencia de consulta MAXDOP.

Answer 2

Crea un par de trabajos de agente de SQL Server donde cada uno ejecuta un proceso en particular.

Luego, desde su master proc, inicie los trabajos.

La única forma de esperar que puedo pensar es si tiene una tabla de estado que cada proc actualiza cuando termina.

Luego, otro trabajo podría sondear esa tabla para completarla por completo y dar inicio a un proceso final. Alternativamente, podría tener un disparador en esta tabla.

Las implicaciones de memoria son totalmente de su entorno ..

ACTUALIZACIÓN: Si usted tiene acceso al sistema de tareas .. entonces usted podría tener el mismo enfoque. Simplemente haga que Windows ejecute múltiples tareas, cada una responsable de un proceso. Luego use un disparador en la tabla de estado para iniciar algo cuando todas las tareas se hayan completado.

Update2: Además, si usted está dispuesto a crear una nueva aplicación, que podría albergar a toda la lógica en un solo exe ...

Answer 3

Es necesario para mover los procedimientos almacenados durante la noche a puestos de trabajo . El control de trabajo de SQL Server le permitirá hacer toda la programación que está solicitando.

Answer 4

Es posible que desee considerar el uso de DTS (que se puede ejecutar desde el Agente SQL como un trabajo). Le permitirá un control bastante preciso sobre qué procedimientos almacenados deben esperar a que otros finalicen y qué se puede ejecutar en paralelo. También puede ejecutar el paquete DTS como un EXE desde su propio software de programación si es necesario.

NOTA: Tendrá que crear varias copias de sus objetos de conexión para permitir que las llamadas se ejecuten en paralelo. Dos llamadas que usan el mismo objeto de conexión se bloquearán entre sí incluso si no se establece explícitamente una dependencia.