En nuestro trabajo diario como DBAs o administrando alguna infraestructura de base de datos, siempre es de vital importancia saber qué usuarios están conectados a la instancia o a una base de datos específica, ya sea para diagnosticar algún problema o determinar el grado de uso de la misma. En SQL Server hay un método sencillo de averiguar esto.

Para ver cómo funciona, basta abrir una ventana de consulta y ejecutar el comando SP_WHO2.

Este Procedimiento Almacenado (o Stored Procedure) nos listará todos los procesos actuales corriendo en la base de datos. Entre la información que nos da este comando, vemos lo siguiente:

• SPID: Identificador de sesión
• Status: Estado actual de la sesión. Puede tener los valores:
  • BACKGROUND: Para servicios internos de SQL Server
  • PENDING: La sesión está abierta pero esperando un thread disponible para ejecutarse
  • RUNNABLE: Si es una sesión abierta y tiene asignado un thread pero no ciclos de CPU
  • RUNNING: Para una sesión que está ejecutando un proceso o consulta ahora
  • SLEEPING: Si es una sesión abierta pero no está ejecutando nada actualmente
  • SUSPENDED: La sesión está abierta a la espera de que se libere un recurso (I/O, CPU) para seguir ejecutándose, o empezar a hacerlo.
• Login: Nombre del usuario conectado a la base de datos
• Hostname: Nombre del servidor/workstation desde donde el Login está ejecutando la consulta
• BlkBy: Indica si la sesión en mención está bloqueada. Si es así, nos mostrará un número, que es el SPID de la sesión que está causando el bloqueo.
• DBName: Nombre de la base de datos a la cual está conectado el Login
• Command: Tipo de comando que está ejecutando el Login
• ProgramName: Nombre del programa desde el cual el Login está ejecutando la consulta

Como podemos ver, este poderoso comando también nos puede ayudar a verificar si existen bloqueos en la base de datos, por lo que es uno de los comandos más usados a la hora de diagnosticar problemas de rendimiento.

Es esta la única forma?

Si bien hay otros comandos personalizados que pueden darnos más flexibilidad o información más detallada, he creído conveniente recomendar este (junto con el SP_WHO, para situaciones donde la base de datos está tan saturada que no es posible ejecutar el SP_WHO2) porque ambos son procedimientos nativos de SQL Server y no requieren de la creación de ningún procedimiento almacenado para su uso.

En otro artículo estaré cubriendo este otro tipo de comandos que nos ayudarán a visualizar la actividad de nuestra instancia de base de datos previa creación de sus stored procedures, a la par de cuáles son los más usados por DBAs y consultores 😉.

Si tienes alguna duda, comentario o sugerencia, puedes mandarme un email a bitácoradeundba@gmail.com.