Una base de datos no se administra sola

Una aplicación puede funcionar correctamente durante meses.

Hasta que ocurre algo:

El punto de partida

Imagina una organización donde:

• Nadie tiene claramente definida la responsabilidad sobre las bases de datos.
• Desarrollo y producción comparten recursos sin controles adecuados.
• Los cambios se realizan directamente sobre sistemas en operación.
• La configuración no está documentada.
• No existe claridad sobre quién puede acceder a la información.

Pregunta orientadora

Si una organización depende de sus datos para operar, ¿qué necesita controlar para que una base de datos sea confiable?

Piensa en cuatro dimensiones:

Ruta de la unidad

La unidad responde cinco preguntas fundamentales sobre la gestión de bases de datos.

Objetivos de aprendizaje

Al finalizar la unidad podrás:

¿Qué significa ser DBA?

DBA — Database Administrator

Es el profesional responsable de administrar el funcionamiento de uno o más sistemas gestores de bases de datos dentro de una organización.

Su trabajo comprende, entre otras funciones:

El DBA administra un servicio, no solamente una base

Una base de datos forma parte de un sistema mayor.

El DBA no trabaja aislado

¿Hasta dónde llega la responsabilidad del DBA?

El DBA tiene una responsabilidad especializada, pero la gestión de los datos requiere la participación coordinada de distintas áreas.

Actividad 1 · El problema detrás del problema

Actividad 2 · Mapa de relación del DBA con otros roles

¿Qué hace un DBA durante una semana normal?

El trabajo no consiste únicamente en reaccionar ante fallas.

Dos responsabilidades más, y dos dimensiones transversales

De la responsabilidad a la acción

Un principio importante

No se optimiza lo que no se ha diagnosticado.

Si una consulta tarda más:

No significa automáticamente que haya que aumentar memoria.

Primero se necesita conocer:

• ¿Qué cambió?
• ¿Dónde ocurre la demora?
• ¿Qué recursos están involucrados?
• ¿Qué evidencia proporciona el sistema?

Actividad 3 · ¿Qué haría un DBA?

Dos conceptos que no debemos confundir

¿Por qué importa esta diferencia?

Porque una organización puede experimentar problemas diferentes:

Estos conceptos se relacionan, pero no son sinónimos.

¿Qué es un ambiente?

Un ambiente es el conjunto de recursos tecnológicos, configuración y datos destinados a ejecutar un sistema para un propósito determinado.

No es simplemente:

"otra copia de la base de datos".

También involucra:

infraestructura + configuración + aplicación + datos + propósito

Tres ambientes, tres propósitos

¿Por qué no trabajar directamente en producción?

Porque producción tiene consecuencias reales.

Un cambio no validado puede:

• alterar información
• interrumpir servicios
• afectar a otros usuarios
• generar inconsistencias
• dificultar la recuperación del sistema

Separar ambientes no significa aislarlos por completo

Los ambientes deben ser diferentes en propósito y control, pero mantener una coherencia suficiente para que lo validado en pruebas sea representativo de producción.

Una cuarta posibilidad: preproducción

Algunas organizaciones incorporan un ambiente adicional:

Staging / preproducción

Su propósito es aproximarse a las condiciones de producción antes del despliegue definitivo.

Caso de estudio · Knight Capital

En 2012, un despliegue dejó inconsistencias entre servidores que debían ejecutar la misma versión del sistema.

Un servidor conservó código antiguo y terminó activando una funcionalidad que no debía estar operativa.

Knight Capital · ¿qué debemos aprender?

No basta con decir:

"había un error en el código".

La pregunta profesional es:

¿Qué proceso técnico y operativo permitió que una diferencia entre servidores llegara a producción?

Caso de estudio · GitLab

En 2017, una operación administrativa ejecutada sobre el entorno de producción provocó una pérdida importante de datos.

El incidente también puso en evidencia problemas relacionados con los mecanismos de respaldo y recuperación.

GitLab · una pregunta más profunda

El problema no puede reducirse a:

"alguien ejecutó el comando equivocado".

La pregunta profesional es:

¿Qué controles debieron existir para reducir la probabilidad de error y limitar su impacto?

Actividad 4 · Analizar un incidente

Antes de hablar de motores...

No memorices nombres todavía.

Primero comprende una pregunta mucho más sencilla:

¿Qué tiene que hacer un SGBD para procesar una consulta y conservar los datos?

Necesita resolver, al menos, dos problemas:

El modelo mental

Memoria y almacenamiento no cumplen la misma función

Idea clave: RAM y almacenamiento persistente cumplen funciones diferentes y complementarias.

¿Qué ocurre cuando llega una consulta?

Podemos simplificar el proceso así:

¿Cómo resuelven esto Oracle y PostgreSQL?

Los conceptos de memoria, caché y almacenamiento persistente son comunes a cualquier SGBD relacional. A continuación, dos ejemplos paralelos de cómo los implementa cada motor:

Oracle: un ejemplo de implementación

Del dato lógico al dato físico

Cuando administramos una base de datos debemos distinguir dos perspectivas.

El DBA necesita comprender ambas perspectivas.

Una pregunta de DBA

Supón que una tabla contiene millones de registros.

La aplicación pregunta:

¿Dónde están esos datos?

Una respuesta profesional no es:

"En la base de datos".

Debe poder distinguir:

estructura lógica → estructura física → memoria → almacenamiento

Actividad 5 · Construye el modelo

NoSQL: una familia, no una sola arquitectura

NoSQL agrupa diferentes sistemas de gestión de datos que utilizan modelos distintos al modelo relacional tradicional.

No significa necesariamente:

• "sin esquema"
• "sin relaciones"
• "sin consistencia"
• "sin SQL"

Significa que existen otras formas de representar, consultar y distribuir los datos.

Cuatro modelos para reconocer

El mismo contexto, cuatro perspectivas

Imagina información sobre una estudiante y sus cursos.

{
  "alumna": "Ana",
  "cursos": ["DBA", "Redes"]
}

alumna:1001
→ "Ana"

partición: 1001
curso → DBA
curso → Redes

(Ana)
  │
  └── INSCRITA_EN ──→ (DBA)

¿Por qué existen distintos modelos?

Porque los datos y las necesidades de las aplicaciones también son diferentes.

Lo importante no es memorizar herramientas

Ante una tecnología nueva, pregunta:

Actividad 6 · Elegir el modelo adecuado

Regresemos al problema inicial

Al comenzar encontramos:

• responsabilidades poco claras
• cambios directos en producción
• ausencia de documentación
• desconocimiento de la arquitectura
• falta de controles operativos

Ahora podemos analizar el problema desde varias perspectivas.

Cinco preguntas para analizar una base de datos

El panorama completo

El DBA piensa en relaciones

Una decisión rara vez pertenece a una sola dimensión.

Por ejemplo:

"Necesitamos modificar la base de datos."

El DBA debe preguntarse:

Esa forma de pensar es parte de la profesionalización de la administración de bases de datos.

Actividad 7 · Diagnóstico integral

¿Qué debes llevarte de esta unidad?

Cinco preguntas antes de continuar

Antes de pasar a la siguiente unidad, deberías poder responder:

De la administración a la seguridad

Hasta ahora hemos construido una visión general de la administración de bases de datos:

Referencias

Las fuentes académicas y técnicas utilizadas en esta unidad se encuentran en:

Bibliografía y fuentes — Unidad 1

Incluye documentación oficial de SGBD, marcos profesionales, fuentes institucionales y casos de estudio.

Referencias principales

• DAMA International — DAMA-DMBOK2R
• Oracle — Database Administrator's Guide
• PostgreSQL — PostgreSQL Documentation
• MongoDB — MongoDB Documentation
• Redis — Redis Documentation
• Apache Cassandra — Documentation
• Neo4j — Documentation
• Wiggins — The Twelve-Factor App
• GitLab — Database Outage Postmortem
• U.S. SEC — Knight Capital