Lesson 4 of 5
The database layer
9 min
Every SAP system has exactly one database, which holds all of its data: business data for every client, customizing, the ABAP repository and dictionary, and much of the system's own administration data. For SAP S/4HANA, that database is always SAP HANA. Earlier SAP ERP releases could run on several database products; SAP S/4HANA was built for SAP HANA only.
The database interface
ABAP programs do not talk to SAP HANA directly. Each work process contains a database interface that translates the program's ABAP SQL into the database's native SQL, adds the client automatically for client-specific tables, and serves frequently read, rarely changed tables from table buffers in the application server's memory. Automatic client handling is why a user in client 100 never sees client 200's data, even though both live in the same tables.
What SAP HANA changes
SAP HANA keeps data in memory and, for most business tables, stores it by column rather than by row. That makes aggregations and scans across large volumes fast, which is why SAP S/4HANA could simplify its data model, for example by bringing finance postings together in the universal journal instead of maintaining many separate totals tables. It also changed how ABAP is written: modern SAP code pushes calculations down into the database through core data services (CDS) views rather than reading large volumes into the application server and calculating there.
| Aspect | Older SAP ERP on other databases | SAP S/4HANA on SAP HANA |
|---|---|---|
| Database choice | Several supported database products | SAP HANA only |
| Storage | Mostly row-based, disk-oriented | In-memory, mostly column-based |
| Totals and aggregates | Many redundant totals and index tables | Fewer aggregates; calculated on the fly |
| Where logic runs | Mostly on the application server | Increasingly pushed down to the database (CDS views) |
| Sizing driver | Disk space and CPU | Memory size of the data, plus CPU |
Why administrators and testers care
- Sizing and data volume: SAP HANA memory is sized to the data, so volume decisions (archiving, history in a migration) have direct cost.
- Backups and recovery: the database is where everything lives; backup and log settings determine how much data could be lost.
- System copies and refreshes: refreshing QAS from production is essentially a database copy plus post-processing, which is why it overwrites all clients in the target system.
- Performance testing: results depend on realistic data volumes; a test on a nearly empty database says little about production.
- High availability: SAP HANA system replication keeps a secondary database ready to take over.
- Request a refreshTest lead asks to refresh CMQ from production before a regression cycle
- Copy the databaseProduction database copied into CMQ: all clients overwritten
- Post-processingSystem settings, RFC destinations, interfaces and users adjusted so CMQ does not act like production
- Re-apply in-flight transportsChanges not yet in production imported again
- Release for testingTest data rebuilt; cycle starts
What would you do?
Priya asks Basis to refresh only test client 100 in CMQ from production and leave training client 200 untouched. Basis proposes a full system copy. What is the issue?
- Every SAP system has one database; for SAP S/4HANA it is always SAP HANA.
- The database interface translates ABAP SQL, adds the client automatically and manages table buffers.
- SAP HANA is in-memory and mostly columnar, enabling a simpler data model and code pushdown with CDS views.
- Sizing, backups, refreshes, performance testing and high availability all depend on the database layer.
Check your understanding · not graded
Lesson check
1. In SAP S/4HANA, the database is:
2. What adds the client automatically to database access for client-specific tables?
3. Why does a database-level refresh of CMQ affect every client?
4. What does code pushdown with CDS views mean?