SAP Landscape Management: Strategy for Complex System Landscapes
Manage SAP system landscapes efficiently and optimise lifecycle management.
Read more →S/4HANA on SAP HANA offers enormous performance advantages over traditional databases through its in-memory architecture. However, these advantages only materialise when the system is properly configured and monitored. This article describes the most important analysis tools, tuning measures and monitoring strategies for stable S/4HANA systems.
HANA-Specific Performance Analysis
The key tools for performance analysis in HANA: HANA Studio Performance Monitor for real-time monitoring, DBA Cockpit (DBACOCKPIT) for database administration, ST04 for database performance overview, M_EXPENSIVE_STATEMENTS view for the most expensive SQL statements and the HANA Plan Visualizer for detailed execution plan analysis. Start every performance analysis with the DBA Cockpit – it provides the best overview of the current system state.
SQL Statement Analysis and Tuning
Even though HANA is fast, poorly written SQL statements can bring any system to its knees. Identify the top 10 most expensive statements via the expensive statements trace or the M_SQL_PLAN_CACHE view. Typical problems: missing or unused indexes, full table scans on large tables, unoptimised CDS views and inefficient AMDP implementations. Use the SQL Plan Visualizer to analyse the execution plan and identify bottlenecks.
Memory Management: Row Store vs. Column Store
HANA uses two storage models: the column store (default for S/4HANA tables) is optimised for analytical queries and compression. The row store is suitable for transactional access to individual records. Monitor the memory distribution regularly: if the row store grows excessively, this may indicate incorrect table configurations. Use the HANA memory alerts (Alert 1–5) for proactive monitoring.
Table Partitioning
Table partitioning significantly improves performance for large tables. HANA supports hash, range and round-robin partitioning. For S/4HANA standard tables, SAP provides partitioning recommendations. Check partitioning especially for tables with more than 100 million records. However, incorrect partitioning can degrade performance – always test changes in non-production first.
Batch Job Optimisation
Batch jobs are often the biggest performance consumers in S/4HANA. Typical problems: sequential processing instead of parallelisation, missing selection limits, overlapping runtimes and unnecessary index access. Optimise batch jobs through parallelisation, efficient selections and scheduling outside peak business hours. Use job analysis in SM37 together with performance trace evaluation.
Setting Up Proactive Monitoring
Reacting rather than acting proactively is the wrong strategy for performance issues. Set up proactive monitoring: HANA alerts for memory, CPU and disk. SAP Solution Manager or Focused Run for end-to-end monitoring. Define baselines for normal performance values and automatically report deviations. Establish regular performance reviews (monthly) with the Basis team. Define clear KPIs: average dialog response time below 1 second, batch runtimes within defined windows and memory utilisation below 80%.
Conclusion
S/4HANA performance is not automatic. In-memory technology provides the foundation, but without systematic tuning and monitoring, potential remains unused and problems go undetected. Invest in expertise and tooling – the stability of your production system depends on it.
Related Articles
SAP Kernel Update & Patch Strategy
Systematically plan kernel updates and patches with risk mitigation.
Read more →S/4HANA Migration Checklist
12 points your Basis team must clarify before project start.
Read more →Need support with this topic?
We help you with implementation – from analysis to go-live.
Get in touch