Curso DBA Senior – C1 – Fundamentos sólidos que siguen siendo clave

---

¿Por qué volver al inicio cuando ya eres senior?

Porque a veces lo que creemos que ya dominamos es justo lo que dejamos de mirar con atención. Y en bases de datos, los errores más costosos no vienen de lo que no sabemos… vienen de lo que creímos que ya sabíamos.

Este capítulo no es solo para repasar teoría. Es para ver con nuevos ojos los cimientos que sostienen todo: el motor relacional, los índices, las transacciones, los niveles de aislamiento, y ese gran olvidado llamado TempDB.
Porque si sabes esto de verdad, puedes detectar cuellos de botella, anticipar errores, mejorar el rendimiento sin escalar costos… y hablar de arquitectura con propiedad.

¿Qué vas a encontrar en este bloque?

Cada subcapítulo te lleva a revisar, entender y aplicar cinco temas que siguen siendo el núcleo técnico de cualquier DBA que se respete:

• 1.1 Estructura interna de los motores relacionales
  Cómo funciona realmente lo que usas a diario: páginas, extensiones, buffers, el planificador de ejecución…
• 1.2 Tipos de índices y su impacto
  No es solo crear un índice. Es saber cuál, por qué y cuándo eliminarlo también.
• 1.3 Planes de ejecución y estadísticas
  Leer un execution plan no es para pasar exámenes: es para no matar servidores.
• 1.4 Transacciones, ACID y niveles de aislamiento
  Porque un mal nivel de aislamiento puede ser más peligroso que un DROP sin WHERE.
• 1.5 TempDB y rendimiento
  ¿Cuántas veces has escuchado “va lento” y el problema estaba ahí?

Una metáfora para tener en mente

Un arquitecto puede obsesionarse con el diseño exterior de un edificio. Pero si no entiende cómo están distribuidas las cargas internas, los cimientos o la red eléctrica, cualquier fachada bonita se cae con una sobrecarga mínima.
Así funciona también la base de datos. No importa cuán bonita sea tu arquitectura cloud o tu dashboard de BI: si los fundamentos fallan, todo colapsa. Y tú eres quien debe sostenerlo.

Consejos antes de entrar a los subtemas

• No lo leas como repaso. Léelo como si tuvieras que explicárselo mañana a alguien que admiras.
• Piensa en fallos que has visto en producción. ¿Cuál de estos temas fue realmente la raíz?
• Anota lo que no aplicas aún. Este no es un curso para sabérselo todo, sino para usar mejor lo que ya sabes.

---

1.1 – Estructura interna de los motores relacionales

Desde lo básico hasta lo que realmente marca la diferencia

¿Qué pasa cuando ejecutas una consulta?

Cuando haces una consulta como SELECT * FROM Clientes, no solo estás pidiendo datos. Estás activando procesos internos que involucran memoria, disco, CPU y una estructura bien definida que el motor de base de datos usa para organizar, buscar y devolver la información.
Entender esta estructura te da claridad para diagnosticar lentitud, optimizar sin adivinar y anticipar errores que muchos solo descubren cuando ya es tarde.

Este capítulo te introduce a ese “motor interno” que no se ve, pero que sostiene todo.

Componentes clave del motor relacional

1. Páginas de datos (data pages)

• Unidad mínima de almacenamiento.
• En SQL Server, cada página tiene un tamaño fijo de 8 kilobytes (KB).
• Cada fila de una tabla vive dentro de una página.
• Las páginas tienen una cabecera con metadatos, espacio para filas y espacio libre que se puede fragmentar con el tiempo.

Analogía:
Piensa en una hoja de Excel: cada fila es un dato y toda la hoja representa una página.

2. Extents

• Conjunto de 8 páginas consecutivas: 8 KB x 8 = 64 kilobytes (KB).
• El motor asigna espacio en extents.
• Hay dos tipos: uniformes (una sola tabla) y mixtos (comparten varias tablas).

Analogía:
Como una carpeta que guarda 8 hojas juntas. Cuando necesitas más espacio, te asignan otra carpeta del mismo tipo.

3. Buffer Pool (memoria caché)

• Área de la memoria RAM donde se cargan las páginas más usadas.
• Evita tener que ir al disco, lo cual es más lento.
• Si una página no está en memoria, se produce un “page read” desde disco.

Analogía:
Como tener sobre tu escritorio los documentos que usas más seguido. Lo que no cabe, lo buscas en el archivo físico.

4. Checkpoint y Lazy Writer

• Checkpoint: guarda en disco las páginas modificadas que estaban solo en memoria.
• Lazy Writer: libera espacio en el buffer pool sacando páginas que ya no se usan frecuentemente.

Analogía:
Checkpoint es como guardar un documento de Word antes de cerrar. Lazy Writer es cerrar pestañas para liberar RAM.

5. Optimizador de consultas

• Decide cómo ejecutar una consulta: qué índices usar, qué orden de operaciones seguir.
• Lo hace basándose en estadísticas y metadatos.
• Si las estadísticas están desactualizadas, puede tomar decisiones costosas.

Analogía:
Como una app de rutas (Waze): analiza las opciones, elige la que parece más rápida. Si no tiene buena información, puede fallar.

6. Plan de ejecución

• Conjunto de pasos que el motor usará para devolver resultados.
• Incluye decisiones como usar o no un índice, tipo de unión entre tablas, uso de escaneos o búsquedas.
• Afecta directamente el rendimiento.

Explorar visualmente el plan de ejecución (SSMS)

1. Abre SQL Server Management Studio (SSMS).
2. Conéctate a tu servidor.
3. Abre una nueva consulta: SELECT * FROM Clientes WHERE ID = 500;
4. Haz clic en el ícono de “Mostrar plan de ejecución estimado” (parece un diagrama de flujo), o presiona Ctrl + L.
5. Ejecuta la consulta (F5).
6. Observa el plan que aparece en la parte inferior de la pantalla.

Desafío práctico guiado

Objetivo: entender cómo se acceden los datos internamente y cómo influye el almacenamiento en el rendimiento.

Paso a paso:

1. ¿No tienes datos de ejemplo?
   Descarga una base ya armada desde aquí:
   → Bases de datos gratuitas para tus proyectos y prácticas
2. O crea una tabla de prueba: CREATE TABLE Clientes ( ID INT PRIMARY KEY, Nombre NVARCHAR(100), Ciudad NVARCHAR(50) );
3. Llénala con al menos 1000 registros. Puedes hacerlo manualmente o usar scripts de inserción en bucle.
4. Ejecuta: SELECT * FROM Clientes WHERE ID = 500;
5. Activa el plan de ejecución (ver pasos anteriores).
6. Activa también las estadísticas: SET STATISTICS IO ON; SET STATISTICS TIME ON;
7. Observa el resultado:
   • ¿Dice Table Scan o Index Seek?
   • ¿Cuántas lecturas de página realiza?
   • ¿Cuánto tiempo consume?

¿Qué deberías haber notado?

• Cuando haces una consulta, la base no simplemente “busca datos”. Decide cómo hacerlo en base a sus estructuras internas.
• Entender estas decisiones te da control: puedes optimizar, anticipar problemas y justificar mejoras con claridad técnica.

Pregunta para reflexionar o compartir

¿Qué parte de este funcionamiento interno nunca habías notado antes, pero ahora te hace sentido?

---

1.2 – Tipos de índices y su impacto

Cómo acelerar tus consultas sin adivinar

¿Qué es un índice en una base de datos?

Un índice es una estructura especial que permite a la base de datos encontrar datos más rápido.
En lugar de revisar fila por fila (lo que se llama escaneo de tabla), el índice actúa como una guía que permite al motor ir directamente al lugar donde está la información.

Cuando una tabla tiene miles o millones de filas, un buen índice puede reducir el tiempo de una consulta de minutos a milisegundos.

¿Dónde ayuda un índice?

• Consultas que filtran por columnas (WHERE), hacen búsquedas (JOIN), ordenan (ORDER BY) o agrupan (GROUP BY)
• Tablas grandes que se consultan frecuentemente
• Columnas usadas como clave foránea

¿Dónde puede estorbar?

• En tablas con muchos cambios (INSERT, UPDATE, DELETE), los índices se actualizan cada vez.
• Demasiados índices innecesarios pueden ralentizar operaciones de escritura y consumir espacio.

Tipos de índices que debes conocer

1. Índice agrupado (Clustered Index)

• Es el índice principal de la tabla.
• Ordena físicamente los datos en disco.
• Solo puede haber uno por tabla.
• Generalmente está en la clave primaria.

Analogía:
Como una estantería ordenada por número de cliente. Los documentos están físicamente organizados según esa numeración.

2. Índice no agrupado (Non-Clustered Index)

• No cambia el orden físico de los datos.
• Es como una guía externa con referencias al lugar donde está el dato real.
• Puedes tener varios por tabla.

Analogía:
Como una hoja alfabética donde buscas “Carlos Gómez” y te dice en qué carpeta física encontrarlo.

3. Índice compuesto

• Usa dos o más columnas.
• Útil cuando las consultas usan condiciones múltiples.
• El orden de las columnas es importante: funciona mejor si la consulta usa las primeras columnas del índice.

Ejemplo:

CREATE NONCLUSTERED INDEX idx_ciudad_nombre
ON Clientes (Ciudad, Nombre);

4. Índice único

• Asegura que los valores sean únicos.
• Se usa para campos como correo, cédula o nombre de usuario.

5. Índice filtrado (SQL Server)

• Aplica solo a un subconjunto de datos.
• Reduce tamaño y mejora rendimiento si solo se consulta una condición específica.

Ejemplo:

CREATE NONCLUSTERED INDEX idx_estado_activo
ON Clientes (Estado)
WHERE Estado = 'Activo';

¿Cómo saber qué índice se está usando?

Usando el plan de ejecución.

1. En SSMS, escribe una consulta como: SELECT * FROM Clientes WHERE Ciudad = 'Bogotá';
2. Haz clic en el botón “Mostrar plan de ejecución estimado” o presiona Ctrl + L.
3. Ejecuta la consulta (F5).
4. Observa si aparece una operación de tipo:
   • Index Seek: el índice está siendo aprovechado.
   • Index Scan o Table Scan: se está leyendo más de lo necesario.

Consulta para ver índices existentes en una tabla

SELECT name, type_desc, is_unique
FROM sys.indexes
WHERE object_id = OBJECT_ID('Clientes');

Desafío práctico guiado

Objetivo: comprobar el impacto real de un índice bien aplicado.

Paso a paso:

1. Asegúrate de tener la tabla Clientes con muchos registros. Si no la tienes, puedes crearla o usar una base desde aquí:
   → Bases de datos gratuitas para tus proyectos y prácticas
2. Ejecuta una consulta sin índice: SELECT * FROM Clientes WHERE Ciudad = 'Bogotá';
3. Activa el plan de ejecución:
   • Haz clic en “Mostrar plan de ejecución estimado”.
   • Presiona F5 y analiza si hay un Table Scan (escaneo completo).
4. Crea el índice: CREATE NONCLUSTERED INDEX idx_ciudad ON Clientes (Ciudad);
5. Repite la consulta: SELECT * FROM Clientes WHERE Ciudad = 'Bogotá';
6. Observa:
   • ¿Ahora aparece Index Seek?
   • ¿El tiempo bajó?
   • Usa también: SET STATISTICS IO ON; SET STATISTICS TIME ON;

¿Qué deberías haber notado?

• Con índice, la búsqueda es más precisa y rápida.
• El plan de ejecución se vuelve más eficiente.
• Puedes usar esta información para justificar mejoras en bases reales.

Pregunta para reflexión o conversación

¿Cuántos índices tienes en tu tabla más crítica? ¿Los has validado últimamente o están allí desde siempre?

---

1.3 – Planes de ejecución y estadísticas

Cómo entender lo que realmente hace la base de datos al ejecutar una consulta

¿Por qué importa el plan de ejecución?

Cuando ejecutas una consulta, el motor de base de datos debe decidir cómo obtener los datos: si usa un índice, escanea toda la tabla, hace un join, agrupa, ordena, etc.
Ese conjunto de decisiones se llama plan de ejecución, y es lo que realmente se ejecuta, no lo que tú escribiste.

Saber leer ese plan te permite optimizar con precisión.
No se trata de cambiar consultas a ciegas, sino de entender por qué van lentas y cómo mejorar su comportamiento.

¿Qué es el plan de ejecución?

• Es un diagrama generado por el motor que muestra el camino que sigue para procesar una consulta.
• Incluye cada paso (operador), su costo estimado y el orden en que se ejecutan.
• Hay dos tipos:
  • Plan estimado: se genera sin ejecutar la consulta.
  • Plan real: se genera al ejecutar y muestra datos reales de uso.

¿Cómo ver el plan de ejecución en SSMS?

1. Abre SQL Server Management Studio (SSMS).
2. Escribe tu consulta, por ejemplo: SELECT * FROM Clientes WHERE Ciudad = 'Bogotá';
3. Haz clic en:
   • “Mostrar plan de ejecución estimado” (Ctrl + L), o
   • “Incluir plan de ejecución real” (Ctrl + M) para verlo tras ejecutar.
4. Ejecuta la consulta (F5).
5. El plan aparece en la pestaña inferior: una serie de bloques conectados con flechas.

Elementos clave que debes entender

Operador	¿Qué hace?	¿Cuándo preocuparte?
Table Scan	Recorre toda la tabla	Tablas grandes sin índice
Index Scan	Recorre un índice completo	Puede ser costoso si el índice no es selectivo
Index Seek	Busca directamente el dato	Ideal: uso eficiente del índice
Nested Loops	Compara cada fila de una tabla con otra	Bueno para pocas filas, costoso si son muchas
Hash Match	Une datos usando hash	Útil para conjuntos grandes, pero consume memoria
Sort	Ordena resultados	Costoso si no hay índice que ya ordene

¿Qué significa el “costo” de cada paso?

• Es una estimación del uso de recursos relativo dentro del plan.
• No es tiempo en segundos, sino un porcentaje interno que permite priorizar optimizaciones.

Pro tip:
No te fijes solo en lo que está al principio del plan: lo más costoso puede estar al fondo, en una suboperación.

¿Qué son las estadísticas y por qué son clave?

• Son metadatos que resumen el contenido de una columna: cuántos valores hay, qué tan distribuidos están, cuántos son nulos, etc.
• El optimizador las usa para decidir qué plan de ejecución tomar.
• Si están desactualizadas, puede elegir un plan lento.

¿Cómo ver si las estadísticas están actualizadas?

-- Ver estadísticas de una tabla
EXEC sp_helpstats 'Clientes', 'ALL';

-- Forzar actualización de estadísticas
UPDATE STATISTICS Clientes;

Desafío práctico paso a paso: Analiza y mejora un plan de ejecución

1. Ejecuta una consulta sin índice

SELECT * FROM Clientes WHERE Ciudad = 'Bogotá';

2. Activa el plan de ejecución real (Ctrl + M) y ejecuta (F5)

3. Observa:

• ¿Qué operadores aparecen?
• ¿Cuál tiene mayor “costo estimado”?
• ¿Está usando un índice o haciendo un escaneo completo?

4. Crea un índice

CREATE NONCLUSTERED INDEX idx_ciudad ON Clientes (Ciudad);

5. Repite la consulta y observa el nuevo plan

6. Activa estadísticas

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

7. Compara resultados antes y después del índice

¿Qué deberías haber notado?

• El uso de Index Seek mejora tiempos y reduce lecturas lógicas.
• El plan de ejecución revela cuellos de botella que no se ven en la consulta original.
• Las estadísticas influyen directamente en las decisiones del optimizador.

Pregunta para reflexionar o compartir

¿Qué operador o parte del plan te sorprendió más al verlo? ¿Tienes alguna consulta que podrías revisar ahora con esta mirada?

---

1.4 – Transacciones, ACID y niveles de aislamiento

Cómo proteger la integridad de los datos en entornos reales

¿Qué es una transacción en bases de datos?

Una transacción es un conjunto de instrucciones SQL que se ejecutan como una sola unidad lógica.
O se completan todas correctamente, o no se aplica ninguna.

Ejemplos reales:

• Transferencias bancarias (resta a un lado, suma en otro)
• Actualizaciones múltiples en cascada
• Procesos de facturación o contabilidad

Principios ACID de toda transacción confiable

Letra	Significa	¿Qué garantiza?
A	Atomicidad	Todo o nada. Si algo falla, se revierte todo.
C	Consistencia	El sistema pasa de un estado válido a otro válido.
I	Aislamiento	Otras operaciones no ven una transacción incompleta.
D	Durabilidad	Una vez confirmada, la transacción no se pierde (aunque haya apagón).

Cómo se crea una transacción en SQL Server

BEGIN TRANSACTION;

UPDATE Cuentas SET Saldo = Saldo - 500 WHERE ID = 1;
UPDATE Cuentas SET Saldo = Saldo + 500 WHERE ID = 2;

COMMIT; -- confirma todo
-- o
ROLLBACK; -- revierte todo si algo sale mal

¿Qué puede pasar si no usas transacciones?

• Queda un registro modificado y otro no.
• Se mezclan operaciones de distintos usuarios.
• Se pierden datos al interrumpirse un proceso.

Pro tip:
Usa transacciones en cualquier operación que implique múltiples pasos o afecte varios registros clave.

¿Qué es el aislamiento en una transacción?

Los niveles de aislamiento determinan qué tanto puede ver una transacción de lo que otras están haciendo.
Elige el nivel según el equilibrio entre rendimiento y protección contra errores de concurrencia.

Niveles de aislamiento (explicados simple)

Nivel	¿Qué permite ver?	¿Riesgos?
Read Uncommitted	Lee datos incluso si no han sido confirmados (dirty reads)	Alta velocidad, pero muy peligroso
Read Committed (por defecto)	Solo ve datos confirmados	Puede ver datos distintos si se repite la lectura
Repeatable Read	Bloquea filas leídas hasta el final de la transacción	Evita cambios inesperados, pero puede bloquear
Serializable	Impide nuevos registros que alteren el rango leído	Máxima seguridad, pero más lenta
Snapshot (SQL Server con versióning)	Usa versiones de datos, sin bloquear	Muy útil si está disponible en tu base

Ejemplo práctico: comparando niveles de aislamiento

1. Usa este comando antes de una consulta para cambiar el nivel de aislamiento:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN TRANSACTION;

SELECT * FROM Productos WHERE Categoria = 'Electrónica';
-- Simula un proceso largo...

-- COMMIT o ROLLBACK después

2. En otra ventana, intenta actualizar o insertar algo en la misma categoría.
¿Qué pasa? ¿Se bloquea? ¿Te deja escribir?

Desafío práctico guiado

Objetivo: experimentar cómo una transacción protege (o no) tus datos.

1. Crea una tabla simple de cuentas con ID, Nombre y Saldo.
2. En una ventana, inicia una transacción: sqlCopiarEditarBEGIN TRANSACTION; UPDATE Cuentas SET Saldo = Saldo - 100 WHERE ID = 1; -- Espera antes de hacer COMMIT
3. En otra ventana, intenta leer el saldo del mismo registro.
4. Cambia el nivel de aislamiento y repite.
5. Compara:
   • ¿Ves el cambio sin confirmar?
   • ¿Se bloquea la segunda consulta?
   • ¿Qué pasa si haces un ROLLBACK?

¿Qué deberías haber notado?

• Las transacciones protegen tu lógica, pero también pueden bloquear a otros si no se diseñan bien.
• Elegir el nivel de aislamiento correcto es parte de pensar como arquitecto, no solo como técnico.

Pregunta para reflexionar o compartir

¿Tienes procesos en tu sistema que deberían ser transacciones y no lo son? ¿Te ha pasado que dos procesos chocan?

---

1.5 – TempDB y rendimiento

El espacio de trabajo invisible que puede frenar todo tu sistema

¿Qué es TempDB y para qué sirve?

TempDB es una base de datos especial, compartida por todo el servidor SQL, que se usa para almacenar objetos temporales y operaciones intermedias.

Todo lo que SQL necesita “hacer mientras trabaja” pasa por TempDB.

Ejemplos comunes:

• Tablas temporales (#MiTabla)
• Variables tipo tabla
• Ordenamientos (ORDER BY, GROUP BY)
• Hash joins
• CTEs y subconsultas complejas
• Versionado de datos (cuando usas Snapshot Isolation)

¿Por qué es importante cuidarla?

Porque TempDB es compartida por todas las bases de datos.
Si se satura, cualquier proceso —aunque no sea tuyo— puede volverse lento o fallar.
Es como el taller común de una fábrica: si está desordenado o lleno, ningún operario trabaja bien.

¿Dónde se nota el impacto de TempDB?

• Consultas que antes eran rápidas y ahora tardan sin razón aparente
• Procesos de ETL o reportes que generan mucha carga intermedia
• Transacciones con muchas escrituras que usan Snapshot Isolation
• Falla del sistema por falta de espacio

Cómo monitorear si TempDB está siendo un cuello de botella

-- Ver archivos, tamaños y uso actual de TempDB
USE tempdb;
GO
EXEC sp_spaceused;

-- Consultar las sesiones que más están usando TempDB
SELECT 
    session_id, 
    user_objects_alloc_page_count, 
    internal_objects_alloc_page_count,
    total_allocations = user_objects_alloc_page_count + internal_objects_alloc_page_count
FROM sys.dm_db_session_space_usage
ORDER BY total_allocations DESC;

Buenas prácticas para optimizar TempDB

Recomendación	¿Por qué ayuda?
Usar múltiples archivos de datos (.mdf)	Reduce contención en escrituras simultáneas
Mover TempDB a un disco rápido (SSD)	Mejora rendimiento I/O
Evitar abusar de tablas temporales innecesarias	Reduce escritura en disco
Revisar planes de ejecución que usen operadores como Sort o Hash Match	Muchas veces son los culpables invisibles

Configuración sugerida de archivos TempDB (SQL Server)

• Mismo tamaño inicial para todos los archivos
• Autocrecimiento controlado (no en pasos pequeños)
• 1 archivo por CPU lógica (hasta un límite razonable, 8 a 16 en entornos grandes)

Esto se puede hacer desde el instalador, el Management Studio o vía script.

Desafío práctico guiado

Objetivo: detectar y visualizar el uso de TempDB en tus consultas

1. Ejecuta una consulta pesada con ordenamiento o agrupamiento:

SELECT TOP 10000 Ciudad, COUNT(*) 
FROM Clientes
GROUP BY Ciudad
ORDER BY COUNT(*) DESC;

2. Activa el plan de ejecución y busca el operador “Sort” o “Hash Match”

3. Abre otra ventana y corre:

SELECT * 
FROM sys.dm_db_session_space_usage
WHERE session_id = @@SPID;

4. Verifica si los valores de uso interno aumentaron (indicando que usó TempDB)

¿Qué deberías haber notado?

• Muchas operaciones usan TempDB sin decirlo.
• El rendimiento general no solo depende del código, sino del entorno donde ese código se ejecuta.
• Aprender a cuidar TempDB es clave para escalar sistemas sin sorpresas.

Pregunta para reflexionar o compartir

¿Tu sistema ha sufrido lentitud “sin razón clara”? ¿Habías revisado alguna vez qué tanto estás usando TempDB?

---

¿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.

♥️ Hey sí, ¡quiero apoyar esto!

---

---

---

---