Autor: Oscar Morán

SQL Server Rebuild vs Reorganize, en SQL Server, es posible realizar tanto un rebuild como un reorganize sobre los índices. Estas son operaciones relacionadas con el mantenimiento de los índices en la base de datos, y ambas tienen el objetivo de mejorar el rendimiento de las consultas optimizando los índices. Sin embargo, funcionan de manera diferente y se utilizan en diferentes situaciones dependiendo del grado de fragmentación de los índices.

1. Rebuild (Reconstruir Índices)

• Qué hace: El comando rebuild crea un índice completamente nuevo desde cero, eliminando el índice existente y reconstruyéndolo. Este proceso reorganiza los datos físicamente en las páginas de datos de la base de datos, eliminando cualquier fragmentación.
• Cuándo usarlo: Se recomienda realizar un rebuild cuando la fragmentación de un índice es superior al 30%.
• Efecto en el sistema: Esta operación es más intensiva que el reorganize, ya que requiere más recursos (CPU, memoria, disco) y bloquea el índice durante la operación, aunque en las versiones recientes de SQL Server, se puede realizar un rebuild en línea para reducir el impacto.

Comando:

sql

ALTER INDEX nombre_del_indice
ON nombre_de_la_tabla
REBUILD;

• Pros:
  • Elimina completamente la fragmentación.
  • Compacta las páginas de datos.
• Contras:
  • Consume más recursos.
  • Puede bloquear el acceso a los datos durante la operación.

2. Reorganize (Reorganizar Índices)

• Qué hace: El comando reorganize realiza una reorganización de los fragmentos de un índice existente. Es una operación menos agresiva que el rebuild, ya que solo reorganiza los datos dentro de las páginas existentes en lugar de recrear el índice desde cero. Reorganize también compacta los niveles del índice.
• Cuándo usarlo: Se recomienda hacer un reorganize cuando la fragmentación es entre el 5% y 30%.
• Efecto en el sistema: Es una operación menos intensiva y se puede realizar sin bloquear el índice, permitiendo que las consultas sigan ejecutándose.

Comando:

ALTER INDEX nombre_del_indice
ON nombre_de_la_tabla
REORGANIZE;

• Pros:
  • Consume menos recursos y no bloquea el índice.
  • Se puede realizar mientras los usuarios acceden a los datos.
• Contras:
  • No elimina completamente la fragmentación, solo la reduce.

Cuándo usar Rebuild vs Reorganize

• Menos del 5% de fragmentación: No se necesita mantenimiento.
• Entre 5% y 30% de fragmentación: Es recomendable hacer un reorganize.
• Más del 30% de fragmentación: Se recomienda hacer un rebuild.

Ver fragmentación de los índices

Antes de decidir si hacer un rebuild o reorganize, es útil medir el nivel de fragmentación con la siguiente consulta:

SELECT 
    dbschemas.[name] AS 'Schema',
    dbtables.[name] AS 'Table', 
    dbindexes.[name] AS 'Index', 
    indexstats.avg_fragmentation_in_percent
FROM 
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
    INNER JOIN sys.tables dbtables ON dbtables.[object_id] = indexstats.[object_id]
    INNER JOIN sys.schemas dbschemas ON dbtables.[schema_id] = dbschemas.[schema_id]
    INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
    AND indexstats.index_id = dbindexes.index_id
WHERE 
    indexstats.database_id = DB_ID()
    AND dbindexes.[name] IS NOT NULL
ORDER BY 
    avg_fragmentation_in_percent DESC;

Resumen:

• Rebuild: Ideal para fragmentación >30%, más intensivo, elimina completamente la fragmentación.
• Reorganize: Para fragmentación entre 5%-30%, menos intensivo, no elimina toda la fragmentación, pero es más rápido y amigable para el sistema.

Guía Completa para Implementar FULLTEXT en SQL

EXEC sp_change_users_login SQL SERVER

Para que una tabla tenga FULLTEXT SQL

Procedimientos Almacenados Temporales en SQL Server

Tutorial completo Data Migration Assistant SQL Server

Extracción de las Vistas en SQL Server

Monitoreo Avanzado de Sesiones en SQL Server, en la administración de bases de datos SQL Server, es crucial monitorear las sesiones activas para identificar problemas de rendimiento, bloquear procesos, y optimizar las operaciones. Una manera efectiva de hacerlo es utilizando consultas avanzadas que nos proporcionen una visión detallada de lo que está sucediendo en el servidor. En este blog, desglosaremos una consulta compleja que te permite obtener información detallada sobre las sesiones activas, el progreso de sus operaciones, y otros indicadores clave.

La Consulta en Detalle

La consulta que vamos a analizar es la siguiente:

SELECT 
    ss.session_id SPID,
    original_login_name,
    sp.status,
    blocking_session_id [Blk by],
    command,
    db_name(sp.database_id) [Database],
    [objectid],
    percent_complete [% Done],
    CASE 
        WHEN DATEDIFF(mi, start_time, GETDATE()) > 60 THEN 
            CONVERT(varchar(4), (DATEDIFF(mi, start_time, GETDATE()) / 60)) + ' hr '  
        ELSE '' 
    END + 
    CASE 
        WHEN DATEDIFF(ss, start_time, GETDATE()) > 60 THEN 
            CONVERT(varchar(4), (DATEDIFF(mi, start_time, GETDATE()) % 60)) + ' min ' 
        ELSE '' 
    END + 
    CONVERT(varchar(4), (DATEDIFF(ss, start_time, GETDATE()) % 60)) + ' sec' [Duration],
    estimated_completion_time / 60000 [ETA (Min)],
    [text] [input stream/text],
    (SUBSTRING([text], statement_start_offset / 2 + 1, 
    ((CASE 
        WHEN statement_end_offset < 0 THEN (LEN(CONVERT(nvarchar(max), [text])) * 2) 
        ELSE statement_end_offset 
    END)  - statement_start_offset) / 2 + 1)) AS [Executing_sql_statement],
    wait_resource,
    wait_time / 1000 [wait_time (sec)],
    last_wait_type,
    login_time,
    last_request_start_time,
    last_request_end_time,
    host_name,
    CASE 
        WHEN program_name LIKE 'SQLAgent%Job%' THEN 
            (SELECT TOP 1 '(SQLAgent Job - ' + name + ' - ' + RIGHT(program_name, LEN(program_name) - CHARINDEX(':', program_name)) 
             FROM msdb.dbo.sysjobs SJ 
             WHERE UPPER(master.dbo.fn_varbintohexstr(SJ.job_id)) = UPPER(SUBSTRING([program_name], 30, 34))) 
        ELSE program_name  
    END  [program_name],
    sp.open_transaction_count,
    CASE 
        WHEN sp.transaction_isolation_level = 0 THEN 'Unspecified' 
        WHEN sp.transaction_isolation_level = 1 THEN 'ReadUncommitted' 
        WHEN sp.transaction_isolation_level = 2 THEN 'ReadCommitted' 
        WHEN sp.transaction_isolation_level = 3 THEN 'Repeatable' 
        WHEN sp.transaction_isolation_level = 4 THEN 'Serializable' 
        WHEN sp.transaction_isolation_level = 5 THEN 'Snapshot' 
    END [transaction_isolation_level],
    sp.cpu_time,
    sp.reads,
    sp.writes,
    sp.logical_reads,
    sp.lock_timeout,
    sp.row_count 
FROM sys.dm_exec_requests AS sp 
OUTER APPLY sys.dm_exec_sql_text(sp.sql_handle) AS esql 
RIGHT OUTER JOIN sys.dm_exec_sessions ss ON ss.session_id = sp.session_id  
WHERE ss.status <> 'sleeping';

¿Qué hace esta consulta sobre Monitoreo Avanzado de Sesiones en SQL Server?

Esta consulta está diseñada para obtener información detallada sobre las sesiones activas en SQL Server, excluyendo aquellas en estado sleeping. Vamos a desglosar los principales elementos de la consulta para entender cómo funciona y qué información proporciona.

1. Información Básica de la Sesión

• SPID (session_id): Identificador único de la sesión en el servidor.
• original_login_name: El nombre de usuario que inició la sesión.
• status: El estado actual de la sesión, por ejemplo, running, suspended, etc.
• Blk by (blocking_session_id): Indica el SPID del proceso que está bloqueando esta sesión, si existe un bloqueo.

2. Detalles del Comando y Progreso

• command: El comando SQL que se está ejecutando en la sesión.
• Database: La base de datos donde se está ejecutando el comando.
• percent_complete: Porcentaje de progreso de la operación en ejecución, útil para operaciones de larga duración como indexaciones o backups.
• Duration: Muestra cuánto tiempo ha estado en ejecución la operación actual.

3. Estimaciones y Texto de la Consulta

• ETA (Min): Estimación del tiempo restante para completar la operación en minutos.
• input stream/text: El texto completo del comando SQL que se está ejecutando.
• Executing_sql_statement: El texto exacto de la declaración SQL que se está ejecutando en ese momento.

4. Información de Espera y Bloqueos

• wait_resource: El recurso específico en el que la sesión está esperando.
• wait_time (sec): Tiempo que la sesión ha estado esperando en segundos.
• last_wait_type: El tipo de espera más reciente para esta sesión, que puede ayudar a diagnosticar problemas de rendimiento.

5. Detalles del Sistema y Programa

• host_name: Nombre del host desde el cual se ha iniciado la sesión.
• program_name: Nombre del programa que inició la sesión. Si es un trabajo de SQL Agent, también se muestra el nombre del trabajo.

6. Transacciones y Aislamiento

• open_transaction_count: Número de transacciones abiertas en la sesión.
• transaction_isolation_level: El nivel de aislamiento de transacción actual, que puede variar desde ReadUncommitted hasta Serializable.

7. Estadísticas de Uso de Recursos

• cpu_time, reads, writes, logical_reads: Estadísticas sobre el uso de CPU, operaciones de lectura y escritura, y lecturas lógicas realizadas por la sesión.
• lock_timeout: El número de veces que una operación ha excedido el tiempo de espera para obtener un bloqueo.
• row_count: El número de filas procesadas por la sesión.

Aplicaciones Prácticas

Monitoreo de Sesiones Activas

Esta consulta es invaluable para administradores de bases de datos que necesitan una visión detallada de las sesiones activas en su servidor. Permite identificar rápidamente sesiones problemáticas, como aquellas que están bloqueando otras, o que están consumiendo una cantidad excesiva de recursos.

Diagnóstico de Problemas de Rendimiento

Al revisar los tiempos de espera, los tipos de bloqueo, y las estadísticas de uso de recursos, puedes diagnosticar cuellos de botella en el rendimiento y tomar medidas para optimizar las operaciones. Por ejemplo, si un proceso está tomando demasiado tiempo debido a una espera en un recurso, puedes investigar más a fondo o ajustar la configuración de SQL Server para mejorar la eficiencia.

Gestión de Transacciones

Con el conteo de transacciones abiertas y el nivel de aislamiento de transacciones, esta consulta también ayuda a garantizar que las transacciones se manejen de manera eficiente y que no existan conflictos que puedan causar bloqueos o ralentizaciones.

¿Cuándo usar este script: Monitoreo Avanzado de Sesiones en SQL Server?

Esta consulta es una herramienta poderosa para monitorear y diagnosticar sesiones activas en SQL Server. Aquí te explico algunas situaciones específicas en las que puede ser especialmente útil:

1. Identificación de Procesos Lentos o Colgados

Si experimentas que ciertas operaciones en SQL Server están tomando mucho más tiempo de lo habitual, puedes ejecutar esta consulta para identificar el proceso problemático. Al revisar columnas como Duration, percent_complete, y ETA (Min), puedes determinar cuánto tiempo ha estado ejecutándose la operación y si está cerca de completarse.

Situación: Supongamos que un trabajo de mantenimiento, como la reconstrucción de un índice, está tomando demasiado tiempo. Esta consulta te permite ver el porcentaje completado (percent_complete), el tiempo estimado de finalización (ETA (Min)), y el tiempo total que ha estado en ejecución (Duration). Si los tiempos son excesivos, puedes tomar decisiones como cancelar el trabajo o investigar más a fondo qué lo está ralentizando.

2. Diagnóstico de Bloqueos

Los bloqueos son un problema común en bases de datos concurridas, donde un proceso retiene un bloqueo sobre un recurso y otros procesos deben esperar. Esta consulta te ayuda a identificar procesos que están siendo bloqueados y el proceso que los está bloqueando (Blk by).

Situación: Si los usuarios informan que una aplicación se está quedando colgada o que las transacciones están tardando más de lo normal, puedes ejecutar esta consulta para ver si hay bloqueos. La columna Blk by te muestra el SPID del proceso que está causando el bloqueo, permitiéndote investigar más a fondo o tomar acciones, como matar el proceso bloqueador.

3. Optimización de Consultas

La consulta muestra el texto completo del SQL que se está ejecutando (input stream/text) y la parte específica de la declaración que se está ejecutando actualmente (Executing_sql_statement). Esto es extremadamente útil para optimizar consultas, ya que te permite identificar qué parte exacta de una consulta compleja está consumiendo más recursos o está tomando más tiempo.

Situación: Si una consulta está utilizando demasiado CPU o está provocando muchas lecturas/escrituras, puedes usar esta información para revisar y optimizar la consulta SQL en cuestión. Podrías agregar índices, reescribir la consulta, o ajustar los planes de ejecución para mejorar el rendimiento.

4. Monitoreo de Trabajos Programados

SQL Server Agent es responsable de ejecutar trabajos programados, como copias de seguridad o tareas de mantenimiento. A veces, estos trabajos pueden fallar o tomar más tiempo del esperado. La columna program_name en esta consulta identifica específicamente si una sesión está ejecutando un trabajo de SQL Agent, incluyendo el nombre del trabajo.

Situación: Si sospechas que un trabajo de SQL Agent no se está ejecutando correctamente, esta consulta te permitirá identificarlo y ver en qué etapa está. Esto es útil para resolver problemas rápidamente sin tener que buscar manualmente en los registros de SQL Agent.

5. Análisis de Esperas y Bloqueos

Las columnas wait_time (sec) y last_wait_type te permiten ver cuánto tiempo ha estado esperando un proceso y cuál fue el último tipo de espera experimentado. Esto es crucial para diagnosticar problemas de rendimiento relacionados con la espera de recursos como discos, CPU, o bloqueos de otros procesos.

Situación: Si notas que ciertas transacciones están tardando más de lo normal, puedes usar estas columnas para ver si están esperando en recursos específicos, como una página de datos bloqueada por otro proceso o esperando en disco debido a una operación de entrada/salida lenta.

6. Gestión de Transacciones

Las columnas open_transaction_count y transaction_isolation_level son útiles para entender cómo las transacciones están siendo manejadas en el servidor. Esto puede ayudarte a diagnosticar problemas de concurrencia o ver si una transacción está manteniendo recursos bloqueados durante mucho tiempo.

Situación: Si un proceso tiene una transacción abierta durante un período prolongado, podría estar reteniendo bloqueos que afectan a otros procesos. Identificar el nivel de aislamiento de la transacción también te permite ajustar configuraciones o recomendaciones para evitar problemas de concurrencia.

7. Control del Uso de Recursos

Las columnas que muestran cpu_time, reads, writes, y logical_reads te permiten evaluar el uso de recursos de una sesión específica. Esta información es crucial para identificar procesos que están consumiendo más recursos de los necesarios.

Situación: Si el rendimiento del servidor está degradado, puedes usar esta consulta para identificar qué procesos están utilizando mucho CPU o realizando muchas operaciones de lectura/escritura. Esto te ayuda a tomar decisiones sobre si es necesario optimizar la consulta, moverla a un horario de menor carga, o revisar el plan de ejecución.

Conclusión

Esta consulta avanzada es una herramienta poderosa para el monitoreo y diagnóstico de sesiones activas en SQL Server. Proporciona una visión profunda del comportamiento de las sesiones y permite a los administradores identificar problemas de rendimiento, gestionar transacciones, y asegurar que el servidor funcione de manera óptima. Si estás buscando una manera de mejorar el rendimiento y la estabilidad de tu servidor SQL, incorporar esta consulta en tus rutinas de monitoreo es un excelente primer paso.

UPDATE JOIN en SQL para Actualizar Tablas Relacionadas

dm_exec_procedure_stats en SQL Server

Información del Servidor SQL Server con T-SQL

Script para saber el histórico de queries ejecutados SQL

Guía Completa para Implementar FULLTEXT en SQL

Cuentos de miedo para Informáticos: Historias de terror para informáticos

Sentencia de Bloqueo en SQL Server, en SQL Server, los bloqueos son una parte fundamental del mecanismo de control de concurrencia, garantizando la integridad de los datos cuando múltiples transacciones acceden simultáneamente a los mismos recursos. En este blog, vamos a desglosar y analizar un ejemplo concreto de una sentencia de bloqueo que puedes encontrar en un entorno de SQL Server.

Entendiendo la Sentencia de Bloqueo

Aquí tienes la sentencia de bloqueo que vamos a analizar:

pagelock fileid=3 pageid=174947664 dbid=7 subresource=FULL id=lock35f1dbd5000 mode=X associatedObjectId=72057674882351104

Esta sentencia es un ejemplo de la información que SQL Server proporciona cuando un bloqueo ocurre en una página específica de la base de datos. Vamos a desglosar cada componente para entender su significado.

1. pagelock

Este término indica que el tipo de bloqueo se está aplicando a una página dentro de un archivo de datos de la base de datos. En SQL Server, los datos se almacenan en páginas de 8 KB. Un pagelock significa que SQL Server está bloqueando una página específica para evitar accesos simultáneos no controlados.

2. fileid=3

El fileid identifica el archivo dentro de la base de datos en el que se encuentra la página bloqueada. En SQL Server, una base de datos puede estar compuesta por múltiples archivos de datos, y cada uno de ellos tiene un identificador único. Aquí, fileid=3 indica que el bloqueo está ocurriendo en el archivo con ID 3.

3. pageid=174947664

El pageid indica el identificador de la página dentro del archivo especificado que está siendo bloqueada. En este caso, pageid=174947664 nos dice cuál es la página específica que está bajo el bloqueo dentro del archivo con fileid=3.

4. dbid=7

El dbid es el identificador de la base de datos en la que está ocurriendo el bloqueo. Cada base de datos en SQL Server tiene un ID único. Aquí, dbid=7 indica la base de datos donde se encuentra el archivo y la página bloqueada.

5. subresource=FULL

subresource=FULL indica que el bloqueo afecta a toda la página, no solo a una porción específica de la misma. Esto significa que ningún otro proceso puede acceder o modificar cualquier parte de esta página hasta que se libere el bloqueo.

6. id=lock35f1dbd5000

El id es un identificador único para el bloqueo en cuestión. Este ID es utilizado internamente por SQL Server para gestionar y rastrear los bloqueos.

7. mode=X

El mode (modo) indica el tipo de bloqueo que se ha aplicado. En este caso, mode=X indica un bloqueo exclusivo (Exclusive Lock). Un bloqueo exclusivo impide que otros procesos lean o modifiquen la página hasta que se complete la transacción que lo generó.

8. associatedObjectId=72057674882351104

El associatedObjectId indica el ID del objeto asociado con el bloqueo. Este ID se puede utilizar para identificar la tabla o índice específico que contiene la página bloqueada. En este caso, associatedObjectId=72057674882351104 es el identificador del objeto dentro de la base de datos.

Análisis del Bloqueo

El bloqueo descrito en la sentencia anterior es un bloqueo exclusivo en una página específica dentro de un archivo de datos. Esto significa que una transacción está realizando una operación que modifica los datos en esa página, y SQL Server ha colocado un bloqueo para garantizar que ningún otro proceso interfiera con esta operación.

¿Por qué es importante entender estos detalles?

• Identificación de problemas de rendimiento: Si observas que un proceso está reteniendo un bloqueo exclusivo durante un período prolongado, podría estar causando bloqueos a otros procesos, lo que se traduce en problemas de rendimiento. Identificar el archivo, página y objeto involucrados puede ayudarte a resolver estos problemas.
• Resolución de bloqueos: Conociendo el mode=X, sabes que ningún otro proceso puede acceder a esa página. Esto puede ser crucial si estás diagnosticando un problema de bloqueo donde otros procesos están esperando a que este se libere.
• Optimización de consultas: Si constantemente ves bloqueos en las mismas páginas, podría ser un indicio de que las consultas que acceden a esos datos necesitan ser optimizadas, o que es necesario modificar la estructura de la base de datos para reducir la contención.

Conclusión

Entender los detalles de una sentencia de bloqueo en SQL Server, como la que hemos analizado, es crucial para un administrador de bases de datos. Proporciona una visión clara de cómo SQL Server maneja la concurrencia y te permite identificar, diagnosticar y resolver problemas de rendimiento relacionados con bloqueos. Al comprender estos componentes, puedes tomar decisiones informadas para optimizar el rendimiento de tus bases de datos y mejorar la eficiencia de tus aplicaciones.

Procedimientos Almacenados Temporales en SQL Server

Obtener el Uso de Espacio de Todas las Tablas en SQL Server con un Solo Comando

¿Qué es el Transaction Log? La Importancia en SQL Server

dm_exec_requests en SQL Server

¿Qué son las vistas SQL Server? Una Guía Completa

Extracción de las Vistas en SQL Server

Sp_who2 en SQL Server, cuando trabajas con bases de datos SQL Server, es fundamental tener herramientas que te permitan diagnosticar y monitorear el estado de tus procesos. Una de esas herramientas es el procedimiento almacenado sp_who2. Este comando es esencial para identificar qué está sucediendo en tu servidor, permitiéndote tomar decisiones informadas sobre la administración de tu base de datos.

¿Qué es sp_who2?

El comando sp_who2 es una versión mejorada del comando sp_who, ambos proporcionan información sobre los procesos actuales en SQL Server. Sin embargo, sp_who2 ofrece información más detallada y es más comúnmente utilizado debido a sus capacidades extendidas.

¿Cómo ejecutar sp_who2?

Para ejecutar sp_who2, solo necesitas conectarte a tu instancia de SQL Server y ejecutar el siguiente comando:

EXEC sp_who2;

Este comando devolverá una lista de procesos que están actualmente activos en el servidor.

Entendiendo la salida de sp_who2

Al ejecutar sp_who2, verás una tabla con varias columnas. A continuación, te explico las más relevantes:

1. SPID: (ID de Sesión del Proceso, por sus siglas en inglés). Este número identifica de manera única cada proceso en ejecución.
2. Status: Indica el estado actual del proceso. Algunos valores comunes incluyen:
   • RUNNABLE: El proceso está listo para ejecutar y solo espera su turno.
   • SLEEPING: El proceso está en espera, sin realizar ninguna acción activa.
   • SUSPENDED: El proceso está bloqueado, esperando a que se resuelva un recurso.
3. Login: Muestra el usuario que inició sesión y está ejecutando el proceso.
4. HostName: El nombre del equipo desde donde se originó el proceso.
5. DBName: La base de datos en la que se está ejecutando el proceso.
6. Command: El comando que está ejecutando el proceso.
7. CPUTime y DiskIO: Indican el tiempo de CPU utilizado y las operaciones de entrada/salida en disco realizadas por el proceso, respectivamente. Estos valores ayudan a identificar procesos que consumen muchos recursos.
8. LastBatch: Muestra cuándo se ejecutó el último lote de instrucciones en esa sesión.
9. ProgramName: Indica el nombre de la aplicación que inició el proceso.
10. BlkBy: (Bloqueado por). Si un proceso está siendo bloqueado, esta columna mostrará el SPID del proceso que lo bloquea.

Ejemplos prácticos

1. Identificación de procesos que bloquean otros procesos

Supongamos que tu aplicación está experimentando problemas de rendimiento. Ejecutas sp_who2 y observas que varios procesos tienen el estado SUSPENDED y en la columna BlkBy se muestra un valor distinto a cero. Esto indica que esos procesos están siendo bloqueados. Puedes identificar al proceso que causa el bloqueo buscando su SPID en la columna correspondiente.

códigoEXEC sp_who2;

2. Localización de procesos que consumen mucho CPU

Si notas que tu servidor está lento, puedes utilizar sp_who2 para identificar procesos que consumen una cantidad excesiva de CPU. Observa la columna CPUTime y busca los valores más altos.

EXEC sp_who2;

3. Monitoreo de procesos específicos

Puedes filtrar la salida de sp_who2 para centrarte en procesos específicos. Por ejemplo, si solo te interesa ver los procesos relacionados con un usuario específico:

EXEC sp_who2 'usuario_especifico';

4. Identificación de sesiones inactivas

A veces, las conexiones a la base de datos permanecen abiertas sin realizar ninguna operación. Puedes identificarlas observando la columna Status para ver los procesos en estado SLEEPING y revisando la columna LastBatch para verificar cuándo fue la última vez que ejecutaron un lote de instrucciones.

Conclusión

El comando sp_who2 es una herramienta poderosa en SQL Server para monitorear y diagnosticar problemas de rendimiento. Te permite obtener una visión rápida del estado de los procesos, identificar bloqueos, y localizar sesiones que consumen muchos recursos. Con este conocimiento, puedes optimizar el rendimiento de tu servidor y garantizar un funcionamiento más eficiente de tus aplicaciones.

Archivos MDF y NDF en SQL Server: Guía Completa

Dependencia de Usuarios en SQL: Guía Completa

Descarga de SQL Server Management Studio (SSMS)

Comando Read Linux: Cómo Hacer Peticiones al Usuario en Scripting

Dependencia de Usuarios en SQL: Guía Completa