Migraciones de Bases de Datos en SAP

El Proyecto de Alto Riesgo

Las migraciones de bases de datos son proyectos técnicos críticos que combinan riesgo alto con impacto masivo. Un error puede resultar en días de downtime y pérdida de datos. El dominio de las herramientas y estrategias de migración es obligatorio para un administrador BASIS senior.

Los escenarios típicos:

• Migración Homogénea: Misma base de datos, diferente plataforma OS (ej. Oracle on Windows → Oracle on Linux).
• Migración Heterogénea: Cambio de base de datos (ej. SQL Server → Oracle).
• Migración a HANA: El caso especial. No solo cambio de DB, sino transformación a SAP HANA y opcionalmente upgrade a S/4HANA.

DMO: La Revolución del Downtime

Database Migration Option (DMO) es la herramienta de SAP específica para migraciones a HANA. Su ventaja clave: reducción dramática de downtime.

Arquitectura de DMO

DMO es un componente del Software Update Manager (SUM). Opera en dos fases:

Fase 1: Uptime Migration (Sistema Origen Operativo)

Durante esta fase, el sistema origen (ej. ECC en Oracle) sigue operativo mientras DMO trabaja en background:

• Tabla Shadow: DMO copia las tablas grandes (BSEG, BKPF, etc.) a tablas "shadow" en HANA.
• Delta Detection: Captura cambios en las tablas originales mediante triggers o log mining.
• Sin Impacto a Usuarios: Las operaciones normales continúan.

Esta fase puede durar horas o días dependiendo del tamaño de la base de datos (una DB de 5TB puede tomar 24-48h de uptime migration).

Fase 2: Downtime Migration

Finalmente, el sistema se detiene para la fase final:

• Delta Apply: Aplicar los cambios acumulados durante la fase de uptime a las tablas shadow en HANA.
• Tablas Críticas: Migrar las tablas pequeñas pero muy activas que no se pudieron copiar en uptime (ej. NAST, SDBAH).
• Metadata Conversion: Convertir diccionario ABAP para apuntar a HANA.

Resultado: Un sistema de 5TB que tradicionalmente requería 24-48h de downtime, ahora se migra en 4-8 horas de downtime.

Benchmarking

DMO incluye una función de benchmarking que predice el downtime antes de la migración real:

Execute DMO in benchmark mode:
- Mide velocidad de I/O de discos origen y destino
- Calcula tiempo de export/import de muestra de datos
- Estima downtime total con margen de error ±20%

Siempre ejecutar benchmark en sistema de prueba primero para ajustar expectativas y planificación.

SUM: Migración + Upgrade Combinados

Software Update Manager (SUM) orquesta migraciones combinadas con upgrades técnicos. El caso de uso típico: ECC 6.0 en Oracle → S/4HANA en HANA.

Workflow de SUM

1. Extraction (Preparación): Descarga de software de S/4HANA desde SAP.
2. Configuration: Definir parámetros (tamaño de HANA, parallelization, etc.).
3. Checks (Prerequisitos): Validación de versiones, patches, espacio en disco.
4. Uptime Actions: DMO copia tablas grandes mientras el sistema opera.
5. Downtime Actions:
   • Detener sistema ECC.
   • Completar migración a HANA.
   • Aplicar upgrade técnico a S/4HANA.
   • Ejecutar conversiones de simplificación de datos (Custom Code Adaptation, etc.).
6. Post-Processing: Generación de índices, estadísticas, validación.

Ventanas de Mantenimiento

Para proyectos S/4HANA, la ventana típica es un fin de semana largo (viernes noche a lunes mañana = 60h). SUM permite pausar y reanudar si surgen problemas.

R3load: La Herramienta de Bajo Nivel

R3load es el motor de export/import que todas las herramientas de migración usan internamente. En migraciones heterogéneas sin DMO, R3load se ejecuta manualmente.

Export

Extraer datos del sistema origen a archivos planos:

R3load -i BSEG.STR -export -datacodepage 4103 -l BSEG.log

Genera:
- BSEG.001 (archivo de datos comprimido)
- BSEG.log (log de ejecución)

Import

Cargar datos en el sistema destino:

R3load -i BSEG.STR -import -datacodepage 4103 -l BSEG.log -loadprocedure FAST

Paralelización

La clave para reducir downtime es paralelizar. En lugar de migrar tabla por tabla secuencialmente, ejecutar múltiples procesos R3load simultáneamente:

• Pequeña DB (< 500GB): 8-16 procesos paralelos.
• Mediana DB (500GB-2TB): 32-64 procesos.
• Grande DB (> 2TB): 128+ procesos (limitado por cores disponibles y I/O de storage).

Estrategias de Optimización de Downtime

Table Splitting

Dividir tablas masivas (BSEG con millones de filas) en segmentos para paralelizar el export/import:

-- Dividir BSEG en 10 paquetes por rango de BUKRS
Package 1: BUKRS 0001-1000
Package 2: BUKRS 1001-2000
...

Pre-Migration de Datos Históricos

Mover datos antiguos (> 5 años) a una DB separada o archivar antes de la migración principal. Esto reduce el volumen total a migrar.

Replicación Continua (SLT)

Para downtime cercano a cero, usar SAP Landscape Transformation (SLT):

• SLT replica continuamente cambios de la DB origen a HANA destino mediante triggers.
• El sistema origen sigue operativo durante días/semanas de replicación inicial.
• Cuando los dos sistemas están sincronizados, se ejecuta un cutover rápido (15-30 min de downtime real).

SLT es complejo de configurar y requiere recursos adicionales, pero es la única opción para sistemas 24/7 que no pueden tolerar downtime de horas.

Validación Post-Migración

NUNCA declarar una migración exitosa sin validación exhaustiva:

Checklist Técnico

• Count de Registros: Comparar row counts de todas las tablas (origen vs destino). Debe coincidir exactamente.
• Checksums: Verificar checksums de tablas críticas (BSEG, BKPF, EKPO).
• Índices y Estadísticas: Regenerar todos los índices y actualizar estadísticas del optimizer.
• Jobs Batch: Ejecutar jobs críticos (cierre contable, interfaces nocturnas) en entorno de test.

Validación Funcional

El equipo de negocio debe validar procesos core:

• Creación de orden de compra.
• Posting contable.
• Ejecución de reportes financieros.
• Interfaces con sistemas externos.

Preparar un script de validación con transacciones específicas a ejecutar y resultados esperados.

Rollback: El Plan B

Siempre tener un plan de rollback. Si la migración falla críticamente:

Opción 1: Restaurar Backup del Sistema Origen

Si se tomó un backup completo antes de la migración:

• Restaurar la base de datos origen.
• Reiniciar el sistema SAP.
• Perder cualquier transacción ejecutada durante la migración (generalmente aceptable si había downtime programado).

Opción 2: Sistema Paralelo

Para migraciones críticas, mantener el sistema origen intacto en paralelo durante 1-2 semanas post-migración. Si hay problemas en el nuevo sistema, se puede volver al antiguo.

Tiempo de Decisión

Definir un Go/No-Go Decision Point. Ejemplo: "Si a las 6 AM del sábado la migración no ha completado al menos 80%, ejecutamos rollback". No esperar hasta el último minuto de la ventana de mantenimiento.

Lecciones Aprendidas de Migraciones Reales

Caso 1: Subestimación de Downtime

Problema: Proyecto estimó 12h de downtime basándose en velocidades de I/O teóricas. En producción, la migración tardó 36h.

Causa: No se consideró la contention de I/O con otros sistemas en la misma SAN.

Lección: Siempre hacer benchmark en el entorno REAL de producción, no en laboratorio.

Caso 2: Falta de Testing de Interfaces

Problema: Migración técnica exitosa, pero las interfaces EDI con proveedores fallaron.

Causa: Los destinos RFC cambiaron después de la migración y no se actualizaron en SM59.

Lección: Incluir testing de interfaces externas en el plan de validación.

Caso 3: Custom Code No Optimizado para HANA

Problema: Post-migración a HANA, ciertos programas Z eran 10x MÁS LENTOS que en Oracle.

Causa: Código ABAP con bucles anidados y SELECT dentro de LOOP. Oracle perdona esto con buffering; HANA no.

Lección: Ejecutar herramienta de análisis de Custom Code (ATC - ABAP Test Cockpit) ANTES de la migración y remediar code smells críticos.

Páginas relacionadas

Volver a Bases de Datos SAP

SAP HANA (Destino típico de migraciones modernas)

Oracle / SQL Server / DB2 (Orígenes comunes de migración)