Buscar este blog

viernes, 26 de agosto de 2016

Diferentes Status de una Sesión (Spid) en Sql Server // Scheduler Qué Es y Cuál es su Función?


Hola amigos…

Luego de unos meses en los cuales la actividad me impidió estar en contacto con Uds. quiero retomar el mismo, con la promesa de intentar no volver a interrumpirlo, a través de este artículo…

Gracias por los mails recibidos con preguntas, y todo tipo de cuestiones relacionadas con nuestra actividad. Como siempre, las voy respondiendo con toda la urgencia que puedo y con la privacidad requerida por uds.

Justamente quiero abordar un tema que suele ser muy frecuente en los correos que recibo. Tiene que ver con los distintos estados por los que una sesión – SPID - (proceso),   puede pasar hasta ser resuelta por el motor de base de datos. Para ello considero fundamental ahondar previamente en un concepto que pocos colegas parecen tener claro, hablo de qué es y qué función cumple el Scheduler en el motor de base de datos.

 Particularmente noto que el estado “Suspended” es el que más inquieta a los colegas.. Pero eso será objeto de un próximo post.

Hoy quiero concentrarme en una breve pero explícita explicación de los posibles estados de un SPID.
Un SPID es una sesión abierta para la ejecución de un proceso en nuestra base de datos.  Los SPID  1 al 49 están reservados para los procesos del sistema, el resto (del 50 en adelante), para los procesos de usuario.

Hay un concepto aquí que es fundamental entender y es el que tiene que ver con el SCHEDULER.
Qué es el scheduler? Básicamente es un proceso madre encargado de Organizar y Asignar a cada Spid un hilo de ejecución (Worker Thread).

Cada Scheduler puede estar corriendo una, y solo una,  tarea activa. El resto de las tareas son puestas por el scheduler en una cola de espera, que da origen, como verán luego, a algunos de los status por los que un proceso puede pasar.

Pero cuántos Scheduler hay en nuestro motor de base de datos?. Uno por cada procesador lógico (no físico).  Es decir que si vuestro equipo tiene tan sólo un procesador, pero tiene habilitado  hyperthreading, van a existir dos Schedulers.

 Una consulta para entender los schedulers presentes en nuestro sistema? Pues claro que si.. Microsoft nos asiste con la siguiente vista a saber:
SELECT * FROM sys.dm_os_schedulers WHERE STATUS = ‘VISIBLE ONLINE’

Entonces, y pasando en limpio, el Scheduler es quien se encarga de asignar a cada spid un hilo de ejecución del cpu. Es un intermediario entre los procesos y el cpu.

Pensemos en estos términos. Supongamos que vamos de compras a un mercado en el que solo 2 operarios están atendiendo (procesadores lógicos).  Pues bien, sería un caos si todos los clientes vamos a abordar a los pobres vendedores al mismo tiempo verdad?. Por suerte hay dos encargados que reparten números para que nosotros podamos ser atendidos, cada uno a su tiempo. Estos dos encargados en el contexto del sql server serían los Schedulers).

Recordemos que los procesos que se están ejecutando actualmente en nuestro SQL pueden ser consultados entre otras herramientas por medio del sp_who2 o la vista del sistema sys.sysprocesses. (por más detalles consultar en este mismo blog en post anteriores).

Vamos a la explicación de los estados entonces. Si bien hay mucha bibliografía al respecto noto por las consultas recibidas que muchos colegas necesitan de una explicación más amena que y simple que la de Microsoft da en su web.

Vamos con la explicación entonces al estilo Sql Server Para Todos. Es decir, sencilla y en castellano para todos los hermanos de Latinoamérica:

“Running”:  este estado es “música para nuestros oídos de DBA”,  puesto que implica que nuestro proceso está en plena ejecución, utilizando el thread asignado por el Scheduler y en camino de ser resuelto.

Runnable”: no confundir con “running”… Es un estado en el cual la sesión ha obtenido un worker thread (hilo de ejecución) por parte del Scheduler, mas está esperando la resolución de un proceso previo que libere al cpu y así poder utilizar el thread de trabajo que le fue asignado.  Pensemos en nuestro ejemplo el mercado… El cliente ya tiene el número, pero tienen que esperar que el vendedor se desocupe…

Pending”:  la sesión está esperando la asignación por parte del Scheduler de un Thread de Ejecución. El cliente está en el mercado esperando un nº para entonces si entrar en la cola y poder ser atendido por el vendedor…

Background”: generalmente un estado de los spids que corren “tras bambalinas” y que corresponden al sistema, no al usuario. Todos tienen un spid menor a 50 y no debiera de llamar nuestra atención de modo particular.

Sleeping”:  refiere a una sesión abierta cuyo proceso ya fue ejecutado y  no está desarrollando ninguna actividad en el server. Es típico ver este tipo de sesiones en programas mal diseñados o en usuarios que abren “new queries” constantemente en la consola del Sql Server sin cerrar las mismas una vez utilizadas. Ojo..toda sesión abierta, aún inactiva,  genera consumo de recursos, no debiera permitirse este comportamiento

Dormant” = el dormant es el estado en el cual una conexión hecha a través de un server linkeado permanece inactiva una vez que la misma deja de ser utilizada. El tiempo de permanencia de la sesión en este estado es de aproximadamente 4 a 5 minutos (antes de ser cerrada automáticamente por el SQL)

Rollback” =  indica que una transacción está en medio de un rollback. No recomiendo hacer ningún tipo de acción por más que el rollback se prolongue en el tiempo. Alguna vez he visto a un colega reiniciar el servicio de sql server pensando que eso iba a solucionar la demora.. Desde ya no es asi…

 “Suspended” = La session está ejecutándose (tal el caso de la sesión que muestra el valor running), mas está esperando por la liberación de recursos a nivel de I/O, memoria etc… Sin dudas es un estado que no debiera reflejar las constante de nuestro sistema y que merece un tratamiento aparte que, les prometo, he de abordarlo en mi próximo post.


Amigos espero que el post le haya sido de utilidad. Ya retomamos el contacto. Nos vemos próximamente con otro nuevo post. Sigan enviando sus mail que son muy bien recibidos (y por favor tengan paciencia y no olviden de apuntar la privacidad con la que quieren que sean contestados)..

5 comentarios:

  1. Muchas gracias por este articulo me fue de muchísima utilidad me ayudo a comprender el tema con total facilidad gracias nuevamente.
    Claudia de Argentina

    ResponderEliminar
  2. Gustavo: Super! gracias, eres muy claro para explicar. Una consulta, el post que prometiste en esta publicación, sobre el estado Suspended, me puedes dejar el link? Muchas gracias!

    ResponderEliminar
  3. Hola!!!
    Gracias por la explicación, me encanto tu blog :D saludos desde la CDMX

    ResponderEliminar
  4. Si está en modo Sleeping es recomendable matarlo con un kill?

    ResponderEliminar
    Respuestas
    1. Oscar depende. Hay aplicaciones que toman un pool de conexiones y las utilizando on demand. Si es ese el caso, estarías permanentemente forzando a la app a recomponer su pool. Si por el contrario se trata de ventanas abiertas por users en las ides pues tal vez puedas hacer un job que se encargue de hacer el kill correspondiente cada x tiempo. Saludos.

      Eliminar