Problema

Los sistemas de base de datos trabajaban con información aeronáutica en tiempo real. Para investigar incidencias sin interferir en esos entornos, se solicitaron a Sistemas dumps de los esquemas implicados y se planteó reproducirlos localmente.

Instalar Oracle de forma tradicional, resolver sus requisitos y licencias y montar cada conjunto de dumps manualmente tenía un coste elevado cada vez que aparecía un nuevo análisis. La solución fue preparar un entorno basado en contenedores capaz de levantar una base Oracle e importar automáticamente todos los esquemas entregados para cada caso. El diseño no estaba limitado a tres: el número de dumps debía poder variar según la investigación.

La solución tenía que ser transportable, verificable y segura frente a errores operativos comunes:

  • Imagen inexistente en el servidor.
  • TAR corrupto o incompleto.
  • Carpeta vacía, dumps corruptos o un conjunto incompleto.
  • Dos dumps pertenecientes al mismo esquema.
  • Reejecución accidental de una importación ya completada.
  • Diferencias entre PowerShell de Windows y Bash antiguo dentro de la imagen.
  • Dificultad para encontrar las tablas importadas en SQL Developer.

Decisión de entrega: copia independiente

Se creó una carpeta nueva con el proyecto completo y se dejó intacto el proyecto original. Esta decisión permitía:

  • Preparar una distribución específica para el servidor offline.
  • Evitar introducir cambios experimentales en el entorno fuente.
  • Incluir la imagen y documentación sin contaminar el proyecto original.
  • Validar el paquete como una unidad autónoma.

Exportación de la imagen

Se confirmó previamente la identidad de la imagen local: plataforma Linux amd64, etiqueta esperada e ID de imagen.

Después se exportó a un TAR de aproximadamente 8,6 GB. Junto al TAR se generó un archivo SHA-256.

La verificación no era un detalle accesorio. En una transferencia offline, un archivo truncado puede llegar al servidor sin que exista un registry contra el que comparar. El hash permitía comprobar integridad antes de invertir tiempo en cargar o arrancar la imagen.

Docker Compose sin acceso externo

La configuración utilizó pull_policy: never. Con ello se evitaba que Docker intentara contactar con el registro y se convertía la presencia de la imagen local en una precondición explícita.

El flujo de arranque era:

text
start.ps1
   |
   +-- verificar SHA-256 del TAR
   |
   +-- comprobar si la imagen existe
   |       |
   |       +-- no existe -> docker image load
   |
   +-- docker compose up
   |
   +-- esperar inicialización e importaciones
   |
   +-- health check final

El script ofrecía además -ResetDatabase para una reconstrucción deliberada. Esta operación debía ser explícita porque implicaba eliminar el estado persistente de la base.

Diseño del importador

El importador aplicó varios controles antes de ejecutar impdp:

1. Comprobar que existía al menos un archivo .dmp y construir el inventario de entrada.
2. Inspeccionar cada dump mediante impdp ... sqlfile=... include=user.
3. Detectar el usuario o esquema contenido.
4. Verificar que no hubiera esquemas duplicados y que cada dump pudiera asociarse a un propietario.
5. Crear o preparar los usuarios necesarios.
6. Importar cada dump con logs separados.
7. Calcular y persistir un SHA-256 por dump importado.
8. Evitar repetir una importación idéntica en reinicios posteriores.

El uso de marcadores persistentes convertía el proceso en reiniciable. Un reinicio del contenedor no debía volver a cargar decenas de gigabytes ni duplicar objetos.

Integración del estado de importación con el health check

El servicio solo debía considerarse saludable cuando Oracle estuviera disponible y las importaciones hubieran terminado correctamente.

Esto evitaba un falso positivo frecuente: que el puerto 1521 respondiera mientras los esquemas aún no estaban listos. El estado técnico del proceso se alineó con el estado funcional esperado por el usuario.

Incidente 1: operaciones de 8,6 GB y timeouts

La exportación y una prueba posterior de carga superaron el timeout de la herramienta, pero los procesos continuaron ejecutándose y terminaron correctamente.

Repetir el comando habría duplicado trabajo, consumido almacenamiento y dificultado saber qué proceso era el válido. La decisión fue inspeccionar primero:

  • Si el proceso Docker seguía activo.
  • Si el archivo seguía aumentando de tamaño.
  • Si la operación había terminado en segundo plano.
  • Si el hash final era correcto.
El aprendizaje fue adaptar los timeouts al tamaño real y no confundir el timeout del cliente con el fracaso del proceso subyacente.

Incidente 2: incompatibilidad con Bash antiguo

La imagen incluía una versión antigua de Bash que no aceptaba mapfile -d. El script era válido en un entorno moderno, pero no en el runtime real.

Se sustituyó por mapfile -t combinado con find ... -print | sort. Además, se cambió el enfoque de validación: los scripts Bash debían probarse dentro de la imagen, no únicamente desde Windows o desde un Bash diferente.

Este incidente demuestra por qué la compatibilidad debe validarse en el entorno de ejecución final.

Validaciones realizadas

Se comprobaron:

  • Configuración de Docker Compose.
  • Sintaxis PowerShell.
  • Sintaxis Bash dentro de la imagen.
  • Estructura OCI del TAR.
  • Hash SHA-256 del archivo.
  • Preservación de la etiqueta esperada.
  • Comportamiento cuando no había dumps.
  • Rechazo explícito de una carpeta vacía o de dumps que no pudieran identificarse de forma segura.
La validación sin dumps produjo el error esperado y confirmó que la protección se ejecutaba antes de iniciar una importación inválida.

Diagnóstico posterior en SQL Developer

Cuando las tablas no aparecieron en la interfaz, se evitó asumir inmediatamente que habían desaparecido o que la importación había fallado.

Oracle diferencia entre el contenedor raíz y las pluggable databases. La conexión debía usar el servicio ORCLPDB1 en el puerto 1521, no tratar ORCLCDB como el SID de trabajo.

El procedimiento de diagnóstico propuesto fue:

1. Comprobar el contenedor actual con SYS_CONTEXT('USERENV','CON_NAME').
2. Confirmar que el resultado era ORCLPDB1.
3. Refrescar Other Users/Otros usuarios en SQL Developer.
4. Buscar los objetos bajo el propietario real del esquema, no bajo SYSTEM.
5. Consultar DBA_TABLES y DBA_OBJECTS por propietario.
6. Diferenciar entre problema visual, permisos, PDB incorrecta e importación parcial.

Sin los resultados SQL del servidor no se declaró una causa final.

Alternativas descartadas

Descargar la imagen desde el servidor

Descartada porque el servidor no tenía acceso al registro externo.

Usar siempre latest sin verificar contenido

Descartada como mecanismo de confianza. Se conservaron etiqueta, ID y hash del TAR.

Limitar el importador a un número fijo de dumps

Descartada. El objetivo era reutilizar la herramienta en investigaciones diferentes, por lo que el importador debía recorrer el conjunto recibido y aplicar las mismas comprobaciones a cada esquema.

Considerar saludable el servicio al abrir el puerto

Descartada porque la disponibilidad de Oracle no garantizaba que la importación hubiera finalizado.

Repetir automáticamente todos los imports al reiniciar

Descartada por coste, riesgo de duplicidad y falta de idempotencia.

Resultado real

El paquete offline, la imagen, los hashes, scripts, protecciones y configuración quedaron validados estructuralmente. La arquitectura quedó preparada para importar tantos esquemas como incluyera el conjunto de dumps, manteniendo un log y un marcador por archivo. La validación integral con datos reales siguió siendo parcial, por lo que el proyecto se presenta como un entorno reutilizable preparado y validado estructuralmente, no como una migración productiva completada.

El diagnóstico de SQL Developer quedó igualmente pendiente de los resultados del servidor real.