Preguntas de entrevista para Administrador de Base de Datos

Respuesta modelo

En mi último puesto trabajaba con dos esquemas. En Oracle, RMAN con copia completa semanal, incremental de nivel 1 diaria y archivado de redo cada 15 minutos hacia un segundo almacenamiento y a cinta con retención de 35 días. En PostgreSQL, pgBackRest con la misma lógica y WAL archivados de forma continua. Esto nos daba un RPO de 10 minutos y un RTO comprometido de 45. La última restauración real fue en enero: un proveedor ejecutó una carga masiva errónea sobre una tabla de facturación y recuperamos a un punto anterior mediante restauración point-in-time en un entorno auxiliar; tardamos 38 minutos hasta tener el dato validado y solo se repusieron las filas afectadas, sin parar el resto del sistema. Al margen de los incidentes, hacíamos doce restauraciones de prueba al año, cronometradas y con acta, porque una copia que no se ha restaurado no es una copia sino una suposición.

Respuesta modelo

En los sistemas de núcleo transaccional teníamos un RTO de 45 minutos y un RPO de 10; en los sistemas departamentales, RTO de 8 horas y RPO de 24. Esos valores no los fijé yo en solitario: salieron de una reunión con negocio en la que se cuantificó cuánto costaba cada hora de parada y cuántos minutos de datos era asumible rehacer a mano. La verificación era doble: restauraciones de prueba mensuales con cronómetro sobre un servidor de recuperación, y un simulacro semestral completo de conmutación al centro de respaldo, con las áreas de negocio operando allí durante dos horas. En el simulacro de octubre detectamos que un servicio de la aplicación no reconectaba solo tras el cambio de rol; se corrigió el arranque y en el simulacro siguiente el tiempo total bajó de 71 a 43 minutos.

Respuesta modelo

Un jueves por la noche, durante mi semana de retén, el nodo principal de un RAC de cuatro nodos dejó de admitir sesiones nuevas. Lo primero fue confirmar el alcance con la monitorización y avisar al responsable de guardia de negocio con un mensaje claro: servicio degradado, sin pérdida de datos por el momento. El diagnóstico apuntó a un agotamiento del espacio de la zona de recuperación por un archivado que llevaba dos días sin purgar tras un fallo del script. Liberé espacio moviendo archivos ya respaldados, restablecí el archivado y el servicio volvió en 22 minutos. Después vino lo importante: análisis de causa raíz, alerta específica de ocupación al 75 % en lugar del 90 % que teníamos, y control del resultado del script de purga en la monitorización, no solo de su ejecución. No volvió a repetirse en los dos años siguientes.

Respuesta modelo

Primero delimito: ¿es toda la base de datos o una funcionalidad concreta?, ¿desde cuándo exactamente?, ¿coincide con un despliegue, una carga o un cambio de volumen? Comparo el periodo lento con un periodo sano usando AWR y ASH en Oracle o Query Store en SQL Server, y busco las esperas dominantes. En la mayoría de los casos que he vivido, la causa era una de estas cuatro: estadísticas obsoletas tras una carga masiva que cambió el plan de ejecución, un índice eliminado o no desplegado en el último cambio, un crecimiento de tabla que convirtió un acceso por índice en un barrido completo, o contención de bloqueos por una transacción larga nueva. Solo después de identificar la espera dominante propongo la corrección, y siempre la contrasto en preproducción. Lo que evito es la reacción refleja de añadir memoria o crear índices a ciegas: eso enmascara el problema y deja deuda.

Respuesta modelo

Con un guion escrito y probado. Empiezo por el inventario: qué bases de datos, qué tamaño, qué aplicaciones dependen de cada una y qué proveedor tiene que certificar la versión de destino. Después clono el entorno más complejo en preproducción y ejecuto allí el upgrade completo al menos dos veces, cronometrando cada fase y midiendo el rendimiento antes y después con la misma carga de pruebas, porque un cambio de optimizador puede degradar consultas que funcionaban bien. Preparo el plan de vuelta atrás y lo ensayo también, que es la parte que suele omitirse. Luego negocio ventanas por oleadas, empezando por los sistemas menos críticos. En mi última migración, 28 bases de datos de Oracle 12c a 19c en cuatro ventanas nocturnas, con 11 minutos de parada media por sistema y ninguna vuelta atrás necesaria.

Respuesta modelo

Parto de tres principios: mínimo privilegio, separación de funciones y trazabilidad de todo acceso privilegiado. En la práctica significa cuentas nominales en lugar de genéricas compartidas, roles por función y no permisos sueltos por persona, y revisión trimestral de accesos junto con los responsables de cada aplicación. Los accesos administrativos quedan registrados con Oracle Unified Auditing o SQL Server Audit en un destino que el propio DBA no puede alterar, que es el punto que siempre revisa un auditor. Para los entornos de preproducción aplicamos enmascarado de los datos personales, porque copiar producción tal cual a un entorno de pruebas es una de las brechas más frecuentes y más fáciles de evitar. En mi último puesto reduje de 47 a 6 las cuentas con privilegios de administrador y superamos la auditoría interna sin no conformidades.

Respuesta modelo

El desarrollador es dueño del modelo de datos de su aplicación y de las consultas que escribe; yo soy dueño del servicio: que la instancia esté disponible, respaldada, parcheada, dimensionada y auditada. Cuando una consulta va lenta, no la reescribo yo en su lugar: aporto el plan de ejecución, señalo la espera dominante y propongo el índice o el cambio de acceso, y decidimos juntos. En sentido contrario, ningún cambio de esquema entra en producción sin pasar por mi revisión de impacto en volumetría, bloqueos y ventana de despliegue. Esa frontera evita dos disfunciones típicas: el DBA convertido en cuello de botella que reescribe el código ajeno, y el equipo de desarrollo desplegando cambios estructurales un viernes por la tarde sin medir su efecto.

La recuperación completa devuelve la base de datos al último estado consistente disponible: restauro la copia y aplico todo el registro de transacciones o los archivelog hasta el final. La point-in-time me lleva a un instante concreto anterior, que es lo que necesito cuando el problema no es un fallo de hardware sino un error lógico, por ejemplo un borrado masivo. Para la primera basta con la copia y los registros posteriores; para la segunda necesito además saber el momento exacto o el número de cambio del sistema al que quiero volver, y disponer de la cadena de registros completa desde la copia hasta ese punto. En Oracle uso RMAN con UNTIL TIME o UNTIL SCN, en SQL Server la restauración con STOPAT, y en PostgreSQL la recuperación con recovery_target_time sobre los WAL archivados. Casi siempre restauro a un entorno auxiliar y recupero solo los datos afectados, en lugar de retroceder todo el sistema y perder las transacciones legítimas posteriores.

Empiezo por mirar el plan real de ejecución, no el estimado, y comparo filas estimadas con filas devueltas. Si la diferencia es de órdenes de magnitud, casi siempre son estadísticas obsoletas o no representativas, y las recalculo. Después reviso motivos que invalidan el índice: una función o una conversión implícita de tipo sobre la columna filtrada, un comodín inicial en un LIKE, una intercalación distinta entre columnas, o un predicado poco selectivo que hace que el barrido completo sea realmente más barato. También compruebo el orden de las columnas del índice frente al del predicado y si la consulta necesita columnas no incluidas, lo que obliga a accesos adicionales a la tabla y puede hacer que el optimizador lo descarte. Solo cuando todo lo anterior está descartado considero una directiva o un plan fijado, y siempre como medida temporal documentada, porque congelar un plan es aplazar el problema.

En la replicación síncrona la transacción no se confirma hasta que la réplica ha recibido y asegurado el registro; el RPO es cero, pero cada confirmación paga la latencia de la red, así que solo es viable si los centros están próximos. En la asíncrona la transacción confirma en el principal y los cambios viajan después, de modo que el rendimiento no se resiente pero existe una ventana de pérdida igual al retardo de aplicación, que hay que monitorizar de forma permanente. En la práctica he usado la combinación habitual: una réplica síncrona en el centro principal para tolerar la caída de un servidor sin perder datos, y una asíncrona en el centro de respaldo remoto para el escenario de desastre. Oracle lo formaliza en los modos de protección de Data Guard, SQL Server en el modo de confirmación de los grupos Always On y PostgreSQL en el parámetro synchronous_commit. La decisión no es técnica sino de negocio: cuántos segundos de datos está dispuesta a perder la empresa.

Para el bloqueo persistente identifico la cadena de espera: quién bloquea a quién, desde cuándo y qué sentencia está en la raíz. En Oracle miro las sesiones bloqueantes y el evento de espera; en SQL Server, la sesión de bloqueo principal y el informe correspondiente; en PostgreSQL, las consultas en espera de bloqueo y su antigüedad. La medida inmediata puede ser terminar la sesión bloqueante, pero eso es la tirita: lo relevante es por qué existía una transacción abierta tanto tiempo, y en mi experiencia suele ser una transacción que espera confirmación de un usuario, un lote que actualiza sin acotar o una aplicación que no cierra la transacción cuando falla. Para los interbloqueos activo su registro, extraigo el grafo y busco el patrón: casi siempre dos procesos que acceden a las mismas tablas en orden inverso. La solución estructural es unificar el orden de acceso, acortar las transacciones y ajustar los lotes, y eso se corrige con el equipo de desarrollo, no en el motor.

PostgreSQL no sobrescribe las filas al actualizarlas: crea una versión nueva y deja la anterior como versión muerta. El vacuum recupera ese espacio y, sobre todo, evita el agotamiento del contador de transacciones, que en el peor caso obliga a parar la base de datos. El autovacuum lo hace de forma automática, pero se queda corto en tablas muy grandes o con mucha actualización si se dejan los parámetros por defecto: entonces la tabla se hincha, las lecturas leen páginas casi vacías y el rendimiento cae poco a poco sin que nadie lo relacione con la causa. Lo que hago es vigilar la proporción de filas muertas y la antigüedad de las transacciones por tabla, ajustar los umbrales y el coste del autovacuum en las tablas críticas y programar mantenimientos específicos en ventana para las peores. Un VACUUM FULL reorganiza y devuelve espacio al sistema de ficheros, pero bloquea la tabla por completo, así que solo lo uso en ventana planificada o recurro a una reorganización en línea.

Con tres niveles. El primero, la validación que ofrece la propia herramienta: la verificación de bloques de RMAN, la comprobación de sumas al restaurar en SQL Server o la validación de repositorio de pgBackRest. El segundo, la vigilancia de la cadena: que no falten registros archivados, que el retardo de envío al almacenamiento secundario esté dentro de lo previsto y que las alertas salten cuando un trabajo termina con aviso, no solo cuando falla. Y el tercero, el único concluyente: restaurar de verdad en un servidor de recuperación, arrancar la base de datos, ejecutar consultas de control acordadas con negocio y cronometrar el proceso completo. Esas restauraciones de prueba las planificaba mensualmente por rotación, de forma que cada sistema crítico se recuperaba al menos dos veces al año, y cada prueba terminaba con un acta y una revisión del runbook.

Parto de la carga esperada, no de una regla fija. Estimo el tamaño del conjunto de datos activo, es decir, la porción realmente consultada, y busco que quepa en la caché de datos, porque ahí está el salto de rendimiento. En Oracle reparto entre la SGA y la PGA teniendo en cuenta el número de sesiones concurrentes y las operaciones de ordenación; en SQL Server fijo un máximo de memoria del servidor dejando margen para el sistema operativo; en PostgreSQL configuro shared_buffers, work_mem por operación y effective_cache_size según la memoria total. Para el almacenamiento calculo el volumen inicial, el crecimiento mensual observado, el espacio de registros y archivado, el margen para índices y reorganizaciones y la retención de copias. Después mido: en las semanas siguientes reviso ratios de acierto en caché, esperas de E/S, lecturas físicas y ocupación, y ajusto. Un dimensionado sin medición posterior es una previsión, no un dimensionado.

Lo primero es fijar el reloj: tengo cuatro horas y cincuenta minutos, así que decido en qué momento dejo de intentar reparar y paso a restaurar. Suelo ponerme un límite de una hora para el diagnóstico. Reviso los registros de alerta y el sistema operativo para descartar lo más frecuente: disco lleno, un fichero de control o de registro corrupto, un cambio de permisos tras un parche del sistema. En paralelo aviso al responsable de guardia con un mensaje breve y sin tecnicismos: incidencia en curso, hora estimada de siguiente comunicación y peor escenario contemplado. Si a la hora no tengo una causa clara y una solución en marcha, inicio la restauración según el runbook, que es un camino conocido y cronometrado, en lugar de seguir explorando una hipótesis. Cuando el servicio vuelve, envío una comunicación de cierre y al día siguiente, con el equipo completo, hago el análisis de causa raíz.

No entrego credenciales de administrador, pero tampoco me limito a decir que no, porque el problema del compañero es real. Le ofrezco tres alternativas por orden: acceso de solo lectura sobre las vistas y trazas que necesita, extracción de los datos de diagnóstico por mi parte en el momento, o una sesión conjunta en la que él indica qué mirar y yo ejecuto, con todo registrado. Si el caso exige de verdad un acceso elevado, se tramita como acceso temporal aprobado por el responsable, con caducidad automática y auditoría completa, y se revoca al cerrar la incidencia. Este proceder no es burocracia: la separación de funciones y la trazabilidad de accesos privilegiados es justo lo que se revisa en auditoría de RGPD, y ceder una vez sienta el precedente que hace inútil todo el modelo.

Lo traduzco a riesgo y a coste, que es el idioma en el que se decide. Explico qué se hace en esa ventana (parches de seguridad, reorganizaciones, pruebas de conmutación) y qué ocurre si se deja de hacer: exposición a vulnerabilidades conocidas, degradación progresiva del rendimiento y un plan de continuidad que deja de estar verificado. Después llevo opciones en lugar de una negativa: reducir la ventana aplicando el parcheado por oleadas sobre los nodos del clúster, mover la ventana a la franja de menor facturación con datos de tráfico en la mano, o suprimirla a cambio de una inversión en alta disponibilidad que permita parchear en caliente. Que la decisión la tome negocio con la información completa, y que quede por escrito. En mi experiencia, cuando se presenta así, casi siempre se acaba negociando una ventana más corta y mejor situada, no su desaparición.

Primero verifico si la transacción está confirmada; si sigue abierta, la deshago y se acabó el incidente. Si ya se confirmó, evito el impulso de retroceder toda la base de datos, porque perdería cuarenta minutos de operaciones legítimas del resto de usuarios. Restauro a un entorno auxiliar con recuperación point-in-time a un instante inmediatamente anterior al borrado, extraigo las filas afectadas y las reinserto en producción respetando claves e integridad referencial, coordinado con el responsable funcional para validar el resultado. En Oracle, si la ventana de retención lo permite, la consulta sobre datos históricos me ahorra la restauración completa. Mientras tanto, comunico el alcance real a negocio y registro la incidencia. Y después viene la pregunta incómoda pero necesaria: por qué existía una cuenta con permiso de borrado directo sobre esa tabla en producción, que es la causa real y la que hay que corregir.

Con datos, y sin entrar en la discusión de culpas. Aporto el tiempo consumido dentro del motor para las operaciones señaladas: cuántas ejecuciones, tiempo medio, esperas dominantes y cuánto de ese tiempo es CPU, E/S o bloqueo. Si la base de datos devuelve las respuestas en decenas de milisegundos y el usuario percibe varios segundos, el tiempo se pierde entre medias, y entonces medimos juntos la latencia de red y el comportamiento de la aplicación. Me ha ocurrido el caso opuesto también: la traza mostraba miles de ejecuciones de la misma consulta por pantalla, un patrón de acceso ineficiente del propio programa, y ahí el trabajo era conjunto. Convoco una revisión con ambas partes, con las mediciones sobre la mesa y una franja horaria concreta, porque comparar periodos distintos es la forma más rápida de no llegar a ninguna conclusión.