Categoría: Monitoreo y mantenimiento SQL

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’

Generando Script de creación de Usuarios en SQL Server

Qué es la temp-db en sql

dm_exec_requests en SQL Server

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:

1. 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.
2. 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.
3. Monitorea el Rendimiento: Después de habilitar una traza, monitorea el rendimiento del servidor para asegurarte de que no está causando problemas inesperados.
4. 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

Insertar Varias Filas en SQL Server: Simplifica tu Trabajo

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

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 datos master 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:

1. 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.
2. 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.
3. Revisión de Cuentas Inactivas: Elimina o desactiva cuentas que ya no se utilizan para reducir el riesgo de acceso no autorizado.
4. 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

Insertar Varias Filas en SQL Server: Simplifica tu Trabajo

Cambiar el collation en un servidor sql server 2019

Como administradores de bases de datos (DBA), una de nuestras responsabilidades clave es comprender y manejar la configuración a nivel de servidor de SQL Server. Estas configuraciones no solo controlan varias características del servidor, sino que también pueden influir significativamente en su rendimiento y seguridad. En esta entrada, exploraremos cómo obtener toda la información relacionada con la configuración del servidor utilizando una simple consulta SQL.

¿Por Qué Es Importante la Configuración a Nivel de Servidor?

La configuración a nivel de servidor define cómo se comporta SQL Server en su totalidad, afectando aspectos como la memoria, la seguridad, la ejecución de consultas y más. Conocer estos parámetros permite a los DBAs ajustar el servidor para optimizar el rendimiento, asegurar la integridad de los datos y cumplir con los requisitos de seguridad.

Recuperando Información de Configuración del Servidor

Para obtener un listado completo de las configuraciones del servidor, puedes ejecutar la siguiente consulta T-SQL:

SELECT * FROM sys.configurations ORDER BY name;

¿Qué Hace Esta Consulta?

La consulta selecciona todas las filas de la vista del sistema sys.configurations, que contiene información detallada sobre cada configuración del servidor. Al ordenar los resultados por el nombre de la configuración (ORDER BY name), se facilita la búsqueda y análisis de parámetros específicos.

Desglose de la Vista sys.configurations

La vista sys.configurations proporciona una variedad de columnas que contienen información valiosa sobre cada configuración. Aquí se describen algunas de las columnas más importantes:

• Name: El nombre de la opción de configuración.
• Value: El valor actual de la configuración.
• Minimum y Maximum: Los valores mínimo y máximo permitidos para la configuración.
• Description: Una descripción breve de lo que hace la configuración.
• Is_dynamic: Indica si la configuración puede cambiarse sin reiniciar el servidor.
• Is_advanced: Señala si es una opción avanzada.

Ejemplo de Uso Práctico

Supongamos que necesitas verificar las configuraciones relacionadas con la memoria. Al ejecutar la consulta, puedes buscar parámetros como ‘max server memory’ o ‘min server memory’ en los resultados ordenados, permitiéndote ajustar estos valores para optimizar el uso de memoria del servidor.

Ajustando Configuraciones del Servidor

Una vez que has identificado las configuraciones que necesitan ajustes, puedes modificarlas usando el comando sp_configure. Aquí tienes un ejemplo de cómo cambiar la configuración de memoria máxima del servidor:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory', 4096;
RECONFIGURE;

Explicación del Ejemplo

1. Habilitar Opciones Avanzadas:sqlCopiar códigoEXEC sp_configure 'show advanced options', 1; RECONFIGURE; Esto permite cambiar configuraciones avanzadas que no están disponibles por defecto.
2. Modificar la Configuración:sqlCopiar códigoEXEC sp_configure 'max server memory', 4096; RECONFIGURE; Aquí estamos configurando la memoria máxima del servidor a 4096 MB. Después de ejecutar el comando sp_configure, usamos RECONFIGURE para aplicar el cambio.

Importancia de Documentar y Monitorear

Es crucial documentar cualquier cambio en la configuración del servidor para futuras referencias y auditorías. Además, monitorear regularmente estas configuraciones ayuda a identificar problemas potenciales y mantener el servidor funcionando de manera óptima.

Herramientas de Monitoreo

SQL Server ofrece varias herramientas y vistas dinámicas de gestión (DMV) para monitorear el estado y el rendimiento del servidor. Utilizar estas herramientas junto con sys.configurations puede proporcionar una visión completa del entorno de tu SQL Server.

Conclusión

Comprender y gestionar la configuración a nivel de servidor en SQL Server es esencial para cualquier DBA. La consulta SELECT * FROM sys.configurations ORDER BY name te proporciona una vista completa de todos los parámetros configurables, permitiéndote ajustar y optimizar el servidor según las necesidades de tu entorno.

Descarga de SQL Server Management Studio (SSMS)

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

Qué es la temp-db en sql

Insertar Varias Filas en SQL Server: Simplifica tu Trabajo

dm_exec_procedure_stats en SQL Server

La gestión eficiente de una base de datos SQL Server incluye la identificación y eliminación de objetos no utilizados. Estos objetos pueden ser tablas, vistas, procedimientos almacenados, funciones, índices, entre otros. Mantener una base de datos limpia y eficiente no solo mejora el rendimiento, sino que también reduce el riesgo de errores y facilita el mantenimiento. A continuación, exploraremos diversas técnicas para identificar estos objetos no utilizados en SQL Server.

Métodos para Identificar Objetos No Utilizados

1. Uso de SQL Server Profiler

SQL Server Profiler es una herramienta poderosa para capturar y analizar eventos en SQL Server. Se puede utilizar para monitorear la actividad de la base de datos y determinar qué objetos están siendo utilizados.

Pasos para usar SQL Server Profiler:

1. Configuración del Profiler:
   • Abre SQL Server Profiler y crea una nueva traza.
   • Configura los eventos que deseas capturar, como RPC, SQL, y SP, que rastrean la ejecución de procedimientos almacenados, lotes SQL y procedimientos de almacenamiento.
2. Ejecución de la traza:
   • Ejecuta la traza durante un período de tiempo representativo, asegurándote de que todas las funcionalidades de la aplicación que se conecta a la base de datos se utilicen.
3. Análisis de los resultados:
   • Analiza los resultados capturados para identificar qué objetos han sido utilizados y cuáles no. Si un objeto no aparece en los resultados, es posible que no esté en uso.

2. Método de Cambio de Nombre y Observación

Otra técnica consiste en cambiar el nombre de los objetos que se sospecha no están en uso y observar si esto provoca errores en la aplicación.

Pasos para implementar este método:

1. Identificación y renombramiento:
   • Cambia el nombre de un objeto, como un procedimiento almacenado o una tabla, añadiendo un prefijo o sufijo (por ejemplo, _old).
2. Monitoreo de errores:
   • Observa la base de datos y la aplicación durante un período de tiempo para ver si el cambio de nombre provoca errores o fallos.
3. Restauración o eliminación:
   • Si no se producen errores después de un tiempo razonable, es probable que el objeto no se esté utilizando. Puedes proceder a eliminarlo o archivarlo.

3. Uso de Consultas SQL para Monitoreo

Una alternativa más técnica es usar consultas SQL para monitorear el uso de los objetos a través de las vistas dinámicas de gestión (DMVs).

Ejemplo de consulta SQL:

SELECT source_code, last_execution_time
FROM sys.dm_exec_query_stats as stats
CROSS APPLY (
   SELECT text as source_code
   FROM sys.dm_exec_sql_text(sql_handle)
) AS query_text
ORDER BY last_execution_time DESC;

Explicación de la consulta:

• Esta consulta obtiene el código fuente de las consultas ejecutadas y la última vez que se ejecutaron.
• Analiza los resultados para ver qué objetos han sido utilizados recientemente.
• Al monitorear los resultados durante un período, puedes identificar objetos que no se utilizan, ya que no aparecerán en los resultados.

Otros Scripts Útiles para Identificar Objetos No Utilizados

1. Identificar Tablas No Utilizadas

SELECT t.name AS table_name,
       ius.user_seeks,
       ius.user_scans,
       ius.user_lookups,
       ius.user_updates
FROM sys.tables AS t
LEFT JOIN sys.dm_db_index_usage_stats AS ius
  ON t.[object_id] = ius.[object_id]
WHERE ius.[object_id] IS NULL
   OR (ius.user_seeks = 0
   AND ius.user_scans = 0
   AND ius.user_lookups = 0
   AND ius.user_updates = 0);

Explicación:

• Esta consulta busca tablas que no tienen actividad registrada en la vista sys.dm_db_index_usage_stats, lo que indica que no han sido leídas o modificadas.

2. Identificar Procedimientos Almacenados No Utilizados

SELECT p.name AS proc_name,
       ps.last_execution_time
FROM sys.procedures AS p
LEFT JOIN sys.dm_exec_procedure_stats AS ps
  ON p.[object_id] = ps.[object_id]
WHERE ps.[object_id] IS NULL
   OR ps.last_execution_time IS NULL;

Explicación:

• Esta consulta lista los procedimientos almacenados que no tienen un registro de ejecución reciente en sys.dm_exec_procedure_stats.

3. Identificar Vistas No Utilizadas

SELECT v.name AS view_name,
       SUM(ius.user_seeks + ius.user_scans + ius.user_lookups + ius.user_updates) AS total_usage
FROM sys.views AS v
LEFT JOIN sys.dm_db_index_usage_stats AS ius
  ON v.[object_id] = ius.[object_id]
GROUP BY v.name
HAVING SUM(ius.user_seeks + ius.user_scans + ius.user_lookups + ius.user_updates) = 0;

Explicación:

• Esta consulta identifica vistas que no han sido utilizadas para búsquedas, escaneos, consultas o actualizaciones.

Ejemplos Prácticos

Ejemplo 1: Uso del SQL Server Profiler

Imagina que tienes una base de datos para una aplicación de gestión de inventarios. Quieres saber si un procedimiento almacenado llamado sp_UpdateInventory todavía se utiliza.

1. Configura el Profiler para capturar la ejecución de sp_UpdateInventory.
2. Ejecuta la aplicación y utiliza todas las funcionalidades relacionadas con el inventario.
3. Analiza los resultados: Si sp_UpdateInventory no aparece en la traza, es posible que ya no se esté utilizando.

Ejemplo 2: Método de Cambio de Nombre

Tienes una tabla llamada TemporaryData que sospechas que ya no se usa.

1. Renombra la tabla a TemporaryData_old.
2. Monitorea la aplicación durante un mes.
3. Observa los errores: Si no hay errores relacionados con TemporaryData, puedes eliminarla de manera segura.

Ejemplo 3: Consulta SQL

Quieres saber si la función fn_CalculateDiscount se está utilizando.

1. Ejecuta la consulta SQL proporcionada anteriormente.
2. Revisa los resultados para buscar fn_CalculateDiscount.
3. Si no aparece en los resultados después de un período de monitoreo, probablemente no se esté utilizando.

Conclusión

Identificar y eliminar objetos no utilizados en SQL Server es esencial para mantener una base de datos eficiente y libre de desorden. Ya sea que utilices SQL Server Profiler, métodos de cambio de nombre o consultas SQL, cada técnica tiene sus ventajas y puede ser adecuada dependiendo del contexto y los recursos disponibles.

Error 15025 SQL Server. The server principal already exists

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

UPDATE JOIN en SQL para Actualizar Tablas Relacionadas

Operador NOT IN de SQL: Una Guía Completa

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

Introducción

Si trabajas con SQL Server, es probable que alguna vez hayas necesitado monitorear las solicitudes en curso en tu base de datos. Para este propósito, la vista del sistema sys.dm_exec_requests es una herramienta esencial. En este blog, te mostraremos cómo usar SELECT * FROM sys.dm_exec_requests para obtener información valiosa sobre las solicitudes actuales en tu servidor de bases de datos. Aprenderás qué es, cómo funciona, y cómo puedes aprovecharlo para optimizar el rendimiento de tu base de datos.

¿Qué es dm_exec_requests?

La vista de administración dinámica sys.dm_exec_requests en SQL Server proporciona información detallada sobre las solicitudes que están siendo ejecutadas en el momento en que se consulta. Cada fila en esta vista representa una solicitud en curso, mostrando detalles como el estado de la solicitud, el tiempo que lleva ejecutándose, y el comando SQL actual.

¿Por Qué es Importante?

Monitorear las solicitudes actuales en tu servidor SQL es crucial para identificar problemas de rendimiento, diagnosticar bloqueos, y entender cómo se están utilizando los recursos del servidor. Con sys.dm_exec_requests, puedes obtener una visión clara de lo que está ocurriendo en tiempo real y tomar decisiones informadas para optimizar tus operaciones.

Cómo Utilizar dm_exec_requests

Para comenzar, simplemente ejecuta la siguiente consulta en tu servidor SQL:

SELECT * FROM sys.dm_exec_requests;

Esta consulta te devolverá una lista de todas las solicitudes actualmente en ejecución. Ahora, veamos algunas de las columnas más útiles que puedes encontrar en esta vista.

Columnas Clave en sys.dm_exec_requests

session_id

Cada solicitud está asociada con una sesión específica. La columna session_id te permite identificar la sesión que originó la solicitud.

request_id

La request_id es un identificador único para cada solicitud dentro de una sesión. Esto es útil para distinguir entre múltiples solicitudes de la misma sesión.

start_time

La columna start_time indica cuándo comenzó la solicitud. Puedes usar esta información para identificar solicitudes que han estado ejecutándose por un tiempo inusualmente largo.

status

El status de una solicitud puede ser running, suspended, runnable, entre otros. Esto te ayuda a entender el estado actual de la solicitud.

command

La columna command muestra el comando SQL que se está ejecutando actualmente. Esto es especialmente útil para diagnosticar consultas problemáticas.

Ejemplos Prácticos

Identificar Solicitudes Largas

Para encontrar solicitudes que han estado ejecutándose por más de un minuto, puedes usar la siguiente consulta:

SELECT session_id, request_id, start_time, status, command
FROM sys.dm_exec_requests
WHERE DATEDIFF(SECOND, start_time, GETDATE()) > 60;

Verificar Bloqueos

Los bloqueos pueden causar serios problemas de rendimiento. Para identificar solicitudes que están bloqueando o están siendo bloqueadas, puedes utilizar la columna blocking_session_id:

SELECT session_id, request_id, blocking_session_id, status, command
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Monitorear Consultas Específicas

Si estás investigando un problema específico, es posible que desees ver todas las solicitudes ejecutadas por una sesión en particular. Aquí tienes un ejemplo de cómo hacerlo:

SELECT session_id, request_id, start_time, status, command
FROM sys.dm_exec_requests
WHERE session_id = <tu_session_id>;

Reemplaza <tu_session_id> con el ID de la sesión que estás investigando.

Consejos para Optimizar el Uso de sys.dm_exec_requests

Filtra las Columnas Necesarias

Para mejorar el rendimiento de tus consultas y hacer que los resultados sean más manejables, selecciona solo las columnas que realmente necesitas:

SELECT session_id, request_id, start_time, status, command
FROM sys.dm_exec_requests;

Usa Índices y Particiones

Aunque no puedes cambiar la estructura de la vista sys.dm_exec_requests, asegúrate de que tus propias tablas y consultas estén optimizadas con índices y particiones adecuados. Esto reducirá la carga en el servidor y hará que las consultas a sys.dm_exec_requests sean más eficientes.

Automatiza el Monitoreo

Considera crear scripts automatizados que ejecuten consultas en sys.dm_exec_requests en intervalos regulares y almacenen los resultados en una tabla para análisis posterior. Esto puede ayudarte a identificar patrones y tendencias en el uso de tu base de datos.

Conclusión

sys.dm_exec_requests es una herramienta poderosa para cualquier administrador de bases de datos o desarrollador que trabaje con SQL Server. Te permite monitorear las solicitudes en tiempo real, identificar problemas de rendimiento y diagnosticar bloqueos. Al utilizar las consultas y técnicas descritas en este blog, puedes obtener una comprensión profunda de lo que está ocurriendo en tu servidor y tomar medidas proactivas para optimizar su rendimiento.

Recuerda, la clave para un servidor SQL eficiente es la monitorización constante y el ajuste continuo basado en los datos que recopilas. ¡Empieza a usar sys.dm_exec_requests hoy mismo y lleva el rendimiento de tu base de datos al siguiente nivel!

Recursos Adicionales

• Documentación Oficial de Microsoft sobre sys.dm_exec_requests
• Mejores Prácticas para Optimización de Consultas en SQL Server

Comentarios

¿Tienes alguna pregunta o comentario sobre el uso de sys.dm_exec_requests? ¡Déjanos tus pensamientos en la sección de comentarios a continuación! Tu experiencia y preguntas pueden ayudar a otros lectores a aprender más sobre esta valiosa herramienta.

SQL: ¿Configurar los Archivos LDF y MDF en Unidades Distintas es Importante?

Restaurar una Base de Datos en SQL usando ATTACH

¿Qué es un SGBDR SQL Server? Todo lo que Necesitas Saber

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

Guía Completa para Formatear Fechas en SQL FORMAT Server 2022