Microsoft SQL Server en SAP

La Plataforma Microsoft-Native

Microsoft SQL Server es la elección natural para organizaciones con infraestructura Windows/Microsoft consolidada. Su integración con Active Directory, familiaridad para equipos IT Microsoft, y modelo de licenciamiento (a veces más favorable que Oracle) la hacen atractiva para empresas medianas.

Aunque SAP HANA es el futuro, SQL Server sigue siendo plataforma sólida para sistemas ECC/ERP que no planean migrar a S/4HANA a corto plazo.

Always On Availability Groups: HA Moderna

Always On Availability Groups es la respuesta de Microsoft a Oracle RAC. La diferencia clave: en lugar de shared storage, Always On replica bases de datos entre nodos independientes.

Arquitectura

• Primary Replica: Nodo activo que procesa todas las transacciones read/write.
• Secondary Replicas: Hasta 8 nodos secundarios que reciben cambios vía log shipping. Se pueden configurar para:
  • Read-Only Queries: Liberar carga del primario (reporting en tiempo real).
  • Backups: Ejecutar backups desde secundario sin impactar producción.
• Listener: VIP (Virtual IP) que siempre apunta al nodo primario actual. Los clientes SAP se conectan al listener, no a servidores específicos.

Modos de Sincronización

• Synchronous Commit: El primario espera confirmación del secundario antes de confirmar la transacción. Garantiza RPO=0 (cero pérdida de datos) pero añade latencia (~2-5ms). Usar solo cuando primario y secundario están en la misma ubicación física.
• Asynchronous Commit: El primario NO espera. Latencia cero pero posible pérdida de datos en failover. Usar para DR (Disaster Recovery) a larga distancia.

Failover Automático

Cuando el primario cae, el cluster (WSFC - Windows Server Failover Clustering) detecta la falta de heartbeat y promueve automáticamente un secundario a primario. Tiempo típico: 15-30 segundos.

El listener actualiza automáticamente su DNS para apuntar al nuevo primario. Las aplicaciones SAP reconectan sin necesidad de cambiar configuración.

Administración con Transacciones SAP

DB02: Monitorización de Espacio

Funciona igual que en Oracle. Muestra:

• Database Size: Tamaño de archivos .mdf y .ndf.
• Log Size: Tamaño del transaction log (.ldf). Crítico: si el log se llena, el sistema se detiene.
• Free Space: Espacio disponible en cada filegroup.

ST04: Performance Analysis

Métricas clave para SQL Server:

• Buffer Cache Hit Ratio: Debe estar >95%. Si es bajo, aumentar la RAM asignada a SQL Server.
• Page Life Expectancy: Tiempo promedio que una página permanece en cache. Debe ser >300s. Si es menor, indica memory pressure.
• Lock Waits: Alto indica contention. Revisar queries que bloquean.

DBACOCKPIT: Cockpit Unificado

SAP proporciona DBACOCKPIT como interfaz gráfica para administración SQL Server desde dentro de SAP. Permite:

• Ejecutar queries SQL.
• Ver planes de ejecución.
• Monitorizar jobs y backups.
• Configurar alertas.

tempdb: La Base de Datos Crítica

tempdb es una base de datos especial de SQL Server que almacena objetos temporales (tablas temporales, variables de tabla, resultados intermedios de queries). En SAP, su configuración es crítica para performance.

Mejores Prácticas

• Múltiples Data Files: Crear 1 data file por cada 4 cores lógicos (máximo 8). Esto reduce contention de allocation pages (PFS/SGAM). Todos los files deben tener tamaño idéntico.
• Ubicación en Disco Rápido: tempdb debe estar en SSD, separado de las bases de datos de usuario.
• Tamaño Pre-Configurado: No dejar que tempdb crezca automáticamente durante operaciones. Pre-dimensionar a tamaño suficiente (ej. 50GB) para evitar auto-growth costoso.
• Instant File Initialization: Habilitar en el servicio SQL Server para que file grow no inicialice bloques a cero (ahorra segundos críticos).

Monitorización

Verificar uso de tempdb:

SELECT 
    SUM(unallocated_extent_page_count) AS free_pages,
    SUM(user_object_reserved_page_count) AS user_objects
FROM sys.dm_db_file_space_usage;

Índices y Tuning

Índices Columnstore

SQL Server 2016+ soporta Columnstore Indexes que almacenan datos por columna (similar a SAP HANA). En SAP, se pueden agregar a tablas grandes para mejorar queries analíticas sin afectar OLTP.

Ejemplo: Añadir columnstore index a tabla BSEG (documentos contables) para acelerar reportes financieros sin impactar postings.

Index Maintenance

La fragmentación es el enemigo. Crear job de mantenimiento que ejecute semanalmente:

-- Rebuild si fragmentación > 30%
-- Reorganize si fragmentación 10-30%
ALTER INDEX ALL ON [tabla] REBUILD WITH (ONLINE = ON);

Usar ONLINE = ON para evitar bloquear la tabla durante rebuild (Enterprise Edition requerida).

Backups y Recovery

Estrategia Recomendada

• Full Backup: Domingo noche (ventana de mantenimiento).
• Differential Backup: Lunes-Sábado noche (más rápido que full).
• Transaction Log Backup: Cada 15-30 minutos. Esto garantiza RPO < 30 min.

Compresión de Backups

SQL Server 2008+ soporta backup compression nativo. Ahorra 50-70% de espacio y reduce I/O:

BACKUP DATABASE [SAP_PROD] 
TO DISK = 'E:\Backups\SAP_PROD.bak'
WITH COMPRESSION, CHECKSUM;

Verificación de Backups

NUNCA confíes en un backup sin verificarlo:

RESTORE VERIFYONLY FROM DISK = 'E:\Backups\SAP_PROD.bak';

Integración con Active Directory

Una ventaja única de SQL Server: autenticación integrada con Windows/AD.

• Los usuarios SAP pueden usar sus credenciales de dominio para conectarse a la base de datos.
• No se requiere gestionar passwords separados.
• Grupos de AD pueden mapearse a roles SQL Server (gestión centralizada).

En la práctica, SAP usa cuentas de servicio dedicadas (ej. DOMAIN\sap_service) con permisos específicos, no usuarios finales individuales.

Troubleshooting Común

Problema: "Transaction log full"

Síntoma: Mensajes de error 9002. El sistema se detiene.

Causa: El log no se ha truncado porque:

• No hay backups de transaction log configurados.
• Hay una transacción vieja no commiteada bloqueando el truncate.

Solución Inmediata:

BACKUP LOG [SAP_PROD] TO DISK = 'NUL';  -- Trunca el log sin backup real

Solución Permanente: Configurar backups de transaction log cada 15-30 min.

Problema: "Queries lentas tras upgrade"

Causa: Estadísticas desactualizadas o plan cache corrupto tras migración de versión SQL Server.

Solución:

-- Limpiar plan cache
DBCC FREEPROCCACHE;

-- Actualizar estadísticas
EXEC sp_updatestats;

Problema: "Failover automático no funciona"

Diagnóstico:

• Verificar que el secondary está en modo Synchronous Commit (Asynchronous no permite failover automático).
• Verificar que WSFC (Windows Failover Cluster) está configurado correctamente.
• Revisar Event Viewer de Windows en ambos nodos para errores de cluster.

Páginas relacionadas

Volver a Bases de Datos SAP

Oracle Database

SAP Sybase ASE