Categoría: Monitoreo y mantenimiento SQL
SQL Server Rebuild vs Reorganize
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
Script de Monitoreo Avanzado de Sesiones 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
hastaSerializable
.
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
Análisis de una Sentencia de Bloqueo en SQL Server
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
Explorando sp_who2 en SQL Server: Monitoreo y Diagnóstico Eficiente
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:
- 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.
- 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.
- Login: Muestra el usuario que inició sesión y está ejecutando el proceso.
- HostName: El nombre del equipo desde donde se originó el proceso.
- DBName: La base de datos en la que se está ejecutando el proceso.
- Command: El comando que está ejecutando el proceso.
- 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.
- LastBatch: Muestra cuándo se ejecutó el último lote de instrucciones en esa sesión.
- ProgramName: Indica el nombre de la aplicación que inició el proceso.
- 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
Bloqueo procedimiento por un Blk By en SQL server
Bloqueo procedimiento por un Blk By en SQL Server. En SQL Server, la gestión de bloqueos es una tarea crucial para garantizar el rendimiento y la disponibilidad de las bases de datos. Los bloqueos ocurren cuando un proceso en SQL Server impide que otro proceso acceda a los recursos que necesita, lo que puede llevar a cuellos de botella y problemas de rendimiento. Una herramienta clave para identificar y resolver estos problemas es la columna «Blk By» (Blocked By), que indica qué sesión está bloqueando a otra. En este blog, exploraremos qué es el bloqueo en SQL Server, cómo utilizar «Blk By» para identificar bloqueos y algunos ejemplos prácticos para gestionar y solucionar estos problemas.
¿Qué es un bloqueo en SQL Server?
Un bloqueo en SQL Server ocurre cuando un proceso (una sesión o transacción) mantiene un recurso, como una tabla o una fila, y otro proceso intenta acceder a ese mismo recurso. SQL Server utiliza bloqueos para garantizar la integridad de los datos, pero cuando los bloqueos no se gestionan correctamente, pueden causar que otros procesos se queden esperando indefinidamente, lo que se conoce como bloqueo.
¿Qué es «Blk By» y cómo funciona?
La columna «Blk By» (Blocked By) es una propiedad en la vista del sistema sys.dm_exec_requests
que indica el ID de la sesión que está bloqueando a otra sesión. Esta información es crucial para identificar qué transacciones están bloqueando otras operaciones y es el primer paso para resolver problemas de rendimiento relacionados con bloqueos.
Puedes obtener una lista de sesiones bloqueadas y las sesiones que las están bloqueando usando la siguiente consulta T-SQL:
sql: SELECT
session_id AS [SPID],
blocking_session_id AS [Blk By],
wait_type,
wait_time,
wait_resource,
transaction_id,
TEXT AS [SQL Text]
FROM
sys.dm_exec_requests
CROSS APPLY
sys.dm_exec_sql_text(sql_handle)
WHERE blocking_session_id <> 0;
Este script te proporciona una lista de sesiones que están actualmente bloqueadas, mostrando el ID de la sesión bloqueada, el ID de la sesión que la está bloqueando, el tipo de espera, el tiempo de espera y el recurso específico que está causando el bloqueo.
Ejemplo Práctico: Identificación y Resolución de un Bloqueo
Imagina que tienes dos transacciones ejecutándose en tu base de datos:
- Transacción A: Actualiza una fila en la tabla
Orders
. - Transacción B: Intenta leer la misma fila en la tabla
Orders
antes de que la Transacción A haya finalizado.
Aquí es donde podría ocurrir un bloqueo:
- La Transacción A adquiere un bloqueo exclusivo en la fila para actualizarla.
- La Transacción B intenta leer esa misma fila, pero se encuentra bloqueada porque la Transacción A aún no ha terminado.
Si ejecutas el script mencionado anteriormente durante este bloqueo, verás algo como esto:
SPID | Blk By | wait_type | wait_time | wait_resource | transaction_id | SQL Text |
---|---|---|---|---|---|---|
53 | 52 | LCK_M_S | 2000 | PAGE: 7:1:123 | 123456 | SELECT * FROM Orders WHERE … |
En este caso:
- SPID 53 está bloqueado por SPID 52.
- El
wait_type
indica que SPID 53 está esperando un bloqueo compartido (LCK_M_S). - La columna
wait_time
muestra cuánto tiempo ha estado esperando la transacción bloqueada.
Resolución de Bloqueos
Una vez identificado el bloqueo utilizando «Blk By», hay varias formas de resolverlo:
- Revisión del código: Analiza las consultas que están causando los bloqueos. En muchos casos, es posible optimizar las consultas o la lógica de las transacciones para reducir la posibilidad de bloqueos.
- Terminación de la sesión bloqueadora: Si el bloqueo está afectando gravemente al rendimiento y no puede resolverse rápidamente, puedes optar por finalizar la sesión que está causando el bloqueo. Esto se hace con el comando
KILL
:
KILL 52; — Termina la sesión bloqueadora SPID 52
- Advertencia: Finalizar una sesión puede causar la pérdida de datos si la transacción no se ha completado.
- Implementar niveles de aislamiento de transacciones: Puedes ajustar los niveles de aislamiento de las transacciones para reducir la probabilidad de bloqueos. Por ejemplo, puedes utilizar Read Committed Snapshot Isolation (RCSI) para permitir que las transacciones lean datos sin esperar a que se liberen los bloqueos.
Consejos para Evitar Bloqueos en el Futuro
- Mantén las transacciones cortas: Cuanto más tiempo duren las transacciones, mayor es la posibilidad de que causen bloqueos. Asegúrate de que las transacciones se completen lo más rápido posible.
- Orden de acceso a los recursos: Diseña tus aplicaciones para que accedan a los recursos en un orden coherente. Esto ayuda a evitar situaciones en las que dos transacciones se bloquean mutuamente.
- Monitoreo continuo: Usa herramientas de monitoreo de SQL Server para detectar bloqueos en tiempo real y actuar antes de que se conviertan en un problema mayor.
Porque puede bloquear una de sus propias operaciones SQL Server
Un proceso en SQL Server puede bloquear una de sus propias operaciones en situaciones donde hay competencia por los mismos recursos que el proceso necesita para continuar. Esto generalmente ocurre debido a la forma en que SQL Server maneja los bloqueos y las transacciones. Aquí te explico algunas de las razones más comunes por las cuales un proceso puede bloquearse a sí mismo:
1. Contención de Recursos dentro de una Transacción
- Cuando un proceso ejecuta múltiples operaciones que necesitan acceder al mismo recurso dentro de una transacción, SQL Server puede bloquearse si la primera operación aún no ha completado su trabajo en ese recurso.
- Ejemplo: Si un índice se está reconstruyendo y la operación intenta acceder a las mismas páginas de datos o índices que ya están bloqueados por otra parte de la misma transacción, esto puede causar un bloqueo interno.
2. Escalado de Bloqueos
- SQL Server puede escalar un bloqueo de nivel de fila o página a un bloqueo de nivel de tabla si se están tocando muchos recursos. Si una parte del proceso ya tiene un bloqueo en una fila o página y otra parte del mismo proceso intenta escalar ese bloqueo, podría bloquearse a sí mismo.
- Ejemplo: Durante una operación de índice o actualización masiva, SQL Server intenta bloquear la tabla completa después de haber adquirido muchos bloqueos de página, lo que causa que la operación espere a sí misma.
3. Operaciones Concurrentes en Paralelo
- En algunos casos, SQL Server puede ejecutar partes de un mismo proceso en paralelo (especialmente si la opción MAXDOP está habilitada). Si una de estas operaciones paralelas necesita un recurso que otra parte del proceso ya ha bloqueado, puede haber un bloqueo interno.
- Ejemplo: Diferentes threads del mismo proceso paralelo intentan acceder a la misma página de índice al mismo tiempo.
4. Espacio en TempDB
- Si el proceso está usando tempdb intensivamente, como cuando se reconstruyen índices con la opción SORT_IN_TEMPDB, y tempdb no tiene suficiente espacio, esto puede hacer que las diferentes partes del proceso se bloqueen mientras esperan recursos en tempdb.
5. Actualizaciones o Modificaciones Complejas
- Si un proceso realiza operaciones complejas de actualización que requieren múltiples pasos en una sola transacción, SQL Server podría establecer bloqueos en diferentes niveles de la jerarquía (fila, página, tabla) y acabar bloqueando el proceso.
- Ejemplo: Una actualización que involucra una combinación de varias filas y luego un intento de acceso a esas mismas filas en la misma transacción.
6. Deadlocks Internos
- Aunque menos común, un proceso puede experimentar un deadlock interno, donde diferentes partes de una misma operación se bloquean mutuamente.
Diagnóstico y Resolución bloqueo procedimiento por un Blk By en SQL Server
- Monitoreo de Esperas (sys.dm_exec_requests):
- Usa la consulta que te proporcioné antes para identificar el tipo de espera (wait_type) y el recurso (wait_resource) que está causando el bloqueo.
- Revisión del Plan de Ejecución:
- Si el proceso involucra una consulta compleja, revisa el plan de ejecución para ver si hay operaciones que están escalando los bloqueos o creando contenciones inesperadas.
- Revisar las Transacciones:
- Si el proceso está ejecutando múltiples pasos dentro de una transacción, considera si es posible dividir las operaciones o mejorar el manejo de los bloqueos para evitar la contención.
- Optimización de Índices y Consultas:
- Asegúrate de que las consultas y las operaciones de índice están optimizadas para evitar acceder repetidamente a los mismos recursos en paralelo.
- Uso de Hints de Bloqueo:
- Si es apropiado, considera el uso de hints de bloqueo para controlar mejor cómo SQL Server maneja los bloqueos durante la operación.
Conclusión
Gestionar los bloqueos en SQL Server es fundamental para mantener el rendimiento y la disponibilidad de las bases de datos. La columna «Blk By» es una herramienta esencial para identificar rápidamente las sesiones que están causando bloqueos y tomar medidas correctivas. Implementar buenas prácticas y utilizar herramientas de monitoreo proactivas te ayudará a minimizar la incidencia de bloqueos y mantener tus bases de datos funcionando de manera eficiente.
Cómo Obtener el tamaño de los archivos de Datos en SQL Server
dm_exec_procedure_stats en SQL Server
dm_exec_procedure_stats en SQL Server
Script Creación de Roles en SQL Server
¿Qué es el Transaction Log? La Importancia en SQL Server
Procedimientos Almacenados Temporales en SQL Server
Identificar Objetos No Utilizados en su Base de Datos SQL Server
Obtener el Uso de Espacio de Todas las Tablas en SQL Server con un Solo Comando
Espacio de Todas las Tablas en SQL Server, en la administración de bases de datos SQL Server, una de las tareas más importantes es monitorear el uso del espacio en las tablas. Saber cuánto espacio está ocupando cada tabla te ayuda a optimizar el rendimiento y a gestionar el almacenamiento de manera eficiente. Afortunadamente, SQL Server ofrece una forma rápida y sencilla de obtener esta información para todas las tablas de una base de datos con un solo comando. En este blog, te explicaré cómo hacerlo utilizando el procedimiento almacenado sp_spaceused
en combinación con sp_msforeachtable
.
¿Qué hace el comando EXEC sp_msforeachtable 'EXEC sp_spaceused [?]'
?
Este comando es un truco útil en SQL Server que te permite ejecutar el procedimiento almacenado sp_spaceused
en todas las tablas de la base de datos actual. El procedimiento sp_spaceused
proporciona información sobre el uso de espacio de una tabla específica, incluyendo el tamaño de los datos, el tamaño de los índices y el espacio no utilizado. Al combinarlo con sp_msforeachtable
, puedes obtener esta información para todas las tablas en una sola ejecución.

¿Cómo funciona?
El comando sp_msforeachtable
es un procedimiento no documentado en SQL Server que itera sobre cada tabla en la base de datos y ejecuta un comando específico en cada una de ellas. En este caso, se utiliza para ejecutar sp_spaceused
en cada tabla. El carácter ?
dentro del comando se reemplaza automáticamente con el nombre de cada tabla durante la iteración.
Aquí está el comando completo:
sql: EXEC sp_msforeachtable 'EXEC sp_spaceused [?]';
¿Qué información proporciona este comando?
Cuando ejecutas este comando, SQL Server devuelve una serie de resultados, uno por cada tabla en la base de datos. Cada resultado incluye:
- Nombre de la tabla: El nombre de la tabla para la cual se está mostrando la información.
- Número de filas: El número de filas almacenadas en la tabla.
- Espacio reservado: La cantidad total de espacio reservado para la tabla.
- Espacio de datos: El espacio ocupado por los datos almacenados en la tabla.
- Espacio de índices: El espacio utilizado por los índices asociados a la tabla.
- Espacio no utilizado: La cantidad de espacio reservado que no está siendo utilizado actualmente.
Aplicaciones prácticas del comando sp_msforeachtable
y sp_spaceused
Este comando es extremadamente útil en varias situaciones, especialmente cuando necesitas revisar el uso de espacio en una base de datos con muchas tablas:
- Optimización del rendimiento: Al revisar regularmente el uso de espacio, puedes identificar tablas que están ocupando más espacio del esperado y tomar medidas para optimizar su rendimiento, como la reorganización de índices o la limpieza de datos no utilizados.
- Gestión de almacenamiento: Conocer el uso de espacio de cada tabla te permite gestionar el almacenamiento de manera más eficiente, asegurándote de que no estás acercándote a los límites de capacidad del disco.
- Auditorías y reportes: Este comando es útil para generar reportes rápidos sobre el estado de las tablas en términos de espacio utilizado, lo cual puede ser requerido en auditorías o para fines de planificación.
Conclusión
El uso del comando EXEC sp_msforeachtable 'EXEC sp_spaceused [?]'
es un truco poderoso para cualquier DBA que necesite monitorear y gestionar el uso de espacio en SQL Server. Con un solo comando, puedes obtener una visión completa del espacio utilizado por cada tabla en tu base de datos, lo que te permite tomar decisiones informadas para optimizar el rendimiento y la eficiencia del almacenamiento.
La Seguridad en SQL Server: Identificar Roles de Administrador a Nivel de Servidor
Entendiendo Kerberos en SQL Server: Seguridad y Autenticación
SQL login failed for user ‘NT AUTHORITY \ ANONYMOUS LOGIN’
Cómo Obtener el tamaño de los archivos de Datos en SQL Server
Cómo Obtener el tamaño de los archivos de Datos en SQL Server
Tamaño de los archivos de Datos en SQL Server, en la gestión de bases de datos SQL Server, es crucial para los DBAs conocer el tamaño y la ubicación de los archivos de datos de las bases de datos. Tener esta información no solo ayuda en la planificación del almacenamiento, sino que también facilita tareas de mantenimiento y mejora el rendimiento general de la base de datos. A continuación, te explico cómo un sencillo script SQL puede proporcionarte toda la información que necesitas sobre los archivos de datos en una base de datos específica.
¿Por qué es importante conocer el tamaño de los archivos de datos?
Los archivos de datos en SQL Server son fundamentales para el funcionamiento de la base de datos. Conocer su tamaño y ubicación te permite:
- Planificar y gestionar el almacenamiento de manera eficiente: Al entender cuánto espacio ocupan los archivos de datos, puedes asegurarte de que tienes suficiente capacidad en tu sistema de almacenamiento.
- Optimizar el rendimiento: Evitarás problemas de rendimiento asociados con el crecimiento descontrolado de los archivos.
- Facilitar la recuperación ante desastres: Sabrás exactamente qué archivos necesitas respaldar y restaurar en caso de una falla.
Desglose del Script SQL
El siguiente script SQL te proporcionará información detallada sobre los archivos de datos de una base de datos específica, excluyendo los archivos de log:
SELECT
name AS LogicalFileName,
physical_name AS PhysicalFileName,
size * 8 / 1024 AS SizeMB,
CASE type_desc
WHEN 'ROWS' THEN 'Data File (.mdf or .ndf)'
WHEN 'LOG' THEN 'Log File (.ldf)'
END AS FileType
FROM
sys.master_files
WHERE
type_desc = 'ROWS' -- Solo archivos de datos, excluye los logs
AND database_id = DB_ID('Nombre_De_Tu_Base_De_Datos'); -- Asegúrate de que el nombre de la base de datos sea correcto
Este script es sencillo pero poderoso. Extrae información relevante de la vista del sistema sys.master_files
, que contiene detalles sobre todos los archivos asociados con las bases de datos en el servidor SQL.

¿Qué información proporciona el script?
Al ejecutar el script, obtendrás una tabla con los siguientes datos:
- LogicalFileName: El nombre lógico del archivo tal como lo reconoce SQL Server. Este es el nombre que usarás en tus consultas y scripts.
- PhysicalFileName: La ruta completa y el nombre del archivo en el sistema operativo. Esta información es esencial para identificar la ubicación física de los datos.
- SizeMB: El tamaño del archivo en megabytes. Este dato es calculado multiplicando el tamaño del archivo en páginas de 8 KB por 8, y luego dividiéndolo por 1024 para convertirlo a MB.
- FileType: El tipo de archivo, que te indica si se trata de un archivo de datos (
mdf
ondf
) o de log. En este caso, el script está configurado para mostrar solo archivos de datos.
¿Cómo aplicar este script en tu día a día?
Este script es una herramienta versátil que puedes usar en diversas situaciones:
- Antes de realizar una migración de base de datos: Verifica el tamaño y la ubicación de los archivos de datos para planificar la migración de manera efectiva.
- Para la gestión de almacenamiento: Evalúa el espacio que ocupan tus archivos de datos y ajusta la configuración de autogrowth si es necesario para prevenir el crecimiento descontrolado.
- Durante auditorías de seguridad: Mantén un registro preciso de los archivos de datos para garantizar que se cumplan las políticas de seguridad y recuperación.
Consideraciones finales
Conocer el tamaño y la ubicación de los archivos de datos en SQL Server es una de las mejores prácticas en la administración de bases de datos. Este script es una herramienta esencial que te permite obtener esta información de manera rápida y precisa. Implementarlo en tu rutina diaria te ayudará a mantener un entorno de base de datos organizado, seguro y optimizado para el rendimiento.
Asegúrate de adaptar el script a la base de datos que estás utilizando cambiando el nombre de la base de datos en la línea DB_ID('Nombre_De_Tu_Base_De_Datos')
para que coincida con la base de datos que deseas analizar.
La Seguridad en SQL Server: Identificar Roles de Administrador a Nivel de Servidor
Extracción de las Vistas en SQL Server
Generando Script de creación de Usuarios en SQL Server
Monitorización del Espacio Utilizado en Tablas SQL: Un Script Esencial para DBAs
Monitorización del Espacio Utilizado en Tablas SQL: Un Script Esencial para DBAs
Monitorización del Espacio Utilizado en Tablas SQL, en la administración de bases de datos, uno de los aspectos más críticos es la gestión eficiente del espacio de almacenamiento. El script SQL que exploraremos en este blog es una herramienta poderosa para los DBAs, permitiendo obtener una visión detallada del uso del espacio en las tablas de una base de datos. Este script no solo proporciona información sobre el espacio reservado y utilizado, sino que también desglosa estos datos en componentes clave como el tamaño de los índices y el espacio no utilizado. Vamos a desglosar su estructura, funcionamiento y la importancia de cada componente.
sql:
SELECT a3.name + '.' + a2.name AS [name],
a1.rows AS [rows],
(a1.reserved + ISNULL(a4.reserved, 0)) * 8 AS [Reserved KB],
a1.data * 8 AS [Data KB],
(CASE
WHEN(a1.used + ISNULL(a4.used, 0)) > a1.data
THEN(a1.used + ISNULL(a4.used, 0)) - a1.data
ELSE 0
END) * 8 AS [Index_size KB],
(CASE
WHEN(a1.reserved + ISNULL(a4.reserved, 0)) > a1.used
THEN(a1.reserved + ISNULL(a4.reserved, 0)) - a1.used
ELSE 0
END) * 8 AS [unused KB],
CONVERT(DECIMAL(18, 2), (((a1.reserved + ISNULL(a4.reserved, 0)) * 8) - ((CASE
WHEN(a1.reserved + ISNULL(a4.reserved, 0)) > a1.used
THEN(a1.reserved + ISNULL(a4.reserved, 0)) - a1.used
ELSE 0
END) * 8)) / 1024.0 / 1024.0) AS [Table_used_Space GB]
FROM
(
SELECT ps.object_id,
SUM(CASE
WHEN(ps.index_id < 2)
THEN row_count
ELSE 0
END) AS [rows],
SUM(ps.reserved_page_count) AS reserved,
SUM(CASE
WHEN(ps.index_id < 2)
THEN(ps.in_row_data_page_count + ps.lob_used_page_count + ps.row_overflow_used_page_count)
ELSE(ps.lob_used_page_count + ps.row_overflow_used_page_count)
END) AS data,
SUM(ps.used_page_count) AS used
FROM sys.dm_db_partition_stats ps
GROUP BY ps.object_id
) AS a1
LEFT OUTER JOIN
(
SELECT it.parent_id,
SUM(ps.reserved_page_count) AS reserved,
SUM(ps.used_page_count) AS used
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.internal_tables it ON(it.object_id = ps.object_id)
WHERE it.internal_type IN(202, 204)
GROUP BY it.parent_id
) AS a4 ON(a4.parent_id = a1.object_id)
INNER JOIN sys.all_objects a2 ON(a1.object_id = a2.object_id)
INNER JOIN sys.schemas a3 ON(a2.schema_id = a3.schema_id)
WHERE a2.type != N'S'
AND a2.type != N'IT'
ORDER BY [Table_used_Space GB] DESC, [rows] desc ;

1. Descripción del Script y su Funcionalidad
El script en cuestión realiza una consulta a las vistas de sistema de SQL Server para obtener información detallada sobre el uso del espacio en las tablas de la base de datos. La consulta principal utiliza las vistas sys.dm_db_partition_stats
, sys.all_objects
y sys.schemas
para recoger datos esenciales como:
- Nombre completo de la tabla: Incluyendo el esquema.
- Número de filas: Contando las filas presentes en cada tabla.
- Espacio reservado: Cantidad de espacio reservado para cada tabla, en KB.
- Espacio utilizado para datos: Espacio real utilizado por los datos.
- Tamaño de los índices: Espacio ocupado por los índices de las tablas.
- Espacio no utilizado: Espacio reservado pero no utilizado.
- Espacio total utilizado por la tabla en GB: Una conversión del espacio total reservado menos el espacio no utilizado.
2. Importancia del Script para un DBA
Este script es una herramienta indispensable para cualquier DBA por varias razones:
- Optimización del Almacenamiento: Permite identificar tablas que están utilizando más espacio del necesario. Esto es crucial en entornos donde el almacenamiento es costoso o limitado.
- Monitoreo de Crecimiento de Tablas: Ayuda a monitorear el crecimiento de las tablas a lo largo del tiempo, permitiendo prever cuándo será necesario realizar tareas de mantenimiento, como la reorganización de índices o la limpieza de datos no utilizados.
- Identificación de Ineficiencias: Al separar el espacio ocupado por índices del espacio ocupado por datos, los DBAs pueden identificar si ciertos índices están consumiendo más espacio de lo que deberían, lo que puede indicar la necesidad de reevaluar la estrategia de indexación.
- Mantenimiento Proactivo: El script facilita la identificación de tablas con grandes cantidades de espacio no utilizado, lo que puede ser un signo de ineficiencias que necesitan ser abordadas a través de la reorganización de tablas o la actualización de estadísticas.
3. Desglose de la Consulta SQL
Selección y Agregación de Datos
La consulta comienza con dos subconsultas que agregan datos a nivel de particiones y tablas internas:
- Primera Subconsulta: Se agrupan los datos por
object_id
para obtener el número de filas, el espacio reservado y utilizado, y el espacio ocupado por los datos en las tablas. - Segunda Subconsulta: Se enfoca en tablas internas específicas, identificando el espacio reservado y utilizado por ellas.
Combinación y Filtrado de Resultados
Los resultados de estas subconsultas se combinan usando una unión externa (LEFT JOIN) y se integran con las tablas de objetos (sys.all_objects
) y esquemas (sys.schemas
) para obtener los nombres de las tablas completos.
Cálculos de Espacio
El script realiza cálculos clave, incluyendo:
- Espacio Total Reservado en KB: Considera tanto el espacio reservado por la tabla como por las estructuras internas asociadas.
- Tamaño de los Índices: Calculado como la diferencia entre el espacio total utilizado y el espacio utilizado por los datos.
- Espacio No Utilizado: Calculado como la diferencia entre el espacio reservado y el espacio utilizado.
Ordenamiento de los Resultados
Finalmente, los resultados se ordenan por el espacio total utilizado en GB, seguido por el número de filas, lo que permite identificar rápidamente las tablas que están utilizando más espacio.
4. Conclusión
El uso eficiente del almacenamiento es un componente clave de la administración de bases de datos. El script SQL presentado aquí es una herramienta poderosa que permite a los DBAs obtener una visión completa del uso del espacio en sus bases de datos. Al proporcionar detalles granulares sobre cómo se utiliza el espacio en cada tabla, los DBAs pueden tomar decisiones informadas para optimizar el rendimiento y la eficiencia de la base de datos.
Conociendo las Trazas Habilitadas en SQL Server: Guía DBAs
SQL login failed for user ‘NT AUTHORITY \ ANONYMOUS LOGIN’
Conociendo las Trazas Habilitadas en SQL Server: Guía DBAs
Trazas Habilitadas en SQL Server, como Administrador de Bases de Datos (DBA), es fundamental conocer todos los aspectos que influyen en el comportamiento de tu servidor SQL. Uno de esos aspectos clave son las trazas habilitadas. Las trazas en SQL Server son configuraciones que alteran o mejoran el comportamiento del servidor para tareas específicas, como el diagnóstico o la depuración. En este blog, te mostraré cómo identificar todas las trazas que están activas en tu servidor SQL, utilizando comandos T-SQL.
¿Qué son las Trazas en SQL Server?
Las trazas en SQL Server, comúnmente conocidas como «trace flags», son configuraciones que permiten al DBA modificar temporalmente el comportamiento del servidor. Estas trazas son útiles para diagnosticar problemas, optimizar el rendimiento o cambiar la forma en que ciertas operaciones son manejadas por el motor de SQL Server.
Las trazas pueden estar habilitadas de manera global (afectando a todo el servidor) o solo para una sesión específica. Saber qué trazas están activas es crucial para entender el estado de tu servidor y evitar problemas inesperados.

¿Cómo Listar las Trazas Habilitadas en SQL Server?
Para conocer qué trace flags están habilitadas globalmente en tu servidor SQL, puedes utilizar el siguiente comando T-SQL:
DBCC TRACESTATUS(-1);
Desglose del Comando
- DBCC TRACESTATUS(-1): Este comando devuelve el estado de todas las trace flags que están habilitadas globalmente en el servidor. El parámetro
-1
indica que quieres revisar todas las trazas activas a nivel global.
¿Qué Información Proporciona?
Al ejecutar este comando, obtendrás una lista que incluye:
- TraceFlag: El número de la traza que está habilitada.
- Status: Indica si la traza está habilitada o deshabilitada.
- Global: Un valor que indica si la traza está habilitada globalmente en el servidor.
- Session: Un valor que indica si la traza está habilitada solo para la sesión actual.
Esta información es invaluable para cualquier DBA que necesite un control detallado sobre las configuraciones y optimizaciones aplicadas al servidor.
Cómo Listar las Trazas Habilitadas en la Conexión Actual
Además de conocer las trazas habilitadas globalmente, es posible que necesites saber cuáles están activas en tu conexión actual. Para ello, puedes utilizar el siguiente comando:
DBCC TRACESTATUS;
Desglose del Comando
- DBCC TRACESTATUS: A diferencia del comando anterior, este no incluye un parámetro específico. Esto significa que devolverá el estado de las trace flags que están habilitadas en la conexión actual que estás utilizando para ejecutar el comando.
¿Qué Información Proporciona?
El resultado te mostrará las trace flags activas solo en tu sesión actual. Esta información es útil para entender cómo tu conexión específica puede estar siendo influenciada por determinadas configuraciones temporales.
Buenas Prácticas en la Gestión de Trace Flags
El uso de trace flags es una herramienta poderosa, pero debe ser manejada con cuidado. Aquí algunas buenas prácticas para los DBAs:
- Documenta Todas las Trazas Activas: Mantén un registro detallado de las trace flags que habilitas, junto con la razón y el impacto esperado. Esto te ayudará a recordar por qué se aplicaron ciertas configuraciones y a revertir cambios si es necesario.
- Evalúa el Impacto Antes de Habilitar Trazas: Algunas trace flags pueden alterar significativamente el comportamiento del servidor. Asegúrate de probarlas en un entorno de desarrollo o prueba antes de aplicarlas en producción.
- Monitorea el Rendimiento: Después de habilitar una traza, monitorea el rendimiento del servidor para asegurarte de que no está causando problemas inesperados.
- Revisa Regularmente las Trazas Activas: Las necesidades de tu servidor pueden cambiar con el tiempo. Es una buena práctica revisar periódicamente las trace flags activas para asegurarte de que aún son necesarias.
Conclusión
La gestión adecuada de las trace flags es esencial para mantener un entorno SQL Server optimizado y seguro. Como DBA, es tu responsabilidad conocer qué trazas están habilitadas, tanto a nivel global como en sesiones específicas, y entender su impacto en el servidor. Utilizando los comandos DBCC TRACESTATUS(-1)
y DBCC TRACESTATUS
, puedes obtener una visión clara de estas configuraciones y tomar decisiones informadas para gestionar tu entorno SQL.
No subestimes el poder de las trace flags, pero manéjalas con cuidado y siempre con una comprensión clara de lo que están haciendo en tu servidor. ¡Mantente al tanto de nuestras futuras publicaciones para más consejos y trucos sobre la administración de SQL Server!
Convertir una Fecha y Hora a Solo Fecha en SQL
La Seguridad en SQL Server: Identificar Roles de Administrador a Nivel de Servidor
Procedimientos Almacenados Temporales en SQL Server
Error 15025 SQL Server. The server principal already exists
Sacar permisos de Base de Datos SQL scripts
La Seguridad en SQL Server: Identificar Roles de Administrador a Nivel de Servidor
La Seguridad en SQL Server es uno de los aspectos más críticos que un Administrador de Bases de Datos (DBA) debe dominar. Mantener un entorno seguro no solo protege los datos sensibles, sino que también garantiza la integridad y disponibilidad del sistema. Una de las tareas esenciales de un DBA es conocer qué cuentas de inicio de sesión (login) tienen asignados los roles de administrador del sistema (sysadmin) o administrador de seguridad (security admin) a nivel de servidor. En este blog, te mostraré cómo identificar estos roles utilizando una simple consulta SQL.
La Seguridad en SQL Server, conocer los Roles de Seguridad
En un entorno de SQL Server, los roles de servidor determinan qué tipo de acceso y privilegios tiene un usuario sobre el servidor. Dos de los roles más poderosos son:
- Sysadmin: Este rol otorga control total sobre el servidor SQL. Un usuario con este rol puede realizar cualquier tarea, incluyendo la administración de bases de datos, seguridad, y configuración del servidor.
- Securityadmin: Este rol permite a un usuario gestionar la seguridad del servidor. Un usuario con este rol puede crear y gestionar cuentas de inicio de sesión, asignar permisos, y cambiar contraseñas.
Conocer quién tiene estos roles es fundamental para mantener la seguridad y el control sobre el entorno de SQL Server. Una mala gestión de estos roles podría llevar a accesos no autorizados, lo que comprometería la seguridad de la base de datos.
¿Cómo Identificar Usuarios con Roles de Sysadmin o Security Admin?
Para identificar qué cuentas de inicio de sesión tienen asignados los roles de sysadmin o securityadmin, puedes utilizar la siguiente consulta SQL:
SELECT l.name, l.denylogin, l.isntname, l.isntgroup, l.isntuser
FROM master.dbo.syslogins l
WHERE l.sysadmin = 1 OR l.securityadmin = 1;

Desglose de la Consulta
Esta consulta accede a la tabla syslogins
en la base de datos master
, la cual contiene información sobre todas las cuentas de inicio de sesión configuradas en el servidor SQL. Aquí te explico lo que hace cada parte de la consulta:
- SELECT l.name, l.denylogin, l.isntname, l.isntgroup, l.isntuser: Este comando selecciona varias columnas de la tabla
syslogins
.l.name
: Muestra el nombre de la cuenta de inicio de sesión.l.denylogin
: Indica si el inicio de sesión está denegado.l.isntname
,l.isntgroup
,l.isntuser
: Estos campos muestran si el inicio de sesión es una cuenta de Windows NT, un grupo de Windows NT, o un usuario de Windows NT, respectivamente.
- FROM master.dbo.syslogins l: Especifica la tabla
syslogins
en la base de datosmaster
como la fuente de datos. - WHERE l.sysadmin = 1 OR l.securityadmin = 1: Este filtro asegura que solo se muestren las cuentas de inicio de sesión que tienen asignado el rol de sysadmin o securityadmin.
¿Qué Información Proporciona la Consulta?
Al ejecutar esta consulta, obtendrás una lista de todos los usuarios que tienen un control significativo sobre el servidor SQL, ya sea total (sysadmin) o sobre aspectos de seguridad (securityadmin). Esta información es crucial para auditar quién tiene privilegios elevados y garantizar que solo los usuarios adecuados tienen acceso a estas funciones críticas.
Buenas Prácticas de Seguridad
Identificar estos roles es solo el primer paso. Aquí te dejo algunas buenas prácticas para gestionar la seguridad en SQL Server:
- Auditorías Regulares: Realiza auditorías periódicas para revisar qué usuarios tienen asignados roles críticos. Esto ayuda a detectar y corregir posibles problemas de seguridad.
- Principio de Menor Privilegio: Asegúrate de que cada usuario tenga solo los permisos necesarios para realizar su trabajo. Evita otorgar roles como sysadmin o securityadmin a menos que sea absolutamente necesario.
- Revisión de Cuentas Inactivas: Elimina o desactiva cuentas que ya no se utilizan para reducir el riesgo de acceso no autorizado.
- Monitoreo Continuo: Utiliza herramientas de monitoreo para rastrear cualquier cambio en los permisos o en la configuración de seguridad.
Conclusión
La seguridad en SQL Server es un aspecto esencial que no se debe tomar a la ligera. Identificar qué cuentas de inicio de sesión tienen los roles de sysadmin o securityadmin te permite mantener un control adecuado sobre tu servidor y prevenir accesos no autorizados. Con la consulta SQL que te mostré, puedes obtener esta información de manera rápida y eficiente, asegurando así que solo los usuarios correctos tengan acceso a las funciones críticas del servidor.
Cuentos de miedo para influencers
Para que una tabla tenga FULLTEXT SQL
Guía Completa para Implementar FULLTEXT en SQL
Dependencia de Usuarios en SQL: Guía Completa