Background
It is a common misconception that S/4HANA is inherently faster simply because it runs on SAP HANA. In reality, achieving optimal performance for complex calculations and joins requires the use of tuning objects. These repository objects allow developers to define technical settings that optimize runtime behavior independently of the underlying data models.
In the S/4HANA 2025 environment, these objects minimize the “distance” between application logic and data in two ways:
ABAP Tuning Objects buffer records in the application server’s shared memory to eliminate unnecessary data transport.
HANA Tuning Objects implement database-layer caches to significantly reduce CPU and thread utilization for intensive aggregations The core purpose of buffering is to minimize database load, hence increasing the overall system throughput and decreasing CPU consumption on SAP HANA database. Buffering avoids the high cost of repeated data transport between the Application Server (AS) and the Database. By keeping a local copy of data in the AS layer, the system can fulfill requests without ever reaching out to the network or the DB disk.
Performance tuning is not just about raw speed for a single user; it is about system-wide efficiency. By offloading repetitive row-level reads to the application layer, you free up the HANA database to focus on what it does best: complex calculations and massive data processing.
Sequence of Data Access
Apart from code pushdown introduced with CDS views, it is important to understand that when data is requested using CDS views, below is the sequence of steps:
The Initial Request: System checks the local Entity Buffer. This is the ABAP Shared memory of the individual Application server instance. If data is not found then it is a cache miss and the ABAP SQL interface sends the query to SAP HANA database.The Storage Phase: From SAP HANA DB, the data is placed into Shared Memory of current Application server automatically by ABAP SQL InterfaceSubsequent Queries: For any requests henceforth, the ABAP SQL Engine acts as localized DB manager bypassing HANA DB entirely and reading data directly from ABAP Shared Memory
ABAP Tuning Objects
Our first choice of buffering should be entity buffering in ABAP Layer – it uses ABAP Shared Memory of the application server.
It is not enabled by default. The annotation  @AbapCatalog.entityBuffer.definitionAllowed: true should be mentioned in CDS entity. Below are different buffer types available in ABAP layer:
View Entity Buffer: This buffer is meant for CDS View Entities and supports standard ABAP buffering types – Single, Generic and Full as well as DELEGATED Table Entity Buffer: This buffer is meant for DDIC tables and was introduced in S/4HANA 2025 edition. Supports standard ABAP buffering types – Single, Generic and Full but DELEGATED is not supportedPropagated Buffer: This buffer is meant for CD View Entities and uses path expressions to process joins in the buffer. Pre-requisite of this buffer type is the data source of propagated fields must be Fully Buffered. It allows ABAP SQL engine to process joins locally on application server by using data already available in the buffer hence preventing round trip to HANA DB. This can be very effective for a complex DB join.
Scenarios
When primary goal is to avoid repeated data transport between AS ABAP and DB ServerData that is rarely updated such as localized textJoins can be processed locally on application server itself by utilizing data in the buffer
Implementation
Ensure annotation @AbapCatalog.entityBuffer.definitionAllowed: true exists in target CDS entity and define the buffer in ADT using below statements as applicable:
DEFINE VIEW / TABLE ENTITY BUFFER ON cds_entity
LAYER CORE
/ LOCALIZATION
/ INDUSTRY
/ PARTNER
/ CUSTOMER
TYPE SINGLE
/ {GENERIC NUMBER OF KEY ELEMENTS number}
/ FULL
/ DELEGATED| NONEDEFINE VIEW / TABLE ENTITY BUFFER ON cds_entity
LAYER CORE
/ LOCALIZATION
/ INDUSTRY
/ PARTNER
/ CUSTOMER
TYPE SINGLE
/ {GENERIC NUMBER OF KEY ELEMENTS number}
/ FULL
/DELEGATED / NONEPROPAGATE VIEW ENTITY BUFFER ON cds_entity
{
propagated_field1[,
propagated_field2][,
…]
}[;]
Monitoring & Maintenance
Buffering is automatically handled by ABAP SQL engine. Monitoring typically occurs through standard ABAP Shared Memory (SHMM).
HANA Tuning Objects
These objects are stored in memory of SAP HANA DB to save database resources and are oriented towards saving database resources such as memory and CPU consumption during heavy aggregations on massive tables. These are known as result cache used to improve performance by reusing previously queried data rather than reprocessing it from HANA Database everytime it is requested. They are defined in ABAP dictionary and implement technical settings directly on SAP HANA Database. Below are the types of result cache available in S/4HANA:
Static Result Cache: This caches results for the specific CDS Entity View for a user defined retention period and is refreshed once that period expires. Best suited for complex views, KPIs, quarterly calculations where slightly stale data is acceptable to maximize performance. Dynamic Result Cache: This caches aggregated results for single-table SQL views. Best suited for heavy aggregation workloads on massive tables where real time data is required. It automatically updates using delta records when source table changes ensuring most recent results.
Scenarios
Heavy Aggregation Workloads such as SUM, COUNT or AVG on massiv tables like ACDOCA or CDPOS (Dynamic Result Cache)Analytical scenarios such as KPIs for complex views or quarterly calculations (Static Result Cache)
Implementation
SAP HANA tuning objects can be created from ADT using below syntax:
DEFINE STATIC CACHE cache_name
ON view_entity_name
{ element_list }
[RETENTION retention_in_minutes]
[SEGREGATE CACHE DATA BY filter_cond]
[CREATION CONFIGURABLE DEFAULT {ON|OFF}];DEFINE DYNAMIC CACHE cache_name
ON dbtab
{ projection_list }
[WHERE filter_cond]
[SEGREGATE CACHE DATA BY filter_cond]
[CREATION CONFIGURABLE DEFAULT {ON|OFF}];
Use tcode S_DBCACHE_CONFIG to manually toggle the “DB Status” and activate the cache.
 Monitoring & Maintenence
Use DBACOCKPIT to monitor cache objects. The query M_DYNAMIC_RESULT_CACHE for real time hit rates and M_DYNAMIC_RESULT_CACHE_EXCLUSIONS to see views that failed to cache (e.g., due to 1GB size limits). For static caches use RESULT_CACHE. Use ALTER SYSTEM CLEAR DYNAMIC RESULT CACHE to globally remove all entries or ALTER SYSTEM REMOVE… for a specific cache ID.Â
Conclusion
Leveraging both ABAP and HANA tuning objects in S/4HANA 2025 provides a robust framework for optimizing system performance while maintaining data integrity. The Dynamic Result Cache is essential for high-performance, real-time scenarios—such as aggregating the Universal Journal (ACDOCA) – because it guarantees transactionally consistent, non-stale results. By defining these as transportable ABAP Dictionary objects and managing them through tools like S_DBCACHE_CONFIG, you can significantly reduce CPU consumption and database response times across your landscape. While Dynamic Caches are ideal for real-time accuracy, Static Caches remain a strategic choice for complex views where periodic refreshes meet business needs.
Â
​ BackgroundIt is a common misconception that S/4HANA is inherently faster simply because it runs on SAP HANA. In reality, achieving optimal performance for complex calculations and joins requires the use of tuning objects. These repository objects allow developers to define technical settings that optimize runtime behavior independently of the underlying data models.In the S/4HANA 2025 environment, these objects minimize the “distance” between application logic and data in two ways:ABAP Tuning Objects buffer records in the application server’s shared memory to eliminate unnecessary data transport.HANA Tuning Objects implement database-layer caches to significantly reduce CPU and thread utilization for intensive aggregations The core purpose of buffering is to minimize database load, hence increasing the overall system throughput and decreasing CPU consumption on SAP HANA database. Buffering avoids the high cost of repeated data transport between the Application Server (AS) and the Database. By keeping a local copy of data in the AS layer, the system can fulfill requests without ever reaching out to the network or the DB disk.Performance tuning is not just about raw speed for a single user; it is about system-wide efficiency. By offloading repetitive row-level reads to the application layer, you free up the HANA database to focus on what it does best: complex calculations and massive data processing.Sequence of Data AccessApart from code pushdown introduced with CDS views, it is important to understand that when data is requested using CDS views, below is the sequence of steps:The Initial Request: System checks the local Entity Buffer. This is the ABAP Shared memory of the individual Application server instance. If data is not found then it is a cache miss and the ABAP SQL interface sends the query to SAP HANA database.The Storage Phase: From SAP HANA DB, the data is placed into Shared Memory of current Application server automatically by ABAP SQL InterfaceSubsequent Queries: For any requests henceforth, the ABAP SQL Engine acts as localized DB manager bypassing HANA DB entirely and reading data directly from ABAP Shared MemoryABAP Tuning ObjectsOur first choice of buffering should be entity buffering in ABAP Layer – it uses ABAP Shared Memory of the application server.It is not enabled by default. The annotation  @AbapCatalog.entityBuffer.definitionAllowed: true should be mentioned in CDS entity. Below are different buffer types available in ABAP layer:View Entity Buffer: This buffer is meant for CDS View Entities and supports standard ABAP buffering types – Single, Generic and Full as well as DELEGATED Table Entity Buffer: This buffer is meant for DDIC tables and was introduced in S/4HANA 2025 edition. Supports standard ABAP buffering types – Single, Generic and Full but DELEGATED is not supportedPropagated Buffer: This buffer is meant for CD View Entities and uses path expressions to process joins in the buffer. Pre-requisite of this buffer type is the data source of propagated fields must be Fully Buffered. It allows ABAP SQL engine to process joins locally on application server by using data already available in the buffer hence preventing round trip to HANA DB. This can be very effective for a complex DB join.ScenariosWhen primary goal is to avoid repeated data transport between AS ABAP and DB ServerData that is rarely updated such as localized textJoins can be processed locally on application server itself by utilizing data in the bufferImplementationEnsure annotation @AbapCatalog.entityBuffer.definitionAllowed: true exists in target CDS entity and define the buffer in ADT using below statements as applicable:DEFINE VIEW / TABLE ENTITY BUFFER ON cds_entity
LAYER CORE
/ LOCALIZATION
/ INDUSTRY
/ PARTNER
/ CUSTOMER
TYPE SINGLE
/ {GENERIC NUMBER OF KEY ELEMENTS number}
/ FULL
/ DELEGATED| NONEDEFINE VIEW / TABLE ENTITY BUFFER ON cds_entity
LAYER CORE
/ LOCALIZATION
/ INDUSTRY
/ PARTNER
/ CUSTOMER
TYPE SINGLE
/ {GENERIC NUMBER OF KEY ELEMENTS number}
/ FULL
/DELEGATED / NONEPROPAGATE VIEW ENTITY BUFFER ON cds_entity
{
propagated_field1[,
propagated_field2][,
…]
}[;]Monitoring & MaintenanceBuffering is automatically handled by ABAP SQL engine. Monitoring typically occurs through standard ABAP Shared Memory (SHMM).HANA Tuning ObjectsThese objects are stored in memory of SAP HANA DB to save database resources and are oriented towards saving database resources such as memory and CPU consumption during heavy aggregations on massive tables. These are known as result cache used to improve performance by reusing previously queried data rather than reprocessing it from HANA Database everytime it is requested. They are defined in ABAP dictionary and implement technical settings directly on SAP HANA Database. Below are the types of result cache available in S/4HANA:Static Result Cache: This caches results for the specific CDS Entity View for a user defined retention period and is refreshed once that period expires. Best suited for complex views, KPIs, quarterly calculations where slightly stale data is acceptable to maximize performance. Dynamic Result Cache: This caches aggregated results for single-table SQL views. Best suited for heavy aggregation workloads on massive tables where real time data is required. It automatically updates using delta records when source table changes ensuring most recent results.ScenariosHeavy Aggregation Workloads such as SUM, COUNT or AVG on massiv tables like ACDOCA or CDPOS (Dynamic Result Cache)Analytical scenarios such as KPIs for complex views or quarterly calculations (Static Result Cache)ImplementationSAP HANA tuning objects can be created from ADT using below syntax:DEFINE STATIC CACHE cache_name
ON view_entity_name
{ element_list }
[RETENTION retention_in_minutes]
[SEGREGATE CACHE DATA BY filter_cond]
[CREATION CONFIGURABLE DEFAULT {ON|OFF}];DEFINE DYNAMIC CACHE cache_name
ON dbtab
{ projection_list }
[WHERE filter_cond]
[SEGREGATE CACHE DATA BY filter_cond]
[CREATION CONFIGURABLE DEFAULT {ON|OFF}];Use tcode S_DBCACHE_CONFIG to manually toggle the “DB Status” and activate the cache. Monitoring & MaintenenceUse DBACOCKPIT to monitor cache objects. The query M_DYNAMIC_RESULT_CACHE for real time hit rates and M_DYNAMIC_RESULT_CACHE_EXCLUSIONS to see views that failed to cache (e.g., due to 1GB size limits). For static caches use RESULT_CACHE. Use ALTER SYSTEM CLEAR DYNAMIC RESULT CACHE to globally remove all entries or ALTER SYSTEM REMOVE… for a specific cache ID. ConclusionLeveraging both ABAP and HANA tuning objects in S/4HANA 2025 provides a robust framework for optimizing system performance while maintaining data integrity. The Dynamic Result Cache is essential for high-performance, real-time scenarios—such as aggregating the Universal Journal (ACDOCA) – because it guarantees transactionally consistent, non-stale results. By defining these as transportable ABAP Dictionary objects and managing them through tools like S_DBCACHE_CONFIG, you can significantly reduce CPU consumption and database response times across your landscape. While Dynamic Caches are ideal for real-time accuracy, Static Caches remain a strategic choice for complex views where periodic refreshes meet business needs.   Read More Technology Blog Posts by SAP articlesÂ
#SAP
#SAPTechnologyblog
