DB02 — Database Performance and Space Monitor

DB02 gives an administrative view of the database itself rather than of application data: overall size and growth trend, tablespace or datafile utilization, table and index sizes, missing indexes, and whether cost-based optimizer statistics are current. The one fact that explains most confusion is that DB02 has no data model of its own. It queries the native database catalog and statistics views, so a table that looks fine in DB02 on Oracle may look completely different once the same system is migrated to HANA, because HANA has no tablespaces in the classical disk sense and measures memory consumption by column store and delta storage instead. Consultants moving between systems on different platforms frequently misread DB02 output because they apply the wrong platform's mental model to it.

Reached for whenever a performance ticket traces back to a specific table or index rather than to workload or buffer settings, when planning an archiving run and needing before-and-after table sizes, when a tablespace fills up and datafiles need extending, or when EarlyWatch or a routine health check flags missing indexes or outdated statistics. It sits downstream of ST04 (database workload) and ST03 (workload by transaction): those point at a slow statement, DB02 confirms whether the underlying object has an index problem or stale statistics. It is not the tool for live session monitoring or lock waits, and it does not replace DB13 for scheduling the statistics and backup jobs that keep its own numbers accurate.

Because DB02 reads live catalog views rather than a persisted SAP table, there is no single SE16 screen that reproduces its output. Instead check DBSTATC filtered on the table name to see whether automatic statistics collection is switched off for that object, and check DD02L for the table's buffering and size category to rule out a configuration mismatch masquerading as a database problem. Confirm the statistics or space collection job actually ran recently through the DB13 job calendar before trusting any growth trend gap in DB02 as real data loss.

On S/4HANA the underlying database is HANA, and DB02 functionality is generally accessed through DB02N or DBACOCKPIT, which add HANA-specific views such as column store memory consumption and delta merge status alongside the classical size and statistics screens. The core diagnostic logic is unchanged: still checking size, growth, missing indexes, and statistics currency, just against a different catalog. A browser-based database administration cockpit also exists for HANA monitoring outside the SAP GUI transaction, though its exact naming should be confirmed in the target landscape rather than assumed.

Owned by Basis or the DBA team. Functional consultants should not act on DB02 findings directly. A good handover to Basis includes the table or index name, the specific tab or figure in DB02 that triggered concern, the timestamp of the observation, and whether a workload symptom (slow transaction, timeout) is linked to it. ABAP involvement is limited to cases where custom table growth points to a design or archiving object gap.

Read ST04 next to see whether the database-level symptom found in DB02 correlates with actual workload or wait time, and ST03 to see which transaction or job is driving load on the flagged table. ST02 is useful when a buffering setting found via DD02L might explain part of the size or access pattern. DB13 explains the job schedule that keeps DB02's statistics and growth data trustworthy in the first place, and RZ20 is where a recurring space or growth alert would surface automatically rather than being found by manual DB02 checks.