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)..
