Hay muchas razones para terminar un paquete SSIS que está corriendo mucho tiempo. Imagine un escenario donde un DBA/desarrollador sin experiencia accidentalmente inicia un trabajo mensual en lugar de un trabajo diario, inadvertidamente impactando el desempeño de SQL Server. Cuales quieran que sean las razones, es muy posible encontrarse en una situación en la cual usted tiene que parar temporalmente un proceso de corrida larga.
Aunque SQL Server hace fácil terminar procesos no deseados, es posible que reciba mensajes de error ambiguos en el registro para sus acciones, dependiendo del mecanismo usado para terminar esos procesos. En este artículo damos un vistazo a cómo parar un paquete del Catálogo de Servicios de Integración que ha estado corriendo mucho tiempo pude ser registrado de forma diferente cuando se lo hace desde SQL Server Management Studio (SSMS) versus hacerlo desde el Servidor de Servicios de Integración.
Un caso en punto
Para simular un paquete que ha estado corriendo mucho tiempo, armé un proyecto de demostración de SSIS que contiene Package Sleep.dtsx que usa una Tarea de Script. La Tarea de Script usa un métodoThread.Sleep para añadir un retraso de 10 minutos por cada ejecución de paquete. El método principal de Package Sleep.dtsx es mostrado en Script 1.
|
1 2 3 4 5 |
public void Main() { Thread.Sleep(600000); Dts.TaskResult = (int)ScriptResults.Success; } |
Script 1
My proyecto de demostración SSIS fue luego desplegado en una instancia local de SQL Server 2016 y un Trabajo de SQL Agent – SSISDemoJob – Sleep – fue creado con un solo paso cuyo propósito es ejecutarPackage Sleep.dtsx. La Figura 1 muestra la localización del proyecto recién desplegado SSISDemo y el recién creado SSISDemoJob – Sleep.
El Catálogo de Servicios de Integración tiene un reporte integrado llamado All Executions report que básicamente lista las ejecuciones recientes. Estaremos usando este reporte para recuperar detalles acerca de la ejecución del paquete. El reporte puede accederse como se muestra en la Figura 2.
Cancelar paquete de ejecución desde SSMS
Comencemos corriendo el trabajo SSISDemoJob – Sleep. Digamos que somos informados más tarde de que no deberíamos haber corrido ese trabajo y como resultado tenemos que pararlo. Todo lo que se requiere para pararlo es hacer clic en la opción Stop Job, como se muestra en la Figura 3.
Figura 3 Ahora, si vamos a través del reporte All Executions, podemos notar que parar el Trabajo de SQL Agent generó un estado Unexpected Termination como se muestra en la Figura 4.
Figura 4 El mensaje de error registrado en el Catálogo está en contraste con el mensaje registrado en el trabajo de SQL Agent, como puede verse en la Figura 5 – el registro del agente es más preciso, ya que nosotros sí paramos el trabajo.
Figura 5 Parar la ejecución del paquete haciendo clic en Stop operation en SQL Agent es el equivalente de correr el comando T-SQL Kill . Para demostrar esto, corrí nuevamente SSISDemoJob – Sleep. En lugar de hacer clic en la opción Stop Job en SQL Agent, recuperé la id del proceso (58) para esta operación desde Activity Monitor como se muestra en la Figura 6.
Figura 6 Luego, corrí un comando Kill como se muestra en Script 2.
Script 2 Como puede verse en la Figura 7, matar el proceso con id 58 condujo a que se registre el mismo mensaje que cuando paramos la ejecución usando SQL Agent – Unexpected Termination.
Figura 7 De todas maneras, lo que es más impresionante es que SQL Agent está de nuevo registrando correctamente lo que pasó a la ejecución de este trabajo. Como se puede ver la Figura 8 – la razón por la que el trabajo (y subsecuentemente el paquete) fue terminado fue por una sentencia Kill que fue invocada.
Figura 8 Cancelar la ejecución del paquete desde SSISDB
La sección previa mostraba que cuando la ejecución de un paquete es terminada dentro de SSMS (por ejemplo, un Trabajo de SQL Agent o el comando T-SQL KILL) usted debería usar a información registrada en el historial de trabajos de SQL Agent para saber más acerca de las causas de la terminación. En esta sección damos un vistazo a las varias opciones para terminar un paquete dentro del Servidor de Servicios de Integración (ISS, por sus siglas en ingles). De nuevo, volvemos al trabajo de SQL Agent y corremos nuevamente SSISDemoJob – Sleep.
SSISDB de ISS rastrea todas las operaciones que están actualmente activas/ejecutándose. Para recuperar una lista de todas las operaciones activas, usted necesita hacer clic derecho en SSISDB y elegir Active Operations, como se muestra en la Figura 9.
Figura 9 Se abre la ventana Active Operations, como se muestra en la Figura 10. Usted puede entonces hacer clic en el botón Stop localizado en la parte inferior derecha de la ventana.
Figura 10 Ahora demos un vistazo al estado del mensaje que es registrado siguiendo lo que hicimos. Como puede verse en la Figura 11, un estado Cancelado fue generado por para la ejecución del paquete vía la ventana Active Operations.
Figura 11 Cuando volvemos a SQL Agent, podemos ver en la Figura 12 que el trabajo fue parado debido a una falla, pero el mensaje de error del trabajo va un paso más allá y nos dice que la fuente del error está en el Servidor IS y luego aconseja ir a través del reporte All Executions para más información.
Figura 12 Similarmente a usar el comando Kill, usted puede parar una operación en ISS usando un comando T-SQL. SSISDB tiene el procedimiento almacenado integrado [catalog].[stop_operation] el cual, como el nombre sugiere, para una operación activa. Por tanto, todo lo que pasó cuando hizo clic en el botón Stop en el diálogo Active Operations fue esencialmente ejecutar el procedimiento almacenado stop operation.
Para demostrar esto, corrí de nuevo el trabajo SSISDemoJob – Sleep. También obtuve una lista de operaciones activas en SSISDB, pero en lugar de hacer clic en el botón Stop, tomé nota del ID de la operación, como se muestra en la Figura 13 (en mi caso, el id de la operación es 20038).
Figura 13 Luego usé este ID de operación como parámetro de entrada para al procedimiento almacenado [catalog].[stop_operation]como se muestra en el Script 3.Script 3.
1234USE SSISDBGOEXEC [catalog].[stop_operation] 20038Script 3
Después de ejecutar exitosamente el Script 3, la Figura 14 muestra que otra fila ha sido añadida con un estado Cancelado. Esto confirma que parar la ejecución de un paquete usando la ventana Active Operations es equivalente a ejecutar el procedimiento almacenado [catalog].[stop_operation].
Figura 14 Conclusión
En este artículo hemos demostrado diferentes maneras de parar un Paquete SSIS que ha estado corriendo mucho tiempo. Fue demostrado que el historial de trabajos de SQL Agent es una fuente de información confiable cuando el paquete que se está ejecutando mucho tiempo es terminado usando SQL Agent o un comando T-SQL Kill. Alternativamente, el Servidor de Servicios de Integración se convierte en una fuente confiable para detalles relacionados a ejecución de paquetes que son parados usando la ventana Active Operations o el procedimiento almacenado stop operation.
Downloads
Reference
- Método Thread.Sleep
- Catalog.stop_operation (Base de datos SSISDB)
- Servidor de Servicios de Integración (SSIS) y Catálogo
Sifiso es un profesional basado en Johannesburgo dentro de un amplio rango de Competencias en Tecnología Microsoft como SQL Server y Visual Studio Application Lifecycle Management.
Él es un miembro del Grupo de Usuarios de SQL de Johannesburgo y tiene un grado de maestría en MCom IT Management de la Universidad de Johannesburgo.
Actualmente, él trabaja para Sambe Consulting como Consultor principal.
Ver todas las publicaciones de Sifiso W. NdlovuÚltimas entradas de Sifiso Ndlovu (ver todo)- Entendiendo el Impacto de las sugerencias NOLOCK y WITH NOLOCK en SQL Server - May 28, 2018
- Cómo reemplazar caracteres especiales ASCII en SQL Server - May 25, 2018
- Convertir resultados de SQL Server a JSON - June 2, 2017
