ST04 — ST04 Database Performance Monitor

ST04 is the database performance monitor. It shows the health of the database instance itself: CPU, memory and disk utilization, buffer or cache quality, active sessions or services, wait events, and the most expensive SQL statements running or recently run. The one structural fact that explains most of the confusion around it is that the screen content is entirely database-dependent. The transaction code is the same on every system, but the function modules behind it differ by database platform, so an Oracle-trained consultant opening ST04 on a HANA system finds a different layout, different tabs, and different terminology (services and hosts instead of tablespaces and datafiles). It is a monitor, not a configuration or maintenance transaction; nothing about the database is changed by using it.

ST04 is reached when a performance complaint has already been narrowed to the database layer, or when that narrowing has not happened yet and needs to. Typical triggers: a batch job or report that used to finish in minutes now takes hours, a spike in database CPU or memory alerts, a go-live health check, or a blocking/lock situation reported by users. It sits below ST03 (workload analysis, which shows time split by transaction and by component such as database time, CPU time, wait time at the ABAP layer) and above OS-level tools. A consultant checks ST03 first to confirm the bottleneck is database time, then moves to ST04 to find which statement or resource is responsible, rather than starting in ST04 for every slow transaction complaint.

From the DBA Cockpit SQL editor reachable through ST04, run a query against the expensive statements view filtering on the start time window of the incident and sorting descending by duration; this returns the statement text, execution count and elapsed time that ST04's screen summarizes visually. Join that result to the service statistics view on host and port to see whether one service (usually the index server) was CPU- or memory-bound at the same timestamps. If the numbers in ST04 and DB02n disagree, compare the refresh timestamp shown on each screen rather than assuming either one is wrong.

On S/4HANA, ST04 becomes a HANA-oriented monitor and its content overlaps substantially with what DBA Cockpit shows, since both read from the same HANA statistics infrastructure. The transaction itself remains usable as a GUI entry point for quick checks. For deeper administration, HANA-specific tools with broader drilldown (memory tracing, thread samples, workload class analysis) go beyond what ST04's screens expose, so Basis teams increasingly use DBA Cockpit or HANA-side tooling for anything past a first-pass check.

Database performance is a Basis or dedicated DBA problem, not functional and not ABAP development, except when the root cause traces to a specific poorly written statement, in which case ownership shifts to the ABAP developer of that program. A good handover includes the statement identifier, the affected table, the exact time window, and whether the ST03 workload breakdown confirms database time as the dominant component.

Start with ST03 to confirm the bottleneck is genuinely at the database layer before spending time in ST04. Pair ST04 with DB02 for space, segment and backup-related questions that ST04 does not answer. ST06 gives the OS-level view (CPU, memory, disk at the host) that explains resource pressure ST04 reports from the database side. SM50 and SM66 show the application server work process view, useful for ruling out that the delay is actually at the app server rather than the database.