El oficio del DBA

Alrededor de una base de datos hay tres oficios distintos que conviene no mezclar. Quien la diseña decide qué entidades hay y cómo se relacionan, y su producto es un modelo. Quien la programa escribe las consultas y los procedimientos que la aplicación necesita, y su producto es código SQL. Quien la administra se ocupa de que ese motor exista, arranque, quepa en el disco, responda a tiempo, deje entrar solo a quien debe y se pueda recuperar si un día se rompe.

Ese tercer papel es el que se llama administrador de bases de datos, DBA por sus siglas en inglés, y es el que pide este tema. La pregunta que resuelve no es «cómo obtengo los alumnos que suspendieron el tema 7», sino «cuánto espacio va a hacer falta el año que viene», «por qué la aplicación va lenta desde el martes», «quién puede leer la tabla de intentos» y «cuánto tardaría en volver a tener el servicio en pie si ahora mismo se quema el disco».

El trabajo se agrupa en cuatro grandes bloques que son, además, el orden en que se estudian aquí: instalar y configurar el gestor, repartir y vigilar el almacenamiento, controlar quién accede y con qué permisos, y garantizar el respaldo, la recuperación y la disponibilidad del servicio.

El diseñador responde del modelo, el programador de las consultas y el administrador del servicio: que esté disponible, sea seguro, rinda y se pueda recuperar.

Desglosado tarea a tarea, lo que se espera de un administrador de bases de datos suele enunciarse en esta lista, que es la que aparece en los temarios y en las relaciones de puestos de trabajo.

• Instalar el gestor y mantenerlo: parches, versiones y actualizaciones.
• Definir la política de almacenamiento y anticipar sus necesidades, incluido el particionamiento de las tablas que crecen sin freno.
• Definir la política de copias de seguridad y de restauración, y probarla.
• Monitorizar y optimizar el rendimiento, apoyándose en el plan de ejecución de las consultas caras.
• Crear las bases de datos y los esquemas, con sus guiones de creación y de carga inicial, sus restricciones y su integridad.
• Crear y definir usuarios y roles, y dejar traza de lo que hace cada uno.
• Documentar la instalación, la configuración y los procedimientos de operación.
• Establecer los mecanismos de seguridad, tanto sobre los datos (vistas y permisos) como sobre el servicio (arquitecturas de alta disponibilidad).
• Dar soporte a quienes desarrollan contra esa base de datos.

Conviene fijarse en que la lista tiene dos mitades. Una es preventiva y se hace en frío: instalar, dimensionar, documentar, definir la política. La otra es reactiva y se hace bajo presión: diagnosticar una lentitud, recuperar una tabla borrada, levantar el servicio caído. Las decisiones de la primera mitad son exactamente las que determinan si la segunda se puede resolver o no.

Hay dos cosas que en el habla corriente se llaman igual y que un administrador tiene que separar. La base de datos es el conjunto de ficheros que hay en el disco: los datos, los índices, los registros de cambios y los ficheros de control. La instancia es lo que existe mientras el servicio está arrancado: la memoria reservada y los procesos que la manejan. Si se apaga la máquina, la instancia desaparece y la base de datos sigue estando ahí.

Un mismo conjunto de ficheros puede ser abierto por una instancia hoy y por otra mañana, y en las arquitecturas de clúster varias instancias en máquinas distintas abren a la vez la misma base de datos. Por eso arrancar un gestor tiene fases: primero se levantan la memoria y los procesos, después se leen los ficheros de control y solo al final se abre la base para los usuarios.

Oracle es el caso extremo de esta distinción y por eso se cita siempre: su instalación ya crea una base de datos, que no es del administrador sino del propio producto. Todo vive dentro de ella y ahí están sus ficheros. La consecuencia práctica es la que se ve en el subtema de usuarios: en Oracle no se crea una base de datos por aplicación, se crea un usuario, y ese usuario es el esquema donde viven sus tablas.

La base de datos está en el disco y sobrevive al apagado. La instancia es memoria y procesos, y muere con él.

Un gestor arrancado no es un solo programa: es un conjunto de procesos especializados repartiéndose zonas de memoria compartida. Saber para qué está cada uno es lo que permite leer un problema de rendimiento, porque casi siempre el síntoma señala a uno de ellos. La nomenclatura de Oracle es la que más se pregunta, así que es la que se usa aquí como referencia.

El reparto de papeles entre DBWn y LGWR es el que conviene entender, porque es la base de todo el subtema de copias. Cuando una transacción se confirma no hace falta que sus bloques estén ya escritos en los ficheros de datos: basta con que el cambio esté anotado en el registro. Escribir el registro es secuencial y barato; escribir los bloques de datos es aleatorio y caro, y se hace después y en grupo. Si la máquina se cae en medio, el gestor arranca, lee el registro y rehace lo que faltaba.

La SGA es memoria compartida por toda la instancia; la PGA es privada de cada sesión. El COMMIT espera al registro, no a los ficheros de datos.

Los puertos por defecto son de las preguntas más repetidas del examen y, además, son lo primero que se mira cuando una aplicación no llega a su base de datos: si el puerto no está abierto en el cortafuegos, el error que se ve es de conexión rechazada o agotada, no de credenciales.

Con Oracle hay un matiz que se pregunta con mala idea. Además del 1521, que es el que usan las instalaciones por defecto, existen los puertos 2483 y 2484, registrados oficialmente para el protocolo de Oracle en claro y sobre TLS respectivamente. No han sustituido al 1521 en la práctica, pero conviene reconocerlos: si una pregunta ofrece los tres, los tres son de Oracle, y el 2484 es el cifrado.

Regla mnemotécnica del examen: 1521 Oracle, 1433 SQL Server, 3306 MySQL y MariaDB, 5432 PostgreSQL.