“Sequential read” tiene un contexto diferente a lectura secuencial en el ámbito de SAP SM50.



 Muchas veces cuando monitoreamos el sistema SAP ERP y sobre todo los work process (que es en donde se procesan las peticiones que hace el usuario) a través de la transacción sm50 o en su defecto en la sm66, observamos que en la columna action, algunas veces se refleja el texto “sequential read”, tal y como se observa en la imagen siguiente:




En múltiples ocasiones nos sorprendemos y caemos en lo que lo que en el ámbito de base de datos se denomina lectura secuencial, que para quienes hemos trabajados en base de datos o estudiamos en la universidad, nos enseñaron que es uno de los métodos más ineficaces e ineficientes para construir consultas. La verdad desde el punto de vista técnico, resulta ser un término muy engañoso, ya que por lo general suele ser comparado con este método ineficaz.

Quiero aclarar que no obedece a lo mismo, aunque el mensaje así lo pareciese. Este método “sequential read” cuando aparece en la sm50, se refiere a todos los demás accesos a la base de datos leídos, en los que puede haber más de una línea devuelta. Ahora, cuando uno quiere profundizar para hallar la causa raíz, durante el proceso de análisis, no podemos encontrar que la razón es debido a que la consulta está utilizando la estrategia “full table scan”, que es un indicador donde nos indica que la consulta no está leyendo el índice o no existe el índice para que la consulta tenga buenos tiempos de respuesta o dicho en otros términos sea más eficiente en traer o brindar la información solicitada, en este punto es donde debemos acudir al grupo desarrollador para que nos ayude a revisar la consulta o en su defecto, buscar notas OSS que nos ayude a mejorar y/o resolver el inconveniente.

Adicionalmente, como complemento, cuando se presenta esos textos “sequential read”, puede también obedecer a inconvenientes que se tienen en el área del almacenamiento, o un disco esta alarmado o se quedó en estado de recuperación, entre otras, que pueden estar ocasionando este comportamiento y que se reflejan por lo general en el rendimiento y tiempo de respuesta que manifiestan los usuarios finales; la mayoría de las veces son muy altos. Es aquí donde también se debe involucrar al equipo de infraestructura para que hagan los respectivos análisis y nos ayuden a identificar la causa raíz del problema.

No obstante, en algunos casos, el error también se presenta en la transacciones estándar, no simplemente en la transacciones o programas del cliente. Cuando es el caso, SAP también las identifica y las mejora o da las recomendaciones sobre el respecto, en donde puede estar desde crear un índice, ajustar el índice, aplicar un ajuste a un programa o en su defecto ajustar los parámetros de memoria en el área de los buffers.  Por ejemplo, que los swaps no estén correctamente definidos y/o configurados en la st02 y que sugiere revisar y/o ajustar los parámetros siguientes:



zcsa/table_buffer_area      #Buffer size

zcsa/db_max_buftab          #Number of directory entries

Comentarios

Entradas populares de este blog

Verificación de la caducidad de un rol como de la duplicidad del mismo

Ventajas de activar el log de auditoria SM20 de una manera más eficiente