Profile parameters accompany the SAP Basis administrators their entire lives. Still, in many SAP systems one can find sub-optimal handling of those and when it comes to monitoring or compliance checking one may be curious how to determine the currently effective values. This may be from a special interest if one considers to implement a tool for compliance checking.
In this blogpost I like to give a brief overview about profile parameters, maybe some handling tips.
In another blogpost I give an overview about how the effective profile parameter values can be determined.
Effective Parameters
At first we must know that many profile parameters have a so called „kernel default value“. This value is compiled into the kernel and will take effect if it is not overwritten by other means - we will come to that in a few.
We can display the kernel default values of all parameters recognized by the actual SAP kernel for example by running the command sappfpar all on OS-level as user <sid>adm.
Please note: Looking at the output we may find some profile parameters which have no kernel default value and some parameters are entirely unknown to the kernel and therefore are not listed in the output at all. Values for these profile parameters must then be set explicitly in a profile file. An example would be the parameters ccl/* to setup the CommonCryptoLib.
The kernel default values might change with newer releases or patch levels of the SAP kernel. New sub-parameters might be added to existing profile parameters. Furthermore, completely new parameters may be added and in rare cases parameters get removed.
Please note: SAP started to provide a list of what has been changed for profile parameters. We can find this in the What's New Viewer in the section ABAP Server Infrastructure -> Parameter Changes. For example, here.
To make profile parameter values configurable and persistent they have to be stored in the so-called profile files. At system startup the profile parameters’ values are read from those profile files residing on the filesystem. This happens in the following order:
| # | Identifier | Location |
| 1. | kernel default value | compiled into the kernel |
| 2. | default profile | for SAP NW: /sapmnt/$SAPSYSTEMNAME/profiles/DEFAULT.PFL for SAP HANA: /hana/shared/$SAPSYSTEMNAME/profile/DEFAULT.PFL for SAP Host Agent: n/a |
| 3. | Instance profile | for SAP NW: /sapmnt/$SAPSYSTEMNAME/profiles/$SAPSYSTEMNAME_<instance_name>_<saplocalhost> for SAP HANA: /hana/shared/$SAPSYSTEMNAME/profile/$SAPSYSTEMNAME_<instance_name>_<saplocalhost> for SAP Host Agent: /usr/sap/hostctrl/exe/host_profile |
With this, we must keep in mind: A value from the instance profile might oversteer a value from the DEFAULT.PFL. In some cases, this may be used by intent.
Determine the correct profile for a parameter and use variables to define its value
As a rule of thumb, instance profiles (file name <SID>_<INSTANCE>_<HOST>) should contain only parameters which are specific for the particular instance.
Instance specific parameters may also be shifted into the DEFAULT.PFL if there is a variable available which can be used to make values instance specific while defining them in the DEFAULT.PFL.
To make this concept more clear, I like to give an example for that based on the profile parameter icm/HTTP/logging_<xx>:
We should prefer to set the following in the default profile
icm/HTTP/logging_0 = PREFIX=/,LOGFILE=$(DIR_LOGGING)$(DIR_SEP)↵
icm_http_server_$(SAPSYSTEMNAME)_$(INSTANCE_NAME)_$(SAPLOCALHOST)-%y-%m-%d.log
over setting the following in the instance profile
icm/HTTP/logging_0 = PREFIX=/,LOGFILE=/usr/sap/NPL/D00/log/↵
icm_http_server_NPL_D00_vhcalnplci-%y-%m-%d.log
In this example, we've made the value independent from the SID, Instance Name, hostname and we also made the value independent from the operating system by specifying the path by the variable $(DIR_LOGGING) and the delimiter using $(DIR_SEP). So, no matter how many instances our system has, even if heterogenous, we can rely on the desired value will take effect on each instance.
Excursus:
Having a closer look at the kernel default value of the profile parameter DIR_LOGGING we will see that it is specified as $(DIR_INSTANCE)$(DIR_SEP)log. And DIR_INSTANCE is specified as $(DIR_SEP)usr$(DIR_SEP)sap$(DIR_SEP)$(SAPSYSTEMNAME)$(DIR_SEP)$(INSTANCE_NAME). For DIR_SEP the kernel default value is hard coded in the OS-specific SAP Kernel, for Linux it is "/".
Knowing this, we can note: even nested usage of variables is possible.
Another example would be the kernel default profile parameters ES/SHM_SEG_SIZE and ES/SHM_MAX_PRIV_SEGS. Both make use of variables. They are so called formula parameters. Their values are determined by using math functions:
ES/SHM_SEG_SIZE = ($(em/blocksize_KB)/1024 * (ceil(max($(ztta/max_memreq_MB) *2, $(abap/shared_objects_size_MB) + $(rsdb/tbi_buffer_area_MB) + 4*($(em/blocksize_KB)/1024)) / ($(em/blocksize_KB)/1024))))
and show that calculated values can be used as variables for further calculations:
ES/SHM_MAX_PRIV_SEGS = (ceil(max($(ztta/roll_extension_dia), $(ztta/roll_extension_nondia)) / (1024*1024 * $(ES/SHM_SEG_SIZE))) + 1)
Precisely, there are only very few profile parameters which must be set in the instance profile.
Please note: The only deviation I came across are the rdisp/wp_no_* profile parameters which need to be set explicitly in the instance profile to be recognized correctly by the "Operation Modes and Instances" editor of transaction RZ04. A warning will be displayed if these profile parameters are not present in the instance profile. Even though, the values for these profile parameters would be correctly determined and used if they would be defined in the default profile only.
Some parameters are flagged as system-wide when being displayed in transaction RZ11 and therefore should never be set in any instance profile.
Maintaining profile parameter values
For maintaining profile parameter values, we have basically two possibilities.
1. Maintain the profile files on the OS-level using your preferred text editor.
Please note: If you maintain the profiles on OS-level, you should import profiles before displaying them in RZ10 to avoid inconsistencies.
2. Logon to the system and use transaction RZ10.
Please note: In RZ10 the instance profile of the ASCS instance (/usr/sap/<SAPSID>/SYS/profile/<SAPSID>_ASCS<nn>_<hostname>) could be included after implementing SAP Note 2789094.
Profile parameter values become effective during the system startup. Some time this is also referred as 'they become "activated"'.
Change profile parameter values at runtime (Dynamic Parameters)
For some profile parameters it is possible to change their value at runtime. These parameters are known as "Dynamic Parameters". Changes to such dynamic parameters during runtime (aka. "changes in productive operation") are withdrawn after a system restart.
We can change profile parameters via web methods offered by the SAP Instance Agent (aka SAP Start Service):
sapcontrol -nr <Inst-No> -function [SetProcessParameter|SetProcessParameter2]
Within AS ABAP, changes during runtime can be performed using transaction RZ11 or function module TH_CHANGE_PARAMETER or SPFL_PARAMETER_CHANGE_VALUE.
For the ICM, vector parameters like icm/HTTP/logging_<xx> can be changed using the Function module ICM_SET_VECTOR_PARM. Some components like the ICM will recognize dynamic parameter changes and will perform a soft-restart, others will just use the new value for their next task execution.
Please note: There are a few profile parameters which allow a change at runtime depending on their current value. Which means, we can change the value from 'a' to 'b' without a restart, but changing back from 'b' to 'a' would need a restart. This is for security reasons.
Transaction RZ11 provides a change history for dynamic changes performed since the last restart of the system. The link to the change history can be found below the "Current Value of Parameter"-table indicated by "Origin of Current Value: Dynamic Switch ( Change History )".
As this link is only displayed if there have been changes since the last restart of the system, Frank Buchholz provided the report ZRSPFPAR_DYNAMIC_CD which can be found at GitHub https://github.com/SAP-samples/security-services-tools to make them visible for all dynamic changes. Values different to the effective value are displayed in yellow, values identical to the effective value are displayed in green.
Please note: As of SAP note 2201397 only the last 10 dynamic changes are logged. If you want to see all changes you have to search the syslog for the IDs Q19, Q1A.
- SAP Managed Tags:
1 Comment
