DBSTATC table — DBSTATC Table Statistics Override Control

One row in DBSTATC represents an explicit override for how the database's automatic update-statistics job should treat a single named database table. The default assumption for every table not listed here is that it follows the standard statistics refresh cycle scheduled through the normal DBA housekeeping job. A row appears in DBSTATC only when someone has deliberately intervened, typically to exclude an extremely large or volatile table from the routine run, to pin a non-default sample size or estimation method, or to stop a statistics refresh from repeatedly triggering an expensive full scan on a table where the default settings caused problems. The table is therefore small compared to most Basis tables and is not meant to grow organically; every entry reflects a conscious tuning decision made by whoever administers the database.

Only the table name field can be stated with confidence; the remaining columns hold the override details but their exact technical names are not asserted here to avoid guessing.

The only reliable join is on the table name itself, used to pull in the technical attributes of the table being overridden. Consultants confirm which application object a suspicious entry refers to and check its delivery class and buffering setting before deciding whether the override still makes sense.

The table is client-independent, so there is no client field to restrict on. It is also small enough that a full unrestricted read is not a performance risk in itself, but the useful query is always a single lookup by TABNAME rather than a scan, since the purpose of consulting the table is to answer one question: does this specific table have an override recorded or not. A blank result for a given table name is the normal case and simply means the table follows default statistics behaviour; it is not evidence of a configuration gap.

Symptom: the cost-based optimizer keeps choosing a poor execution plan on one large table right after a scheduled statistics refresh, and someone suspects the refresh is being skipped or misconfigured for that table. Selection: look up DBSTATC restricted to that TABNAME. A row confirms an active override exists and explains why the refresh behaved differently from the default; no row means the table follows the standard job, and the plan problem has to be investigated through actual data distribution and the executed statistics run, not through this table.

The table exists in S/4HANA as part of the underlying Basis layer, but its practical weight depends on the database platform underneath. On SAP HANA, optimizer statistics are managed through HANA's own statistics service rather than through this classic override table, so DBSTATC entries carry little or no operational meaning on a HANA-based system. The table remains more relevant on non-HANA secondary databases or in historical system landscapes still running a classic anyDB. No CDS compatibility view is associated with it.

Most misreadings of DBSTATC come from treating a small, exception-only table as if it were a complete inventory or a performance dashboard.

This is a database administration question, owned by whoever runs the DBA housekeeping and statistics scheduling for the system, not by a functional module team. Any request to add, remove, or interpret an entry should go through that team rather than being changed ad hoc by an application consultant chasing a performance ticket.

The natural neighbour is the dictionary table catalog used to confirm the technical attributes of the table an override refers to. The entries in DBSTATC are consumed by the scheduled statistics update job that DBA housekeeping runs, and are reviewed through the standard database administration cockpit rather than through a functional transaction.