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.
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:
Recovery model en FULL sin backups de log
Bases en estado sospechoso (RECOVERY_PENDING, SUSPECT)
No se trata solo de listar queries. Se trata de entender:
Podemos buscar consultas problemáticas con esta query:
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:
En este punto tendríamos que mirar
Los indices tienen que estar equilibrados:
Tenemos que buscar Deadlocks y queries que bloquean el sistema, podemos utilizar consultas como esta:
El problema aparece cuando:
Hay que revisa usuarios y permisos que no tengamos usuarios sin control, Permisos excesivos, db_owner innecesarios, etc ...
La integridad de datos garantiza que los datos no están corruptos, sean coherentes y se pueden leer correctamente.
Con esta consulta podemos ver las tareas automáticas
Los problemas más habituales que vas a encontrar:
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
:-)
/
Que vamos ver en este artículo
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
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
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:
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
Los indices tienen que estar equilibrados:
- Los necesarios → para leer rápido
- Los mínimos → para escribir rápido
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 darTenemos 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
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
:-)
/
Comentar el artículo
Suscríbete a nuestra newsletter
Copias de seguridad, Índices y rendimiento, Consultas lentas, Espacio en disco, logs, mantenimiento ...