RZ11 — Profile Parameter Maintenance

RZ11 displays and, for a subset of parameters marked dynamic, changes the runtime value of an ABAP system profile parameter without a restart. The screen shows the current value, the value as defined in the active profile, the default, and whether the parameter is static or dynamic switchable, together with parameter documentation pulled from the kernel. The one fact that explains most of the confusion around this transaction: a change made here is held only in the memory of the instance it is applied to. It is not written back into the profile file. Restart the instance and the parameter reverts to whatever the profile says, unless the profile itself was also updated separately through RZ10.

RZ11 gets pulled up mid-incident, not during planned change. Typical scenario: a work process shortage, a buffer overflow, a lock table exhaustion, or a rollback area limit is hit and restarting the instance to fix the profile is not an option during business hours. A Basis consultant checks the current and default values here first, then, if the parameter is dynamic, raises or lowers it live to relieve the immediate pressure. RZ10 is the tool for the durable fix - editing the profile so the new value survives the next restart. ST02, SM50 and SM04 are the monitoring transactions that identify which parameter is actually the bottleneck before RZ11 is opened at all. RZ11 itself never diagnoses anything, it only reads and, sometimes, changes a value.

The sequence below assumes the parameter name is already known from monitoring or dump analysis; RZ11 has no search-by-symptom capability.

There is no SE16 table to query for an RZ11 change because nothing is written to the database. To confirm a change actually happened and where, reopen RZ11 for the same parameter and compare the Current value field against the Profile value field - a mismatch confirms a live-only change is still in effect. Cross-check the timestamp against SM21 system log entries for that parameter name and user on that instance. If the persisted value also needs verifying, open RZ10, select the relevant profile, and compare its maintained value to what RZ11 currently reports.

RZ11 is unchanged on S/4HANA; it is a kernel-level ABAP transaction and did not move with the shift to S/4. There is no Fiori app replacement - Basis parameter tuning is still done through the classic GUI transaction. What is different is the database layer: HANA-specific parameters, the ones controlling the HANA database itself, are not visible or changeable through RZ11 at all. Those are maintained through HANA-side tools and are entirely separate from ABAP instance profile parameters.

This is Basis territory without exception - functional consultants should never touch a live parameter, and ABAP developers rarely have reason to either. A clean handover to Basis includes the exact parameter name, the requested value against the current value, whether the change should be instance-specific or system-wide, and whether the fix is meant as temporary incident mitigation or a permanent change requiring RZ10 and a restart window.

RZ10 is the natural next stop for anyone using RZ11 seriously - it is where the same parameter gets made permanent. SM21 confirms what actually happened and when, since RZ11 leaves no other trace of its own. SM50 shows whether running work processes reflect the new parameter or are still operating under the old limit. ST02 is worth reading before RZ11 for buffer and memory-related parameters, since it identifies which specific buffer or area is under pressure and therefore which parameter name to look up in the first place.