Cómo hacer una auditoría de base de datos SQL Server y evitar problemas en producción



Realizar un auditoría a tu SQL Server en una de las mejores decisiones que puedes tomar para detectar errores, cuellos de botella y riesgos antes de que afecten a producción. Revisar rendimiento, índices, seguridad, logs y configuración es clave para evitar caídas y pérdida de datos. Esta guía es un mínimo que se tiene que revisar




En esta mini guía vamos a repasar las cosas mas importantes a revisar en tu base de datos:

Es una guía pequeña donde los puntos que expongo se tiene que amplair y adaptar a la instancia y base de datos reales.


1) Información general del entorno

Antes de nada hay que saber que tenemos entre manos y revisar el contexto donde vamos a trabajar:
  • Versión del motor
  • Edition (Standard, Enterprise…)
  • Nivel de compatibilidad de la base de datos
  • Tamaño de BBDD y crecimiento
Ojo! con el Nivel de compatibilidad que si arrastráis bases de datos de migraciones es posible que no se haya actualizado.

Es decir, si tienes una instancia de SQL Server 2022 que tiene un nivel 160 y dentro de esta instancia hay bases de datos con un nivel de 130 esto quiere decir que tu base de datos trabaja en cierto modo en una versión SQL Server 2016 y no estas utilizando toda la potencia del servidor.

En este punto se pueden utilizar sentencias como:
SELECT @@VERSION;

SELECT name, compatibility_level
FROM sys.databases;

EXEC sp_spaceused;
Aquí detectas problemas típicos como:

  • Versiones sin soporte
  • Compatibility level antiguo (impacto en el optimizador)


2) Estado y configuración de la base de datos

En esta parte revisaremos el estado de la base de datos, configuraciones de servidor y de bases de datos, podemos utilizar la siguiente sentencia:
SELECT name, state_desc, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases;
Que nos dirá Puntos críticos como:
Recovery model en FULL sin backups de log
Bases en estado sospechoso (RECOVERY_PENDING, SUSPECT)



3) Tamaño de datos vs logs

Aquí hay que revisar tamaño de logs que no sean mas grandes que los datos, por ejemplo:
  • Data: 1,2GB
  • Log: 4.4 GB
Esto no es normal en la mayoría de los sistemas y puede significar que el log crece sin control y/o que no se esta truncando correctamente.
DBCC SQLPERF(LOGSPACE);
También podemos ver transacciones abierta:
DBCC OPENTRAN;



4) Análisis de rendimiento

Tenemos que detectar que consultas son lentas y están degradando el sistema:

No se trata solo de listar queries. Se trata de entender:
  • Qué consultas están degradando el sistema
  • Por qué lo hacen
  • Qué impacto real tienen

Podemos buscar consultas problemáticas con esta query:
SELECT TOP 20
    qs.total_elapsed_time / qs.execution_count AS avg_time,
    qs.execution_count,
    qs.total_elapsed_time,
    SUBSTRING(qt.text, qs.statement_start_offset/2,
        (CASE WHEN qs.statement_end_offset = -1
              THEN LEN(CONVERT(nvarchar(max), qt.text)) * 2
              ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY avg_time DESC;

Aquí podremos detectar:
  • Queries mal optimizadas
  • Falta de índices
  • Problemas de diseño Y cuando detectemos queries lentas, una query sospechosa, se tiene que analizar:

    Con un Execution Plan (esto es obligatorio)

    Y entender el problema:
    • Select * .... (Más datos = más IO = peor rendimiento)
    • Joins mal definidos



    5) Índices: exceso, falta y fragmentación

    Los índices son el motor del rendimiento en SQL Server… pero mal gestionados son un problema enorme.

    En este punto tendríamos que mirar
    • Índices no usados (exceso de índices)
    • Índices faltantes (Missing Indexes)
    • Fragmentación de índices
    • Revisar el diseño de índices (el verdadero problema)
    • Ratio lectura/escritura
    • Mantenimiento de índices
    • Fill Factor
    Como podemos ver en este punto hay muchas cosas a revisar y optimizar

    Los indices tienen que estar equilibrados:
    • Los necesarios → para leer rápido
    • Los mínimos → para escribir rápido
    Podemos utilizar consultas como
    SELECT *
    FROM sys.dm_db_missing_index_details;
    
    Para ver los indices faltantes o esta otra:
    SELECT
        OBJECT_NAME(ps.object_id) AS table_name,
        ps.index_id,
        ps.avg_fragmentation_in_percent
    FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ps
    WHERE ps.avg_fragmentation_in_percent > 30;
    
    Para ver la fragmentación de los indices.


    6) Bloqueos y concurrencia

    Este punto también es complicado y uno de los que mas dolores suele dar

    Tenemos que buscar Deadlocks y queries que bloquean el sistema, podemos utilizar consultas como esta:
    SELECT
        blocking_session_id,
        session_id,
        wait_type,
        wait_time,
        wait_resource
    FROM sys.dm_exec_requests
    WHERE blocking_session_id <> 0;
    
    SQL Server usa bloqueos para garantizar:
    • Consistencia de datos
    • Integridad
    • Aislamiento entre transacciones

    El problema aparece cuando:
    • Los bloqueos duran demasiado
    • Se encadenan
    • O se convierten en esperas masivas
    Los bloqueos no son un bug… son parte del sistema. El problema es cómo se usan las queries y las transacciones.


    7) Seguridad

    La seguridad es algo fundamental no solo para la base de datos sino también para el negocio.

    Hay que revisa usuarios y permisos que no tengamos usuarios sin control, Permisos excesivos, db_owner innecesarios, etc ...
    SELECT name, type_desc
    FROM sys.database_principals;
    
    También tendremos que revisar temas de:
    • autenticación (SQL vs Windows)
    • Accesos remotos
    • Datos sensibles
    • xp_cmdshell y features peligrosas
    • Backups y su seguridad.
    • ...



    8) Backups

    Se tiene que realizar backups periódicos, comprobarlos y ponerlos en lugar seguro.
    SELECT
        database_name,
        MAX(backup_finish_date) AS last_backup
    FROM msdb.dbo.backupset
    GROUP BY database_name;
    
    No hay un servidor seguro 100% y contra robos o perdidas un buen backup es lo que te salva la vida


    9) Integridad de datos

    Hay que detectar corrupción en las bases de datos:
    DBCC CHECKDB ('TuBaseDeDatos') WITH NO_INFOMSGS;
    
    Este comando:
    • Verifica estructura física de tablas e índices
    • Comprueba consistencia de páginas
    • Detecta corrupción en datos

    La integridad de datos garantiza que los datos no están corruptos, sean coherentes y se pueden leer correctamente.


    10) Jobs y mantenimiento

    Se tienen que programar tareas de mantenimiento periódicas para mantener el sistema sano, por ejemplo
    • Reindexación
    • Actualización de estadísticas
    • Backups automatizados

    Con esta consulta podemos ver las tareas automáticas
    SELECT name, enabled
    FROM msdb.dbo.sysjobs;
    


    Para resumir ...

    Una auditoria real de SQL Server no es solo técnica, es preventiva.

    Los problemas más habituales que vas a encontrar:
    • Logs descontrolados
    • Queries lentas
    • Índices mal diseñados
    • Falta de backups
    • Bloqueos en producción

    Si detectas varios de estos a la vez, no tienes un problema aislado… tienes un problema estructural.


    ... y esto es todo amig@s!!! hasta la próxima ...
    Saludos
    Alex
    :-)
    /

  • Suscríbete a nuestra newsletter

    Sin spam. Solo contenido útil para profesionales de bases de datos.