none
Seguir conexiones generadas por un paquete RRS feed

  • Pregunta

  • Hola gente!

    Por lo que he visto, cuando se ejecuta un paquete SSIS cada componente de base de datos (por ejemplo, Tarea de ejecución de script) abre una conexión (sesión) nueva.

    Existe alguna forma de saber qué conexiones abre la ejecución de un paquete invocado por el SQL Agent?

    Gracias y saludos!

    jueves, 14 de junio de 2012 15:33

Respuestas

  • Hola,

    También está la propiedad RetainSameConnection de los administradores de conexiones que añadas a los paquetes, por defecto su valor es false.

    Puedes monitorizar las conexiones que lanza un paquete si añades la propiedad Application Name="Paquete Integration xx" a la cadena de conexión y utilizando una traza de SQL Profiler conectada al servidor dónde estas conectando para obtener/cargar datos. En SQL Profiler puedes filtrar por el valor de esta propiedad y monitorizar eventos relacionados con la conexión (como Audit Login).


    Víctor M. Sánchez García (ES) (BI) Hope this help. Please vote if you find this posting was helpful. if this is an answer to your question, please mark it. http://bifase.blogspot.com | http://twitter.com/atharky

    • Marcado como respuesta mmiraglia viernes, 15 de junio de 2012 12:23
    jueves, 14 de junio de 2012 22:53

Todas las respuestas

  • Hola.

    Eso no depende del Agente, sino del paquete de Integration Services (y el número de tareas en paralelo que tenga que ejecutar) y del servidor en que corra, concretamente del número de procesadores del mismo. Así, se lanzarán paralelamente N + 2 procesos, siendo N el número de núcleos del servidor, y claro está, si no se ha limitado por la configuración del paquete el número de tareas a lanzar en paralelo y no estén secuenciadas en el mismo.

    ¿Se te ha planteado algún problema o caso concreto por el que debas preocuparte?


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.com
    Sígueme en twitter en http://twitter.com/qwalgrande

    jueves, 14 de junio de 2012 21:43
    Moderador
  • Hola,

    También está la propiedad RetainSameConnection de los administradores de conexiones que añadas a los paquetes, por defecto su valor es false.

    Puedes monitorizar las conexiones que lanza un paquete si añades la propiedad Application Name="Paquete Integration xx" a la cadena de conexión y utilizando una traza de SQL Profiler conectada al servidor dónde estas conectando para obtener/cargar datos. En SQL Profiler puedes filtrar por el valor de esta propiedad y monitorizar eventos relacionados con la conexión (como Audit Login).


    Víctor M. Sánchez García (ES) (BI) Hope this help. Please vote if you find this posting was helpful. if this is an answer to your question, please mark it. http://bifase.blogspot.com | http://twitter.com/atharky

    • Marcado como respuesta mmiraglia viernes, 15 de junio de 2012 12:23
    jueves, 14 de junio de 2012 22:53
  • Hola qwalgrande!
    El problema que se plantea es en el servidor de Gestión, donde corren varios ETLs a la vez (automáticamente, por medio de trabajos programados) y hace unos días nos encontramos con que hay varios trabajos corriendo, pero que en realidad vemos que hay 3 sesiones activas sobre el servidor, por lo que el resto (entre 10 o 15, dependiendo de la hora) no están ejecutando realmente.
    Pero cuál de esos trabajos paramos? La ejecución del job tiene un spid y las conexiones que hace el paquete que ejecuta dicho trabajo tienen otros varios. Así, por más que veamos que se está ejecutando un stored procedure, no sabemos a qué ETL pertenece.

    Para ejemplificarlo mejor, te adjunto una imágen de un caso sencillo, donde hay dos tareas de ejecución de SQL que se conectan a dos bases distintas.

    Paquete SSIS

    Cuando arranca el job, éste obtiene el SPID 113. Al ejecutar la primer consulta (mientras el SPID 113 sigue vivo) se abre otra sesión con SPID 111. Al terminar esta consulta y ejecutar la segunda sobre la BaseB, se abre otra sesión con SPID 73.

    Gracias y saludos!

    • Editado mmiraglia viernes, 15 de junio de 2012 14:36
    viernes, 15 de junio de 2012 12:23
  • Hola Victor M!

    Ya configuré la propiedad RetainSameConnection en las dos conexiones del ejemplo que le cometaba a qwalgrande, pero el resultado es el que mencioné: se siguen generando distintas sesiones.
    En cuanto a tu otra sugerencia, te paso la cadena de conexión que tengo:

    Data Source=torrontes;Initial Catalog=BaseA;Provider=SQLNCLI.1;Integrated Security=SSPI;Auto Translate=False;Application Name="DBA_PruebaConexion";

    Y lo pude ver en la traza!!! Además, también esa información la brinda el sp_who2, así que va de fábula!
    El dolor ahora va a ser modificar los 100 ETLs que tenemos... así que si tienen algún "atajo" para esto (agregar esa información a la cadena de conexión programáticamente) será bien recibido!

    Gracias y saludos!
    • Marcado como respuesta mmiraglia viernes, 15 de junio de 2012 12:23
    • Desmarcado como respuesta mmiraglia viernes, 15 de junio de 2012 12:23
    viernes, 15 de junio de 2012 12:23
  • Hola,

    En la medida de lo posible deberías utilizar configuraciones (si utilizas package deployment model) o modificar las propiedades de las conexiones a través de parametros de entorno (si utilizas project deployment model, disponible en SQL Server 2012). Seguramente de los 100 habrá muchos, o algunos en el peor de los casos, que compartan la misma conexión y mediante configuraciones o parámetros puedes hacer que tomen una nueva cadena de conexión sin tener que modificar los paquetes. Si no utilizas alguno de estos métodos si que tendrás que modificar todos los paquetes, pero te sugiero que lo hagas para incorporar alguno de los métodos que te comento.

    Un saludo!


    Víctor M. Sánchez García (ES) (BI) Hope this help. Please vote if you find this posting was helpful. if this is an answer to your question, please mark it. http://bifase.blogspot.com | http://twitter.com/atharky

    viernes, 15 de junio de 2012 13:22
  • Hola,

    En la medida de lo posible deberías utilizar configuraciones (si utilizas package deployment model) o modificar las propiedades de las conexiones a través de parametros de entorno (si utilizas project deployment model, disponible en SQL Server 2012). Seguramente de los 100 habrá muchos, o algunos en el peor de los casos, que compartan la misma conexión y mediante configuraciones o parámetros puedes hacer que tomen una nueva cadena de conexión sin tener que modificar los paquetes. Si no utilizas alguno de estos métodos si que tendrás que modificar todos los paquetes, pero te sugiero que lo hagas para incorporar alguno de los métodos que te comento.

    Un saludo!


    Víctor M. Sánchez García (ES) (BI) Hope this help. Please vote if you find this posting was helpful. if this is an answer to your question, please mark it. http://bifase.blogspot.com | http://twitter.com/atharky

    Gracias nuevamente Victor, pero olvidé mencionar que el servidor en cuestión es versión 2005, por lo que hasta ahora vamos a tener que modificar los ETLs uno por uno :(

    viernes, 15 de junio de 2012 14:37
  • En SQL 2005 también existen las configuraciones para paquetes...http://msdn.microsoft.com/en-us/library/ms141682(v=sql.90).aspx

    Te recomiendo que intentes implementarlas :)

    En este enlace muestra como hacerla mediante un archivo XML pero también puedes almacenar las configuraciones en una tabla SQL.

    http://www.mssqltips.com/sqlservertip/1434/using-xml-package-configurations-with-integration-services-ssis/


    Víctor M. Sánchez García (ES) (BI) Hope this help. Please vote if you find this posting was helpful. if this is an answer to your question, please mark it. http://bifase.blogspot.com | http://twitter.com/atharky


    • Editado Víctor M viernes, 15 de junio de 2012 14:49
    viernes, 15 de junio de 2012 14:48