ST02 — Buffer and memory tuning monitor

ST02 displays the current state of the buffers and shared memory areas an application server instance uses to avoid repeated database access: program buffer, table buffer (generic key and single record), export/import buffer, calendar buffer, screen buffer, CUA buffer and a few others. For each it shows allocated size, current usage, free space, hit ratio and the swap count. The one fact that causes most confusion is that everything shown is per instance and lives in shared memory that is wiped on every application server restart, so numbers reset to zero and rebuild organically as work processes run. Reading ST02 right after a restart or on a system that has been up only a few hours produces misleading swap counts and low hit ratios that look like sizing problems but are simply the buffer warming up.

ST02 is reached for during performance troubleshooting when response times are generally slow across many transactions rather than one specific report, or when SM50/SM66 shows work processes spending unusual time and CPU without an obvious lock or long-running SQL statement. It is also checked proactively after a go-live or a major transport, since new custom tables or changed buffering settings change buffer load patterns. It is not the tool for single-transaction slowness (that is ST05 or SQL trace territory) and not the tool for database-side memory (that is ST04 or the database monitor). Basis uses it during capacity planning and before recommending a profile parameter change; functional consultants use it mainly to rule out infrastructure before escalating a slow custom program.

ST02 does not write or save application data. It reads live counters maintained in the application server's shared memory buffer management structures and presents them; there is no save step and no persistent database table behind the screen itself.

There is no SE16 table to query directly for the live counters. To prove a buffer problem is real rather than restart noise, cross-check three things: the instance start time in SM51 against the swap counters in ST02 (short uptime explains low numbers), the actual configured buffer size against the profile parameter value shown in RZ11 for the corresponding parameter (mismatch means the parameter change was never activated), and the historical trend for the same buffer over several days through the workload monitor's history view, which shows whether swaps are climbing steadily or were a one-off spike tied to a specific load event.

ST02 behaves the same on ECC and S/4HANA for the ABAP application server buffers described here; the transaction itself has not changed structurally. What differs on S/4HANA is that many former database buffering decisions are now less relevant because the database itself is SAP HANA, so the emphasis shifts more toward table buffer settings for tables that still benefit from application server side buffering, and database-side memory is checked separately in ST04 or the HANA-specific monitors rather than in ST02. There is no dedicated Fiori app replacing ST02; it remains a GUI transaction used by Basis.

This is Basis territory. Functional or ABAP consultants may be asked to confirm whether a specific custom table is buffered or should be, but sizing decisions, parameter changes and restarts belong to Basis. A good handover states the affected buffer, the swap trend over several days with timestamps, the instance uptime at time of observation, and whether the issue reproduces on all instances or one.

Read ST03 next to see how buffer behavior correlates with workload volume and response time breakdown over time, since ST02 alone gives a snapshot but ST03 gives the trend. ST04 covers the equivalent memory and cache picture on the database side, useful when ST02 looks healthy but the slowness persists. RZ11 and RZ10 are where the profile parameters behind every ST02 buffer size actually live, needed once a genuine sizing change is agreed. DB02 is worth checking in parallel when table buffer misses correlate with heavy database growth on the same tables.