RZ10 — Maintain SAP Instance Profile Parameters
RZ10 maintains the default, instance and start profiles that control kernel and work process behavior on an SAP system. It edits and activates a database-tracked version of the profile, but the change only takes effect for a running instance after restart, unless the specific parameter is flagged as dynamically switchable, in which case RZ11 applies it immediately.
This page covers RZ10, the transaction for editing default, instance and start profiles that govern SAP kernel and work process behavior. It focuses on the recurring confusion between saving/activating a profile and the parameter actually taking effect at runtime, and how to prove from the data which state a given instance is in.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,167 words
What it does
RZ10 maintains the operating system profile files that an SAP instance reads at startup: the default profile shared by all instances, each application server's instance profile, and the start profile used to launch it. It controls things like work process counts per type, memory area sizes, gateway and message server settings, and various security switches. The one fact that explains almost all confusion with this transaction is that RZ10 edits a version of the profile tracked in the database, and saving or even activating that version does not change what a live work process is using right now. The running kernel only picks up the new value at the next instance restart, with a small, fixed set of parameters marked dynamically switchable being the exception, changeable in memory through RZ11 without a restart.
When it is used
RZ10 is reached for whenever a planned change to kernel or instance-level behavior is needed: raising dialog or background work process counts ahead of a load event, adjusting SAP memory areas after a performance review, enabling or disabling a security parameter, or preparing a parameter change that will be rolled out during a maintenance window with a restart already scheduled. It sits upstream of SM50/SM51, which show the currently running configuration, and upstream of RZ11, which is used instead when the change is a single parameter that is dynamically switchable and needs to take effect immediately without waiting for a restart. RZ10 is not used to inspect current live values; that is RZ11's job.
How to use it
- Call RZ10 and select the target profile: DEFAULT for the system-wide profile, or the specific instance profile of the application server being changed.
- Choose Extended maintenance to see and edit the raw parameter list, or Basic maintenance for the guided screens covering common parameter groups.
- Add the parameter and value, or change an existing entry; the change is written as a new, unsaved version of that profile.
- Save the profile; this creates a new version tracked in the database but does not touch the file used by the running instance.
- Activate the profile; this writes the new version out as the active profile file on the file system, ready to be picked up.
- Restart the instance during the agreed window, or, if the parameter is dynamically switchable, apply it immediately through RZ11 instead of waiting.
Key fields
- Profile file on the operating system (default, instance, or start profile) - the actual text file in the profile directory that the kernel reads at startup; this is the file whose content ultimately determines runtime behavior.
- Database shadow copy of profile versions maintained by RZ10 - holds saved and activated versions of each profile so changes can be compared, reverted, or audited from within the transaction rather than by editing the file directly.
- Kernel shared memory parameter table populated at instance startup - the in-memory set of active parameter values a running work process actually uses; this is what RZ11 reads and reports, not the RZ10 saved version.
- Change and transport log entries recorded when a profile is activated - used to trace who changed which parameter and when, independent of whether the instance has been restarted since.
How to prove it in the data
To confirm whether a change made in RZ10 is actually live, use RZ11 on the parameter in question and compare the displayed current value against the profile value shown for that instance; a mismatch means the profile was activated but the instance has not been restarted since. To confirm the change reached the file system at all, browse the profile directory through AL11 and open the instance profile file directly, checking the parameter line and the file's last-changed timestamp against the activation time recorded in RZ10's own version history for that profile.
ECC vs S/4HANA
RZ10 is unchanged on S/4HANA; profile maintenance remains a classic SAP GUI transaction and there is no dedicated Fiori app that replaces it for general parameter editing. The same distinction between saving, activating, and restarting applies identically on S/4HANA as on ECC, and RZ11 continues to be the tool for dynamically switchable parameters on both.
Common pitfalls
- Saved but never activated: the parameter shows in RZ10's edited version but was never pushed out as the active profile; check the activation status in RZ10 first before assuming the change failed elsewhere.
- Activated but instance not restarted: RZ11 shows the old value as current and the new value as the profile value pending activation; this is normal for non-dynamic parameters and is not a system fault, it is a scheduling gap.
- Wrong profile layer edited: a parameter set in the DEFAULT profile is silently overridden by the same parameter set at the instance profile level, so the intended systemwide change never reaches that particular server; check both layers when a change appears to have no effect.
- Change applied to one instance only: in a multi-server system each application server has its own instance profile file, so an edit made against one instance's profile does not propagate to the others; verify against SM51 which instances still show the old behavior.
- Unrecognized or mistyped parameter name: older releases do not always validate the parameter name at save time, so a typo is accepted silently and simply ignored, or causes a startup error only discovered later in the developer trace; check spelling against a known-good reference before activating.
- Reflex overreaction: restarting the entire system because a change appears not to have taken effect, when the actual cause is a pending restart on one instance or a dynamically switchable parameter that only needed RZ11; check activation status and dynamic-switch eligibility before scheduling any outage.
Whose problem this is
RZ10 is Basis territory; functional and ABAP consultants should not be editing instance profiles directly. A good handover to Basis names the exact parameter, target instance or DEFAULT profile, whether it is dynamically switchable, the current value observed in RZ11, and whether a restart window has already been agreed, so Basis is not left to rediscover the activation state from scratch.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/rz10ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.