¿Por qué este capítulo importa?
Porque no se trata solo de que el sistema funcione.
Se trata de que funcione de forma sostenible, automatizada y visible.
Un DBA senior ya no puede depender del “yo lo reviso cada tanto” ni del “alguien me avisa si falla”.
Necesita:
- Procesos que se ejecuten solos
- Scripts que mantengan el orden
- Alertas que le hablen antes de que explote algo
- Y un ecosistema que pueda autoevaluarse y reportar
Este capítulo es donde tu trabajo empieza a escalar sin que escale tu agotamiento.
¿Qué cambia cuando automatizas y monitoreas con estrategia?
- Pasas de apagar incendios a prevenir fallas
- Tu conocimiento se vuelve replicable y documentado
- Puedes integrar IA, scripts, y sistemas de alerta que trabajan contigo
- Ganas visibilidad sobre lo que normalmente es invisible
Porque lo que no se automatiza, consume tiempo
Y lo que no se monitorea, algún día te va a sorprender
Subtemas que exploramos en este capítulo
- 5.1 PowerShell para DBAs: scripts y mantenimiento básico automatizado
- 5.2 Azure CLI y herramientas complementarias para gestión desde terminal
- 5.3 Log Analytics, métricas clave y alertas inteligentes
- 5.4 Query Store, Extended Events y diagnóstico avanzado
Ejemplo para abrir el capítulo:
Imagina que puedes ejecutar backups diarios, reorganizar índices, revisar logs y enviar alertas…
Todo sin abrir SSMS. Todo sin que te lo recuerden. Todo con un log que se documenta solo.
Eso no es lujo. Eso es profesionalismo técnico con visión.
Pregunta para entrar al mindset del capítulo
¿Qué tanto de lo que haces hoy podría ejecutarse solo con un script bien hecho o una alerta bien configurada?
Este capítulo es la diferencia entre operar bajo presión y diseñar con inteligencia.
5.1 – PowerShell para DBAs: scripts y mantenimiento
Automatiza lo básico, domina lo importante
¿Por qué PowerShell sigue siendo clave para DBAs?
Porque PowerShell es tu mejor aliado cuando necesitas:
- Automatizar tareas repetitivas que harías a mano desde SSMS
- Ejecutar procesos sobre varias bases al mismo tiempo
- Integrar SQL con el sistema operativo, Azure, archivos o programación
- Detectar y resolver errores antes de que escalen
Y lo mejor: puedes usarlo en local o en la nube, de forma programada o bajo demanda, y sin depender del SQL Agent si estás en Azure SQL Database.
Tareas críticas que puedes automatizar fácilmente con PowerShell
- Backups con timestamp
- Actualización de estadísticas
- Mantenimiento de índices (rebuild o reorganize)
- Verificación de espacio por base
- Ejecución de
DBCC CHECKDB
para integridad - Revisión de jobs fallidos o procesos con error
Ejemplo 1 – Backup con timestamp automático
$fecha = Get-Date -Format yyyyMMdd_HHmm
$base = "MiBase"
$ruta = "C:\\Backups\\$base" + "_$fecha.bak"
Invoke-Sqlcmd -Query "BACKUP DATABASE [$base] TO DISK = N'$ruta' WITH COMPRESSION, INIT" -ServerInstance "localhost"
¿Para qué sirve?
Genera backups con fecha/hora, sin sobrescribir los anteriores. Ideal para pruebas o backups programados.
Ejemplo 2 – Actualizar estadísticas en todas las bases
$instancia = "localhost"
$bases = Invoke-Sqlcmd -ServerInstance $instancia -Query "SELECT name FROM sys.databases WHERE database_id > 4"
foreach ($base in $bases) {
$nombre = $base.name
Write-Output "Actualizando estadísticas en $nombre..."
Invoke-Sqlcmd -ServerInstance $instancia -Database $nombre -Query "EXEC sp_updatestats"
}
¿Para qué sirve?
Mejora la precisión del optimizador de consultas, evita planes de ejecución deficientes.
Ejemplo 3 – Ver espacio por base
Invoke-Sqlcmd -Query "
SELECT
DB_NAME(database_id) AS BaseDatos,
SUM(size) * 8 / 1024 AS Tamaño_MB
FROM sys.master_files
GROUP BY database_id;" -ServerInstance "localhost"
¿Para qué sirve?
Detecta bases que están creciendo de forma anormal. Es base para decisiones de archivo o expansión.
Ejemplo 4 – Rebuild de índices con fragmentación alta
$instancia = "localhost"
$bases = Invoke-Sqlcmd -ServerInstance $instancia -Query "SELECT name FROM sys.databases WHERE database_id > 4"
foreach ($base in $bases) {
$nombre = $base.name
Write-Output "Mantenimiento de índices en $nombre..."
$query = @"
DECLARE @sql NVARCHAR(MAX) = '';
SELECT @sql += '
IF EXISTS (
SELECT * FROM sys.dm_db_index_physical_stats (NULL, OBJECT_ID(''' + QUOTENAME(t.name) + '''), NULL, NULL, ''LIMITED'')
WHERE avg_fragmentation_in_percent > 30 AND index_id > 0
)
BEGIN
ALTER INDEX [' + i.name + '] ON [' + s.name + '].[' + t.name + '] REBUILD;
END
'
FROM sys.indexes i
JOIN sys.tables t ON i.object_id = t.object_id
JOIN sys.schemas s ON t.schema_id = s.schema_id
WHERE i.type_desc IN ('CLUSTERED', 'NONCLUSTERED') AND i.name IS NOT NULL;
EXEC sp_executesql @sql;
"@
Invoke-Sqlcmd -ServerInstance $instancia -Database $nombre -Query $query
}
¿Para qué sirve?
Mejora el rendimiento al reducir fragmentación física de los índices, sin tocar estructuras ni datos.
Ejemplo 5 – Ejecutar DBCC CHECKDB
en todas las bases
$instancia = "localhost"
$bases = Invoke-Sqlcmd -ServerInstance $instancia -Query "SELECT name FROM sys.databases WHERE database_id > 4"
foreach ($base in $bases) {
$nombre = $base.name
Write-Output "Ejecutando CHECKDB en $nombre..."
Invoke-Sqlcmd -ServerInstance $instancia -Database $nombre -Query "DBCC CHECKDB WITH NO_INFOMSGS"
}
¿Para qué sirve?
Verifica integridad lógica y física de cada base. Detecta corrupción antes de que explote.
Ejemplo 6 – Ver últimos jobs fallidos
Invoke-Sqlcmd -Query "
SELECT
j.name AS JobName,
h.run_date,
h.run_time,
h.message
FROM msdb.dbo.sysjobhistory h
JOIN msdb.dbo.sysjobs j ON h.job_id = j.job_id
WHERE h.run_status != 1
ORDER BY h.run_date DESC, h.run_time DESC;
" -ServerInstance "localhost"
¿Para qué sirve?
Detecta procesos que están fallando en segundo plano y que podrían estar afectando la operación sin que nadie lo note.
¿Cómo ejecutarlos?
- Manualmente en PowerShell
- Agendados desde el Programador de tareas de Windows
- Integrados a un pipeline de CI/CD o a un sistema de monitoreo
- O incluso convertidos en Runbooks en Azure Automation
Desafío práctico
Objetivo: convertir estos scripts en un plan de mantenimiento mensual
- Copia los scripts en archivos
.ps1
individuales - Prueba cada uno en tu entorno de desarrollo
- Agrúpalos en un job maestro por etapas (por ejemplo, índices + estadísticas juntos)
- Agenda su ejecución
- Registra los resultados en logs locales o en una tabla de control
¿Qué deberías haber notado?
- Estas rutinas te dan control sin estar presente
- Automatizar mantenimiento mejora rendimiento, previene errores y gana tiempo
- Documentarlas y ejecutarlas con frecuencia te posiciona como un DBA sólido y proactivo
5.2 – Azure CLI y herramientas complementarias
Administra desde la terminal, con rapidez, precisión y control
¿Por qué aprender Azure CLI como DBA?
Porque aunque Azure tiene un portal visual muy completo, las tareas críticas y repetitivas se hacen más rápido desde la línea de comandos, y además:
- Puedes integrarlo con scripts, pipelines y automatizaciones
- No necesitas depender de interfaces gráficas lentas o inestables
- Tienes control total desde tu máquina o desde cualquier entorno de DevOps
Azure CLI es la forma más directa y multiplataforma de interactuar con Azure, y como DBA puedes usarlo para tareas de gestión, monitoreo, backup, permisos, configuración y más.
¿Qué es Azure CLI?
- Es la interfaz de línea de comandos oficial para gestionar recursos en Azure.
- Funciona en Windows, Mac y Linux.
- Se puede instalar localmente o usar directamente desde https://shell.azure.com
- El comando base es
az
, y se estructura por grupos:az sql
,az storage
,az monitor
, etc.
Tareas clave que puedes hacer con Azure CLI como DBA
Tarea | Comando base |
---|---|
Crear o eliminar bases | az sql db create/delete |
Listar bases o servidores | az sql db list |
Exportar base (backup) a blob | az sql db export |
Crear y asociar firewalls | az sql server firewall-rule |
Activar alertas o logs | az monitor metrics alert |
Ver métricas de rendimiento | az monitor metrics list |
Ejemplo 1 – Listar todas tus bases en una suscripción
az sql db list --output table
¿Para qué sirve?
Ver rápidamente qué bases tienes activas, sus tamaños, ubicaciones y planes.
Ejemplo 2 – Exportar una base a Blob Storage
az sql db export \
--admin-user usuarioadmin \
--admin-password MiClave123 \
--name MiBase \
--server miservidor.database.windows.net \
--storage-key "CLAVE_DE_TU_STORAGE" \
--storage-key-type StorageAccessKey \
--storage-uri "https://mitenant.blob.core.windows.net/backups/MiBase.bacpac"
¿Para qué sirve?
Exporta tu base como.bacpac
directamente al contenedor, sin entrar a SSMS.
Ejemplo 3 – Crear una regla de firewall para permitir tu IP
az sql server firewall-rule create \
--resource-group mi-grupo \
--server miservidor \
--name PermitirMiIP \
--start-ip-address 190.123.45.67 \
--end-ip-address 190.123.45.67
¿Para qué sirve?
Acceder a tu base desde casa o desde una sede externa sin abrir todo el acceso público.
Otras herramientas complementarias que puedes combinar con Azure CLI
1. Azure Storage Explorer (GUI local para Blob)
- Ver, subir y borrar archivos de contenedores
- Ideal para manejar backups
.bak
,.bacpac
, logs, etc.
2. AzCopy (transferencia de archivos por terminal)
- Más rápido que cargar desde navegador
- Puedes mover backups de forma automatizada o programada
3. Azure Data Studio
- Editor liviano para consultas, notebooks y análisis gráfico
- Puedes combinarlo con extensiones de Jupyter y PowerShell
Desafío práctico sugerido
Objetivo: exportar una base de Azure a Blob Storage usando CLI
- Abre el Azure Cloud Shell o instala Azure CLI
- Obtén tu Storage Key desde el portal
- Crea un contenedor si no existe
- Ejecuta el comando
az sql db export
con los parámetros adecuados - Verifica en Azure Blob que el archivo
.bacpac
se generó
¿Qué deberías haber notado?
- Azure CLI te permite hacer en segundos lo que el portal a veces tarda minutos
- Como DBA, usar CLI te da independencia, velocidad y automatización
- Puedes integrar estos comandos a scripts PowerShell o Runbooks fácilmente
5.3 – Log Analytics, métricas clave y alertas
Monitorea como un equipo de operaciones, actúa como un DBA senior
¿Por qué necesitas Log Analytics como DBA?
Porque en un entorno real:
- Lo que no se mide no se puede optimizar
- Lo que no se alerta no se soluciona a tiempo
- Y lo que no se centraliza se pierde entre herramientas aisladas
Log Analytics y Azure Monitor te permiten ver el estado de tus bases, responder a eventos críticos, y anticiparte a problemas de rendimiento, capacidad o seguridad.
¿Qué es Log Analytics?
Es una solución de Azure para recolectar, consultar y analizar registros y métricas de múltiples servicios, incluyendo:
- Bases de datos (Azure SQL, Managed Instance)
- Firewalls, redes, sistemas operativos
- Aplicaciones, scripts y automatizaciones
Se integra con:
- Azure Monitor (para alertas)
- Dashboards personalizados
- Workbooks para visualización avanzada
- Log queries (KQL) para exploración y diagnóstico profundo
Métricas clave que deberías estar monitoreando
Métrica | ¿Por qué importa? |
---|---|
CPU % y memoria utilizada | Detecta sobrecarga o necesidad de escalar |
DTUs/vCores consumidos | Identifica si tu base está sobredimensionada o al límite |
Latencia de disco (IOPS) | Ayuda a anticipar cuellos de botella |
Conexiones activas | Muestra saturación o patrones inusuales |
Deadlocks detectados | Indicador crítico de bloqueo mal gestionado |
Operaciones por tipo (lectura/escritura) | Ayuda a perfilar el uso de la base |
Ejemplo 1 – Consulta simple en Log Analytics (KQL)
AzureDiagnostics
| where ResourceType == "DATABASES"
| summarize count() by bin(TimeGenerated, 1h), OperationName
¿Para qué sirve?
Te muestra cuántas operaciones se realizaron por hora, segmentadas por tipo.
Ejemplo 2 – Crear una alerta por alto uso de CPU
- En Azure Portal, ve a Monitor > Alerts > New alert rule
- Selecciona tu base o servidor
- En condición, elige “CPU percentage > 85% durante 5 minutos”
- Crea una acción (correo, webhook, Logic App o Runbook)
- Asigna nombre y guarda
Ejemplo 3 – Crear un dashboard con métricas clave
- En Azure Portal, ve a Dashboard > New
- Añade gráficos desde Azure Monitor
- Incluye:
- CPU y DTU %
- Latencia de lectura/escritura
- Conexiones activas
- Alertas activas recientes
- Guarda como tablero compartido para tu equipo
Alertas recomendadas para empezar
- CPU > 85% durante 5 minutos
- DTUs > 90% en base productiva
- Fallos en exportaciones o backups
- Cantidad de deadlocks > 1 por hora
- Creación de usuarios o logins no esperados
Desafío práctico sugerido
Objetivo: configurar una alerta real sobre una base activa
- Ingresa a Azure Monitor
- Elige una base (Azure SQL o MI)
- Crea una alerta por uso de CPU o DTU
- Asócialo a un grupo de acción (correo o Teams)
- Provoca la alerta con una consulta pesada o una prueba controlada
- Valida que se reciba la notificación y se registre en Log Analytics
¿Qué deberías haber notado?
- Monitorear desde Azure es proactivo, escalable y conectado
- Una buena alerta a tiempo puede evitar una caída o una pérdida de reputación
- Dominar Log Analytics y KQL te posiciona como un DBA moderno con visión de SRE (Site Reliability Engineering)
5.4 – Query Store, Extended Events y diagnóstico avanzado
Porque optimizar sin datos es adivinar, y diagnosticar sin rastrear es perder el tiempo
Ver no es lo mismo que adivinar
En el mundo real, cuando una consulta empieza a tardar más, o cuando algo se bloquea sin explicación, el DBA promedio sospecha.
El DBA senior demuestra, documenta y decide.
Y para eso existen dos herramientas clave: Query Store y Extended Events.
Ambas están diseñadas para ayudarte a entender lo que pasa dentro de tu base, incluso si tú no estás mirando.
Query Store: tu caja negra técnica
¿Qué es?
Es un repositorio interno de SQL Server (y Azure SQL Database) que almacena:
- El historial de ejecución de tus consultas
- Los diferentes planes que se usaron
- Estadísticas de duración, CPU, I/O y frecuencia
- La posibilidad de forzar un plan si uno nuevo degrada el rendimiento
Es como tener un DVR de tus consultas. Puedes retroceder, revisar y optimizar con datos reales.
Cómo activarlo
ALTER DATABASE MiBase SET QUERY_STORE = ON;
ALTER DATABASE MiBase SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
Consulta útil: ver las 10 más costosas
SELECT TOP 10
qt.query_sql_text,
SUM(rs.avg_duration * rs.count_executions) AS TotalDuration,
MAX(rs.avg_cpu_time) AS MaxCPU
FROM sys.query_store_query_text qt
JOIN sys.query_store_query qs ON qt.query_text_id = qs.query_text_id
JOIN sys.query_store_plan sp ON qs.query_id = sp.query_id
JOIN sys.query_store_runtime_stats rs ON sp.plan_id = rs.plan_id
GROUP BY qt.query_sql_text
ORDER BY TotalDuration DESC;
¿Tu consulta está lenta por un mal plan? Forza el bueno
EXEC sp_query_store_force_plan @query_id = 45, @plan_id = 120;
Ideal para cuando SQL decide cambiar el plan por uno peor. Tú puedes tomar el control.
Extended Events: lo que Profiler ya no puede darte
¿Qué son?
El sucesor de SQL Profiler:
✔️ más ligeros
✔️ más detallados
✔️ más controlables
✔️ y 100% integrables con herramientas modernas
Te permiten:
- Rastrear bloqueos, deadlocks y errores silenciosos
- Capturar tiempos de espera, accesos críticos y estadísticas de ejecución
- Guardar todo en archivos
.xel
para análisis posterior - Integrarse con SSMS, Azure Monitor o Power BI
Cómo crear una sesión de Extended Events básica
CREATE EVENT SESSION [BloqueosYEsperas] ON SERVER
ADD EVENT sqlserver.lock_deadlock,
ADD EVENT sqlserver.sql_statement_completed
ADD TARGET package0.event_file (SET filename = 'C:\\XE\\bloqueos.xel')
WITH (
MAX_MEMORY = 4096 KB,
EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS
);
GO
ALTER EVENT SESSION [BloqueosYEsperas] ON SERVER STATE = START;
Este evento rastrea bloqueos y guarda los detalles en un archivo para análisis.
Dónde ver los resultados
- Desde SSMS: Management > Extended Events > Sessions
- Clic derecho en tu sesión > “Watch Live Data”
- O analiza el
.xel
con script, Power BI o herramientas de logs
Desafío práctico sugerido
Objetivo: identificar una consulta problemática con Query Store y rastrear si genera bloqueos
- Activa Query Store en una base de prueba
- Ejecuta una carga o consulta pesada repetidas veces
- Usa las vistas
sys.query_store_*
para observar su comportamiento (planes, duración, CPU) - Si detectas que un nuevo plan es peor, forza el plan anterior
- Opcional: crea una sesión de Extended Events para monitorear deadlocks en paralelo
- Documenta tu diagnóstico y tu acción correctiva como si fuera un caso real
¿Qué deberías haber notado?
- Query Store te muestra qué consulta cambió de comportamiento y por qué
- Extended Events te deja ver lo que está pasando bajo la superficie sin saturar el sistema
- Combinados, te permiten resolver con claridad, no por intuición
¿Te gustó lo que encontraste aquí?
Si este contenido te fue útil o te inspiró, considera apoyar esta iniciativa.
Aquí sigo, creando recursos que aporten claridad, estructura y propósito en tu camino.