¿Sabe cuáles son las causas más comunes del porque un sistema SAP se congela o en su defecto se bloquea?

El problema inicia con el sorprendente, en la mayoría de los casos, aumento de llamadas que arriban a la mesa de ayuda, sumado al mensaje que con ahínco se escucha en los pasillos de la organización en donde el autor es el usuario final, esgrimiendo “No hay SAP” o “SAP no funciona”, siempre lo ponen en un contexto en el que empiezan a prenderse las alarmas para el área de TI. No obstante, no se hace esperar de parte de nosotros la pregunta que nos asalta y taladra en el interior ¿“Y ahora qué pasó? Si toda venia funcionando bien.

Todo ese volumen de información que se encuentra en transitó y arribando al área de TI, puede ponerte en una situación que cuando te das cuentas estas en una encrucijada, en donde te ves envuelto en medio de 2 fuerzas que no dan tregua,  la una que ejerce presión desde arriba  (jefes y directivas) y la otra que empuja desde abajo (los usuarios finales), tratando de acorralarte y esperando una respuesta concreta, sin dar tregua y muchas veces magnificando el problema. Todo lo anterior en verdad empieza a tornarse oscuro, ya que además de que son elementos que no aportan a la solución, si son, son el detonante que enciende la mecha para que el estrés empiece hacer su aparición. Si estas o has llegado a experimentar esa sensación, solo me queda por decirle, que lo primero que debes hacer es simplemente escuchar y estar tranquilo, conservando la calma, solo desde ese punto de vista puedes atacar e identificar el problema con rapidez y exactitud. En cambio, si te dejas afectar por la situación y el estrés empieza hacer de las suyas, con toda seguridad tu mente no tendrá la claridad para ir en busca de la solución y lo único que conseguirá será además de retrasarla a solución, sumarle tiempo a la indisponibilidad, variable que afecta fuertemente a los acuerdos de nivel de servicio.

Para resolver la dificultad te expondré el camino o la ruta más corta para resolverlo y para ello debes tener como insumo mínimo, el mapa de tu infraestructura claro y visualizado en tu mente (esto debido a que el problema puede estar o se puede encontrar desde la capa física hasta la capa de aplicación).

Acto seguido, es que con el volumen de información que llegó, debes clasificar la información que recibiste, con el fin de entrar en el área de descartes. De esa forma empezaras a localizar el problema, para ello te detallo un pool de preguntas que debes chulear para ir identificando la causa, en orden de prioridad.

• Analiza de donde viene el problema, de que áreas de la organización vienen las quejas, ¿de todas las áreas (LAN, MAN, WAN)?

• Analiza tu infraestructura de SAP, ¿puedes llegar a tus servidores SAP, a nivel de sistema operativo?

• Chequea el acceso a SAP, ¿te responde el servicio?

Con estos tres puntos ya deberías tener definido en donde está el origen del problema. Analicemos cada una.

Si la respuesta es negativa para la pregunta 1, ya descartas que sea un problema de comunicación en la red y vas aislando el problema. No obstante, puedes encontrarte que el problema este en algunas áreas de la red WAN, para lo cual puede que tengas algún inconveniente de comunicación, que tu equipo de redes debe resolver. En caso de que la respuesta sea afirmativa, ya puedes integrar a tu equipo de red, para que haga las revisiones correspondientes, mientras en paralelo vas chequeando tu estado de SAP, mirando rápidamente que los work process estén disponibles en la SM50, que los tiempos de respuesta sean aceptables en la smlg y que no veas un mensaje raro en los últimos 20 minutos tanto en la sm21 como en la st22, por las dudas. De esta forma confirmas que el problema se encuentra en la infraestructura de red. Ahora suele presentarse que el problema no puede estar en la red, sino que solo aun grupo de usuarios. Aquí el problema lo pasas o los deja en los puntos de red de esos equipos, en donde el equipo de telecomunicación debe validar lo que ocurre.

Pero si la respuesta es afirmativa, para la primera pregunta y afirmativa para la segunda pregunta, en este punto la hipótesis es que el inconveniente puede estar en algún dispositivo de red que soporta tus servidores de SAP o puede estar fallando o haya dejado de funcionar. También suele suceder, y sí que me encontrado con muchas situaciones de esa naturaleza, que sea por una ruta que temporalmente se haya configurado y se haya perdido. Este tipo de comportamiento en el caso de que sea una ruta de red se presenta debido a que estas rutas se crean para resolver un inconveniente, pero se comete el error de dejarse temporalmente y viene a desencadenar cuando el dispositivo de red se reinicia por algún fallo o cuando se va la energía, pues suben y como no tenían esa ruta aprendida simplemente no la suben, teniendo como consecuencia la indisponibilidad de un servicio tan crítico como es el de SAP. Recuerden que en tecnología “Lo temporal se vuelve permanente”

Para confirmar que solo sea la infraestructura de red, intenta llegar a tus servidores de SAP por sistema operativo, si los alcanzas y observas que los sistemas SAP están arriba, ya tienes un diagnostico concreto.

Ahora, puede que no sea tu infraestructura de red, sino que efectivamente SAP este fallando, antes de confirmarlo, chequea que puedes llegar a todos los servidores de SAP, si lograste acceder, ya debes descartar tu infraestructura de red y enfocarte en tu servidor de SAP.  

Para ello a continuación te detallo las posibles razones que lo originan.

   

  1. Indisponibilidad de work process: Cuando una instancia se congela o bloquea el procesamiento, una de las posibles causas es debido a que no tiene y dependiendo de la necesidad y/o requerimiento work process disponibles. Y las causas podrían ser:

•       Falta de espacio en algún tablespace: puede que no tenga el espacio suficiente para almacenar el dato; pues es de recordar que en los tablespace se encuentran almacenadas las tablas de SAP. Para ello es necesario validar el espacio disponible que tiene el tablespace y en caso tal ampliarlo, para que, de esta forma, el dato pueda ser escrito y los servicios puedan ser reanudados. Aquí hago énfasis en que el espacio disponible que se observa en la base de datos no equivale al espacio que está necesitando el proceso que lo está requiriendo, pues durante esa actividad, suele suceder que el work process de update se detiene con el de fin de auto protegerse y evitar que la base de datos entre en un estado inconsistencia y así no pierda su integridad. La forma de revisarlo es a través de log de la base de datos.

•      Se llenó el espacio donde se guardan los archive log de la base de datos: Suele ocurrir que por alguna carga masiva o porque falló el backup de los archive log, se haya llenado el espacio en disco. Para ello suficiente con moverlos a otra ubicación para liberar el espacio, con el fin de devolver el servicio y con más tiempo identificar que lo pudo haber llenado con el fin de tomar las medidas preventivas.

•      Chequear el estado de los work process: El objetivo es validar que los work process siempre se encuentren disponibles y en estado esperando (waiting), pues en un ambiente ideal, el comportamiento debe ser que las operaciones se realicen con eficiencia o dicho en otras palabras que las operaciones cojan el work process, tramiten el requerimiento y lo liberen. Algunas veces se encuentra que el 90% y en algunos casos el 100% de los WP de dialogo se encuentran ocupados, cuando se presenta esta situación, puede obedecer a que el sistema para algunas operaciones, requieren de work process de background que no encuentra disponible. Para ello se debe revisar el número y su disponibilidad, si se encuentran todos los work process de background ocupados, se debe proceder ampliarlos en la rz04 en línea y revisar si el sistema empieza a descongestionarse. Con este comportamiento el sistema se congela o se vuelve lento, esperando que algún wp se libere y vaya evacuando todas las peticiones que deben estar encoladas. En condiciones normales una instancia de productivo debe contar como mínimo con 8 WP de background, si tiene menos de esa cantidad temporalmente y mientras se evacua los requerimientos, auméntelos al doble a través de la rz04. Algunas veces y dependiendo de la versión, se permite realizar el ajuste en caliente.

    2. Validar si un work process lleva mucho tiempo en tiempo de ejecución. Algunas veces hay procesos en donde se quedan pegados y/o llevan bastante tiempo de ejecución debido a que el usuario se desconectó de una manera inapropiada o se le perdió la red y el proceso y quedo allí. En otras debido al requerimiento, muchas veces estos procesos empiezan a consumir recursos de memoria de forma tal que pueden llegar a colapsar el sistema, para ello se puede realizar una de dos cosas, la primera es identificar si es una consulta, chequear el tiempo de ejecución y validarla con el usuario, puede que la haya mandado sin filtros, la mayoría de las veces suele presentarse por ese suceso y se presenta bien sea por desconocimiento o por olvido. En caso de que lo sea, se debe crear una cultura en donde se capacite al usuario de como enviarlas. Recuerden por más recursos que tenga un sistema todo debe ser tratado con el viejo refrán “Todo con medida y nada con exceso”. Esta situación puede ser contrarrestada configurando un parámetro que cancele el proceso automáticamente cuando supere los 1800 segundos de tiempo de ejecución. En caso de que se requiera más de ese tiempo, se debe negociar con el usuario. Aun así, es demasiado tiempo, de acuerdo con las pruebas que ha hecho SAP, el parámetro viene configurado por defecto en 600 segundos.

   3. Validar que en la sm04 los usuarios no estén consumiéndose la memoria del sistema, si lo encuentren se debe cancelar, como medida de prevención e indagar con el usuario el tipo de consulta que es para aconsejarle como debe ser lanzada.

Ahora algunas veces el performance no obedece a que le sistema este degrado, sino por inconvenientes en los tiempos de respuesta que están asociados a los tiempos ocasionados por el cliente de SAP y que se pueden reflejar en cada estación de trabajo, en la parte inferior derecha de la ventana de SAP. Para tiempos de 200 ms, estos tiempos son ocasionados por el cliente de SAP, si se observa tiempos demasiados altos puede obedecer a un problema de rendimiento pobre en la red.  Para identificarlo es bueno revisarlo mediante herramientas de sap y una de ella es el comando NIPING.

Perform a LAN Ping check via ST06 with a package size of 4096 bytes. The reference response times are:

• In a local area network (LAN: < 20 milliseconds
• In a Wide Area Network (WAN): < 50 milliseconds
• With a modern connection (for example, 56 KB): < 250 milliseconds
• There should be no loss of data package.

For further analysis, use NIPING as per SAP Note 500235 - Network Diagnosis with NIPING. If necessary, contact your network partner to improve the network throughput.

Existen situaciones particulares y que pueden darse, como es el caso de que sea un único usuario se identifique o se queja que algunos servicios le funcionan de manera intermitente, para ello se hace un sinfín de tareas, como es el caso actualización del cliente de SAP, actualizaciones de Windows, etc y aun así por todo lo que se le haga aun no resuelve la situación, no dejen de revisar como última opción, el perfil de Windows, muchos problemas se encuentran asociados a que el perfil del usuario de Windows se encuentra corrupto. Lo único que hay que hacer es validar e inventariar lo que tiene el usuario en el escritorio, sacarle backup a sus archivos, renombrar ese perfil y crear otro, de esta forma se resuelve.