Introducción a dumps y errores
Los dumps ABAP (también llamados short dumps o runtime errors) son terminaciones anormales de programas ABAP que ocurren cuando el sistema detecta una condición de error que no puede manejar. Estos errores interrumpen las transacciones de usuarios, pueden indicar bugs en código custom o estándar, problemas de configuración, o limitaciones de recursos del sistema.
El análisis efectivo de dumps es una habilidad crítica para SAP BASIS. Aunque algunos dumps requieren intervención de desarrolladores ABAP, muchos tienen causas técnicas que BASIS puede diagnosticar y resolver: problemas de memoria, autorizaciones faltantes, configuración incorrecta, o limitaciones de recursos.
Transacción ST22 - ABAP Runtime Errors
ST22 es la transacción principal para análisis de dumps ABAP. Proporciona acceso a todos los runtime errors que han ocurrido en el sistema, con información detallada sobre cada dump que facilita el diagnóstico de la causa raíz.
La pantalla inicial de ST22 muestra dumps recientes, típicamente las últimas 24 horas por defecto. Cada entrada lista el nombre del error, cuándo ocurrió, qué usuario lo experimentó, y en qué programa sucedió.
Al seleccionar un dump específico, ST22 presenta un análisis detallado con múltiples secciones de información. Esta información debe leerse metódicamente para entender qué causó el problema.
Anatomía de un dump ABAP
El error name identifica el tipo específico de runtime error. Nombres como STORAGE_PARAMETERS_WRONG_SET, TSV_TNEW_PAGE_ALLOC_FAILED, o TIME_OUT indican inmediatamente la categoría del problema.
El what happened section proporciona descripción del error en lenguaje comprensible. Explica qué condición causó la terminación anormal y frecuentemente sugiere direcciones para investigación.
La información del usuario y transacción identifica quién experimentó el error y qué estaban haciendo. Esto es crítico para reproducir el problema y entender el contexto de negocio.
El source code excerpt muestra las líneas de código ABAP donde ocurrió el error. Aunque BASIS no necesariamente modificará el código, esta información ayuda a entender qué operación específica falló.
El call stack (pila de llamadas) muestra la secuencia de programas y módulos de función que se llamaron hasta llegar al punto del error. Esto es invaluable para entender el flujo de ejecución y identificar si el problema está en código custom o estándar.
La sección de variables muestra valores de variables ABAP en el momento del error. Frecuentemente revela datos inesperados o nulos que causaron el problema.
Tipos comunes de dumps
Los dumps de memoria (STORAGE_PARAMETERS_WRONG_SET, TSV_TNEW_PAGE_ALLOC_FAILED) indican que un programa intentó alocar más memoria de la disponible. Pueden deberse a parámetros de memoria insuficientes, programas ineficientes que consumen memoria excesiva, o datos de entrada inesperadamente grandes.
Los TIME_OUT dumps ocurren cuando un programa ejecuta demasiado tiempo. SAP tiene límites configurables para prevenir que programas bloqueados consuman recursos indefinidamente. Pueden indicar código ineficiente, queries SQL lentas, o simplemente que el timeout está configurado demasiado bajo para operaciones legítimas pesadas.
Los dumps de autorización (AUTHORITY_CHECK_FAILED) ocurren cuando código intenta operaciones para las que el usuario no tiene permisos. Aunque parecen problemas de seguridad, frecuentemente son configuración incorrecta de roles o bugs donde código verifica autorizaciones que no debería verificar.
Los DBIF_* dumps indican problemas de base de datos: queries inválidas, tablas no existentes, errores de conexión con base de datos, o violaciones de integridad referencial. Requieren investigación tanto de lado SAP como de lado base de datos.
Los dumps de tabla interna (ITAB_*) ocurren cuando código ABAP manipula tablas internas incorrectamente: acceder índices inexistentes, intentar leer tablas vacías, o superar límites de tamaño de tabla.
Los RAISE_EXCEPTION dumps son manejadores de excepciones no capturados. El código lanzó una excepción pero no había manejador para procesarla, causando terminación del programa.
Proceso de análisis de dumps
El primer paso es leer cuidadosamente el mensaje de error. El what happened frecuentemente indica directamente el problema y su solución. No saltes inmediatamente al código sin entender qué dice el mensaje.
Identifica si el dump es aislado o recurrente. Un dump único puede ser anomalía causada por entrada inusual de usuario. Dumps repetidos del mismo tipo indican problema sistemático que requiere corrección.
Verifica si el error está en código custom (nombres comienzan con Z o Y) o estándar SAP. Código custom puede modificarse localmente si el equipo de desarrollo identifica el bug. Errores en código estándar requieren notas SAP o parches.
Busca el dump en SAP Notes. SAP documenta bugs conocidos y sus soluciones en notes. La búsqueda por el nombre exacto del error más keywords del contexto frecuentemente encuentra notes relevantes.
Revisa si hay cambios recientes relacionados. Si dumps comenzaron después de un transporte específico, ese transporte probablemente introdujo el bug. Si comenzaron tras ajuste de parámetros, el cambio de configuración puede ser la causa.
Intenta reproducir el error en un entorno no productivo. Si puedes reproducir el dump consistentemente, es mucho más fácil diagnosticar la causa raíz y validar que la corrección funciona.
Resolución de problemas técnicos
Los problemas de memoria frecuentemente se resuelven ajustando parámetros de perfil. Si dumps de STORAGE_PARAMETERS ocurren consistentemente, incrementar em/initial_size_MB o abap/heap_area_dia puede resolverlos. Sin embargo, también investiga si hay programas ineficientes que deberían optimizarse en lugar de solo aumentar memoria.
Los timeouts pueden requerir ajustar rdisp/max_wprun_time si las operaciones legítimas necesitan más tiempo. Sin embargo, primero verifica que no haya problemas de performance subyacentes que estén causando ejecuciones lentas.
Los problemas de autorización requieren coordinación con el equipo de seguridad para añadir las autorizaciones necesarias a los roles de usuario. La transacción SU53 muestra el último error de autorización del usuario, facilitando identificar exactamente qué objeto de autorización falta.
Los errores de base de datos pueden requerir reconstruir índices, actualizar estadísticas, o investigar problemas de performance a nivel de base de datos. BASIS debe coordinar con administradores de base de datos para estas investigaciones.
Coordinación con desarrollo
Cuando dumps indican bugs en código custom, BASIS debe escalar a desarrollo proporcionando toda la información relevante: el dump completo de ST22, steps para reproducir el problema, impacto en usuarios de negocio, y urgencia de la corrección.
Los desarrolladores pueden necesitar acceso al sistema donde ocurrió el dump para analizar el contexto completo. BASIS facilita este acceso mientras garantiza que la investigación no impacta operaciones normales.
Una vez desarrolladores crean correcciones, BASIS coordina el testing en QAS y la promoción a producción mediante el proceso normal de transportes y change management.
Transacción SM21 - System Log
SM21 muestra el log del sistema SAP que registra eventos importantes del sistema: arranques y paradas, errores de configuración, problemas de comunicación, cambios de parámetros, y otros eventos operativos significativos.
Mientras ST22 se enfoca en dumps ABAP específicos, SM21 proporciona contexto más amplio de lo que estaba ocurriendo en el sistema. Frecuentemente, revisando SM21 alrededor del tiempo de un dump revela información adicional sobre condiciones del sistema que contribuyeron al problema.
Los mensajes en SM21 tienen códigos de severidad: errores requieren atención inmediata, warnings deben investigarse pero no son críticos, y mensajes informativos documentan operaciones normales.
Análisis de errores en SM21
Los errores de conectividad de base de datos en SM21 indican problemas de comunicación entre SAP y la base de datos. Pueden ser transitorios (red inestable) o indicar problemas serios de la base de datos que requieren intervención inmediata.
Los errores de RFC failed indican que comunicaciones con sistemas remotos fallaron. SM21 muestra qué sistema remoto estaba involucrado, facilitando determinar si el problema es local o en el sistema remoto.
Los errores de update task indican que actualizaciones asíncronas de base de datos fallaron. Estos son serios porque significan que datos que usuarios creen que guardaron pueden no haberse persistido correctamente.
Los messages sobre work processes que crashed indican inestabilidad del sistema. Work processes no deberían crashear en sistemas estables. Crashes repetidos sugieren problemas de memoria, bugs en kernel SAP, o incompatibilidades entre componentes.
Filtrado y búsqueda en SM21
SM21 puede contener millones de entradas. Los filtros son esenciales para encontrar información relevante. Puede filtrarse por: rango de fechas/horas, severidad de mensaje, usuario, transacción, tipo de problema, y texto libre.
Para investigar un problema específico, combina múltiples filtros. Por ejemplo, para investigar por qué usuario X experimentó un error a las 10:35 AM, filtra por ese usuario y ventana de tiempo de 10:30-10:40.
El modo de lectura experto (Expert Mode) en SM21 proporciona filtros adicionales y opciones de display más técnicas. Útil para análisis profundo pero puede ser abrumador para revisiones rutinarias.
Logs adicionales de troubleshooting
Los dev_* files en el directorio de trabajo de cada instancia SAP contienen logs técnicos detallados de todos los work processes. Cuando ST22 y SM21 no proporcionan suficiente información, estos logs de bajo nivel frecuentemente contienen el detalle necesario.
El syslog del sistema operativo (/var/log/messages en Linux, Event Viewer en Windows) puede contener información sobre problemas de hardware, problemas del kernel del sistema operativo, o errores de red que impactan SAP pero que SAP mismo no detecta directamente.
Los logs de base de datos (alert.log en Oracle, error log en SQL Server, trace files en HANA) documentan eventos específicos de base de datos que pueden explicar dumps DBIF_* o problemas de performance.
Dumps en sistemas productivos
Los dumps en producción requieren respuesta más urgente que en desarrollo o QAS porque impactan usuarios de negocio reales. BASIS debe tener proceso claro de escalado para dumps críticos que afectan transacciones de negocio importantes.
Los workarounds temporales pueden ser necesarios mientras se desarrolla corrección permanente. Por ejemplo, si un reporte específico causa dumps consistentemente, puede deshabilitarse temporalmente hasta que se corrija el código.
La comunicación a usuarios afectados es importante. Si un dump previene completar una transacción crítica (como aprobar una orden de compra urgente), BASIS debe coordinar con negocio para encontrar alternativas temporales.
Análisis de tendencias
La revisión periódica de dumps permite identificar tendencias. Si cierto tipo de dump ocurre cada vez más frecuentemente, indica problema que se está agravando y requiere atención proactiva antes de causar interrupción mayor.
Los reportes de dumps por programa, usuario, o tipo de error identifican hotspots que requieren optimización. Si un programa custom causa 80% de todos los dumps, claramente necesita refactoring.
El análisis histórico de dumps es valioso durante upgrades. Comparar tipos y frecuencia de dumps antes y después del upgrade identifica regresiones introducidas por la nueva versión.
Prevención de dumps
El code review de desarrollos custom antes de promoción a producción detecta código propenso a dumps: falta de manejo de excepciones, accesos a tablas sin verificar que están pobladas, queries SQL sin límites de resultados.
El testing exhaustivo en QAS con datos realistas (por eso la importancia de refrescar QAS regularmente desde producción) detecta problemas antes de que lleguen a producción.
La monitorización proactiva de recursos previene dumps de memoria y timeout identificando condiciones que eventualmente causarían problemas y corrigiéndolas preventivamente.
Las SAP Notes aplicadas proactivamente corrigen bugs conocidos antes de que los usuarios los experimenten. BASIS debe revisar regularmente notas relevantes para el sistema y aplicar correcciones preventivamente.
Documentación de dumps
Cada dump significativo debe documentarse: cuándo ocurrió, qué lo causó, cómo se diagnosticó, qué acción correctiva se tomó, y si hay medidas preventivas para evitar recurrencia.
Esta documentación construye base de conocimiento del equipo. La próxima vez que ocurra dump similar, la resolución previa proporciona punto de partida para investigación acelerando el troubleshooting.
Los patrones de resolución comunes pueden formalizarse en runbooks: "Para dumps STORAGE_PARAMETERS, verificar estos parámetros, revisar estos programas, considerar estas soluciones". Esto permite que miembros junior del equipo resuelvan problemas efectivamente.
Herramientas de debugging
El debugger ABAP (transacción /h) permite a desarrolladores ejecutar código paso a paso inspeccionando valores de variables. Aunque principalmente herramienta de desarrollo, BASIS ocasionalmente necesita usar debugging para entender comportamiento de transacciones estándar.
La transacción ST05 (SQL Trace) registra todas las operaciones de base de datos ejecutadas durante una transacción. Invaluable para diagnosticar dumps relacionados con base de datos o problemas de performance de queries específicas.
La transacción ST12 (ABAP Trace) proporciona profiling completo de ejecución de programas: tiempo en base de datos, tiempo de CPU, llamadas RFC, todo detallado. Útil para optimización de performance y entender qué operaciones consumen más tiempo.
Dumps relacionados con customizing
Algunos dumps no son bugs de código sino errores de configuración. Por ejemplo, dumps que ocurren porque una tabla de customizing no tiene entrada para cierta combinación de valores. La solución no es cambiar código sino completar la configuración faltante.
BASIS debe coordinar con consultores funcionales para corregir estos problemas de configuración. Los consultores entienden la lógica de negocio y pueden configurar correctamente, mientras BASIS proporciona el análisis técnico identificando qué configuración falta.
Consideraciones de performance
Los dumps antiguos se archivan automáticamente por SAP después de cierto periodo. Sin embargo, la tabla que almacena dumps puede crecer significativamente en sistemas con muchos dumps. Debe monitorizarse y archivarse manualmente si crece excesivamente.
El análisis frecuente de ST22 y SM21 no debe impactar performance del sistema. Sin embargo, búsquedas muy amplias (por ejemplo, todos los dumps de los últimos 6 meses sin filtros) pueden consumir recursos significativos.
Temas relacionados
Para profundizar en análisis de dumps y troubleshooting, consulta:
Monitorización del sistema para detección proactiva de condiciones que pueden causar dumps.
Parametrización para ajustar límites de memoria y timeouts relacionados con dumps comunes.
Gestión de usuarios para resolver dumps de autorización.
Transportes para promoción de correcciones de código que resuelven dumps.
Tareas diarias BASIS para la revisión rutinaria de dumps como parte de operaciones.