✒️La evaluación de parámetros SAP

Unidad 4. Mantenimiento del sistema

Configuracion de los parametros del sistema

La configuracion de las instancias y del sistema SAP se realiza usando los parametros del sistema.Los valores por defecto para estos parametros son definidos en el codigo de programa del kernel del sistema. La fig, muestra los lugares donde estan definidos los parametros del sistema y la secuencia de lectura de los mismos.Tambien podemos observar que existe una prioridad o peso del parametro dependiendo de donde lo definamos.

Esto significa que un parametro que tiene un valor definido por defecto en el kernel del sistema, cuando esta definido en el perfil DEFAULT.PFL tomará el valor de este ultimo, y si esta definido tambien en el perfil de la instancia, entonces será ese valor con el que finalmente funcionará el sistema.

Podemos cambiar los valores por defecto de los parametros utilizando los archivos de perfiles, los cuales son leidos cuando las instancias del sistema se levantan. Estos archivos de perfiles son creados durante la instalacion del sistema y pueden ser editados luego. Como los archivos de perfiles son solamente leidos cuando inicia el sistema, necesitamos reiniciar la instancia o el sistema completo después de cambiar algun parametro.

El dynamic switching (cambio dinamico) de parametros, el cual se realiza mientras el sistema se encuentra operando, es posible para un pequeño grupo de parametros del sistema.

Los archivos de perfil son automáticamente creados durante la instalacion. Después de que completa la instalación, los archivos de perfiles son almacenados a nivel del sistema operativo en el directorio:

usr/sap/< SID >/SYS/profile

Este directorio puede ser leido por todas las instancias de un sistema SAP utilizando las tecnicas de montaje o de directorio compartido, dependiendo del sistema operativo donde este instalado el sistema.

El sistema SAP tiene tres perfiles de sistema, estos son:

a) Start Profile (Perfil de inicio).

b) Default profile (Perfil por defecto).

c) Intance Profile (Perfil de instancia).

2. Visualizacion de los parametros

En principio, podemos cambiar estos archivos con herramientas de edicion del sistema operativo. Al editar estos archivos, deben asegurarse que los cambios realizados sean correctos ya que si son configurados de manera incorrecta el sistema no inicia.

Es mucho mas conveniente y seguro realizar los cambios de los parametros de perfiles utilizando las herramientas en el sistema SAP.

El perfil especifico por instancia de inicio, cuya nomenclatura es: START_

Existe solo un unico perfil por defecto, cuyo nombre es DEFAULT.PFL, por cada sistema SAP y el cual es leido por todas las instancias SAP. Contiene configuraciones que afectan a todo el sistema, tal como el nombre del sistema, el nombre del servidor de bd o el cliente de logon por defecto para el sistema.

El perfil de instancia, < SID > _ define parametros que aplican para una instancia, tales como el número y tipo de work processes, o la definicion del tamaño de area de memoria principal asiganda al sistema SAP. El perfil de la instancia es por lo tanto especifico por instancia.

Los valores actuales de los parametros del sietma pueden visualizarse en el sistema. Para esto, podemos optar por dos maneras: El reporte RSPFPAR el cual muestra una lista de todos los parametros especificos de instancia y de los parametros que aplican para todo el sistema. Esta lista se puede acotar a un rango especifico de parametros.

El resultado es una tabla donde se muestra por cada parametro los valores por defecto del sistema tal como estan definidos en el programa del kernel y si el valor por defecto ha sido anulado por un valor definido por el usuario ya sea en el perfil por defecto o en el especifico de la instancia, se mostrara este valor tambien.Una breve descripcion y si se requiere documentacion para los parametros puede ser visualizada tambien.

Transaccion RZ11: Muestra informacion y documentacion para los parametros de forma individual. Tambien muestra con el indicador Conmutacion Dinámica (Dynamically Switchable), si el parametro puede tomar un cambio de inmediato sin tener que reinciar el sistema.

Cuando modificamos un parametro utilizando la transaccion RZ11, la modificacion se mantendrá mientras la instancia este activa. Una vez que reiniciemos la instancia el valor del parametro volverá al que estaba definido previamente ya sea del kernel o del perfil de la instancia.

Modificar parametros que tienen la propiedad de conmutacion dinamica en la transaccion RZ11, es util para realizar pruebas sin tener que reiniciar la instancia o el sistema enteramente. Luego si decidimos que el cambio debe de ser permanente lo haremos utilizando la herramienta de mantenimiento de parametros, Transaccion RZ10.

NOTA: Tabla TPFYPROPTY, todos los parametros que pueden ser cambiados dinámicamente están identificados con el indicador dinámico (Dynamic). Podemos utilizar la transaccion SE16, para visualizar esta tabla.

Fuera del sistema SAP, podemos visualizar los parametros a nivel de sistema operativo si estamos trabajando con el usuario adm con el programa sappfpar. Podemos obtener el valor actual de un parametro con el comando sappfpar. El comando sappfpar all, devuelve una lista de todos los parametros. Podemos verificar que parametros estan configurados utilizando sappfpar check. El comando sappfpar help, devuelve una breve ayuda sobre las posibles opciones de ejecucion del programa.

Tambien es posible especificar un perfil de instancia, un # de instancia o el nombre del sistema SAP; con este comando si utilizamos las opciones pf=, nr=.

NOTA: REPORTE RSPFPAR: Para la evaluacion de los parametros de perfiles utilizando las herramientas descritas, algunos parametros de perfiles son los mismos para todo el sistema, mientras que otros seran diferentes por cada instancia. El reporte RSPFPAR, muestra la configuracion de la instancia en la que se ejecuta el mismo.

PREGUNTAS Y RESPUESTAS

¿Que variables debemos evaluar, al momento de configurar la cantidad de work process ( dia, btc, enq, vb, spo) con...

no existe una regla standar para calcular cada uno de ellos si no que es en base a las necesidades, por ejemplo se suele colocar de 5 a 10 WP de diálogo por procesador, teniendo 4 core serían 40 WP de diálogo, que es una locura, porque si nos remitimos a pruebas podemos observar que con 20 WP se puede atender a miles de usaurios, pero tampoco sería real si los miles de usuarios ingresan y consultan simultaneamente el sistema... es decir, depende de muchas variables y cada empresa tendrá una realidad diferente.

Una buena práctica es que antes de largar en productivo un proyecto de sap, se solicita un reporte previo llamado go live check, y para el cual se debe ingresar cierta información como cantidad de usuarios, usuarios con alto nivel de acceso, transacciones que van a usar, cantidad de materiales etc etc etc mucha información relacionada al negocio y en base a esto luego de unos días emite un reporte con sugerencias.

Lo que te puedo pasar es las reglas generales que se deben tener en cuenta, por ejemplo procesos de diálogo deben contener mínimo 2 y para el caso de un productivo, sería conveniente que contenga mínimo 10, pero si es un solution manager, en donde ingresan 10 personas en total, con 4 procesos es suficiente... es decir depende mucho de la instalación, para los de background (btc) lo puedes analizar en base a la cantidad de procesos de background concurrentes que tienes en el sistema, este es un análisis que debes hacer para evitar concentración de procesos de btc innecesariamente, igual todo lo que es proceso de btc, se supone que puede durar mucho tiempo por lo tanto si un proceso que debe ejecutarse no puede porque todos los btc están ocupados, se encola esperando que alguno libere, con lo cual puedes analizar si hay muchos procesos con delay en el arranque, ese es un síntoma que hay que reorganizarlos o agregar procesos, en este caso un sistema puede contener 0 a n procesos.

Para el caso de los procesos de enq, vb y spo es el mismo análisis, se puede comenzar colocando mínimo 2 para cada uno, pero por ejemplo si el negocio incluye impresiones de etiquetas de código de barra por ejemplo se van a necesitar muchos procesos de spool para que puedan procesarse en paralelo, de lo contrario cada impresión dependerá de la terminación de otra.

Espero que esto te sirva, pero el análisis es particular de cada instalación y posee mucho del día a día para llegar al nro ideal.-

Por último hay que tener en cuenta que si agregamos WP sea del tipo que sea, implica que sap va a consumir mayor cantidad de procesamiento en paralelo y lo principal mayor cantidad de memoria ram para el arranque del sistema con lo cual puede suceder que si agregamos wp en forma desmedida, puede que no arranque, con lo cual se debe cambiar el profile manualmente para que vuelva a levantar el sistema.